Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

Re: [Snort-users] Problem running Snort Inline

1 view

Skip to first unread message

Anshuman Anil Deshmukh

unread,

Feb 6, 2015, 1:40:20 AM2/6/15

Hi James,

Thanks for your reply.

Even with the command snort --daq afpacket --daq-mode inline -i eth0:eth1 result is same. I already tried different options like providing the options from the command line as well as configuring the same in the snort conf file. But same result with that.

What else could be reason? Just for your information initially snort 2.9.6.1 was installed with the Autosnort script. Later on it was upgraded to version 2.9.7.0. is there anything to do with the daq configuration after snort upgrade?

Regards,

Anshuman

From: James Lay [mailto:jl...@slave-tothe-box.net]
Sent: Thursday, February 5, 2015 7:12 PM
To: snort...@lists.sourceforge.net
Subject: Re: [Snort-users] Problem running Snort Inline

On Thu, 2015-02-05 at 06:40 +0000, Anshuman Anil Deshmukh wrote:

Hi,

We have issues running Snort inline. This is the exact problem which is mentioned here - http://www.linuxforums.org/forum/debian-linux/200751-snort-inline.html (see log below).

We have setup the Snort inline (version 2.9.7.0) which is compiled using switch --enable-sourcefire.

It says “Enabling inline operation” and then switches to IDS mode.

Our command line for running Snort:

/usr/local/snort/bin/snort -c /usr/local/snort/etc/snort_conf_rules.conf -i eth0:eth1 -Q --pid-path=/var/run which creates the bridge automatically. Both the interfaces doesn’t have IP addresses assigned.

We have already enabled following options for snort inline:

config policy_mode:inline

config daq: afpacket

config daq_mode: inline

config daq_var: buffer_size_mb=1024

preprocessor normalize_ip4

preprocessor normalize_tcp: ips ecn stream

preprocessor normalize_icmp4

preprocessor normalize_ip6

preprocessor normalize_icmp6

Under verdicts it shows 0% packets blocked. We have enabled couple of drop rules for BRUTE FORCE attack one of which is getting detected. Here is the snort output.

02/02-12:12:23.042082 [Drop] [**] [1:2019876:2] ET SCAN SSH BruteForce Tool with fake PUTTY version [**] [Classification: Detection of a Network Scan] [Priority: 3] {TCP} 000.000.000.00:38772 -> 00.00.00.:22 (IP addresses information removed)

But under verdicts it shows nothing blocked. Why??

Verdicts:

      Allow:      4335107 ( 59.187%)

      Block:            0 ( 0.000%)

Output says:

Enabling inline operation

Running in IDS mode

        --== Initializing Snort ==--

Initializing Output Plugins!

Initializing Preprocessors!

Initializing Plug-ins!

===============================================

Information about our setup-

   ,,_     -*> Snort! <*-

o" )~   Version 2.9.7.0 GRE (Build 149)

   ''''    By Martin Roesch & The Snort Team: http://www.snort.org/contact#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

============================================================================

/usr/local/snort/bin/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

===========================================================================

Please let me know in case any other information is required.

Regards,

Anshuman

>From snort-2.9.7.0/doc/README.daq:

Configuring Snort
=================

Assuming that you did not disable static modules or change the default DAQ
type, you can run Snort just as you always did for file readback or sniffing an
interface. However, you can select and configure the DAQ when Snort is invoked
as follows:

    ./snort \
        [--daq <type>] \
        [--daq-mode <mode>] \
        [--daq-dir <dir>] \
        [--daq-var <var>]

    config daq: <type>
    config daq_dir: <dir>
    config daq_var: <var>
    config daq_mode: <mode>

    <type> ::= pcap | afpacket | dump | nfq | ipq | ipfw
    <mode> ::= read-file | passive | inline
    <var> ::= arbitrary <name>=<value> passed to DAQ
    <dir> ::= path where to look for DAQ module so's

And from the daq README:

AFPACKET Module
===============

afpacket functions similar to the pcap DAQ but with better performance:

    ./snort --daq afpacket -i <device>
            [--daq-var buffer_size_mb=<#MB>]
            [--daq-var debug]

If you want to run afpacket in inline mode, you must craft the device string as
one or more interface pairs, where each member of a pair is separated by a
single colon and each pair is separated by a double colon like this:

    eth0:eth1

or this:
    eth0:eth1::eth2:eth3

I think you want: snort --daq afpacket --daq-mode inline -i eth0:eth1

I believe -Q and --daq-mode inline work about the same. Hope that helps.

James

"Legal Disclaimer: This electronic message and all contents contain information from Cybage Software Private Limited which may be privileged, confidential, or otherwise protected from disclosure. The information is intended to be for the addressee(s) only. If you are not an addressee, any disclosure, copy, distribution, or use of the contents of this message is strictly prohibited. If you have received this electronic message in error please notify the sender by reply e-mail to and destroy the original message and all copies. Cybage has taken every reasonable precaution to minimize the risk of malicious content in the mail, but is not liable for any damage you may sustain as a result of any malicious content in this e-mail. You should carry out your own malicious content checks before opening the e-mail or attachment." www.cybage.com

Anshuman Anil Deshmukh

unread,

Feb 6, 2015, 7:52:50 AM2/6/15

Hi Yaser,

Please see my answers inline.

Regards,
Anshuman Anil Deshmukh | Sr. IS Analyst - Security
Phone: 91-20-66041700, 91-20-66044700 (Extn. 6114)
Cell: 91-99230-51641

From: Y M [mailto:sn...@outlook.com]
Sent: Friday, February 6, 2015 1:02 PM
To: Anshuman Anil Deshmukh
Cc: snort-users
Subject: RE: [Snort-users] Problem running Snort Inline

Comments inline.

From: ansh...@cybage.com
To: snort...@lists.sourceforge.net
Date: Thu, 5 Feb 2015 06:40:16 +0000
Subject: [Snort-users] Problem running Snort Inline

Hi,

We have issues running Snort inline. This is the exact problem which is mentioned here - http://www.linuxforums.org/forum/debian-linux/200751-snort-inline.html (see log below).

We have setup the Snort inline (version 2.9.7.0) which is compiled using switch --enable-sourcefire.

## While might not be related, did you also upgrade the DAQ to 2.0.4? This version was released with the release of Snort 2.9.7.0 as I remember.

#Anshuman – I didn’t upgrade to DAQ 2.0.4 when I upgraded to Snort version 2.9.7.0

It says “Enabling inline operation” and then switches to IDS mode.

## Are you referring to the message that output in Snort's startup messages? If I recall properly, this came up one before and as I remember that this message "can be" ignored given that you are actually running Snort inline.

#Anshuman – Yes, I am referring to the output in Snort’s startup messages.

Our command line for running Snort:

/usr/local/snort/bin/snort -c /usr/local/snort/etc/snort_conf_rules.conf -i eth0:eth1 -Q --pid-path=/var/run which creates the bridge automatically. Both the interfaces doesn’t have IP addresses assigned.

## While I have not tested this thoroughly, but does your traffic flows from eth0 --> eth1 or from eth1 --> eth0? If you change -i eth0:eth1 to -i eth1:eth0, what happens?

#Anshuman – Yes, my traffic flows from eth0 à eth1.

We have already enabled following options for snort inline:

config policy_mode:inline

config daq: afpacket

config daq_mode: inline

config daq_var: buffer_size_mb=1024

preprocessor normalize_ip4

preprocessor normalize_tcp: ips ecn stream

preprocessor normalize_icmp4

preprocessor normalize_ip6

preprocessor normalize_icmp6

Under verdicts it shows 0% packets blocked. We have enabled couple of drop rules for BRUTE FORCE attack one of which is getting detected. Here is the snort output.

02/02-12:12:23.042082 [Drop] [**] [1:2019876:2] ET SCAN SSH BruteForce Tool with fake PUTTY version [**] [Classification: Detection of a Network Scan] [Priority: 3] {TCP} 000.000.000.00:38772 -> 00.00.00.:22 (IP addresses information removed)

## In the above case, was the connection successful? If you try the same using an ICMP rule and pinging some destination, does the ICMP packet go through?.

#Anshuman – In above case I don’t know if connection was successful because the traffic wasn’t generated by me, but it was the real traffic from Internet. If I try the same using an ICMP rule and ping a destination, ICMP packet isn’t going through. It gets blocked. My ICMP drop rule is working fine.

Here is the section verdict for the session in which I had kept the ICMP rule marked as drop. But you can see that “Block” is still shown as none. Is it like whatever is getting blocked is “Blacklist”?

02/06-17:34:48.559180 [Drop] [**] [1:10000001:1] ICMP ping blocked-test rule [**] [Priority: 0] {ICMP} 192.27.6.22 -> 192.168.1.10

Verdicts:

Allow: 20432 ( 45.983%)

Block: 0 ( 0.000%)

Replace: 0 ( 0.000%)

Whitelist: 23995 ( 54.001%)

Blacklist: 12 ( 0.027%)

Ignore: 0 ( 0.000%)

But under verdicts it shows nothing blocked. Why??

## Not sure why, but lets verify the above first and then lets see.

------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________ Snort-users mailing list Snort...@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://sourceforge.net/mailarchive/forum.php?forum_name=snort-users Please visit http://blog.snort.org to stay current on all the latest Snort news!

Y M

unread,

Feb 6, 2015, 9:42:17 AM2/6/15

From: ansh...@cybage.com
To: snort...@lists.sourceforge.net

Date: Fri, 6 Feb 2015 12:50:17 +0000
Subject: Re: [Snort-users] Problem running Snort Inline

Hi Yaser,

Please see my answers inline.

Regards,
Anshuman Anil Deshmukh | Sr. IS Analyst - Security
Phone: 91-20-66041700, 91-20-66044700 (Extn. 6114)
Cell: 91-99230-51641

From: Y M [mailto:sn...@outlook.com]
Sent: Friday, February 6, 2015 1:02 PM
To: Anshuman Anil Deshmukh
Cc: snort-users
Subject: RE: [Snort-users] Problem running Snort Inline

Comments inline.

From: ansh...@cybage.com
To: snort...@lists.sourceforge.net
Date: Thu, 5 Feb 2015 06:40:16 +0000
Subject: [Snort-users] Problem running Snort Inline

Hi,

We have issues running Snort inline. This is the exact problem which is mentioned here - http://www.linuxforums.org/forum/debian-linux/200751-snort-inline.html (see log below).

We have setup the Snort inline (version 2.9.7.0) which is compiled using switch --enable-sourcefire.

## While might not be related, did you also upgrade the DAQ to 2.0.4? This version was released with the release of Snort 2.9.7.0 as I remember.

#Anshuman – I didn’t upgrade to DAQ 2.0.4 when I upgraded to Snort version 2.9.7.0

* You want to update in the future. Again this may be entirely unrelated.

It says “Enabling inline operation” and then switches to IDS mode.

#Anshuman – Yes, I am referring to the output in Snort’s startup messages.

* Like I said above, this message should not be a problem and it can be ignored as you have proven that your ICMPs are being dropped (blocked).

Our command line for running Snort:

## While I have not tested this thoroughly, but does your traffic flows from eth0 --> eth1 or from eth1 --> eth0? If you change -i eth0:eth1 to -i eth1:eth0, what happens?

#Anshuman – Yes, my traffic flows from eth0 à eth1.

* Try running another simple test for inbound traffic. Just to verify the rule directionality in relation to your HOME/EXTERNAL network configurations works as expected, i.e.: being blocked.

We have already enabled following options for snort inline:

config policy_mode:inline

config daq: afpacket

config daq_mode: inline

config daq_var: buffer_size_mb=1024

preprocessor normalize_ip4

preprocessor normalize_tcp: ips ecn stream

preprocessor normalize_icmp4

preprocessor normalize_ip6

preprocessor normalize_icmp6

Under verdicts it shows 0% packets blocked. We have enabled couple of drop rules for BRUTE FORCE attack one of which is getting detected. Here is the snort output.

## In the above case, was the connection successful? If you try the same using an ICMP rule and pinging some destination, does the ICMP packet go through?.

* From Snort documentation: "Blacklist = packets that caused Snort to block a flow from passing. This is the case when a block TCP rule fires. If the DAQ supports this in hardware, no further packets will be seen by Snort for that session. If not, snort will block each packet and this count will be higher."

0 new messages