Snort mailing list archives

Previous By Date Next
Previous By Thread Next

Re: snort suddenly stopped to record events

From: "Alex" <linux () vfemail net>
Date: Fri, 26 Jul 2013 17:18:31 +0300
Hi Waldo,

Ok, in this case seems that snort is working somehow. To be sure, I moved it 
in another network, with more traffic (192.168.48.0/24) and changed 
snort.conf accordingly!

I've started a nmap scan from 192.168.48.1 against 192.168.48.200 
(nmap -sS -Su 192.168.48.200)
On ids (192.168.48.30) using tcpdump I am able to see nmap scan traffic, but 
snort is not alerting about this scan! It will produce other alerts, about 
other stations but nothing about this scan ...

[root@ids eth1]# tcpdump -i eth1 -v -nn host 192.168.48.200 and host 
192.168.48.1

16:14:36.570570 IP (tos 0x0, ttl 128, id 51446, offset 0, flags [none], 
proto: ICMP (1), length: 56) 192.168.48.200 > 192.168.48.1: ICMP 
192.168.48.200 udp port 13 unreachable, length 36
        IP (tos 0x0, ttl  42, id 37801, offset 0, flags [none], proto: UDP 
(17), length: 28) 192.168.48.1.47973 > 192.168.48.200.13: UDP, length 0
16:14:36.570572 IP (tos 0x0, ttl 128, id 51446, offset 0, flags [none], 
proto: ICMP (1), length: 56) 192.168.48.200 > 192.168.48.1: ICMP 
192.168.48.200 udp port 13 unreachable, length 36
        IP (tos 0x0, ttl  42, id 37801, offset 0, flags [none], proto: UDP 
(17), length: 28) 192.168.48.1.47973 > 192.168.48.200.13: UDP, length 0
16:14:36.570614 IP (tos 0x0, ttl  50, id 36432, offset 0, flags [none], 
proto: UDP (17), length: 28) 192.168.48.1.47973 > 192.168.48.200.279: UDP, 
length 0
16:14:36.570664 IP (tos 0x0, ttl 128, id 51447, offset 0, flags [none], 
proto: ICMP (1), length: 56) 192.168.48.200 > 192.168.48.1: ICMP 
192.168.48.200 udp port 127 unreachable, length 36
        IP (tos 0x0, ttl  40, id 16893, offset 0, flags [none], proto: UDP 
(17), length: 28) 192.168.48.1.47973 > 192.168.48.200.127: UDP, length 0
16:14:36.570667 IP (tos 0x0, ttl 128, id 51447, offset 0, flags [none], 
proto: ICMP (1), length: 56) 192.168.48.200 > 192.168.48.1: ICMP 
192.168.48.200 udp port 127 unreachable, length 36
        IP (tos 0x0, ttl  40, id 16893, offset 0, flags [none], proto: UDP 
(17), length: 28) 192.168.48.1.47973 > 192.168.48.200.127: UDP, length 0
16:14:36.570670 IP (tos 0x0, ttl  54, id 58915, offset 0, flags [none], 
proto: UDP (17), length: 28) 192.168.48.1.47973 > 192.168.48.200.27015: UDP, 
length 0
16:14:36.570714 IP (tos 0x0, ttl 128, id 51448, offset 0, flags [none], 
proto: ICMP (1), length: 56) 192.168.48.200 > 192.168.48.1: ICMP 
192.168.48.200 udp port 91 unreachable, length 36
        IP (tos 0x0, ttl  49, id 28209, offset 0, flags [none], proto: UDP 
(17), length: 28) 192.168.48.1.47973 > 192.168.48.200.91: UDP, length 0
16:14:36.570717 IP (tos 0x0, ttl 128, id 51448, offset 0, flags [none], 
proto: ICMP (1), length: 56) 192.168.48.200 > 192.168.48.1: ICMP 
192.168.48.200 udp port 91 unreachable, length 36
        IP (tos 0x0, ttl  49, id 28209, offset 0, flags [none], proto: UDP 
(17), length: 28) 192.168.48.1.47973 > 192.168.48.200.91: UDP, length 0
16:14:36.570720 IP (tos 0x0, ttl  55, id 59857, offset 0, flags [none], 
proto: UDP (17), length: 28) 192.168.48.1.47973 > 192.168.48.200.1542: UDP, 
length 0
16:14:36.570813 IP (tos 0x0, ttl  57, id 36268, offset 0, flags [none], 
proto: UDP (17), length: 28) 192.168.48.1.47973 > 192.168.48.200.627: UDP, 
length 0
16:14:36.570817 IP (tos 0x0, ttl 128, id 51449, offset 0, flags [none], 
proto: ICMP (1), length: 56) 192.168.48.200 > 192.168.48.1: ICMP 
192.168.48.200 udp port 549 unreachable, length 36
        IP (tos 0x0, ttl  52, id 54752, offset 0, flags [none], proto: UDP 
(17), length: 28) 192.168.48.1.47973 > 192.168.48.200.549: UDP, length 0

...

16:14:36.571318 IP (tos 0x0, ttl 128, id 51460, offset 0, flags [none], 
proto: ICMP (1), length: 56) 192.168.48.200 > 192.168.48.1: ICMP 
192.168.48.200 udp port 523 unreachable, length 36
        IP (tos 0x0, ttl  59, id 38936, offset 0, flags [none], proto: UDP 
(17), length: 28) 192.168.48.1.47973 > 192.168.48.200.523: UDP, length 0
16:14:36.571320 IP (tos 0x0, ttl 128, id 51460, offset 0, flags [none], 
proto: ICMP (1), length: 56) 192.168.48.200 > 192.168.48.1: ICMP 
192.168.48.200 udp port 523 unreachable, length 36
        IP (tos 0x0, ttl  59, id 38936, offset 0, flags [none], proto: UDP 
(17), length: 28) 192.168.48.1.47973 > 192.168.48.200.523: UDP, length 0
16:14:36.571412 IP (tos 0x0, ttl 128, id 51461, offset 0, flags [none], 
proto: ICMP (1), length: 56) 192.168.48.200 > 192.168.48.1: ICMP 
192.168.48.200 udp port 490 unreachable, length 36
        IP (tos 0x0, ttl  52, id 776, offset 0, flags [none], proto: UDP 
(17), length: 28) 192.168.48.1.47973 > 192.168.48.200.490: UDP, length 0
16:14:36.571415 IP (tos 0x0, ttl 128, id 51461, offset 0, flags [none], 
proto: ICMP (1), length: 56) 192.168.48.200 > 192.168.48.1: ICMP 
192.168.48.200 udp port 490 unreachable, length 36
        IP (tos 0x0, ttl  52, id 776, offset 0, flags [none], proto: UDP 
(17), length: 28) 192.168.48.1.47973 > 192.168.48.200.490: UDP, length 0
16:14:36.571418 IP (tos 0x0, ttl 128, id 51462, offset 0, flags [none], 
proto: ICMP (1), length: 56) 192.168.48.200 > 192.168.48.1: ICMP 
192.168.48.200 udp port 2008 unreachable, length 36
        IP (tos 0x0, ttl  46, id 51432, offset 0, flags [none], proto: UDP 
(17), length: 28) 192.168.48.1.47973 > 192.168.48.200.2008: UDP, length 0
16:14:36.571420 IP (tos 0x0, ttl 128, id 51462, offset 0, flags [none], 
proto: ICMP (1), length: 56) 192.168.48.200 > 192.168.48.1: ICMP 
192.168.48.200 udp port 2008 unreachable, length 36
        IP (tos 0x0, ttl  46, id 51432, offset 0, flags [none], proto: UDP 
(17), length: 28) 192.168.48.1.47973 > 192.168.48.200.2008: UDP, length 0
16:14:36.571423 IP (tos 0x0, ttl 128, id 51463, offset 0, flags [none], 
proto: ICMP (1), length: 56) 192.168.48.200 > 192.168.48.1: ICMP 
192.168.48.200 udp port 5193 unreachable, length 36
        IP (tos 0x0, ttl  54, id 57348, offset 0, flags [none], proto: UDP 
(17), length: 28) 192.168.48.1.47973 > 192.168.48.200.5193: UDP, length 0
16:14:36.571425 IP (tos 0x0, ttl 128, id 51463, offset 0, flags [none], 
proto: ICMP (1), length: 56) 192.168.48.200 > 192.168.48.1: ICMP 
192.168.48.200 udp port 5193 unreachable, length 36
        IP (tos 0x0, ttl  54, id 57348, offset 0, flags [none], proto: UDP 
(17), length: 28) 192.168.48.1.47973 > 192.168.48.200.5193: UDP, length 0
16:14:36.571427 IP (tos 0x0, ttl 128, id 51464, offset 0, flags [none], 
proto: ICMP (1), length: 56) 192.168.48.200 > 192.168.48.1: ICMP 
192.168.48.200 udp port 1453 unreachable, length 36
        IP (tos 0x0, ttl  53, id 51760, offset 0, flags [none], proto: UDP 
(17), length: 28) 192.168.48.1.47973 > 192.168.48.200.1453: UDP, length 0
16:14:36.571430 IP (tos 0x0, ttl 128, id 51464, offset 0, flags [none], 
proto: ICMP (1), length: 56) 192.168.48.200 > 192.168.48.1: ICMP 
192.168.48.200 udp port 1453 unreachable, length 36
        IP (tos 0x0, ttl  53, id 51760, offset 0, flags [none], proto: UDP 
(17), length: 28) 192.168.48.1.47973 > 192.168.48.200.1453: UDP, length 0

Filering syslog to catch nmap events:

[root@ids eth1]# tail -f /var/log/messages|grep 'snort'|grep '48.1'

nothing!!!

But else, snort is generating events:

[root@ids eth1]# tail -f /var/log/messages|grep 'snort'

Jul 26 16:26:01 ids snort[31267]: [128:4:1] ssh: Protocol mismatch 
[Classification: Detection of a non-standard protocol or event] [Priority: 
2]: <eth1> {TCP} 192.168.48.50:4584 -> 192.168.48.30:22

Jul 26 16:26:02 ids snort[31267]: [128:4:1] ssh: Protocol mismatch 
[Classification: Detection of a non-standard protocol or event] [Priority: 
2]: <eth1> {TCP} 192.168.48.50:4584 -> 192.168.48.30:22

Jul 26 16:26:02 ids snort[31267]: [128:4:1] ssh: Protocol mismatch 
[Classification: Detection of a non-standard protocol or event] [Priority: 
2]: <eth1> {TCP} 192.168.48.50:4584 -> 192.168.48.30:22

Jul 26 16:26:02 ids snort[31267]: [128:4:1] ssh: Protocol mismatch 
[Classification: Detection of a non-standard protocol or event] [Priority: 
2]: <eth1> {TCP} 192.168.48.50:4584 -> 192.168.48.30:22

Jul 26 16:26:02 ids snort[31267]: [128:4:1] ssh: Protocol mismatch 
[Classification: Detection of a non-standard protocol or event] [Priority: 
2]: <eth1> {TCP} 192.168.48.50:4584 -> 192.168.48.30:22

Jul 26 16:26:02 ids snort[31267]: [128:4:1] ssh: Protocol mismatch 
[Classification: Detection of a non-standard protocol or event] [Priority: 
2]: <eth1> {TCP} 192.168.48.50:4584 -> 192.168.48.30:22

Jul 26 16:26:25 ids snort[31267]: [120:3:1] http_inspect: NO CONTENT-LENGTH 
OR TRANSFER-ENCODING IN HTTP RESPONSE [Classification: Unknown Traffic] 
[Priority: 3]: <eth1> {TCP} 192.168.54.2:8014 -> 192.168.48.200:1907

Jul 26 16:26:33 ids snort[31267]: [128:4:1] ssh: Protocol mismatch 
[Classification: Detection of a non-standard protocol or event] [Priority: 
2]: <eth1> {TCP} 192.168.48.50:3584 -> 192.168.48.30:22

Jul 26 16:26:33 ids snort[31267]: [128:4:1] ssh: Protocol mismatch 
[Classification: Detection of a non-standard protocol or event] [Priority: 
2]: <eth1> {TCP} 192.168.48.50:4584 -> 192.168.48.30:22

Jul 26 16:26:52 ids snort[31267]: [119:19:1] http_inspect: LONG HEADER 
[Classification: Potentially Bad Traffic] [Priority: 2]: <eth1> {TCP} 
192.168.48.50:3823 -> 192.168.54.2:8014

Jul 26 16:26:52 ids snort[31267]: [120:3:1] http_inspect: NO CONTENT-LENGTH 
OR TRANSFER-ENCODING IN HTTP RESPONSE [Classification: Unknown Traffic] 
[Priority: 3]: <eth1> {TCP} 192.168.54.2:8014 -> 192.168.48.50:3823

So, what should be commented out in snort.conf or what rules should be 
activated in order to make snort able to detect and identify such network 
scan?

At the end, I want to mention that I have all snort rules up to date. See 
below pulledpork report from today!

Checking latest MD5 for snortrules-snapshot-2931.tar.gz....
 They Match
 Done!
Prepping rules from snortrules-snapshot-2931.tar.gz for work....
 Done!
Checking latest MD5 for opensource.gz....
 They Match
 Done!
Prepping rules from opensource.gz for work....
 Done!
Checking latest MD5 for emerging.rules.tar.gz....
 They Match
 Done!
Prepping rules from emerging.rules.tar.gz for work....
 Done!
Reading rules...
Generating Stub Rules....
...
Writing /etc/snort/sid-msg.map....
 Done
Writing /var/log/sid_changes.log....
 Done
Rule Stats....
 New:-------1
 Deleted:---1
 Enabled Rules:----19218
 Dropped Rules:----0
 Disabled Rules:---16748
 Total Rules:------35966
 Done

Regards,
Alx

----- Original Message ----- 
From: "waldo kitty" <wkitty42 () windstream net>
To: <snort-users () lists sourceforge net>
Sent: Wednesday, July 24, 2013 6:54 PM
Subject: Re: [Snort-users] snort suddenly stopped to record events



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!





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

VFEmail.net - http://www.vfemail.net
$14.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  

------------------------------------------------------------------------------
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!
Previous By Date Next
Previous By Thread Next

Current thread: