Ssh – Firewall blocking some strange communications from source-port 22 to over-seas ip addresses. Should I be concerned

firewalliptablessshufw

I'm responsible for a server that serves a single service (ssh) over the internet via port-forwarding through a firewall.

The ssh service login is limited to encryption-key only (no passwords allowed).

Several times a week I see the following sort of firewall log (slightly obfuscated of course):

[UFW BLOCK] IN= OUT=eth0 SRC=192.168.x.x DST=211.224.108.50 LEN=48 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=22 DPT=29364 WINDOW=14600 RES=0x00 ACK SYN URGP=0

The source-port is always 22, and the destination IP is always something overseas (Korea, in this case) that appears to be malicious.

I've got the server fairly locked down, but I don't know enough about the SSH and TCP protocols to be confident, and I don't like the fact that it looks like my server is trying to contact a stranger. This sort of communication never happens during a legitimate ssh session.

Should I be concerned? Is there anything else strange about that log that my eyes haven't spotted?

Edit: I've tried a few simple things (like attempted password auth) to reproduce the blocked connection using an ssh client, with no success. Would be nice if I could reproduce it.

Best Answer

Your system is accepting the connection attempt packet from that overseas IP address on port 22, but then the response packet is being blocked. The source port of 22 and the SYN and ACK flags on the packet show that it's attempting to respond to the connection attempt, and being blocked.

Depending on how you've configured your rules (Are you using ufw, as you've tagged the question with that? Or straight iptables? Can you provide your rules?), then this may or may not be the expected way for this attempted connection to fail. But the connection attempt is failing, so you're covered there.

Related Solutions

UFW Logging – Why Are Blocked Requests Logged on Open Port?

Notice that your packet has both the FIN and ACK bits set. This is the last packet that the remote host sends in the TCP tear down (end of connection) procedure.

What happens is, when your host has finished sending it sets the FIN and ACK flags on the last packet. The remote hosts sends a packet with ACK set followed by a packet with FIN and ACK set.

Local          remote
FIN ACK ---->
        <----  ACK
        <----  FIN ACK (?optional?)
ACK     ----->

In practice, the remotes FIN ACK is considered optional so the netfilter firewall will flush it's connection table when it sees the ACK so when the FIN ACK packet arrives it has no associated connection and is dropped.

UFW blocking port 80 when it should not

I spent a significant amount of time trying to troubleshoot this problem. The involvement of UFW was a symptom of the real problem and not the cause. I found a solution so I didn't want to leave the question unanswered.

I discovered that for a reason I cannot yet explain syncookies were disabled on the apache servers behind the load balancer:

# sysctl -a | grep syncookies
net.ipv4.tcp_syncookies = 0

The reason I cannot explain this is that it is set to 1 in the default Centos6 /etc/sysctl.conf file. That is a separate issue for me to figure out.

You can read more about syn cookies here:

http://en.wikipedia.org/wiki/SYN_cookies

These are relatively busy servers that handle a lot of connections. My best guess is that enabling UFW (and thus enabling iptables) slowed things down just enough for the syn queue to fill up and without syncookies on connections started getting refused.

Best Answer

Related Solutions

UFW Logging – Why Are Blocked Requests Logged on Open Port?

UFW blocking port 80 when it should not

Related Topic