Linux host attempting ICMP after receiving SSHD login attempt

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

sheepfarmerAsked:
Who is Participating?
 
kblack05Connect With a Mentor Commented:
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
 
ravenplCommented:
I would guess that's Your snort is checking whether the source IP is reachable, if not - blocks the communication.
0
 
sheepfarmerAuthor Commented:
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
Improved Protection from Phishing Attacks

WatchGuard DNSWatch reduces malware infections by detecting and blocking malicious DNS requests, improving your ability to protect employees from phishing attacks. Learn more about our newest service included in Total Security Suite today!

 
ahoffmannCommented:
sounds like your sshd is configured with
  ReverseMappingCheck yes
0
 
sheepfarmerAuthor Commented:
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
 
ahoffmannCommented:
no is default
well, could be any device (firewall, proxy, etc.) in front of your sshd too
0
 
sheepfarmerAuthor Commented:
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
 
ahoffmannCommented:
are you sure? I guess that this only does a reverse lookup but no ICMP  (never tested myself)
0
 
sheepfarmerAuthor Commented:
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
 
sheepfarmerAuthor Commented:
You were right - it didn't stop.
Any idea when the ReverseMappingCheck directive was added to sshd_config - I'm running Fedora core3
0
 
ahoffmannCommented:
so the accepted answer didn't help, should the question be reopened?
0
 
sheepfarmerAuthor Commented:
I guess it should be re-opened, but I'm happy to open another thread if thats easier
0
 
sheepfarmerAuthor Commented:
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
 
kblack05Commented:
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
 
sheepfarmerAuthor Commented:
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
 
kblack05Commented:
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
 
sheepfarmerAuthor Commented:
# 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
 
kblack05Commented:
Can you please type 'openssl', then from the
OpenSSL> prompt type 'version' (enter)?
0
 
sheepfarmerAuthor Commented:
OpenSSL> version
OpenSSL 0.9.7a Feb 19 2003
OpenSSL>
0
 
kblack05Commented:
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
 
sheepfarmerAuthor Commented:
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
 
kblack05Commented:
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
 
sheepfarmerAuthor Commented:
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
 
kblack05Commented:
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
 
sheepfarmerAuthor Commented:
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
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.