[Snort-users] Snort 2.9.6.2 inline mode problem

Debason Shockre demonsdebason at ...11827...
Sun Aug 24 13:58:22 EDT 2014


I have already tried with this rule:
drop icmp 192.168.1.2 any -> 8.8.8.8 any (msg: "NEW TEST"; sid:10666;)

Also modified 384 ICMP rule:
drop icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"PROTOCOL-ICMP PING";
icode:0; itype:8; metadata:ruleset community; classtype:misc-activity;
sid:384; rev:8;)

Set HOME_NET to any, restarted Snort and got the same crap:
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
>From 8.8.8.8 icmp_seq=1 Destination Port Unreachable
64 bytes from 8.8.8.8: icmp_seq=1 ttl=46 time=40.6 ms
>From 8.8.8.8 icmp_seq=2 Destination Port Unreachable
>From 8.8.8.8 icmp_seq=3 Destination Port Unreachable
64 bytes from 8.8.8.8: icmp_seq=3 ttl=46 time=40.7 ms

I've set additional rule:
drop icmp any any -> any any (msg: "NEW TEST"; sid:10666;)

...and am getting:
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
>From 8.8.8.8 icmp_seq=1 Destination Port Unreachable
64 bytes from 8.8.8.8: icmp_seq=1 ttl=46 time=40.2 ms
>From 8.8.8.8 icmp_seq=2 Destination Port Unreachable
>From 8.8.8.8 icmp_seq=3 Destination Port Unreachable
>From 8.8.8.8 icmp_seq=4 Destination Port Unreachable
>From 8.8.8.8 icmp_seq=5 Destination Port Unreachable
64 bytes from 8.8.8.8: icmp_seq=5 ttl=46 time=40.6 ms
>From 8.8.8.8 icmp_seq=6 Destination Port Unreachable

Tried with and without normalization, works the same.

Snort is blocking, but seems not to be able to drop all the traffic:
08/24-19:56:03.511103  [Drop] [**] [1:10666:0] NEW TEST [**] [Priority: 0]
{ICMP} 192.168.1.2 -> 8.8.8.8
08/24-19:56:03.511145  [Drop] [**] [1:10666:0] NEW TEST [**] [Priority: 0]
{ICMP} x.x.x.x -> 8.8.8.8
08/24-19:56:03.551092  [Drop] [**] [1:10666:0] NEW TEST [**] [Priority: 0]
{ICMP} 8.8.8.8 -> 192.168.1.2
08/24-19:56:03.551058  [Drop] [**] [1:10666:0] NEW TEST [**] [Priority: 0]
{ICMP} 8.8.8.8 -> x.x.x.x



On Sun, Aug 24, 2014 at 6:29 PM, Y M <snort at ...15979...> wrote:

>
> Ok, assuming you are setup this way:
>
> Internet <---> eth2 | IPS | eth1 <---> local, where eth1 and eth2 are the
> listening (promiscuous) interfaces and through which traffic is passing.
> When you force Snort into inline mode using afpacket, Snort (logically)
> bridges the interfaces together to let the traffic pass, otherwise drop it
> when matches occur. Looking again at the rule you have, both destinations
> are local. What happens if you change both destinations (HOME_NET and
> EXTERNAL_NET) to any/any? Better, take rule sid:384 and modify it and try
> to ping an external source and see what happens. For troubleshooting
> purposes only, run Snort with -A console or -A cmg so you can see whats
> going directly on the console (without -D).
>
> Also, do you have normalization enabled?
>
> YM
> ------------------------------
> Date: Sun, 24 Aug 2014 17:50:27 +0200
>
> Subject: Re: [Snort-users] Snort 2.9.6.2 inline mode problem
> From: demonsdebason at ...11827...
> To: snort at ...15979...
> CC: snort-users at lists.sourceforge.net
>
>
> Here is the setup:
>
> INTERNET <--> | IPS/router | <--> | local machines |
>
> IPS box has 4 interfaces, where 2 have an address, others don't. It seemed
> illogical to set Snort to listen on interfaces where no traffic is passing
> through.
> When I set Snort it to use unaddressed interfaces, nothing happens meaning
> no alerts are recorded and ICMP echo test isn't working.
> Tried setting up bride interfaces and assigning the two unaddressed
> interface to Snort, same results.
> The only results I get is having Snort listening the interfaces traffic
> traverse though.
>
>
> On Sun, Aug 24, 2014 at 4:24 PM, Y M <snort at ...15979...> wrote:
>
> How are you testing/connecting the client (icmp echo request sender), the
> sensor, and the receiver of the icmp? The NICs that Snort is using to
> receive --> pass/drop --> forward traffic should be inline with no IP
> addresses. From your description, it seems that you are using the same
> interface to ping the box as well as do the IPS work.
>
> P.S.: Please respond to the list and not only to myself. Its a mutual
> benefit.
>
> YM
>
> ------------------------------
> Date: Sun, 24 Aug 2014 14:00:20 +0200
> Subject: Re: [Snort-users] Snort 2.9.6.2 inline mode problem
> From: demonsdebason at ...11827...
> To: snort at ...15979...
>
>
> The same behavior when running with 'eth1:eth2'.
> Yeah, the interfaces are in promiscuous, silly me.
> Any ideas?
>
>
> On Sun, Aug 24, 2014 at 7:34 AM, Y M <snort at ...15979...> wrote:
>
>
> inline.
> ------------------------------
> Date: Sun, 24 Aug 2014 05:02:13 +0200
> From: demonsdebason at ...11827...
> To: snort-users at lists.sourceforge.net
> Subject: [Snort-users] Snort 2.9.6.2 inline mode problem
>
>
> Hi all.
> I've been working on my Snort IPS for some time now.
> Noticed that 'drop' rules are working half-way, I have set the test rule
> to drop ICMP coming to the sensor from local machine:
> drop icmp 192.168.1.2 any -> 192.168.1.1 any (msg: "Test rule";
> sid:110011;)
>
> Alerts get logged and can view them via BASE, but when I ping from .2 to
> .1 I get this:
> PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
> 64 bytes from 192.168.1.1
>
> : icmp_seq=1 ttl=64 time=0.216 ms
> From 192.168.1.1 icmp_seq=1 Destination Port Unreachable
> 64 bytes from 192.168.1.1
>
> : icmp_seq=2 ttl=64 time=0.269 ms
> >From 192.168.1.1 icmp_seq=2 Destination Port Unreachable
> 64 bytes from 192.168.1.1
>
> : icmp_seq=3 ttl=64 time=0.221 ms
>
> So some of them are getting 'blocked'.
>
> When I shutdown Snort I's all fine:
> 64 bytes from 192.168.1.1
>
> : icmp_seq=8 ttl=64 time=0.226 ms
> 64 bytes from 192.168.1.1
>
> : icmp_seq=9 ttl=64 time=0.201 ms
> 64 bytes from 192.168.1.1
>
> : icmp_seq=10 ttl=64 time=0.253 ms
> 64 bytes from 192.168.1.1
>
> : icmp_seq=11 ttl=64 time=0.204 ms
>
> Here is my info:
>
>    ,,_     -*> Snort! <*-
>   o"  )~   Version 2.9.6.2 GRE (Build 77)
>    ''''    By Martin Roesch & The Snort Team:
> http://www.snort.org/snort/snort-team
>            Copyright (C) 2014 Cisco and/or its affiliates. All rights
> reserved.
>            Copyright (C) 1998-2013 Sourcefire, Inc., et al.
>            Using libpcap version 1.4.0
>            Using PCRE version: 7.8 2008-09-05
>            Using ZLIB version: 1.2.3
> +++++++++++++++++++++++++++
> snort    41104  4.6  2.0 1675528 1342832 ?     Ssl  04:48   0:00
> /usr/sbin/snort -D -i eth1::eth2 -u snort -g snort -c /etc/snort/snort.conf
> -Q --daq-mode inline -k none
> +++++++++++++++++++++++++++
>
> # Looks like you have double colons "eth1::eth2", as opposed to one colon
> "eth1:eth2". Not sure if the double colons are causing the partial drops.
>
>
> snort --daq-list
> Available DAQ modules:
> pcap(v3): readback live multi unpriv
> ipfw(v3): live inline multi unpriv
> dump(v2): readback live inline multi unpriv
> afpacket(v5): live inline multi unpriv
>
> ++++++++++++++++++++++++++
> snort.conf:
>
> config policy_mode:inline
> config daq: afpacket
> config daq_dir: /usr/lib64/daq
> config daq_mode: inline
> config daq_var: buffer_size_mb=1024
>
>
> I've tried dropping all the ICMPs in the iptables, results are as
> expected, but Snort still logs the alerts.
> Do you have any idea what is the issue here?
>
> # Does Snort log the requests or replies or both? I would image if the NIC
> is promiscuous, then it would still see the requests.
>
>
> --
> Aut viam inveniam aut faciam
> :wq!
>
> ------------------------------------------------------------------------------
> Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/
> _______________________________________________ Snort-users mailing list
> Snort-users at lists.sourceforge.net Go to this URL to change user options
> or unsubscribe: https://lists.sourceforge.net/lists/listinfo/snort-users
> Snort-users
> <https://lists.sourceforge.net/lists/listinfo/snort-usersSnort-users>
> list archive:
> http://sourceforge.net/mailarchive/forum.php?forum_name=snort-users
> Please visit http://blog.snort.org to stay current on all the latest
> Snort news!
>
>
>
>
> --
> Aut viam inveniam aut faciam
> :wq!
>
>
>
>
> --
> Aut viam inveniam aut faciam
> :wq!
>



-- 
Aut viam inveniam aut faciam
:wq!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20140824/7ee0b34c/attachment.html>


More information about the Snort-users mailing list