Snort mailing list archives

Re: QUEUE questions?


From: "mdpeters" <michael.peters () lazarusalliance com>
Date: Sun, 9 Jan 2005 08:03:47 -0500

OK. I am running a Nessus scan against the target system which sits on a hub on the other side of the bridge. The 
Nessus scanner sits on a hub at the opposite side of the bridge. 



Here is the Snort-inline command I used:

/opt/snort-inline/bin/snort-inline -Qc /opt/snort-inline/etc/ips.conf -l /var/log/snort-inline-ips



I turned the QUEUE back on in the iptables which breaks the bridge. When I use ALLOW instead of QUEUE, the bridge 
passes packets just fine. 



Here is what the console had to tell us:



Reading from iptables

Running in IDS mode

Log directory = /var/log/snort-inline-ips

Initializing Inline mode

 

        --== Initializing Snort ==--

Initializing Output Plugins!

Setting the Packet Processor to decode packets from iptables

Initializing Preprocessors!

Initializing Plug-ins!

Parsing Rules file /opt/snort-inline/etc/ips.conf

 

+++++++++++++++++++++++++++++++++++++++++++++++++++

Initializing rule chains...

,-----------[Flow Config]----------------------

| Stats Interval:  0

| Hash Method:     2

| Memcap:          10485760

| Rows  :          4099

| Overhead Bytes:  16400(%0.16)

`----------------------------------------------

Iptables NEW,RELATED mark is: (1)

 Iptables ESTABLISHED mark is: (2)

 Forcing stream4 to use iptables state

Stream4 config:

    Stateful inspection: ACTIVE

    Session statistics: INACTIVE

    Session timeout: 30 seconds

    Session memory cap: 8388608 bytes

    State alerts: INACTIVE

    Evasion alerts: INACTIVE

    Scan alerts: INACTIVE

    Log Flushed Streams: INACTIVE

    MinTTL: 1

    TTL Limit: 5

    Async Link: 0

    State Protection: 0

    Self preservation threshold: 50

    Self preservation period: 90

    Suspend threshold: 200

    Suspend period: 30

Stream4_reassemble config:

    Server reassembly: ACTIVE

    Client reassembly: ACTIVE

    Reassembler alerts: ACTIVE

    Zero out flushed packets: INACTIVE

    flush_data_diff_size: 500

    Ports: 21 23 25 53 80 110 111 143 513 1433

    Emergency Ports: 21 23 25 53 80 110 111 143 513 1433

HttpInspect Config:

    GLOBAL CONFIG

      Max Pipeline Requests:    0

      Inspection Type:          STATELESS

      Detect Proxy Usage:       NO

      IIS Unicode Map Filename: /opt/snort-inline/etc/unicode.map

      IIS Unicode Map Codepage: 1252

    DEFAULT SERVER CONFIG:

      Ports: 80 8080 8180

      Flow Depth: 300

      Max Chunk Length: 500000

      Inspect Pipeline Requests: YES

      URI Discovery Strict Mode: NO

      Allow Proxy Usage: NO

      Disable Alerting: NO

      Oversize Dir Length: 500

      Only inspect URI: NO

      Ascii: YES alert: NO

      Double Decoding: YES alert: YES

      %U Encoding: YES alert: YES

      Bare Byte: YES alert: YES

      Base36: OFF

      UTF 8: OFF

      IIS Unicode: YES alert: YES

      Multiple Slash: YES alert: NO

      IIS Backslash: YES alert: NO

      Directory Traversal: YES alert: NO

      Web Root Traversal: YES alert: YES

      Apache WhiteSpace: YES alert: YES

      IIS Delimiter: YES alert: YES

      IIS Unicode Map: GLOBAL IIS UNICODE MAP CONFIG

      Non-RFC Compliant Characters: NONE

rpc_decode arguments:

    Ports to decode RPC on: 111 32771

    alert_fragments: INACTIVE

    alert_large_fragments: ACTIVE

    alert_incomplete: ACTIVE

    alert_multiple_requests: ACTIVE

telnet_decode arguments:

    Ports to decode telnet on: 21 23 25 119

database: compiled support for ( mysql )

database: configured to use mysql

database:          user = someuser

database: password is set

database: database name = snort

database:          host = localhost

database:   sensor name = IPS

database:     sensor id = 1

database: schema version = 106

database: using the "alert" facility

3 Snort rules read...

3 Option Chains linked into 3 Chain Headers

0 Dynamic rules

+++++++++++++++++++++++++++++++++++++++++++++++++++

 

building cached link layer reset packets

 

+-----------------------[thresholding-config]----------------------------------

| memory-cap : 1048576 bytes

+-----------------------[thresholding-global]----------------------------------

| none

+-----------------------[thresholding-local]-----------------------------------

| none

+-----------------------[suppression]------------------------------------------

| none

-------------------------------------------------------------------------------

Rule application order: ->activation->dynamic->drop->sdrop->reject->alert->pass->log

 

        --== Initialization Complete ==--

 

*******************

snort_inline-2.2.0-RC1

*******************

a modification of ...

 

-*> Snort! <*-

Version 2.2.0 (Build 30)

By Martin Roesch (roesch () sourcefire com, www.snort.org)



When I stop snort-inline, I get the following:



Final Flow Statistics
,----[ FLOWCACHE STATS ]----------
Memcap: 10485760 Overhead Bytes 16400 used(%0.186405)/blocks (19546/23) Overhead blocks: 1 Could Hold: (73326)
IPV4 count: 22 frees: 0 low_time: 1105274647, high_time: 1105274671, diff: 0h:00:24s
    finds: 31 reversed: 0(%0.000000)
    find_sucess: 9 find_fail: 22 percent_success: (%29.032258) new_flows: 22
 Protocol: 1 (%32.258065) finds: 10  reversed: 0(%0.000000)
  find_sucess: 9 find_fail: 1 percent_success: (%90.000000) new_flows: 1
 Protocol: 6 (%64.516129) finds: 20  reversed: 0(%0.000000)
  find_sucess: 0 find_fail: 20 percent_success: (%0.000000) new_flows: 20
 Protocol: 17 (%3.225806) finds: 1  reversed: 0(%0.000000)
  find_sucess: 0 find_fail: 1 percent_success: (%0.000000) new_flows: 1
database: Closing connection to database "c Protocol Command Decode"
Snort exiting


The syslog which I am logging to like this:



/usr/local/sbin/iptables -P FORWARD DROP
/usr/local/sbin/iptables -A FORWARD -j LOG --log-prefix "PRE QUEUE"
/usr/local/sbin/iptables -A FORWARD -p tcp --syn -m state --state NEW -j QUEUE
/usr/local/sbin/iptables -A FORWARD -p tcp -m state --state RELATED,ESTABLISHED -j QUEUE
/usr/local/sbin/iptables -A FORWARD -p udp -j QUEUE
/usr/local/sbin/iptables -A FORWARD -p icmp -j QUEUE
/usr/local/sbin/iptables -A FORWARD -j LOG --log-prefix "POST QUEUE"



Here is a sample of the syslog messages:



PRE QUEUEIN=br0 OUT=br0 PHYSIN=eth2 PHYSOUT=eth1 SRC=56.185.89.132 DST=56.185.89.130 LEN=28 TOS=0x00 PREC=0x00 TTL=64 
ID=54532 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=1

PRE QUEUEIN=br0 OUT=br0 PHYSIN=eth2 PHYSOUT=eth1 SRC=56.185.89.132 DST=56.185.89.130 LEN=28 TOS=0x00 PREC=0x00 TTL=64 
ID=54788 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=1

PRE QUEUEIN=br0 OUT=br0 PHYSIN=eth2 PHYSOUT=eth1 SRC=56.185.89.132 DST=56.185.89.130 LEN=28 TOS=0x00 PREC=0x00 TTL=64 
ID=55044 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=1

PRE QUEUEIN=br0 OUT=br0 PHYSIN=eth2 PHYSOUT=eth1 SRC=56.185.89.132 DST=56.185.89.130 LEN=28 TOS=0x00 PREC=0x00 TTL=64 
ID=55300 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=1

PRE QUEUEIN=br0 OUT=br0 PHYSIN=eth2 PHYSOUT=eth1 SRC=56.185.89.132 DST=56.185.89.130 LEN=28 TOS=0x00 PREC=0x00 TTL=64 
ID=55556 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=1

PRE QUEUEIN=br0 OUT=br0 PHYSIN=eth2 PHYSOUT=eth1 SRC=56.185.89.132 DST=56.185.89.130 LEN=28 TOS=0x00 PREC=0x00 TTL=64 
ID=55812 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=1

PRE QUEUEIN=br0 OUT=br0 PHYSIN=eth2 PHYSOUT=eth1 SRC=56.185.89.132 DST=56.185.89.130 LEN=28 TOS=0x00 PREC=0x00 TTL=64 
ID=56068 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=1

PRE QUEUEIN=br0 OUT=br0 PHYSIN=eth2 PHYSOUT=eth1 SRC=56.185.89.132 DST=56.185.89.130 LEN=28 TOS=0x00 PREC=0x00 TTL=64 
ID=56324 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=1

PRE QUEUEIN=br0 OUT=br0 PHYSIN=eth2 PHYSOUT=eth1 SRC=56.185.89.132 DST=56.185.89.130 LEN=41 TOS=0x00 PREC=0x00 TTL=64 
ID=3072 PROTO=TCP SPT=3133 DPT=4764 WINDOW=2048 RES=0x00 ACK URGP=0

POST QUEUEIN=br0 OUT=br0 PHYSIN=eth2 PHYSOUT=eth1 SRC=56.185.89.132 DST=56.185.89.130 LEN=41 TOS=0x00 PREC=0x00 TTL=64 
ID=3072 PROTO=TCP SPT=3133 DPT=4764 WINDOW=2048 RES=0x00 ACK URGP=0




The only things that gets through the bridge now are the arp packets. Both machines on either side of the bridge see 
the others MAC.




  ----- Original Message ----- 
  From: Gould, Scott 
  To: mdpeters 
  Sent: Saturday, January 08, 2005 10:24 PM
  Subject: RE: [Snort-users] QUEUE questions?


  No prob.



  Have your tried running snort_inline without the -d Flag, but using the verbose flag with console logging option.  
Then run a nessus scan of the box on the other side of the ips.  Do you see the alerts showing up in the running 
snort_inline process?



  Once you get this info, why don't you post the reply to the list, so we can see if the rest of the inline gang have 
something to offerJ




------------------------------------------------------------------------------

  From: mdpeters [mailto:michael.peters () lazarusalliance com] 
  Sent: Saturday, January 08, 2005 7:18 AM
  To: Gould, Scott
  Subject: Re: [Snort-users] QUEUE questions?



  snort_inline-2.2.0a        ./configure --with-mysql --with-openssl --enable-inline --enable-flexresp



  Sorry about the name confusion. It was lost in transcription. This is the command used, 
/opt/snort-inline/bin/snort-inline -Qc /opt/snort-inline/etc/ips.conf -l /var/log/snort-inline-ips -D



  I run regular Snort on the same box as well.





    ----- Original Message ----- 

    From: Gould, Scott 

    To: mdpeters 

    Sent: Friday, January 07, 2005 11:40 PM

    Subject: RE: [Snort-users] QUEUE questions?



    I notice your binary is names snort, rather than snort_inline.



    Are you using a 2.3.0RCx build of snort?  If so, did you compile snort using the -enable-inline flag when you ran 
the configure script?



    If your not using that build, what build or snort or snort_inline are you using?




----------------------------------------------------------------------------

    From: mdpeters [mailto:michael.peters () lazarusalliance com] 
    Sent: Friday, January 07, 2005 10:48 PM
    To: Gould, Scott
    Subject: Re: [Snort-users] QUEUE questions?



    Yes, like this: /opt/snort-inline/bin/snort -Qc /opt/snort-inline/etc/ips.conf -l /var/log/snort-inline-ips -D

      ----- Original Message ----- 

      From: Gould, Scott 

      To: mdpeters 

      Sent: Friday, January 07, 2005 9:34 PM

      Subject: RE: [Snort-users] QUEUE questions?



      Are you running snort_inline with the -Q flag?




--------------------------------------------------------------------------

      From: snort-users-admin () lists sourceforge net [mailto:snort-users-admin () lists sourceforge net] On Behalf Of 
mdpeters
      Sent: Friday, January 07, 2005 5:00 PM
      To: snort-users () lists sourceforge net
      Subject: [Snort-users] QUEUE questions?



      I have set up a transparent bridge using Fedora Core 2. The only thing that passes through is arp messages. I 
have a Nessus scanner on a hub at one side of the bridge and the target system on a hub at the other side of the 
bridge. I will get only two line entries in syslog. 



      These are the iptable rules.



      /usr/local/sbin/iptables -P FORWARD DROP
      /usr/local/sbin/iptables -A FORWARD -j LOG --log-prefix "PRE QUEUE"
      /usr/local/sbin/iptables -A FORWARD -p tcp --syn -m state --state NEW -j QUEUE
      /usr/local/sbin/iptables -A FORWARD -p tcp -m state --state RELATED,ESTABLISHED -j QUEUE
      /usr/local/sbin/iptables -A FORWARD -p udp -j QUEUE
      /usr/local/sbin/iptables -A FORWARD -p icmp -j QUEUE
      /usr/local/sbin/iptables -A FORWARD -j LOG --log-prefix "POST QUEUE"



      This is the output.



      PRE QUEUEIN=br0 OUT=br0 PHYSIN=eth2 PHYSOUT=eth1 SRC=69.16.185.132 DST=69.16.185.130 LEN=41 TOS=0x00 PREC=0x00 
TTL=64 ID=3072 PROTO=TCP SPT=3133 DPT=49550 WINDOW=2048 RES=0x00 ACK URGP=0


      POST QUEUEIN=br0 OUT=br0 PHYSIN=eth2 PHYSOUT=eth1 SRC=69.16.185.132 DST=69.16.185.130 LEN=41 TOS=0x00 PREC=0x00 
TTL=64 ID=3072 PROTO=TCP SPT=3133 DPT=49550 WINDOW=2048 RES=0x00 ACK URGP=0



      I understand that the QUEUE target will never return a packet to the system unless the userspace program has 
processed the packet, so it appears that snort-inline is turned off or broken. Since I know that Snort-inline is 
running, does anyone have an idea about what would be causing the problem?

      Thanks,

      Michael

Current thread: