A Trojan horse is a program that does something destructive or disruptive to a system while appearing to be benign. As an example, you could store the following script in an executable file named mkfs:

while true
do
echo 'Good Morning Mr. Jones. How are you? Ha Ha Ha.' > /dev/console
done

If you are running as Superuser when you run this command, it would continuously write a message to the console. If the programmer were malicious, it could do worse. The only thing missing in this plot is access permissions. A malicious user could implement this Trojan horse by changing Superuser’s PATH variable to include a publicly writable directory at the start of the PATH string. (The catch is that you need to be able to write to /etc/profile-where the PATH variable is set for root-and only root can do that.) Then you would need to put the bogus mkfs program file in that directory. Because the fraudulent version appears in a directory mentioned earlier than the real one in PATH, the shell would run it rather than the legitimate version. The next time Superuser tries to run mkfs, the fraudulent version would run.

Trojan horses that lie in wait for and take advantage of the misspellings that most people make are among the most insidious types. For example, you might type sl instead of ls. Because you do not regularly execute a utility named sl and you may not remember typing the command sl, it is more difficult to track down this type of Trojan horse than one that takes the name of a more familiar utility.

A good way to help prevent the execution of a Trojan horse is to make sure that your PATH variable does not contain a single colon (:) at the beginning or end of the PATH string or a period (.) or double colon (::) anywhere in the PATH string. This precaution ensures that you will not execute a file in the working directory by accident. To check for a possible Trojan horse, examine the filesystem periodically for files with setuid permission. The following command lists these files:

# find / -perm -4000 -exec ls -lh {} \; 2> /dev/null
-rws--x--x. 1 root root 30K Oct 5 12:10 /usr/sbin/userhelper
-r-s--x---. 1 root apache 11K Aug 21 07:15 /usr/sbin/suexec
-rws--x--x. 1 root root 1.9M Oct 4 21:38 /usr/bin/Xorg
-rws--x--x. 1 root root 15K Oct 5 08:28 /usr/bin/chsh
-rwsr-xr-x. 1 root root 23K Sep 14 05:14 /usr/bin/passwd
-rws--x--x. 1 root root 16K Oct 5 08:28 /usr/bin/chfn
---s--x--x. 2 root root 169K Aug 21 04:24 /usr/bin/sudoedit
-rwsr-sr-x. 1 root root 45K Aug 21 03:26 /usr/bin/crontab
---s--x--x. 2 root root 169K Aug 21 04:24 /usr/bin/sudo
-rwsr-xr-x. 1 root root 60K Sep 7 08:04 /usr/bin/gpasswd
-rwsr-xr-x. 1 root root 51K Sep 29 11:58 /usr/bin/at
...

This command uses find to locate all files that have their setuid bit set (mode 4000). The hyphen preceding the mode causes find to report on any file that has this bit set, regardless of how the other bits are set. The output sent to standard error is redirected to /dev/null so that it does not clutter the screen.

You can also set up a program, such as AIDE (Advanced Intrusion Detection Environment; part of the aide package), that will take a snapshot of the system and check it periodically. See sourceforge.net/projects/aide for more information.

Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition

Rescue mode is an environment you can use to fix a system that does not boot normally. To bring a system up in rescue mode, boot the system from the first installation CD, the Net Boot CD, or the install DVD. From the install DVD, select Rescue installed system from the Welcome menu (page 56). From the first installation CD and the Net Boot CD, enter the rescue (FEDORA) or boot rescue (RHEL) boot parameter. The boot process may take several minutes. The system then comes up in rescue mode.

In rescue mode, you can change or replace configuration files, check and repair partitions using fsck, rewrite boot information, and more. The rescue screen first asks if you want to set up the network interface. This interface is required if you want to copy files from other systems on the LAN or download files from the Internet. When you choose to set up the network interface, you need to decide whether to have DHCP automatically configure the network connection or to manually supply the IP address and netmask of the interface, as well as the IP addresses of the gateway and DNS server(s).

If the rescue setup finds an existing Linux installation, you can choose to mount it under /mnt/sysimage, optionally in readonly mode. With the existing installation mounted, once the system displays a shell prompt (similar to sh-3.2#), you can give the command chroot /mnt/sysimage to access the existing installation as it would be if you booted normally, with the existing installation’s root directory available as / (root). If you choose not to mount the existing installation, you are running a rescue system with standard tools mounted in standard locations (/bin, /usr/bin, and so on). Partitions from your local installation are available for fixing or mounting. When you exit from the rescue shell, the system reboots. Remove the CD or DVD if you want to boot from the hard drive.

Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition

The consolehelper utility can make it easier for someone who is logged in on the system console but not logged in as root to run system programs that normally can be run only by root. PAM, which authenticates users, can be set to trust all console users, to require user passwords (not the root password), or to require the root password before granting trust. The concept underlying consolehelper is that you may want to consider as trustworthy anyone who has access to the console. For example, Alex can log in on the console as himself and run halt without knowing the root password.

Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition

The su (substitute user) utility can create a shell or execute a program with the identity and permissions of a specified user. Follow su on the command line with the name of a user; if you are working with root privileges or if you know the user’s password, you take on the identity of that user. When you give an su command without an argument, su defaults to Superuser so that you take on the identity of root (you have to know the root password).

To ensure that you are using the system’s official version of su (and not one planted on your system by a malicious user), specify su’s absolute pathname (/bin/su) when you use it. (Of course, if someone has compromised your system enough that you are running a fake su command, you are in serious trouble anyway-but using an absolute pathname for su is still a good idea.)

When you give an su command to become Superuser, you spawn a new shell, which displays the # prompt. You return to your normal status (and your former shell and prompt) by terminating this shell: Press CONTROL-D or give an exit command. Giving an su command by itself changes your user and group IDs but makes minimal changes to your environment. You still have the same PATH you did when you logged in as yourself. When you run a utility that is normally run by root (the utilities in /sbin and /usr/sbin), you may need to specify an absolute pathname for the utility (such as /sbin/service). When you give the command su - (you can use -l or --login in place of the hyphen), you get a root login shell: It is as though you logged in as root. Not only are your user and group IDs the same as those of root, but your entire environment is that of root. The login shell executes the appropriate startup scripts before displaying a prompt, and your PATH is set to what it would be if you had logged in as root, typically including /sbin and /usr/sbin.

Use the id utility to display the changes in your user and group IDs and in the groups you are associated with. In the following example, the information that starts with context pertains to SELinux:

$ id
uid=500(alex) gid=500(alex) groups=500(alex) context=user_u:system_r:unconfined_t
$ su
Password:
# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys), ...

You can use su with the -c option to run a single command with root privileges, returning to your original shell when the command finishes executing. The following example first shows that a user is not permitted to kill a process. With the use of su -c and the root password, the user is permitted to kill (page 409) the process. The quotation marks are necessary because su -c takes its command in the form of a single argument.

$ kill -15 4982
-bash: kill: (4982) - Operation not permitted
$ su -c "kill -15 4982"
Password:
$

Superuser, PATH, and security
The fewer directories you keep in your PATH when you are working with root privileges, the less likely you will be to execute an untrusted program as root. If possible, keep only the default directories, along with /sbin and /usr/sbin, in root’s PATH. Never include the working directory (as . or : : anywhere in PATH, or : as the last element of PATH).

Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition

Much of what a system administrator does is work that ordinary users do not have permission to do. When performing one of these tasks, the system administrator logs in as root (or uses another method; see the list starting on page 406) to have systemwide powers that are beyond those of ordinary users: A user with root privileges is referred to as Superuser. The username is root by default. Superuser has the following powers and more:

• Some commands, such as those that add new users, partition hard drives, and change system configuration, can be executed only by root. Superuser can use certain tools, such as sudo, to give specific users permission to perform tasks that are normally reserved for Superuser.

• Read, write, and execute file access and directory access permissions do not affect root: Superuser can read from, write to, and execute all files, as well as examine and work in all directories.

• Some restrictions and safeguards that are built into some commands do not apply to root. For example, root can change any user’s password without knowing the old password.

When you are running with root (Superuser) privileges, the shell by convention displays a special prompt to remind you of your status. By default, this prompt is or ends with a pound sign (#).

When you are working on the computer, especially when you are working as the system administrator, perform any task while using the least privilege possible. When you can perform a task logged in as an ordinary user, do so. When you must be logged in as Superuser, do as much as you can as an ordinary user, log in or use su so you have root privileges, complete the part of the task that has to be done as Superuser, and revert to being an ordinary user as soon as you can. Because you are more likely to make a mistake when you are rushing, this concept becomes more important when you have less time to apply it.

You can gain or grant Superuser privileges in a number of ways:

1. When you bring the system up in single-user mode, you are Superuser.

2. Once the system is up and running in multiuser mode, you can log in as root. When you supply the proper password, you will be Superuser.

3. You can give an su (substitute user) command while you are logged in as yourself and, with the proper password, you will have Superuser privileges.

4. You can use sudo selectively to give users Superuser privileges for a limited amount of time on a per-user and per-command basis. The sudo utility is controlled by the /etc/sudoers file, which must be set up by root. Refer to the sudo man page for more information.

5. Any user can create a setuid (set user ID) file. Setuid programs run on behalf of the owner of the file and have all the access privileges that the owner has. While you are running as Superuser, you can change the permissions of a file owned by root to setuid. When an ordinary user executes a file that is owned by root and has setuid permissions, the program has full root privileges. In other words, the program can do anything root can do and that the program does or allows the user to do. The user’s privileges do not change. When the program finishes running, all user privileges revert to the way they were before the program started. Setuid programs that are owned by root are both extremely powerful and extremely dangerous to system security, which is why a system contains very few of them. Examples of setuid programs that are owned by root include passwd, at, and crontab. The following example shows two ways for Superuser to give a program setuid privileges:

# ls -l my*
-rwxr-xr-x 1 root other 24152 Apr 29 16:30 myprog
-rwxr-xr-x 1 root other 24152 Apr 29 16:31 myprog2
# chmod 4755 myprog
# chmod u+s myprog2
# ls -l my*
-rwsr-xr-x 1 root other 24152 Apr 29 16:30 myprog
-rwsr-xr-x 1 root other 24152 Apr 29 16:31 myprog2

The s in the owner execute position of the ls -l output (page 203) indicates that the file has setuid permission.

6. Some programs ask you for a password (either your password or the root password, depending on the particular command and the configuration of the system) when they start. When you provide the root password, the program runs with root privileges. When a program requests the root password when it starts, you stop running as the privileged user when you quit using the program. This setup keeps you from remaining logged in as Superuser when you do not need or intend to do so.

Some techniques limit the number of ways to become Superuser. For example, PAM controls the who, when, and how of logging in. The /etc/securetty file controls which terminals (ttys) a user can log in on as root. The /etc/security/access.conf file adds another dimension to login control (see the file for details).


root-owned setuid programs are extremely dangerous
Because root-owned setuid programs allow someone who does not know the root password to exercise the powers of Superuser, they are tempting targets for a malicious user. A system should have as few of these programs as possible. You can disable setuid programs at the filesystem level by mounting a filesystem with the nosuid option. You can also use SELinux to disable setuid programs.


Do not allow root access over the Internet
Prohibiting root logins using login over a network is the default policy of Fedora/RHEL and is implemented by the PAM securetty module. The /etc/security/access.conf file must contain the names of all users and terminals/workstations that you want a user to be able to log in on as root. Initially every line in access.conf is commented out.

You can, however, log in as root over a network using ssh. As shipped by Fedora/RHEL, ssh does not follow the instructions in securetty or access.conf. Also, in /etc/ssh/sshd_config, Fedora/RHEL sets PermitRootLogin to YES (it is set by default) to permit root to log in using ssh.

Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition

???????????????????????????????????????????????? ???????????????????????????????? Wireless ????? Backtrack ? ????????????????????????????????????????? ??????? ??????????????????????????????????????????????????  Command ??????? Hack WEB Wireless password ?????????????????????????? ??????????????????????????????????? ??????????????????????????? ?????????????????????????

You already know? that if you want to lock down your Wi-Fi network, you should opt for WPA encryption because WEP is easy to crack. But did you know how easy? Take a look.

Today we’re going to run down, step-by-step, how to crack a Wi-Fi network with WEP security turned on. But first, a word: Knowledge is power, but power doesn’t mean you should be a jerk, or do anything illegal. Knowing how to pick a lock doesn’t make you a thief. Consider this post educational, or a proof-of-concept intellectual exercise.

Dozens of tutorials on how to crack WEP are already all over the internet using this method. Seriously—Google it. This ain’t what you’d call “ news.” But what is surprising is that someone like me, with minimal networking experience, can get this done with free software and a cheap Wi-Fi adapter. Here’s how it goes.

Read Full Article Here…

?????????????? ????? ?Hacking, How To, Linux Tagged: External Articles, Hack Wireless, Hacks, LifeHacker, Linux, Linux Live CD, Live CD, Network Security, Network Tools, Security