Re: snort suddenly stopped to record events

[waldo kitty <wkitty42 () windstream net>]

On 7/24/2013 10:00, Alex wrote:
> Hi Waldo,
>
> Thanks again for your help. I've collected more info, see below :-)
>
> just commenting out UDP rules in /etc/snort/rules/local-test.rules:
>
> #alert udp $EXTERNAL_NET any ->  $HOME_NET any (msg:"udp traffic inbound";
> classtype:misc-activity; sid:5; rev:1;)
> #alert udp $HOME_NET any ->  $EXTERNAL_NET any (msg:"udp traffic outbound";
> classtype:misc-activity; sid:6; rev:1;)
>
> will still continue to log UDP packets in syslog!!!!
>
> Jul 24 13:56:14 ids snort: [1:4:1] ip traffic outbound [Classification:
> Unknown Traffic] [Priority: 3] {UDP} 192.168.51.10:138 ->  192.168.51.255:138
> Jul 24 13:56:14 ids snort: [1:3:1] ip traffic inbound [Classification:
> Unknown Traffic] [Priority: 3] {UDP} 192.168.51.10:138 ->  192.168.51.255:138

those are alerts from the IP rules... i thought you were talking specifically 
about the UDP traffic rules... yes, the IP rules will alert on all IP traffic...

> Commenting out also ip rules in /etc/snort/rules/local-test.rules, will
> cause snort to stop logging UDP packets.

yes, then you are left with only the TCP and ICMP rules...

> #alert ip $EXTERNAL_NET any ->  $HOME_NET any (msg:"ip traffic inbound";
> classtype:unknown; sid:3; rev:1;)
> #alert ip $HOME_NET any ->  $EXTERNAL_NET any (msg:"ip traffic outbound";
> classtype:unknown; sid:4; rev:1;)
>
> but this time, in merged.log, nothing is recorded! To isolate somehow the
> problem:

hummm...

> - on one terminal I've started a tcpdump -v tcp -i eth4
> - on second terminal, i've started: snort -u snort -g snort snort -c
> /etc/snort/snort.conf
>
> on my host (192.168.51.59) I've telneted host 192.168.51.61 on port 80
> (which is a network printer) and has a management interface listening on
> port 80
>
> See below logs:
> [root@ids ~]# tcpdump -v -nn tcp -i eth4
> tcpdump: WARNING: eth4: no IPv4 address assigned
> tcpdump: listening on eth4, link-type EN10MB (Ethernet), capture size 96
> bytes
> 14:51:45.701106 IP (tos 0x0, ttl  64, id 27972, offset 0, flags [DF], proto:
> TCP (6), length: 48) 192.168.51.61.80>  192.168.51.59.1984: S, cksum 0xf7ba
> (correct), 3548862483:3548862483(0) ack 3068431451 win 11680<mss
> 1460,nop,wscale 0>
> 14:51:45.702054 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto: TCP
> (6), length: 40) 192.168.51.61.80>  192.168.51.59.1984: R, cksum 0x946b
> (correct), 3548862484:3548862484(0) win 0

ok...

> [root@ids snort]# tail -f /var/log/messages|grep snort
> Jul 24 14:51:45 ids snort: [1:2:1] tcp traffic outbound [Classification: A
> TCP connection was detected] [Priority: 4] {TCP} 192.168.51.61:80 ->
> 192.168.51.59:1984
> Jul 24 14:51:45 ids snort: [1:1:1] tcp traffic inbound [Classification: A
> TCP connection was detected] [Priority: 4] {TCP} 192.168.51.61:80 ->
> 192.168.51.59:1984
> Jul 24 14:51:45 ids snort: [1:2:1] tcp traffic outbound [Classification: A
> TCP connection was detected] [Priority: 4] {TCP} 192.168.51.61:80 ->
> 192.168.51.59:1984
> Jul 24 14:51:45 ids snort: [1:1:1] tcp traffic inbound [Classification: A
> TCP connection was detected] [Priority: 4] {TCP} 192.168.51.61:80 ->
> 192.168.51.59:1984

and a match! that, too, is ok...

> Now, I have a question, to be sure that I am understanding correctly snort
> functionality.
>
> Supposing that barnyard IS NOT STARTED and udp and ip rules are enabled in
> local-test.rules, I am able to see that in merged.log will be recorderded
> some things and also in syslog will appear alerts!!!!

yes... when you start barnyard2, if the database is accessible, BY2 will send 
the data from the merged.log to the database...

> Now, in snort.conf I have 2 lines defined for output:

right... that's why you have the two different outputs... you could have more 
from snort but that might cause it to slow down too much and loose traffic...

> output unified2: filename merged.log, limit 128
>
> and
>
> output alert_syslog: LOG_AUTH LOG_ALERT
>
>
> What line in snort.conf will produce alerts in syslog?

that last one says to alert_syslog ;)  comment it out if you do not want snort 
alerts in your local syslog...

> As far as I understand, output unified2: filename merged.log, is related to
> barnyard and will not record in syslog.

yes, you are correct in a manner of speaking... unified2 is simply the logging 
format and merged.log is the name... any tool that can read that logging format 
can use the merged.log file... all output methods get the same data...

> ONLY when barnyard2 will be started, merged.log file will be read and in
> case will be some alerts, barbyard2 will write them in syslog. Correct?

yes...

> The second line (output alert_syslog: LOG_AUTH LOG_ALERT), will be
> responsible to write direct in syslog and has nothing to do with merged.log
> file above. Right?

yes...

> So answer to my question above is: output alert_syslog: LOG_AUTH LOG_ALERT!
> Right?

yes... that is what is causing the syslog alerts...

> Now, I've started snort as daemon and tried to generate some traffic again,
> telneting another host from the same source (192.168.51.59)
>
> telnet 192.168.51.100 80! Unfortunatelly, this time tcpdump will show and
> record only arp request:
>
> [root@ids ~]# tcpdump -i eth4 -v host 192.168.51.59
> tcpdump: WARNING: eth4: no IPv4 address assigned
> tcpdump: listening on eth4, link-type EN10MB (Ethernet), capture size 96
> bytes
> 16:20:41.672663 arp who-has 192.168.51.59 tell 192.168.51.100
>
> and this event is not recorded/alerted by snort even connection has been
> established. Is this normal?

with the IP rules comment out and no ARP rules in place, yes... however, you 
should see in the statistics at the end of the snort run that ARP is counted...

> Anyway, in this time, something has been recorded in merged.log file. I've
> decoded using u2spewfoo, see blelow:
[trim]
> Which decoded with u2boat and tcpdump mean:
>
> [root@ids eth4]# ./u2boat merged.log.1374667559 dump.alx
> Defaulting to pcap output.
>
> [root@ids eth4]# tcpdump -r dump.alx
> reading from file dump.alx, link-type EN10MB (Ethernet)
> 15:06:14.908616 IP 192.168.51.1>  192.168.51.49: ICMP host 193.230.240.22
> unreachable - admin prohibited filter, length 84
> 15:06:14.908616 IP 192.168.51.1>  192.168.51.49: ICMP host 193.230.240.22
> unreachable - admin prohibited filter, length 84
> [root@ids eth4]#
>
> So, I think it matched with your test/debug rules found in
> /etc/snort/rules/local-test.rules

yep! they are GID:SID 1:7 and 1:8 ;)

> alert icmp $EXTERNAL_NET any ->  $HOME_NET any (msg:"icmp traffic inbound";
> classtype:icmp-event; sid:7; rev:1;)
> alert icmp $HOME_NET any ->  $EXTERNAL_NET any (msg:"icmp traffic outbound";
> classtype:icmp-event; sid:8; rev:1;)
>
> If I'm turning off your debug rules, snort (with all rules updated daily
> using pulledpork), will not log anything!!!
>
> So, where is the mistake/problem? In case you need more infor or want to see
> content of any other directory or file on my computer, just let me know ...

at this point in time, everything looks to be OK... the only other thing that 
might be desired is to turn off snort's checksum validation by adding "-k none" 
to the command line (without the quotes)...

other than that, if there are no alerts, then there is (most likely) no traffic 
to alert on with the rules you have chosen to use... that's generally seen as a 
GoodThing<tm> ;) we know your snort is working because the debug rules, which 
are extremely broad and generic, do cause alerts to be raised... there is no 
content matching with those debug rules like most other rules have so they alert 
on everything...

generally speaking, you do not want to see any snort alerts at all... that means 
that all traffic is "GOOD" according to the rules used... that doesn't meant 
that there is no unwanted traffic... only that there are no rules to catch any 
possible unwanted traffic...

in some cases, some configurations include a "heartbeat" rule that monitors for 
known good and desired traffic that occurs at a regular interval... in this 
manner they are reassured that their snort is still working and that at least 
some traffic is being seen... the heartbeat rule may be as simple as looking for 
an ICMP ping packet with a specific content within it... i won't post an example 
that one might use because it may be taken and used by others in a bad manner 
and then its use would be degraded from what you want to use it for... as for 
the ping packet itself, that would be done on one machine to ping another 
machine and to include that content in the ping packet... the path between the 
two machine must travel by snort so that it can see those packets and fire the 
heartbeat alert...

-- 
NOTE: No off-list assistance is given without prior approval.
       Please keep mailing list traffic on the list unless
       private contact is specifically requested and granted.

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
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://sourceforge.net/mailarchive/forum.php?forum_name=snort-users

Please visit http://blog.snort.org to stay current on all the latest Snort news!