[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
?
Solved

Linux host attempting ICMP after receiving SSHD login attempt

Posted on 2006-05-03
26
Medium Priority
?
583 Views
Last Modified: 2010-04-22
Running Snort on a Fedora C3 box, I get :

 [**] [1:485:4] ICMP Destination Unreachable Communication Administratively Prohibited [**] [Classification: Misc activity] [Priority: 3] {ICMP} <my ip> -> <external ip>

This correlates with both my Router log:
TCP Packet - Source:<external ip>.9,58349 Destination:1<my ip>,22 - [SSH match]

and also with /var/message entry
 sshd(pam_unix)[13530]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=<external ip>

It LOOKS like something, presumably the sshd, is pinging the calling machine.

Q. Is that normal and can it be stopped from doing so?

Thanks
SF

0
Comment
Question by:sheepfarmer
  • 13
  • 7
  • 4
  • +1
25 Comments
 
LVL 43

Expert Comment

by:ravenpl
ID: 16603234
I would guess that's Your snort is checking whether the source IP is reachable, if not - blocks the communication.
0
 

Author Comment

by:sheepfarmer
ID: 16603978
I dont think that is the case - my understanding is that Snort is passive and not active, so I'd be surprised if it did any 'checking out'
0
 
LVL 51

Expert Comment

by:ahoffmann
ID: 16609941
sounds like your sshd is configured with
  ReverseMappingCheck yes
0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 

Author Comment

by:sheepfarmer
ID: 16610501
Sounded promising, but there is not such option set in the sshd_config

Unless its on by default and one had to place
  ReverseMappingCheck no
in the file.

I noticed
 UsePAM yes
which is for authentication, but couldn't find any reverse checks in the pam config either (if indeed thats relevant).

man sshd_config does not seem to have any info on ReverseMappingCheck so not sure a 'no' value will help.

Still stuck I guess!

SF


0
 
LVL 51

Expert Comment

by:ahoffmann
ID: 16610525
no is default
well, could be any device (firewall, proxy, etc.) in front of your sshd too
0
 

Author Comment

by:sheepfarmer
ID: 16610535
Ah, I think I found it

From man sshd_config
  UseDNS  Specifies whether sshd should lookup the remote host name and check that the resolved host name
               for the remote IP address maps back to the very same IP address.  The default is 'yes'

Actually, sounds like a good default - I may leave it on.

SF
0
 
LVL 51

Expert Comment

by:ahoffmann
ID: 16610594
are you sure? I guess that this only does a reverse lookup but no ICMP  (never tested myself)
0
 

Author Comment

by:sheepfarmer
ID: 16610707
True.
I'll take a more careful look at the Snort rules and results tomorrow to see if I can glean some more information.
0
 

Author Comment

by:sheepfarmer
ID: 16618529
You were right - it didn't stop.
Any idea when the ReverseMappingCheck directive was added to sshd_config - I'm running Fedora core3
0
 
LVL 51

Expert Comment

by:ahoffmann
ID: 16621846
so the accepted answer didn't help, should the question be reopened?
0
 

Author Comment

by:sheepfarmer
ID: 16622466
I guess it should be re-opened, but I'm happy to open another thread if thats easier
0
 

Author Comment

by:sheepfarmer
ID: 16622641
Thanks for reopening - now to summerise :
1. It seems clear from the logs, that the the inbound (non authorised) ssh connection attempt is triggering a ICMP packet back out to the incoming machine
2. I assume that it is sshd that is doing this.
3. I believe Snort is just reporting that such a packet was detected.
4. I don't have a 'ReverseMappingCheck ...' entry in my sshd_config (and in any case, its no by default)
5. I'm running Fedora Core 3
6. man sshd_config does not list the ReverseMappingCheck entry.

I guess the next stage (unless there are any other config suggestions) is to try and trace the local process that is generating the ICMP if not sshd.

SF

0
 
LVL 11

Expert Comment

by:kblack05
ID: 16635183
Try running tcpdump on the system grepping for ICMP. (Provided tcpdump is installed). Here's the command I used: (though tcpdump comes with a whole plethora of command time options.)

root@ns1:/etc/firewall# tcpdump | grep  -i ICMP

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
16:25:01.601182 IP 10.0.0.1 > 10.0.0.232: ICMP redirect 10.0.128.8 to host 10.0.0.99, length 36
16:25:01.839427 IP 10.0.0.1 > 10.0.0.232: ICMP redirect 10.0.128.8 to host 10.0.0.99, length 36
16:25:02.342368 IP 10.0.0.1 > 10.0.0.232: ICMP redirect 10.0.128.8 to host 10.0.0.99, length 36
120 packets captured
746 packets received by filter
414 packets dropped by kernel

root@ns1:/etc/firewall#
0
 

Author Comment

by:sheepfarmer
ID: 16715733
Anyone got any further thoughts on this.
Certainly kblack05 tcpdump suggestion will show the packets on the wire, but does not help (AFAICS) in identifying the process that is generated the ICMP packets.

I am still assuming its the sshd process doing this, but it seemed reasonable from ahoffmann that
  ReverseMappingCheck no
in the sshd_config should turn it off, but in my build (Fedora Core 3), this config entry does not seem to make any difference and indeed is not listed in the local help.

I guess it may be possible that ReverseMappingCheck may be the only way to sort it out and I have to upgrade my Linux distro to get this functionality - comments?

Thanks
SF

0
 
LVL 11

Expert Comment

by:kblack05
ID: 16719517
Hi again,

Yes tcpdump can help you determine the traffic, but you'll have to dump into a file with >> and then decode the contents of the IP payload.

But before we go there, lets gather some intel
(forgive me if you have posted some of this it's a long thread)

uname -a
cat /etc/fedora-release
iptables -nL

Thanks
0
 

Author Comment

by:sheepfarmer
ID: 16720162
# uname -a
Linux myserver 2.6.12-1.1381_FC3 #1 Fri Oct 21 03:46:55 EDT 2005 i686 i686 i386 GNU/Linux

# cat /etc/fedora-release
Fedora Core release 3 (Heidelberg)

# /sbin/iptables -nL
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
filt-icmp  icmp --  0.0.0.0/0            0.0.0.0/0           icmp type 8
per_src_limit  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:22 flags:0x16/0x02

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain filt-icmp (1 references)
target     prot opt source               destination
ACCEPT     all  --  189.100.0.0/24       0.0.0.0/0
DROP       all  --  0.0.0.0/0            0.0.0.0/0

Chain per_src_limit (1 references)
target     prot opt source               destination
ACCEPT     all  --  189.100.0.0/24       0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           limit: avg 2/min burst 2
REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-admin-prohibited
#
0
 
LVL 11

Expert Comment

by:kblack05
ID: 16720343
Can you please type 'openssl', then from the
OpenSSL> prompt type 'version' (enter)?
0
 

Author Comment

by:sheepfarmer
ID: 16721008
OpenSSL> version
OpenSSL 0.9.7a Feb 19 2003
OpenSSL>
0
 
LVL 11

Expert Comment

by:kblack05
ID: 16721130
SSHD and ICMP are going to be unrelated. I seriously doubt it's SSH causing the ICMP traffic.

At this point I think your best bet is to use Ethereal or similar packet sniffing tool to decode the ICMP packets, and perhaps with a glimpse of the payload you'll know where it's coming from and headed to...what it's doing!?

It's possible SSH can be used to exploit your kernel, that version of the Fedora kernel is susceptible to DOS attacks and some other exploits, and your firewall has some interesting entries in it related to ICMP as well.

If you cannot decode the ICMP, you might consider flushing IP Tables, and see if the feedback still happens. Upgrade the kernel if you think you can get away with it given hardware params, etc...

If you are still convinced that SSH has something to do with it, then try using 'ssh -vv user@hostname' and see if there's anything in there that seems to logically point back to your problem, though I cannot imagine how. All protos there should be using tcp.

In a short order you might consider if you need that traffic all together, and block the hosts concerned at the firewall if you feel it's an issue...
0
 
LVL 11

Accepted Solution

by:
kblack05 earned 2000 total points
ID: 16721147
In fact, I see that your error message, and this firewall chain seem grossly relevant:

REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-admin-prohibited
0
 

Author Comment

by:sheepfarmer
ID: 16721454
Ah, so looking at the relevent bits of the chain :

Chain INPUT (policy ACCEPT)
per_src_limit  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:22 flags:0x16/0x02

Chain per_src_limit (1 references)
target     prot opt source               destination
ACCEPT     all  --  189.100.0.0/24       0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           limit: avg 2/min burst 2
REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-admin-prohibited

The INPUT chain defined for ssh is skipping down to per_src_limit, which is allowing all ssh from the 189.100.0.0/24 network, but if any other (i.e. external) source is attempting ssh, its allows 2 attempts over a 2 min  average, but if any more attempts within that limit, the ssh request is sent the icmp-admin-prohibited signal.  

Thus, is the machine is bombarded with ssh requests from outside 189*, it might appear (as it does) that the sshd is generating the icmp-admin-prohibited packet, but in fact, its the iptables rule that is tirggering it.  Correct?
0
 
LVL 11

Expert Comment

by:kblack05
ID: 16721522
Correct - sometimes it's the little things.

This could be legitimate traffic, but more likely it's
an SSH script kiddy flooding the chain.
0
 

Author Comment

by:sheepfarmer
ID: 16721579
Its definately attempted ssh requests based on the entries from /var/log/message.
I understand that later kernals have more advanced 'limiters' for iptables - the limit: avg 2/min burst 2 is not very effective.

Most grateful for the debug - sorry its only 500 points - if I could, it would be more :)

Great job.
SF
0
 
LVL 11

Expert Comment

by:kblack05
ID: 16721654
Thanks, you are most welcome.

Yeah traffic shaping is changing a lot, if it *really* urks you then later you can upgrade your kernel, and modify the chain with a more specific delimiter...

0
 

Author Comment

by:sheepfarmer
ID: 16721692
Of course, the trouble with Snort is that you spend alot of time investigating why certain traffic is happening - still, its good to have an in-depth look at systems from time to time :)

Cheers
0

Featured Post

Veeam Disaster Recovery in Microsoft Azure

Veeam PN for Microsoft Azure is a FREE solution designed to simplify and automate the setup of a DR site in Microsoft Azure using lightweight software-defined networking. It reduces the complexity of VPN deployments and is designed for businesses of ALL sizes.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

​Being a Managed Services Provider (MSP) has presented you  with challenges in the past— and by meeting those challenges you’ve reaped the rewards of success.  In 2014, challenges and rewards remain; but as the Internet and business environment evol…
Fine Tune your automatic Updates for Ubuntu / Debian
This video shows how to quickly and easily deploy an email signature for all users in Office 365 and prevent it from being added to replies and forwards. (the resulting signature is applied on the server level in Exchange Online) The email signat…
With just a little bit of  SQL and VBA, many doors open to cool things like synchronize a list box to display data relevant to other information on a form.  If you have never written code or looked at an SQL statement before, no problem! ...  give i…
Suggested Courses

834 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question