Snort/Barnyard/MySQL - snort.signature.sig_name

netritious

The "sig_name" field in table "signature" of the "snort" MySQL database is being populated with (for example) "Snort Alert [1:2001219:0]" instead of "ET SCAN Potential SSH Scan," the latter being what I'm expecting for that alert in that field. I have no idea where to start in solving this on my own. ( I tried :P )

I did search the forums and found one post that referenced my issue but no solution was posted and I can't find it again. I recall it had something to do with "waldo files"….mentioning it in case the poster recognizes the reference and points me in the right direction.

Please advise and TIA! pfSense Rocks! \m/

pfSense Version: v2.0-RC1 (i386) - Built On Thu Apr 7 21:53:59 EDT 2011

Installed Packages:

Backup 0.1.5
Country Block 0.2.0
Cron 0.1.5
MAC-to-Vendor 0.2
mtr-nox11 0.65_2
netio 1.26
nmap 5.51
Notes 0.2.4
RRD Summary 1.1
snort 2.8.6.1 pkg v. 1.35
widescreen 0.2

seraphyn

I'm using snorby.
http://snorby.org/
Works like a charm on Debian wirh pfsense.
Hope this helps.
greetings

netritious

Thanks seraphyn for the info on Snorby. Doesn't really solve my problem though.

In short I use pure SQL via MySQL Query Browser to know what I want when I want from alerts outside of what the WebConfigurator interface provides, but not having a description (or reference link for that matter) is killing my productivity having to research each one and makes my use of barnyard and SQL pretty worthless. It use to not be so, but I'm not sure when the change occurred or what I did (or not) that the entries have changed.

Is it some misconfiguration on my part, some change in the package, or some change in snort/barnyard?

And is anyone else experiencing the same output in that table field? If so did you fix it and how?

Or is everything great for you in that table field for you?

Any feedback is welcome.

EDIT: Also if there is any additional information about my configuration or whatnot that would help someone help me please let me know and I will post here.

Thanks

netritious

seraphyn, would you check the snort.signature.sig_name (database.table.field) in your database and paste an example value here? Or just confirm if your entries look like "Snort Alert [1:2001219:0]" or like "ET SCAN Potential SSH Scan" for example. This would let me know if the behavior is isolated to just my instance. If you need help interfacing MySQL directly on your Debian server let me know.

If your entries look more like "Snort Alert [1:2001219:0]" then Snorby it is, unless some one else would like to confirm that these entires are normal?

Lots of presumptions on my part…just looking for info. I would like to setup what I need to setup and be done with it, and run my SQL queries every morning like I used to lol.

In case someone is interested or it helps diagnose my problem, here is the SQL query I use that you can tweak in a number of ways to get some pretty valuable information from snort entries, even with the "Snort Alert [1:2001219:0]" behavior:

(SELECT event.cid as 'EventId',
signature.sig_gid as 'Interface',
signature.sig_priority as 'AlertPriority',
signature.sig_name as 'Alert',
sig_class.sig_class_name as 'AlertClass',
iphdr.ip_proto as 'Protocol',
INET_NTOA(iphdr.ip_src) as 'SourceIP',
tcphdr.tcp_sport as 'SourcePort',
INET_NTOA(iphdr.ip_dst) as 'DestinationIP',
tcphdr.tcp_dport as 'DestinationPort',
event.timestamp as 'EventTimeStamp'
FROM snortdb.event
JOIN snortdb.iphdr ON event.cid=iphdr.cid
JOIN snortdb.tcphdr ON event.cid=tcphdr.cid
JOIN snortdb.signature ON event.signature=signature.sig_id
JOIN snortdb.sig_class ON signature.sig_class_id=sig_class.sig_class_id)
UNION
(SELECT event.cid as 'EventId',
signature.sig_gid as 'Interface',
signature.sig_priority as 'AlertPriority',
signature.sig_name as 'Alert',
sig_class.sig_class_name as 'AlertClass',
iphdr.ip_proto as 'Protocol',
INET_NTOA(iphdr.ip_src) as 'SourceIP',
udphdr.udp_sport as 'SourcePort',
INET_NTOA(iphdr.ip_dst) as 'DestinationIP',
udphdr.udp_dport as 'DestinationPort',
event.timestamp as 'EventTimeStamp'
FROM snortdb.event
JOIN snortdb.iphdr ON event.cid=iphdr.cid
JOIN snortdb.udphdr ON event.cid=udphdr.cid
JOIN snortdb.signature ON event.signature=signature.sig_id
JOIN snortdb.sig_class ON signature.sig_class_id=sig_class.sig_class_id)
UNION
(SELECT event.cid as 'EventId',
signature.sig_gid as 'Interface',
signature.sig_priority as 'AlertPriority',
signature.sig_name as 'Alert',
sig_class.sig_class_name as 'AlertClass',
iphdr.ip_proto as 'Protocol',
INET_NTOA(iphdr.ip_src) as 'SourceIP',
icmphdr.icmp_type as 'SourcePort',
INET_NTOA(iphdr.ip_dst) as 'DestinationIP',
icmphdr.icmp_type as 'DestinationPort',
event.timestamp as 'EventTimeStamp'
FROM snortdb.event
JOIN snortdb.iphdr ON event.cid=iphdr.cid
JOIN snortdb.icmphdr ON event.cid=icmphdr.cid
JOIN snortdb.signature ON event.signature=signature.sig_id
JOIN snortdb.sig_class ON signature.sig_class_id=sig_class.sig_class_id)
ORDER BY EventTimeStamp DESC
LIMIT 100

EDIT: Added LIMIT to SQL query.

tdevries

I have the same problem, except some of my alerts are working properly, and some are not.

Output of the signature table in mysql shows

Some are good and some are bad

| 105 | Snort Alert [1:408:0] | 1 | 3 | 5 | 408 | 1 |
| 106 | Snort Alert [1:396:0] | 1 | 3 | 7 | 396 | 1 |
| 107 | Snort Alert [1:5999:0] | 6 | 1 | 4 | 5999 | 1 |
| 108 | Snort Alert [1:5693:0] | 6 | 1 | 6 | 5693 | 1 |
| 109 | Snort Alert [1:16281:0] | 6 | 1 | 1 | 16281 | 1 |
| 110 | Snort Alert [1:368:0] | 1 | 3 | 6 | 368 | 1 |
| 111 | Snort Alert [1:381:0] | 1 | 3 | 6 | 381 | 1 |
| 112 | Snort Alert [1:16627:0] | 6 | 1 | 1 | 16627 | 1 |
| 113 | ICMP PING Windows | 1 | 3 | 7 | 382 | 1 |
| 114 | ICMP Echo Reply | 1 | 3 | 5 | 408 | 1 |
| 115 | ICMP Destination Unreachable Port Unreachable | 1 | 3 | 8 | 402 | 1 |
| 116 | ICMP PING BSDtype | 1 | 3 | 6 | 368 | 1 |
| 117 | ICMP PING *NIX | 1 | 3 | 7 | 366 | 1 |