0

(skip to the end for less context)

I have a CentOS 6 box with a few security measures taken - disabled root login, strong passwords, and user whitelist for FTP and SSH, and fail2ban installed. I get the 'usual' level of attempted logins for SSH, FTP, and SMTP, all of which fail2ban deals with satisfactorily. Unfortunately I can't change SSH port number or enforce keys, although it's on my list to do when possible.

Today I noticed a more serious attack; something I've not seen before. The same IP was repeatedly attempting root login on SSH, but it was hitting random ports (max 3 tries on each) and somehow not getting banned by fail2ban - I assumed this was because of the random port numbers.

After some investigation of /var/log/secure there seemed to be 22K attempts in a matter of hours, so I manually added a rule to iptables to drop everything from that IP.

sshd: Failed password for invalid user root from x.x.x.x port 48811 ssh2

I don't know what the attacker was trying to accomplish here - was he looking for open ports, trying to bruteforce SSH, or port knocking? Aside from manually banning the attacker, I don't know what to do about it or where to look for more information.

TL;DR

In a *nix system, where should I look for evidence of an attack, and how should I interpret that information to inform what I do about it?

Improve this question

2 Answers 2

Reset to default
4

This port number that you see in your message is his source port number, not the destination port. In most TCP implementations, when you make a connection to any server, the source port number is some random high port. Thats also the reason why he can change it all the time.

If he reaches your SSH server with his connections, and your SSH server is only listening on port 22, then you can be sure he is connecting to port 22 (This means the destination port is set to 22).

Here is a description of source port and destination port in TCP: http://en.wikipedia.org/wiki/Transmission_Control_Protocol

Improve this answer
2
  • thanks for that, it explains the apparently odd logs I was seeing. however, it seems that in that case, fail2ban should have banned that IP almost immediately. something to do with root login being disbaled and so the attempt didn't get far enough to trigger fail2ban? keeping an eye on this just in case, thanks for the explanation.
    – jammypeach
    Commented Feb 18, 2013 at 14:06
  • @jammypeach A better approach would be to figure out why fail2ban didn't block this IP and modify the rule or add a new one so that it works for this type of attack.
    – Ladadadada
    Commented Feb 18, 2013 at 15:04
0

where should I look for evidence of an attack, and how should I interpret that information to inform what I do about it?

Do you really intend to pay someone to watch your logs 24x7? This kind of attack is very common (as is scanning for open SMTP relays and HTTP proxies). While port knocking is a simple way to protect ssh access, it's not a very practical solution for SMTP or HTTP.

Another approach is to use fail2ban - this implements a temporary iptables ban on misbehaving IP addresses and comes with pre-configured attack detection.

Improve this answer
1
  • No I don't have the time to watch them 24x7 unfortunately :) already using fail2ban as stated in the question. What I'm worried about is getting hit by a type of attack I'm not prepared for, and not knowing what to do about it. ideally i'd check manually every few days, just a scan over the appropriate logs.
    – jammypeach
    Commented Feb 18, 2013 at 13:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .