how to get snort working on wireless
 

snort works fine on eth0 but wireless uses eth1, how do I switch, or use both, on Debian?
I have changed ...conf to read DEBIAN_SNORT_INTERFACE="eth1" in /etc/snort/snort.debian.conf and so how do I test which interface snort is now tracking, if any?

Fred.

IIRC it should result in a Snort instance being run for every interface in the $DEBIAN_SNORT_INTERFACE list, so 'pgrep -lf snort|grep eth1' should show?

unSpawn,

1. what is IIRC?
''
2. in 'pgrep-lf snort (pipe) eth1' the l is 'l' as in ls for list, or i as in 'if'

I will post the results

thanks,


Fred.

unSpawn,
results:


bob@bobsgaff:~$ pgrep -if snort | grep eth1
pgrep: invalid option -- 'i'
bob@bobsgaff:~$ pgrep -lf snort | grep eth1
4473 /usr/sbin/snort -m 027 -D -d -l /var/log/snort -u snort -g snort -c /etc/snort/snort.conf -S HOME_NET=[192.168.0.0/24] -i eth1
bob@bobsgaff:~$

any ideas?

Fred.

"If I Recall Correctly", a common FLA (Four Letter Acronym) ;-p


Copy the line to the CLI and you'll see it's l as in list.


Well it reads "-i eth1" and that was as explained / expected. All good.

unSpawn,
thanks, still:

1. if I add a line to that file for snort to look at eth0, snort will examine that as well?

2. there is also a file /etc/snort/snort.conf, does the debian snort.conf take precidence on a debian system?

3. there seems to be an issue involving when the snort is started,i.e, the wireless interface may not be started straight away when you boot up but will snort kick in when the specific wireless interface starts?

sorry to be a pain,

fred.

Please see 'man pgrep'. Basically it only looks for process names. With "-f" you can limit results by using for example 'pgrep -lf "snort.*eth0";'.


I don't know where the Debian snort.conf resides but your 'pgrep' result shows it's using "-c /etc/snort/snort.conf" like it should.


Good question. IIRC Snort doesn't consider network devices that aren't initialized. If you use NetworkManager or equivalent you could force a start / restart by dropping a script in the /etc/NetworkManager/dispatcher.d/ directory?


Hell no: asking questions isn't stupid, not asking is!

unSpawn,
pgrep seems to be a solaris thing but the '-n' option seems to specify what is happening now, so will try -lfn as options to pgrep.
I'm not keen on writing scripts and then inserting them into 'profiles'as I don't know what effects that will have, if indeed that is what you do! I have read that you can set pre-existing conf. files to delay the take up of snort examination on os (debian) conf. files but can't find that reference again, any help would be appreciated.

Fred.

unSpawn,
the results:

pgrep -lfn snort|grep eth1
2984 /usr/sbin/snort -m 027 -D -d -l /var/log/snort -u snort -g snort -c /etc/snort/snort.conf -S HOME_NET=[192.168.0.0/24] -i eth1
bob@bobsgaff:~$
seems to be the same, perhaps I should check logs, not that I have created any percific logs so they will only this login?
It seems eth1 is being monitored as it has generated traffic for today:
root@bobsgaff:/var/log/snort# cat alert
[**] [1:527:8] BAD-TRAFFIC same SRC/DST [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
06/20-23:39:49.757375 :: -> ff02::16
IPV6-ICMP TTL:1 TOS:0x0 ID:256 IpLen:40 DgmLen:96
[Xref => http://www.cert.org/advisories/CA-1997-28.html][Xref => http://cve.mitre.org/cgi-bin/cvename...ame=1999-0016][Xref => http://www.securityfocus.com/bid/2666]

[**] [1:527:8] BAD-TRAFFIC same SRC/DST [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
06/20-23:39:49.818281 0.0.0.0:68 -> 255.255.255.255:67
UDP TTL:128 TOS:0x10 ID:0 IpLen:20 DgmLen:328
I assume it would not if snort was looking on eth0.

Fred.

No?


Why would you think that? You've already shown the right output...


Your choice. Unfortunately I'm not that distro-agnostic to help you with that.



Sure but that's completely the wrong way to use pgrep.

- In short this tells you if Snort is running as it returns the PID and the whole command line:
- and this tells you if Snort is running but selecting only those instances that have "eth1" as one of their arguments and returning nothing but the PId:
That means that in BASH you can:

The assumption would not be something I would want to use to determine what network device Snort listens on...


*BTW:
binary logs (see Barnyard2) are performance-wise way more efficient than having Snort capture traffic, parse packets and then requiring it to write out full human readable analysis logs.

unSpawn,
thanks, I'm not sure how much of it I understand at this point. The results for the penultimate box are as follows:


bob@bobsgaff:~$ pgrep -f "/usr/sbin/snort.*eth1"
3908
bob@bobsgaff:~$ snortcheck() { PIDS=($(pgrep -f "/usr/sbin/snort.*eth1"))
> case ${#PIDS[@]} in
> 1) logger -t $FUNCNAME "Snort running with ${#PIDS[@]} PIds.";;
> *) logger -t $FUNCNAME "Restarting Snort:"
> /path/to/snort_start_script restart;;
> esac; }
bob@bobsgaff:~$
bob@bobsgaff:~$ snortcheck

Does the blank link mean no check was carried out or that Snort was restarted?

Fred.

No. If you check your syslog you should see a message "Snort running with 1 PIds.".

unSpawn,
thanks again, so snort is checking my wireless connection and what you do with that is is up to oneself. Am I right in thinking that Snort will throw off packets or parts of them if they don't conform?

Fred.
.

unspawn,
regarding the syslog, the tail end of the current log at about 23:30 (GMT) is:

Jun 26 23:26:25 bobsgaff NetworkManager[3039]: <info> (eth1): supplicant interface state: associating -> associated
Jun 26 23:26:26 bobsgaff NetworkManager[3039]: <info> (eth1): supplicant interface state: associated -> 4-way handshake
Jun 26 23:26:26 bobsgaff wpa_supplicant[3092]: eth1: WPA: Key negotiation completed with 24:db:ac:47:d8:b7 [PTK=CCMP GTK=CCMP]
Jun 26 23:26:26 bobsgaff wpa_supplicant[3092]: eth1: CTRL-EVENT-CONNECTED - Connection to 24:db:ac:47:d8:b7 completed (reauth) [id=0 id_str=]
Jun 26 23:26:26 bobsgaff NetworkManager[3039]: <info> (eth1): supplicant interface state: 4-way handshake -> completed
Jun 26 23:26:31 bobsgaff NetworkManager[3039]: <info> (eth1): roamed from BSSID (none) ((none)) to 24:DB:AC:47:D8:B7 (VodafoneMobileWiFi-D8B789)


The "none"s cause concern, what do you think?


Fred.

UnSpawn,
short result: bob@bobsgaff:~$ pgrep -lf snort | grep eth? (ie substitute)

from prompt'~$' is a good way of checking if snort is running the eth of your choice, so solved.