Home / server / Questions / 379961
Accepted
David
Asked: 2012-04-17 10:06:17 +0800 CST

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

  • 772

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.

firewall ssh iptables ufw

2 Answers

  1. 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.

    • 2

  2. 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

    • 1