3

I am currently under an SSH attack.
The attack is very strange in nature, the attacker is using a botnet of computers and using them as individual login attempts (see log snippet):
Dec 11 08:30:51 rhea sshd[16267]: Invalid user maureen from 78.43.82.153
Dec 11 08:35:24 rhea sshd[20012]: Invalid user maurizio from 201.244.188.202
Dec 11 08:44:46 rhea sshd[27711]: Invalid user max from 211.140.12.46
Dec 11 08:49:10 rhea sshd[31383]: Invalid user max from 190.144.47.82
Dec 11 08:58:19 rhea sshd[6659]: Invalid user max from 69.250.227.138
Dec 11 09:07:28 rhea sshd[14249]: Invalid user maxim from 93.63.231.55
Dec 11 09:12:03 rhea sshd[18127]: Invalid user maximus from 79.188.240.210

I am willing to filter all access to port 22 (ie only allow IPs I specify to connect), and what I have done a couple days ago (is block all connections to port 22 but from myself). What I want to do is log ALL connections that don't have an accept rule to log and drop it - this way I can track all the computers in the bot not without giving them the opportunity to attempt to login.

What I have is something like this:
-A INPUT -s my.addr(s) -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j DROP

Update
I have added this to my iptables:
[0:0] -A INPUT -m limit --limit 5/min -p tcp -m tcp --dport 22 -j LOG --log-level 4 --log-prefix "** DoS **"
and used
http://www.cyberciti.biz/tips/force-iptables-to-log-messages-to-a-different-log-file.html
To setup a separate file, however, I can only see the logged data in dmesg.

Natalie Adams
  • 745
  • 1
  • 6
  • 15

3 Answers3

2

Edit:
You just need the Log rule between the accept and drop rules, see the following for an example sending them to syslog. http://www.cyberciti.biz/tips/force-iptables-to-log-messages-to-a-different-log-file.html.

This works because log is different in that it is a '"non-terminating target", i.e. rule traversal continues at the next rule. --From man iptables'. So unlike your other rules, the check against the rules is not going to short circuit when it reaches a match.

Also, see this link for how to specify the log file (but note the follow up post).

From Before (Misread Question):
You might want fail2ban, does this for you automatically ... whole bunch of other options for this post: Hundreds of Failed SSH Logins.

Community
  • 1
Kyle Brandt
  • 82,107
  • 71
  • 302
  • 444
  • I already have an IDS in place called Blockhosts. IDS will NOT work because it is only 1 failed attempt per host. And it seems like they are running through a wordlist of names so it eventually will stop but I want to log the requests AND prevent user login attempt from happening. – Natalie Adams Dec 11 '09 at 16:41
  • At least prevent this attacker from running through his wordlist of usernames. My IDS does pick up those who try to login as "Administrator" and other attempted brute force attempts. However, you will notice this attack is 1 login attempt per host. – Natalie Adams Dec 11 '09 at 16:43
  • Distributed SSH attacks have been going on for awhile. I finally got so fed up with them I eventually moved the ssh server to a non-standard port, or on some systems implemented a very basic port-knocking system entirely in iptables. My passwords are secure, but the constant login attempts worried and irritated me. Some info on using IPTables for (multiple port) port knocking: http://www.debian-administration.org/articles/268 – mfarver Dec 11 '09 at 18:50
2

To setup a separate file, however, I can only see the logged data in dmesg.

Messages from the netfilter subsystem are logged via the kenerl logging mechanism. This shows up in dmesg output, and also usually ends up in your syslog via the services of klogd.

If you're running rsyslog or syslog-ng, these generally read kernel log data natively.

The messages show up in syslog using the 'kern' facility, so in a traditional syslog.conf file you can do something like:

kern.* /var/log/kernel-messages

(But note that will get you all kernel messages, not just netfilter).

Both rsyslog and syslog-ng provide pattern-matching facilities to give you more granular control over where log messages go.

larsks
  • 41,276
  • 13
  • 117
  • 170
0

What you want is Ulogd which enables you to log matching iptables packets to a user-specified file.

Once ulogd is installed edit the /etc/ulogd.conf file and uncomment the line: plugin="/usr/lib/ulogd/ulogd_LOGEMU.so"

In the [LOGEMU] section you'll see file="/var/log/ulogd.pktlog"

This is where your iptables logs will go. I suggest you also add this file to logrotate if you have that installed as logs can get large fast, even with limits.

Once ulogd is all setup you would replace this rule:

-A INPUT -m limit --limit 5/min -p tcp -m tcp --dport 22 -j LOG --log-level 4 --log-prefix "** DoS **"

With this rule:

-A INPUT -m limit --limit 5/min -p tcp -m tcp --dport 22 -j ULOG --ulog-prefix "** DoS **"

It's also worth noting that ulogd enables you to log packets to databases such as MySQL, PostgreSQL and SQLite.

SiegeX
  • 525
  • 1
  • 6
  • 16