ssh from SRC port 22 to DST port 22??

[slackwarelinux]

Hey guys, im new here and this is my first post. Ive got a question about Secure Shell.
Today at work snort allerted us to the following

-- snort snort --

[**] spp_stream4: STEALTH ACTIVITY (SYN FIN scan) detection [**]
07/14-21:09:14.854534 211.172.121.210:22 -> 192.168.4.34:22
TCP TTL:20 TOS:0x0 ID:39426 IpLen:20 DgmLen:40
******SF Seq: 0x235A06B0 Ack: 0x5F19F5 Win: 0x404 TcpLen: 20

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
=+=+=+=+=+=+=+=+=+=+=+=+

[**] spp_stream4: STEALTH ACTIVITY (SYN FIN scan) detection [**]
07/14-21:09:14.854534 211.172.121.210:22 -> 192.168.4.34:22
TCP TTL:20 TOS:0x0 ID:39426 IpLen:20 DgmLen:40
******SF Seq: 0x235A06B0 Ack: 0x5F19F5 Win: 0x404 TcpLen: 20

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
=+=+=+=+=+=+=+=+=+=+=+=+

a couple of things to note here.

1. this appears to be a linux box, even though the Time to Live is set at 20. A quick
traceroute 211.172.121.210 shows the host lies 20 hops away from me. point - TTL is forged

2. the SYN | FYN flags are set. I understand the SNY flag being set to initiate a TCP connection, but to include the FYN flag as well, this is not normal ssh behaviour. point - packets are crafted by some tool / possible exploit

3. does anyone know any possible ssh exploits or worms in the wild that use port 22 for the source port, that sets the SYN | FYN flag and that forges TTL values?

perhaps im way off, but this type of traffic does not seem normal to me, looks like
i may have been in the range of some worm or script kiddie scaning domains looking for
vulnerable unpatched OpenBSD or whatever boxes.

anyway hello to everyone, hope we all can be good friends.

Helo from canada

[draziw]

Originally posted here by slackwarelinux
Hey guys, im new here and this is my first post. Ive got a question about Secure Shell.
Today at work snort allerted us to the following

-- snort snort --

[**] spp_stream4: STEALTH ACTIVITY (SYN FIN scan) detection [**]
07/14-21:09:14.854534 211.172.121.210:22 -> 192.168.4.34:22
TCP TTL:20 TOS:0x0 ID:39426 IpLen:20 DgmLen:40
******SF Seq: 0x235A06B0 Ack: 0x5F19F5 Win: 0x404 TcpLen: 20

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
=+=+=+=+=+=+=+=+=+=+=+=+

[**] spp_stream4: STEALTH ACTIVITY (SYN FIN scan) detection [**]
07/14-21:09:14.854534 211.172.121.210:22 -> 192.168.4.34:22
TCP TTL:20 TOS:0x0 ID:39426 IpLen:20 DgmLen:40
******SF Seq: 0x235A06B0 Ack: 0x5F19F5 Win: 0x404 TcpLen: 20

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
=+=+=+=+=+=+=+=+=+=+=+=+

a couple of things to note here.

1. this appears to be a linux box, even though the Time to Live is set at 20. A quick
traceroute 211.172.121.210 shows the host lies 20 hops away from me. point - TTL is forged

It could have just been set artificially high, no? In any case, I'd be less concerned with that for now...

<edit>
BTW, are these logs sanitized? Or are you doing reverse NAT? You shouldn't be able to hit 192.168.0.0/16 from an outside address. So, if this is real and you're not doing reverse NAT (good bet you are, though, protecting things by a firewall and relaying things "in" to the network), then this is an insider.
</edit>

2. the SYN | FYN flags are set. I understand the SNY flag being set to initiate a TCP connection, but to include the FYN flag as well, this is not normal ssh behaviour. point - packets are crafted by some tool / possible exploit

3. does anyone know any possible ssh exploits or worms in the wild that use port 22 for the source port, that sets the SYN | FYN flag and that forges TTL values?

perhaps im way off, but this type of traffic does not seem normal to me, looks like
i may have been in the range of some worm or script kiddie scaning domains looking for
vulnerable unpatched OpenBSD or whatever boxes.

anyway hello to everyone, hope we all can be good friends.

Helo from canada

Well, it certainly doesn't look like "normal" traffic... the low-port to low-port is probably in an effort to evade any screens on a packet (doesn't things like root scp use port 22 to port 22 or similiar for its connection? or sftp or similiar? To be honest, I've not looked at the traffic pattern(s) on ssh much as it's typically wide open on permiter boxes anyway - though I almost always move the port to something else, I rarely filter on source port for SSH.)

And the SYN-FIN scan, I /think/ is referring to the type of scan... basically the machine is tearing down the connection as soon as it's started, as the ACK is never sent. This might imply that someone's spoofing the scan from a machine mid-way between the boxes where they can snoop the traffic going by and implicate the other machine - if they see the SYN-ACK from your box, they know the port's open and the FIN coming back is just nicely clearing the SYN table for you on your box (else you might see a SYN-flood warning in-addition, or your box might stop responding for a bit if it were suitably old to suffer from such issues).

I, personally, know of no worms/scans in the wild that would use some such technique - though it could easily be a home crafted one. I'd make sure that your versions of SSH are current, particularly if you use OpenSSH. I'd also consider moving any SSH ports that are open to the internet to something "uncommon" or that would be missed in a "common port scan" like those typically done with something like nmap.

I'd also go check your syslogs for attempts on SSH from other machines now, too.

Hope this late night/early morning rambling helps. Feel free to PM me if you want more info, etc, when I'm more awake.

[slackwarelinux]

Yes, these logs have been "sanitized" for my and everyone elses protection.

Our network is doing IP Masquerading and our firewalls would block and log any "log martians", "source routed" or any other type of invalid / impossible address coming in on eth0

Thanks for your advice and your well thought out reply.

Moving ssh to a less common port is a good idea as well

You mentioned keeping Openssh up to date. All our servers are running Openssh 3.4p1
complete with "privledge separation" and all.

thanks again

[nebulus200]

It is a very common type of scan. One of the things that nmap lets you do (and other scanners as well) is to set the source port of the scan. Why would you do that ? One reason is that it could confuse the people watching the traffic and lead to some debate over whether or not the traffic is return traffic or initiated traffic. It could also be an attempt to bypass filters in either a firewall or router. If you were in doubt about the source/destination port, the syn-fin should be a dead giveaway...

Older versions of ssh I think did port 22 to port 22 traffic; however, I don't think that is the case anymore.

I have seen variations on this scan, from port 80 to port 80, to port 21 to port 21, to port 21 from port 80, etc. We finally added something to our boundary devices that is similar to this
cisco type access-list entry:
access-list xxxx deny ip any lt 1024 any let 1024

End of problem and as far as I can tell, it had no effect on any of 'our' traffic...

Neb

[draziw]

Originally posted here by nebulus200
It is a very common type of scan. One of the things that nmap lets you do (and other scanners as well) is to set the source port of the scan. Why would you do that ? One reason is that it could confuse the people watching the traffic and lead to some debate over whether or not the traffic is return traffic or initiated traffic. It could also be an attempt to bypass filters in either a firewall or router. If you were in doubt about the source/destination port, the syn-fin should be a dead giveaway...

That's exactly what I said... ;-)

(and technically return traffic should have an established flag set in the header - yet another way that people attempt to bypass router screens is to erroneously (rather, falsely) set this flag... stateful inspection type firewalls (such as IPF for the "free" crowd or CheckPoint for the "I paid too much" crowd) tend to defend against this nicely...

Older versions of ssh I think did port 22 to port 22 traffic; however, I don't think that is the case anymore.

I have seen variations on this scan, from port 80 to port 80, to port 21 to port 21, to port 21 from port 80, etc. We finally added something to our boundary devices that is similar to this
cisco type access-list entry:
access-list xxxx deny ip any lt 1024 any let 1024

End of problem and as far as I can tell, it had no effect on any of 'our' traffic...

Neb

Kind of figured SSH might be low-to-low port... though "fixing" it to not be so badly behaved isn't that big a hack, I believe (kind of uncomfortable with it being setuid root, anyway).

That access list, however, may have a tendancy to break a few things such as Sendmail (and ident - though that may be high to low port), possibly FTP and DNS... DNS, in-particular, tends to do DNS transfers and some server-to-server queries on low ports.

[nebulus200]

sendmail and ftp are defintely not effected.

since at least version 2.9 of openssh this has not been an issue, the older ones I just honestly don't remember...

DNS I don't think is effected, I haven't noticed any effects and when I have done packet traces, the dest is always port 53, src random high. Zone transfers are another question entirely and I will have to look into that, to my knowledge right now there haven't been any problems; however, that may be because of our unique situation rather than there not being any tcp 53 to tcp 53 traffic...Of course you could always bypass the problem with that by having a rule before this that specifically permitted zone transfers to the few places you should be allowing it...

Ident I am not sure of...

There are of course some things that break the rule about the src prt = dst prt but in my experience that has generally been the case with higher number, non-reserved ports (> 1024).

Anyway,

Neb

[backslap]

Search results for '211.172.121.210'
inetnum 211.172.0.0 - 211.199.255.255
netname KRNIC-KR
descr KRNIC
descr Korea Network Information Center
country KR
admin-c HM127-AP, inverse
tech-c HM127-AP, inverse
remarks ******************************************
remarks KRNIC is the National Internet Registry
remarks in Korea under APNIC. If you would like to
remarks find assignment information in detail
remarks please refer to the KRNIC Whois DB
remarks http://whois.nic.or.kr/english/index.html
remarks ******************************************
mnt-by APNIC-HM, inverse
mnt-lower MNT-KRNIC-AP, inverse
changed hostmaster@apnic.net 20000607
changed hostmaster@apnic.net 20010606
source APNIC


person Host Master, inverse
address 11F, KTF B/D, 1321-11, Seocho2-Dong, Seocho-Gu,
address Seoul, Korea, 137-857
country KR
phone +82-2-2186-4500
fax-no +82-2-2186-4496
e-mail hostmaster@nic.or.kr, inverse
nic-hdl HM127-AP, inverse
mnt-by MNT-KRNIC-AP, inverse
changed hostmaster@nic.or.kr 20020507
source APNIC


inetnum 211.172.121.192 - 211.172.121.223
netname JIGUNET-LLINE-IBOOK-KR
descr IBOOKSERVE Co.,Ltd.
descr YoungDong Bldg 3Fl 47-3 Songpa-Dong Songpa-Ku
descr SEOUL
descr 138-170
country KR
admin-c JK5086-KR, inverse
tech-c JK5087-KR, inverse
remarks This IP address space has been allocated to KRNIC.
remarks For more information, using KRNIC Whois Database
remarks whois -h whois.nic.or.kr
remarks This information has been partially mirrored by APNIC from
remarks KRNIC. To obtain more specific information, please use the
remarks KRNIC whois server at whois.krnic.net.
mnt-by MNT-KRNIC-AP, inverse
changed hostmaster@nic.or.kr 20020708
source KRNIC


person Jooneon Kwon, inverse
country KR
phone +82-2-419-5060
fax-no +82-2-419-6671
e-mail jooneon@kumibooks.co.kr, inverse
nic-hdl JK5086-KR, inverse
remarks This information has been partially mirrored by APNIC from
remarks KRNIC. To obtain more specific information, please use the
remarks KRNIC whois server at whois.krnic.net.
mnt-by MNT-KRNIC-AP, inverse
changed hostmaster@nic.or.kr 20020708
source KRNIC

[str34m3r]

There's a program scanner called synscan, which uses SYN-FIN flags for scanning. I did a quick search on google and found this:

http://www.whitehats.com/info/IDS441

[dAggressor]

I would think that the nmap suggestion would be the most likely. It looks like they used nmap coming from port 22 and did a stealth scan (syn/fin) of your host. My question is this, did snort log this for any other machines or is this the only machine that snort is monitoring? Also were any other ports scanned this way or was 22 the only one?

The TTL question is explained here http://lists.insecure.org/nmap-hacke...-Jun/0001.html but the just if it is:

"I've chosen the TTL scan. (Please correct me if I'm wrong).


This consists in sending packets as in a normal scan, but with a TTL
small enough to only reach the gateway we want to firewalk.


If this gateway send ICMP time exceeded, it usually do so only for
packets that could have gone through. Else it drops the packet or send
an ICMP dest unreach. "

Hope this helps in some way.