Possible Intrusion Attempt

mcupples · 04-23-2007, 01:53 PM

Hey guys,

I have a problem that I'm not too certain about. I've googled this and come up with several different paranoid theories. I've been told that I SHOULD care about this but I'm not sure how to go about it. I'm under the assumption that iptables can block a single IP or a range of them but I was told by some people to not mess with iptables unless you know what you're doing. I was hoping I could run some commands by you guys so you could tell me if I'm going to be shooting myself in the foot by running these.

To begin with, however, here are the logs I'm worried about:

Code:

Apr 22 06:03:13 db2 sshd(pam_unix)[26039]: check pass; user unknown
Apr 22 06:03:13 db2 sshd(pam_unix)[26039]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=200.91.87.212
Apr 22 06:03:16 db2 sshd(pam_unix)[26041]: check pass; user unknown
Apr 22 06:03:16 db2 sshd(pam_unix)[26041]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=200.91.87.212
Apr 22 06:03:18 db2 sshd(pam_unix)[26043]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=200.91.87.212  user=news
Apr 22 06:03:21 db2 sshd(pam_unix)[26045]: check pass; user unknown
Apr 22 06:03:21 db2 sshd(pam_unix)[26045]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=200.91.87.212
Apr 22 06:03:24 db2 sshd(pam_unix)[26050]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=200.91.87.212  user=games
Apr 22 06:03:28 db2 sshd(pam_unix)[26053]: check pass; user unknown
Apr 22 06:03:28 db2 sshd(pam_unix)[26053]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=200.91.87.212
Apr 22 06:03:31 db2 sshd(pam_unix)[26057]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=200.91.87.212  user=mail
Apr 22 06:03:33 db2 sshd(pam_unix)[26059]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=200.91.87.212  user=adm
Apr 22 06:03:36 db2 sshd(pam_unix)[26061]: check pass; user unknown

This is just a snippet, mind you. There are quite a few more attempts in the logs and I stopped researching around the 13th of April. If I should research to determine when they started, let me know - but I believe this enough information.

I'm going to go ahead and check out the man pages for iptables and come up with a command which I will post shortly. I just wanted to get this post up asap because I'm starting to get as paranoid as the people I've found on google.

Thanks,
Matt

mcupples · 04-23-2007, 02:08 PM

Okay this is it. I'm going to enter this command as root into my ssh connection. I believe this will drop all packets coming from that specific ip. After that I'll just need to keep an eye on the logs to ensure he's not using a different ip.

Code:

iptables -I INPUT -s 200.91.87.212 -j DROP

Right?

Hangdog42 · 04-23-2007, 03:00 PM

Be sure to have a read through this sticky thread for more ideas on how to handle this. Dictionary attacks against an sshd server are pretty much a daily occurrence, so blocking one IP address isn't going to do much. At a bare minimum, you should make sure SSH2 is the only allowed protocol, disallow root access via ssh, and seriously consider locking down the users with the AllowUsers directive in your sshd_config file. Of course, passwords for legitimate accounts must be strong. A significant improvement could also be had by ditching passwords completely and moving to key based authentication for ssh. That renders a dictionary attack completely useless. There is a nice tutorial on doing that here.

Emerson · 04-23-2007, 03:01 PM

Don't bother. If your box is exposed to the internet you will get portscans and breakin attempts on 24x7 basis. Read the sticky in this forum.

1 min late.

pAn1k · 04-23-2007, 04:15 PM

Try using denyhost it throws an ip into hosts.deny after a specified number of failed attempts. Works great, and is easy to set up.

stormpunk · 04-23-2007, 11:50 PM

Quote:

Originally Posted by pAn1k

Try using denyhost it throws an ip into hosts.deny after a specified number of failed attempts. Works great, and is easy to set up.

Heck, I used to have a script that did stuff like that but the list gets long quickly and if the IP addresses are dynamic you could block real users.

Nowadays, I throttle ssh connection rates similiar to what you'll find in that sticky thread and while you'll get a scan still, they usually give up when they notice dropped packets.

unixfool · 04-24-2007, 09:31 AM

Quote:

Originally Posted by stormpunk

Heck, I used to have a script that did stuff like that but the list gets long quickly and if the IP addresses are dynamic you could block real users.

Nowadays, I throttle ssh connection rates similiar to what you'll find in that sticky thread and while you'll get a scan still, they usually give up when they notice dropped packets.

Key-based authentication lessens the impact of long block lists and dynamic IPs. I use a cocktail of Denyhosts, ipfilter, and SSH key auth, as layered security is best. I've had instances of Denyhosts not running but wasn't impacted because I also used key-based SSH authentication, so even if my firewall policy wasn't secure, I'd still have port 22 locked down.

He could also add the user accounts to his SSH config file, so that only they can access the service.

There are many many ways to tackle this issue.