So, here we are in another installment of my Linux Security Series. To catch up, read the intro post, and check out the other articles.
So, as you should know by now, you should never login as root. You should login as a regular user, and then use sudo to run commands, or su to root.
The real benefit of using su/do is disallowing root logins. Here is a little exert of the logs of a server I run on the internets:
Oct 14 20:31:59 Tomahawk sshd[82597]: error: PAM: authentication error for root from 188-193-191-72-dynip.superkabel.de
Oct 14 20:32:33 Tomahawk sshd[82600]: error: PAM: authentication error for root from s01060000c5ca5b32.su.shawcable.net
Oct 14 20:33:19 Tomahawk sshd[82616]: error: PAM: authentication error for root from 58.26.82.163
Oct 14 20:33:54 Tomahawk sshd[82619]: error: PAM: authentication error for root from mail.act.by
Oct 14 20:34:34 Tomahawk sshd[82622]: error: PAM: authentication error for root from 115.168.35.219
Oct 14 20:35:20 Tomahawk sshd[82628]: error: PAM: authentication error for root from p5098cd41.dip0.t-ipconnect.de
Oct 14 20:35:54 Tomahawk sshd[82631]: error: PAM: authentication error for root from 75-148-164-97-houston.hfc.comcastbusiness.net
Oct 14 20:36:34 Tomahawk sshd[82634]: error: PAM: authentication error for root from mulligan.softspike.org
Oct 14 20:37:23 Tomahawk sshd[82639]: error: PAM: authentication error for root from 69.red-80-33-156.staticip.rima-tde.net
Oct 14 20:38:04 Tomahawk sshd[82642]: error: PAM: authentication error for root from 119.62.128.19
Oct 14 20:38:39 Tomahawk sshd[82645]: error: PAM: authentication error for root from 221.7.58.36
Oct 14 20:39:22 Tomahawk sshd[82648]: error: PAM: authentication error for root from 122.224.128.197
Oct 14 20:40:06 Tomahawk sshd[82654]: error: PAM: authentication error for root from 123.147.144.45
Oct 14 20:40:48 Tomahawk sshd[82657]: error: PAM: authentication error for root from 202.97.0.76
Oct 14 20:41:27 Tomahawk sshd[82660]: error: PAM: authentication error for root from 220.194.66.56
Oct 14 20:41:48 Tomahawk sshd[82663]: Invalid user wawa from 84.1.106.142
Oct 14 20:41:49 Tomahawk sshd[82665]: Invalid user wawa from 84.1.106.142
Oct 14 20:41:50 Tomahawk sshd[82667]: Invalid user wawa from 84.1.106.142
Oct 14 20:41:52 Tomahawk sshd[82669]: Invalid user wawa from 84.1.106.142
Oct 14 20:41:53 Tomahawk sshd[82671]: Invalid user mail from 84.1.106.142
Oct 14 20:41:54 Tomahawk sshd[82673]: Invalid user mail from 84.1.106.142
Oct 14 20:41:56 Tomahawk sshd[82675]: Invalid user mail from 84.1.106.142
Oct 14 20:41:57 Tomahawk sshd[82677]: Invalid user mail from 84.1.106.142
Oct 14 20:41:58 Tomahawk sshd[82679]: Invalid user local from 84.1.106.142
Oct 14 20:42:00 Tomahawk sshd[82681]: Invalid user local from 84.1.106.142
Oct 14 20:42:01 Tomahawk sshd[82683]: Invalid user local from 84.1.106.142
Oct 14 20:42:02 Tomahawk sshd[82685]: Invalid user local from 84.1.106.142
Oct 14 20:42:05 Tomahawk sshd[82687]: error: PAM: authentication error for root from 211.143.240.6
Lots of failed login attempts for root, as well as some other common accounts (mail and local, but I've also seen lots for admin, user, test, webmaster, etc.) A friend checked his server, and saw tons of services, as well as common first and last names. These are all attempts to break into your system. Most are simply bots, that try and connect with SSH using a massive list of common usernames and passwords. If you look at the times, many are with a few seconds of each other. Almost any box on the internet with ssh running on port 22 is being bombarded with these every day.
Now, if you have root login over SSH disabled, and you don't have a common username, you're blocking the vast majority of these attempts. Great you think, now how do I do that?
Well, you could lookup how to do it on your OS (if this dosen't), but here's how to disable root logins over SSH on many Linux/Unix distros.
1) Before you continue, be sure that you have a non-root account that can login with, and either use sudo or su to become root. Without this, you will be locked out of your system. It's not too bad if you're sitting at your desktop, but it's a real pain if it's a system locked up in a datacenter somewhere. I've driven to the datacenter at 7PM before (to fix a firewall I screwed up, luckily it was only a 30 min drive), and it's not the most fun way to spend an afternoon.
Much of this process could be distribution dependent, so check your distro documentation. The useradd command is available on most (all?) linux/unix systems. You can also use any GUI tools your particular linux distribution uses. You may also want to add your user to the wheel group, or an admin or other group if your distribution has it. More details on that later.
2) Find your sshd_config file. It's usually in /etc/ssh/ or /usr/local/etc/ssh folders. If you're having trouble, try doing locate sshd_config
3) Edit the file with your favorite text editor. I'd recommend nano if you're not familiar with one. nano /etc/ssh/ssh_config
4) Search the file for "PermitRootLogin" (Ctrl+W on nano). If it's there, be sure it's not commented out (remove the leading '#' if present), and put "no" there. If you can't find it, add it in somewhere. Put it at the bottom of you don't know where else to put it.
5) Close and save the file. It's Ctrl+X on nano, then Y for saving, then press enter to save it as the same filename.
6) Restart OpenSSH (the SSH Server). Again, this is somewhat OS dependent. On Redhat derrived OS's (Redhat, Fedora, CentOS, Adios, etc.), you can simply do service sshd restart. Other linuxes, you'll probably do /etc/init.d/ssh restart. On Arch linux and FreeBSD, it's /etc/rc.d/sshd restart.
Now, try to login as "root" over ssh. It shouldn't allow it, even with the correct password.
Some other ideas for securing your system:
1) Only allow specific users to use su.
Richard Stallman apparently has no idea about being a sysadmin (read the bottom). In FreeBSD, for a user to be able so su to root, he must be a member of the wheel group. Linux does not have that restriction. The easiest way to do this is to change the permissions for the /bin/su command to only let members of wheel or some other group execute it.
chgrp wheel /bin/su
chmod 550 /bin/su
2) Use sudo for any users that need to run only a few things as root. Check out my other post on su and sudo. It's very robust, and there are lots of guides on how to use it. The idea here is very few users need to have full root access to a system. If you prevent all other users from becoming root, then you don't need to worry as much. On a well configured system, you should be able to give out your root password and not have it affect security at all (assuming your hardware is secured).
3) Secure the terminal. Physical security is a must for any security on a system. But, without absolute physical security (if there even is such a thing), you should take some steps to make sure your system is a little more secure from someone sitting at the terminal. I'll go into this more in a later post.
Wednesday, October 14, 2009
Saturday, October 10, 2009
Linux Security Series - Su and Sudo
So, if you read my Intro post, you'll know that this is tutorial for the novice linux user, not experts. Also, this article has been in the works for a long time, and I'm finally getting around to finishing/posting it.
This all started with my roommate. He recently got the root password to a linux server to use it. As in, the person sent him the root password, and didn't make him a user account or anything. I've been really into linux/unix since about 2003, and I quickly learned that logging in as root is a bad idea. If you mistype one thing, you can quickly hose your system. Once, I was using the root account (in a way I'll explain later), and I accidentally executed a rm -rf /*. This will delete everything on your computer, even if it's read only. About a second later, I realized what I had done (I meant to do ./*), and hit Ctrl+C to stop it. I did an ls to see what the files looked like, and I got bash: ls: command not found! Oh crap, just deleted lots of important files. Turns out pwd had been deleted also. Anyway, I had to reinstall my OS, and luckily my important files didn't get deleted before I stopped it. And THAT is why you don't want to be root unless you have to!
So, if you don't log in as root, then how do you edit system files/settings, etc? You use the nifty commands su and sudo. Now, If you're a linux/unix user, then you're probably aware of what these commands do, but for those of you who don't: su is short for "substitute use" or "switch user". It allows you to become another user, usually root. When you run su user, and you type in the password of the user you're trying to become. Then BAM! (imagine Emeril Lagasse there), you've got a shell, almost exactly like that user would if they logged in. If you don't specify a user, root is assumed. So, you login as a normal user, do your work, then when you have to do something that requires root privileges, you do su for that part.
Now, what's this sudo I keep mentioning? Well, it's short for (technically, I guess it's not short for, but the same length as) "su do". It's like su, except it is used for running a single command. This makes it much more convenient when you need to run a single command (like to edit a config file), but sudo is much more that that! The biggest advantage of sudo over su, is the logging it provides, as well as the security options it gives a sysadmin.
With sudo, you can specify who can run what commands on which computers. You can even specify what users these commands are run as. You can also specify if a user needs to enter their password or not, and if so, how long before they need to enter it again (if you're running multiple commands at once). Any time someone runs sudo, it gets logged. Who ran the command, what terminal they were on, what command they ran, and what time it was. For all the details check out the sudo site, linked above.
In a later article, I'll detail why you should use sudo, and how to lock down a linux system in regards to using sudo.
This all started with my roommate. He recently got the root password to a linux server to use it. As in, the person sent him the root password, and didn't make him a user account or anything. I've been really into linux/unix since about 2003, and I quickly learned that logging in as root is a bad idea. If you mistype one thing, you can quickly hose your system. Once, I was using the root account (in a way I'll explain later), and I accidentally executed a rm -rf /*. This will delete everything on your computer, even if it's read only. About a second later, I realized what I had done (I meant to do ./*), and hit Ctrl+C to stop it. I did an ls to see what the files looked like, and I got bash: ls: command not found! Oh crap, just deleted lots of important files. Turns out pwd had been deleted also. Anyway, I had to reinstall my OS, and luckily my important files didn't get deleted before I stopped it. And THAT is why you don't want to be root unless you have to!
So, if you don't log in as root, then how do you edit system files/settings, etc? You use the nifty commands su and sudo. Now, If you're a linux/unix user, then you're probably aware of what these commands do, but for those of you who don't: su is short for "substitute use" or "switch user". It allows you to become another user, usually root. When you run su user, and you type in the password of the user you're trying to become. Then BAM! (imagine Emeril Lagasse there), you've got a shell, almost exactly like that user would if they logged in. If you don't specify a user, root is assumed. So, you login as a normal user, do your work, then when you have to do something that requires root privileges, you do su for that part.
Now, what's this sudo I keep mentioning? Well, it's short for (technically, I guess it's not short for, but the same length as) "su do". It's like su, except it is used for running a single command. This makes it much more convenient when you need to run a single command (like to edit a config file), but sudo is much more that that! The biggest advantage of sudo over su, is the logging it provides, as well as the security options it gives a sysadmin.
With sudo, you can specify who can run what commands on which computers. You can even specify what users these commands are run as. You can also specify if a user needs to enter their password or not, and if so, how long before they need to enter it again (if you're running multiple commands at once). Any time someone runs sudo, it gets logged. Who ran the command, what terminal they were on, what command they ran, and what time it was. For all the details check out the sudo site, linked above.
In a later article, I'll detail why you should use sudo, and how to lock down a linux system in regards to using sudo.
IPTables "Stealth" Scan Detection
Many of you probably know about port scanning. It's a very simple process, where essentially you attempt to to make a connection on several ports of several machines. If the port is closed, a reset is returned. If the port is open, a SYN+ACK is returned.
Now, there are some other types of scans, such as a FIN scan, Xmas Tree scan, and a NULL scan. These basically work on the same principals of a SYN (normal) scan, but using some different TCP flags (ones that should never be seen in valid TCP connections).
If you'd like, read up on the different types of scans here, which is also a good site to determine what type of reply you want to give the scanning host. It also shows how to perform the scans using NMap.
So, most of the time, you want to just drop invalid packets, since the easiest way to deal with them is not to. However, you may wish to use REJECT here, since what the host does and does not return is part of the data collected. Being able to decide what to return could give you an edge over an attacker. If you return tcp-resets, then you can make an attacker (or more likely a bot) think that all the ports on the host are closed. Different operating systems also respond differently to the various stealth scans, so be mindful of that as well.
I wrote some simple firewall rules to detect, log, and block (either with a tcp-reset or just dropping the packet entirly. This script was made to run on top of an existng firewall.
## IPTables rules for detecting and blocking several different scans
## By Drew Tingen GlimpseIntoEntropy.Blogspot.com
## NOTE: Please understand the use of REJECT/DROP
## NOTE2: You may want to mirror the FORWARD rules to INPUT
## Note on Rule Order - since these are Inserts (designed to be easily plugged into
## an existing iptables config), the packet actions are above the logging action.
## If you put these at the top of a config, and change the -I to -A, reverse the order
## of the rules for logging to work properly
## TCP Null Scan
### Action for packets
### use REJECT option to make port look closed. Use drop for open/stealth
iptables -I FORWARD -p tcp --tcp-flags ALL NONE -j REJECT --reject-with tcp-reset
#iptables -I FORWARD -p tcp --tcp-flags ALL NONE -j DROP
### Detect and log
iptables -I FORWARD -p tcp --tcp-flags ALL NONE -j LOG --log-prefix "TCP Null Scan"
## TCP Fin Scan
### Action for packets
iptables -I FORWARD -p tcp --tcp-flags FIN,SYN FIN -m state --state NEW,INVALID -j REJECT --reject-with tcp-reset
#iptables -I FORWARD -p tcp --tcp-flags FIN,SYN FIN -m state --state NEW,INVALID -j DROP
### Detect and Log
iptables -I FORWARD -p tcp --tcp-flags FIN,SYN FIN -m state --state NEW,INVALID -j LOG --log-prefix "TCP FIN Scan"
## TCP Xmas Tree Scan
### Action for packets
iptables -I FORWARD -p tcp --tcp-flags ALL URG,PSH,FIN -j REJECT --reject-with tcp-reset
#iptables -I FORWARD -p tcp --tcp-flags ALL URG,PSH,FIN -j DROP
### Detect and Log
iptalbes -I FORWARD -p tcp --tcp-flags ALL URG,PSH,FIN -j LOG --log-prefix "Xmas Tree Scan"
Also - if someone wants these rules for OpenBSD's pf, those can be easily created.
Now, there are some other types of scans, such as a FIN scan, Xmas Tree scan, and a NULL scan. These basically work on the same principals of a SYN (normal) scan, but using some different TCP flags (ones that should never be seen in valid TCP connections).
If you'd like, read up on the different types of scans here, which is also a good site to determine what type of reply you want to give the scanning host. It also shows how to perform the scans using NMap.
So, most of the time, you want to just drop invalid packets, since the easiest way to deal with them is not to. However, you may wish to use REJECT here, since what the host does and does not return is part of the data collected. Being able to decide what to return could give you an edge over an attacker. If you return tcp-resets, then you can make an attacker (or more likely a bot) think that all the ports on the host are closed. Different operating systems also respond differently to the various stealth scans, so be mindful of that as well.
I wrote some simple firewall rules to detect, log, and block (either with a tcp-reset or just dropping the packet entirly. This script was made to run on top of an existng firewall.
## IPTables rules for detecting and blocking several different scans
## By Drew Tingen GlimpseIntoEntropy.Blogspot.com
## NOTE: Please understand the use of REJECT/DROP
## NOTE2: You may want to mirror the FORWARD rules to INPUT
## Note on Rule Order - since these are Inserts (designed to be easily plugged into
## an existing iptables config), the packet actions are above the logging action.
## If you put these at the top of a config, and change the -I to -A, reverse the order
## of the rules for logging to work properly
## TCP Null Scan
### Action for packets
### use REJECT option to make port look closed. Use drop for open/stealth
iptables -I FORWARD -p tcp --tcp-flags ALL NONE -j REJECT --reject-with tcp-reset
#iptables -I FORWARD -p tcp --tcp-flags ALL NONE -j DROP
### Detect and log
iptables -I FORWARD -p tcp --tcp-flags ALL NONE -j LOG --log-prefix "TCP Null Scan"
## TCP Fin Scan
### Action for packets
iptables -I FORWARD -p tcp --tcp-flags FIN,SYN FIN -m state --state NEW,INVALID -j REJECT --reject-with tcp-reset
#iptables -I FORWARD -p tcp --tcp-flags FIN,SYN FIN -m state --state NEW,INVALID -j DROP
### Detect and Log
iptables -I FORWARD -p tcp --tcp-flags FIN,SYN FIN -m state --state NEW,INVALID -j LOG --log-prefix "TCP FIN Scan"
## TCP Xmas Tree Scan
### Action for packets
iptables -I FORWARD -p tcp --tcp-flags ALL URG,PSH,FIN -j REJECT --reject-with tcp-reset
#iptables -I FORWARD -p tcp --tcp-flags ALL URG,PSH,FIN -j DROP
### Detect and Log
iptalbes -I FORWARD -p tcp --tcp-flags ALL URG,PSH,FIN -j LOG --log-prefix "Xmas Tree Scan"
Also - if someone wants these rules for OpenBSD's pf, those can be easily created.
Subscribe to:
Posts (Atom)