You are not logged in.
Hello everyone,
Recently, my ssh server was hacked into with a brute force attack and then my whole system was compromised by someone using the wunderbar emporium hack. Luckily I caught them in the act and installed a new, preferable, operating system (previously it was Debian). Obviously I do not want them to hack into my server again so I am taking some security precautions.
1. Ridiculously complicated passwords
2. Disabled root login
3. Used iptables
I have never used iptables before, and currently I am only using the rules:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force "
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
Are these rules decent (I did a small test by trying to log in three times in a row and it seemed to work)?
How can I make these rules be set at boot and taken down at shutdown?
Also, is my best option for preventing against kernel exploits grsecurity?
Are these methods secure, or is there more I can do?
Thank you
Offline
1. Ridiculously complicated passwords
2. Disabled root login
3. Used iptables
All good ideas. I'd suggest changing SSH to another port if possible (ie, 2222 or 53956 etc. Any random port that isn't used for anything else.)
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force "
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROPAre these rules decent (I did a small test by trying to log in three times in a row and it seemed to work)?
You don't want the "ACCEPT" as the first rule. Have a look at this article: http://www.debian-administration.org/articles/187
How can I make these rules be set at boot and taken down at shutdown?
Since you've reinstalled with Debian... This isn't an Arch question. Better to ask the Debian guys or howtos.
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline
Since you've reinstalled with Debian...
No he didn't:
...installed a new, preferable, operating system (previously it was Debian).
Offline
You should first determine what the real problem was that got you hacked. If I understand correctly the wunderbar emporium exploit is a local privilege escalation, so that would mean your SSH got hacked with regular user access and then the hacker gained root access locally, instead of logging in as root?
Either way, the problem is with SSH. If it's a vulnerability in the software itself then there's nothing you could have done (except for keeping your system up to date, but I assume you did). If it wasn't, then there's a configuration problem on your part. In addition to what fukawi said, I'd also force the use of keys. You'd have to carry them with you wherever you go, but without a key (and a proper passphrase attached to them!) it's nearly impossible to hack your way in - except for SSH exploits themselves of course. I think it's also possible to have SSH chroot users upon login, but for your own user that might not be convenient.
Also - I assume you weren't using iptables before (ok you weren't), if that's the case, you need to keep in mind it could well have been another service that was exposed and hacked.
Got Leenucks? :: Arch: Power in simplicity :: Get Counted! Registered Linux User #392717 :: Blog thingy
Offline
All good ideas. I'd suggest changing SSH to another port if possible (ie, 2222 or 53956 etc. Any random port that isn't used for anything else.)
I want to second that. This is simple and does not provide any more real security, as anyone who realy wants to hack exactly your server, can do a port scan on all ports. BUT it's a great mesure to just slip through the net of ip-range scanners with port lists.
Offline
+1 for SSH keys. Passwords are always potentially hackable, no matter how ridiculously complicated they are.
Offline
At least the good thing about disabling the root account is that the hacker would need to know a user on the system that has ssh access in the first place before even attempting a brute force attack.
Offline
fail2ban and a complicated password worked for me in the past. if they guess the password in 3 tries every 10 minutes within a lifetime, they deserve to have access
i dont like rsa keys due to the complexity of having to carry them around. i only use them to connect between my own boxes.
Offline
A different port will reduce the number of times a script kiddie tried to attack your server. I once face a hacker who tried to hack my server with different ip address everytime. I just change the port number to some well known ports and after that there was very few attacks .. :-)
Offline
+1 on the SSH port number. It's not so much about "security through obscurity" as it is about drastically reducing the sheer number of connection attempts from China and all over the world. My server was filled with logs from connection attempts 24/7 until I changed the port number.
Offline
I have an "sshusers" group which contains the only users who are allowed to log in by ssh, set in my sshd_config. "AllowGroup sshusers" iirc.
[git] | [AURpkgs] | [arch-games]
Offline
Similarly, you can use AllowUser (I'm the only one using SSH on the boxes I own/maintain, so it's pretty easy).
Got Leenucks? :: Arch: Power in simplicity :: Get Counted! Registered Linux User #392717 :: Blog thingy
Offline
+1 for SSH keys. Passwords are always potentially hackable, no matter how ridiculously complicated they are.
By SSH keys you mean RSA authentication right? That sounds like it would greatly increase my security.
You should first determine what the real problem was that got you hacked. If I understand correctly the wunderbar emporium exploit is a local privilege escalation, so that would mean your SSH got hacked with regular user access and then the hacker gained root access locally, instead of logging in as root?
I am fairly certain that it was due to my having improperly installed a MySQL database. Instead of letting the MySQL installation handle adding the mysql user, I added it myself and forgot that people would be able to log in to the MySQL user's account via SSH. There was a password, but it was fairly simple, because I had forgotten about SSH access to that account.
Looking through the logs I saw that the hacker logged in as the mysql user, downloaded the wunderbar emporium files, built them, and then became root. I wasn't able to see what they had done after that.
I was under the impression that installing grsecurity would prevent the wunderbar emporium exploit, as well as others. Is this true?
Also,
All good ideas. I'd suggest changing SSH to another port if possible (ie, 2222 or 53956 etc. Any random port that isn't used for anything else.)
Last night I tried putting my SSH server up for a short period of time, and within minutes of it being up there were already hacking attempts made to my server. Then I changed the port to something else, and they all stopped, so I will definitely do this.
So, for my revised security scheme:
1. Disable root access.
2. Very complicated passwords.
3. Change port to something obscure.
4. RSA keys.
5. IPtables (I will actually learn how to use it this time)
6. Possibly grsecurity.
Can anyone think of anything else?
Last edited by merrill541 (2009-11-24 17:52:06)
Offline
Grsecurity would allow you more fine-grained control, yes. It is rather advanced though (like AppArmor for SuSE and SE Linux), so I would first get a hang of the basics of security (correct permissions, limiting users to what they're supposed to be able to do, firewalling your system, etc.). If you really want something like grsecurity, look at it in a later stadium, and keep in mind you need to build a new kernel for it.
You should know e.g. a MySQL user shouldn't have its own shell. That way, if a hacker compromises MySQL, he can mess with your database but shouldn't be able to do anything outside the database (at least that's my understanding). If you had it set up that way, the damage would have been limited.
On my VPS, mysql's user has an /etc/passwd entry like this:
mysql:x:89:89::/var/lib/mysql:/bin/false
Got Leenucks? :: Arch: Power in simplicity :: Get Counted! Registered Linux User #392717 :: Blog thingy
Offline
check this tutorial on the wiki: http://wiki.archlinux.org/index.php/Sim … wall_HOWTO
I wrote the final script in which the iptables block the bruteforcing attacks (based on ip and number of connections/time) and you can test it easily.
And make sure you have the sshd_config file as you want..
If people do not believe that mathematics is simple, it is only because they do not realize how complicated life is.
Simplicity is the ultimate sophistication.
Offline
wunderbar emporium exploit..mmm.. I thought the Archlinux kernel already patch this? or the kernel hackers has released a patch?
Offline
Well, the wunderbar emporium exploit was successfully used on my debian server. I was wondering though, why isn't the linux kernel basecode patched for protection against that exploit? Also, does the archlinux kernel have a patch for this exploit?
Offline
well you can try to use a VM to test arch..
If people do not believe that mathematics is simple, it is only because they do not realize how complicated life is.
Simplicity is the ultimate sophistication.
Offline
+1 for SSH keys. Passwords are always potentially hackable, no matter how ridiculously complicated they are.
Not in my opinion.... Strong passwords are pretty much unbreakable. A key is basically a very complicated password if you think about it. It's a string consisting of some number of bits made to be as random as possible, same as a strong password.
Use a password with 9+ characters taken from upper and lower case letters, numbers, and special characters that is not based on a dictionary word, and no is going to crack it with a brute force attack, there are just too many possibilities.
Combining a strong password with a mechanism to block a username or ip address after some number of failed attempts will stop brute force and dictionary attacks dead in their tracks.
Also don't use common usernames such as your first name. When someone wants to hack in, they need to guess a password AND a username to go along with it. One of the reasons people try to hack the root account so often is not just that it has root priveleges, its also a username that exists on most every linux system.
I administer a fairly large cluster running linux and monitor log in attempts. I get a huge number of invalid attempts from random ip addresses. Most are against the root username, but then they try basically every first name in the english language as well as most system names for daemons and things like that.
To avoid brute force and dictionary attacks I run a password cracker periodically on my own users, if it can crack their password in a few minutes, they need to change it. I also use pam_abl which blocks usernames and ip addresses after 5 failed login attempts.
Offline
@jowilkin
it will be harder to *break/hack* it anyway with rsa key + password. no matter what.
in the end, the iptables will block any attempt to do bruteforces (you can set it by ip or anything else) - just make sure it does.
Last edited by quarkup (2009-11-25 01:15:07)
If people do not believe that mathematics is simple, it is only because they do not realize how complicated life is.
Simplicity is the ultimate sophistication.
Offline
Yes it will be harder, but if all harder means is 75 bits of entropy in a strong password versus 128 bits of entropy in a key, well....thats equivalent to saying it will take 2 times the life of the universe to break the key instead of 1 times the life of the universe to guess the password. Not a meaningful version of "harder". (those numbers are made up, but in the right general ballpark).
Bottom line is, its very easy to prevent someone from hacking in by guessing your password, VERY easy (just enforce good password practices and use fail2ban, denyhosts, pam_abl, etc. to block repeated failed logins). The weakness is likely to be somewhere else in your security scheme. Talking to other cluster admins who have had breakins (I've never had one), the problem was usually a key logger installed on a Windows box of a user who was logging into the cluster from that Windows box.
Last edited by jowilkin (2009-11-25 01:29:02)
Offline
Well, the wunderbar emporium exploit was successfully used on my debian server. I was wondering though, why isn't the linux kernel basecode patched for protection against that exploit? Also, does the archlinux kernel have a patch for this exploit?
Hasn't been working on arch in ages (even back then would only be working if you used pulseaudio -- which is what it ran off iirc).
Offline
merrill541 wrote:Well, the wunderbar emporium exploit was successfully used on my debian server. I was wondering though, why isn't the linux kernel basecode patched for protection against that exploit? Also, does the archlinux kernel have a patch for this exploit?
Hasn't been working on arch in ages (even back then would only be working if you used pulseaudio -- which is what it ran off iirc).
That is good to know. But why isn't the linux kernel base code modified for all distributions. Doesn't really make any sense not to do it.
Also, I read up on how to use iptables and here is the output from iptables-save:
Generated by iptables-save v1.4.5 on Tue Nov 24 21:23:36 2009
*filter
:INPUT ACCEPT [1377:109769]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [4828:1165337]
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8764 -m state --state NEW -m recent --set --name DEFAULT --rsource
-A INPUT -p tcp -m tcp --dport 8764 -m state --state NEW -m recent --update --seconds 60 --hitcount 3 --name DEFAULT --rsource -j DROP
-A INPUT -p tcp -m tcp --dport 8764 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 21 -j ACCEPT
-A INPUT -j DROP
COMMIT
# Completed on Tue Nov 24 21:23:36 2009
Would this be sufficient as a firewall? 8764 is the port where I would have the ssh server.
Offline
Any reason to accept all input 1377-on?
They'res a pretty good writeup on iptables firewalls on the arch wiki that I use often on my boxes..:
Offline
I definitely didn't set that. That is not listed in my rules with iptables -L, I get:
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
tcp -- anywhere anywhere tcp dpt:7321 state NEW recent: SET name: DEFAULT side: source
DROP tcp -- anywhere anywhere tcp dpt:7321 state NEW recent: UPDATE seconds: 60 hit_count: 3 name: DEFAULT side: source
ACCEPT tcp -- anywhere anywhere tcp dpt:7321
ACCEPT tcp -- anywhere anywhere tcp dpt:www
ACCEPT tcp -- anywhere anywhere tcp dpt:ftp
DROP all -- anywhere anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Yes I did read that article. Since I was only interested in blocking brute force ssh attacks, I did not use the script suggested in the article when I could do it with iptables.
Last edited by merrill541 (2009-11-25 02:57:23)
Offline