| Linux security tips #1 |
Linux Security: Physical SecurityWe first start with LILO(the LInuxLOader)... If an attacker has physical access to this machine, and particularly to the keyboard, she/he could get superuser access through the LInuxLOader, or LILO, command line. We will look at other ways to prevent this later, but one easy way is to password-protect the LILO prompt. If LILO is password-protected, any user can reboot the machine normally, but only users with the password can pass arguments to the LILO prompt, such as 'LILO: linux init=/bin/sh'; which would take the attacker into an emergency shell, and from there he/she could do whatever they pleased. Note that this option can interfere dual-booting with a second operating system, since dual booting often requires that type an O/S name to boot one of the two operating systems. If this machine sits in a general purpose lab and dual boots, you probably shouldn't choose this option. Otherwise, this is strongly recommended for general use workstations and servers which are not locked away in their own room. !!!Also note that your system will not be able to boot into ANY OS without someone who knows the password standing by to enter it!!! How we add the password is quite simple... Open your /etc/lilo.conf and add this line, and it's prolly best to put this at the top. #My LILO password Done, lilo is now password protected... Disabling ctrlaltdel: ugh these keys remind me of windows.... In default configuration, while in console mode (non-graphical), any user at the keyboard can reboot the machine by pressing CTRL-ALT-DELETE. This reboot should not damage the filesystem, as it shuts the machine down cleanly, writing out all pending data in the disk cache to disk first. We can disable this functionality, but unless the power line, switch and case of the machine can be physically protected, this is wholly unnecessary. If these can be reached without sounding alarms, the attacker can simply momentarily disrupt power to the machine. In this case, given the fact that the attacker _can_ reboot the machine, would you prefer that she/he do it in a way potentially damages the filesystem? Think carefully here, as maintaining the integrity of the machine's filesystem may be secondary to the goal of keeping an attacker off, in which case it is better to answer yes here, as having to repair/ignore the damage and wait for filesystem checks may slow the attacker down. How do we do this ? Simple... Open up /etc/inittab You'll see a line that looks like this ca::ctrlaltdel:/sbin/shutdown -t3 -r nowadd -a in the line after shutdown, so the line should now look like so... ca::ctrlaltdel:/sbin/shutdown -a -t3 -r nowa Then run 'telinit q' to refresh -a tells shutdown to look for/in /etc/shutdown.allow if there's not one it still acts normal but only root may shut the system down with ctrlaltdel. Whether you want to create a /etc/shutdown.allow is up to you to. ROOT LOGIN: J00 mean we can stop this ? Yes we can stop root login. Besides, you shouldn't be an as root unless you have to! And even then commands that require root privledges should be done through su. I don't even suggest logging in as root through su, rather running su -c. -c == command. Example: I tell su -c what command I want to run, hit enter, it asks me for the root password, runs the commands, then ends the su sessions. Anyway, we move on to stopping root login! Open up /etc/securetty, it'll look like so... # /etc/securetty These are the tty(s) that root is allowed to login in on. I don't want root to be allowed to login period, so what do I do ? Remove them. Now my /etc/securitty looks like this. # /etc/securetty And I 'telinit q' to refresh, now lets try logging in as root now. Kernel 2.3.99-pre3 on an i686 / tty3Done, root is not allowed login.
|
Legitcode.com : All Rights Reserved