Tell me more ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.
up vote 1 down vote favorite

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.

share|improve this question
You may want to determine if there is an open SSH process on your server at the time of the log message and trace what started that process. You can start by using netstat or lsof to find the open ports/sockets on your server. Without additional detail bout your firewall, port forward, network setup it may be hard to tell more. – adric Apr 16 '12 at 18:10

2 Answers

up vote 2 down vote accepted

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.

share|improve this answer
Yeah, I'm using ufw, which builds the rules automatically. The ufw settings are extremely simple regarding the ssh server: everything is blocked except traffic with the destination port of 22, for which both inbound and outbound traffic is allowed. – David Apr 16 '12 at 19:53
up vote 0 down vote

One other suggestion not directly related to your query but important none the less. If you have an internet facing ssh server I highly suggest you change to certificate based logon only, ensure no root logon from ssh, and as always set the lockout to 5 or less.

Addtionally I would suggest putting the ssh server on a different and ephemeral port port i.e. 2222 this will typically quiet traffic to the ssh server drastically due to that hackers are usually scanning large swaths ip blocks for open port 22 in particular just to try and weasel thier way in to your networks.

I hope that helps..

dc

share|improve this answer
Thanks @dc5553! – David Apr 20 '12 at 13:54

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.