ssh from SRC port 22 to DST port 22??
Results 1 to 9 of 9

Thread: ssh from SRC port 22 to DST port 22??

  1. #1

    ssh from SRC port 22 to DST port 22??

    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

  2. #2
    Senior Member
    Join Date
    Apr 2002
    Posts
    712

    Re: ssh from SRC port 22 to DST port 22??

    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.
    \"Windows has detected that a gnat has farted in the general vicinity. You must reboot for changes to take affect. Reboot now?\"

  3. #3
    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

  4. #4
    Jaded Network Admin nebulus200's Avatar
    Join Date
    Jun 2002
    Posts
    1,356
    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
    There is only one constant, one universal, it is the only real truth: causality. Action. Reaction. Cause and effect...There is no escape from it, we are forever slaves to it. Our only hope, our only peace is to understand it, to understand the 'why'. 'Why' is what separates us from them, you from me. 'Why' is the only real social power, without it you are powerless.

    (Merovingian - Matrix Reloaded)

  5. #5
    Senior Member
    Join Date
    Apr 2002
    Posts
    712
    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.
    \"Windows has detected that a gnat has farted in the general vicinity. You must reboot for changes to take affect. Reboot now?\"

  6. #6
    Jaded Network Admin nebulus200's Avatar
    Join Date
    Jun 2002
    Posts
    1,356
    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
    There is only one constant, one universal, it is the only real truth: causality. Action. Reaction. Cause and effect...There is no escape from it, we are forever slaves to it. Our only hope, our only peace is to understand it, to understand the 'why'. 'Why' is what separates us from them, you from me. 'Why' is the only real social power, without it you are powerless.

    (Merovingian - Matrix Reloaded)

  7. #7
    Junior Member
    Join Date
    May 2002
    Posts
    25
    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
    Just when i got used to yesterday, along came today.

  8. #8
    Senior Member
    Join Date
    Mar 2002
    Posts
    425
    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

  9. #9
    Member
    Join Date
    Jul 2001
    Posts
    62
    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.
    dAggressor

    It\'s a long life, until you die

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •