David Ryan wrote:
All,
To partly reply to my own question - one of my flaws was keeping
$HOME_NET as 10.0.0.0/8 - this prevented most of my test traffic from
triggering since my tests were coming from $HOME_NET and not
$EXTERNAL_NET. This was significant where the rule I was testing was
of the form $EXTERNAL_NET -> $HOME_NET
I'm still getting the ICMP messages as well, so I have to presume that
those packets are actually out there also, but I don't understand why
they are being generated since as observeved from the fact that I can
SSH and ping the host it is not actually unreachable.
David
*From:* David Ryan
*Sent:* 30 May 2007 11:10
*To:* 'snort-users@lists.sourceforge.net'
*Subject:* Everything being triggered as 1:486:4 ICMP unreachable
Hi all,
I built and tested a number of machines and shipped them out to remote
sites recently. Now that they are at the remote site I am trying to
tweak them a bit but I have run into some pretty basic problems that I
hadn't come across before. I'm sure the devices were logging events
properly before I shipped them, but now every time I try to test a
rule I get back the following line -
May 30 10:35:14 <hostname> snort[5017]: [1:486:4] ICMP Destination
Unreachable Communication with Destination Host is Administratively
Prohibited [Classification: Misc activity] [Priority: 3]: {ICMP}
<probe address> -> <my test machine address>
There are a couple of relevant points here -
$HOME_NET is defined as 10.0.0.0/8 and $EXTERNAL_NET is defined as
!$HOME_NET
The probe has an ip address assigned in a /24 10.x.x subnet
My test machine has an ip address assigned in a different /23 10.x.x
subnet
I know there is no routing problem since I am SSH'd in to the probe
from my test machine and I can ping in both directions
I am trying to read through the rule generating this message to see
what is being triggered, but it looks pretty much like it is triggered
on what it describes - an ICMP destination unreachable notification
packet.
I looked back through the old logs and see the following from before I
shipped it off so I know it was logging correctly -
May 15 12:08:10 <hostname> snort[2331]: [1:2189:3] BAD-TRAFFIC IP
Proto 103 PIM [Classification: Detection of a non-standard protocol or
event] [Priority: 2]: {PIM} <old probe address> -> 224.0.0.13
The only thing that changed is the probe IP address, but both the old
and new configs used DHCP and I'm pretty sure that when I was testing
before the IP address changed and it still continued to log OK.
Any ideas what is causing this trigger ? As above, I am reasonably
sure that it is not an actual ICMP destination unreachable packet
because the destination is reachable . . .
David
Sounds like it might be a firewall issue. This response is usually sent
by a firewall to say that it's filter won't allow communication with
that host/port. It may be allowing ssh to that host (port 22) and may
be allowing pings, but not allowing the host/port combo used in your test.
Todd
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Snort-users mailing list
Snort-users@lists.sourceforge.net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users
