Snort Package 2.5.7 – Issues
-
SUPER!!
-
For folks currently impacted by this, they can manually create a suitable Alias and then create a Whitelist from that Alias. Finally, on the Snort Interface Settings tab for the affected interface, set $HOME_NET to the created whitelist object.
I already was doing that and I had this on my wish list for Snort, since I noticed that on my WAN interface the whole subnet was on $HOME_NET and not just the WAN IP address and I don't like my neighbors there.
It is also possible to redefine $HOME_NET when editing the interface in "Advanced configuration pass through". I tested that a week ago. -
I already was doing that and I had this on my wish list for Snort, since I noticed that on my WAN interface the whole subnet was on $HOME_NET and not just the WAN IP address and I don't like my neighbors there.
It is also possible to redefine $HOME_NET when editing the interface in "Advanced configuration pass through". I tested that a week ago.Yep, I don't like that "whole subnet" whitelisting on the WAN side either. I plan on fixing that, but there are some complicating factors caused by other interfaces that might have gateways. For example, my initial idea was to add the whole subnet as "friendly" on all interfaces EXCEPT those that had a gateway. For those, just add the interface IP. But that idea fell apart when I realized some other friendly interfaces may themselves have associated gateways, but where the user would still expect the subnet to be part of HOME_NET. So I'm still trying to figure something out that works in most all cases (especially for the default HOME_NET). Maybe I can safely assume the interface with the default gateway is the WAN, and just whitelist the IP on that one and not the entire subnet.
I welcome any ideas from you experienced Snort users. :)
By the way, I think I found the "issue" that has been dogging some folks where their subnets have been getting blocked. There are two calls that work with HOME_NET and whitelists. One to generate the $HOME_NET variable in snort.conf, and the other to generate the whitelist file fed to the Spoink plugin to control IP blocking. On the second call a parameter is set to TRUE that causes only IP addresses and not subnets to be returned and included in the Spoink whitelist. This was there from the old days when Spoink could only take individual IPs. Ermal fixed Spoink so that it could handle IP ranges (or subnets), but the little piece of code that builds the whitelist did not get altered.
-
DO IT :D
(thanks SO much Bill!!)
-
I already was doing that and I had this on my wish list for Snort, since I noticed that on my WAN interface the whole subnet was on $HOME_NET and not just the WAN IP address and I don't like my neighbors there.
It is also possible to redefine $HOME_NET when editing the interface in "Advanced configuration pass through". I tested that a week ago.Yep, I don't like that "whole subnet" whitelisting on the WAN side either. I plan on fixing that, but there are some complicating factors caused by other interfaces that might have gateways. For example, my initial idea was to add the whole subnet as "friendly" on all interfaces EXCEPT those that had a gateway. For those, just add the interface IP. But that idea fell apart when I realized some other friendly interfaces may themselves have associated gateways, but where the user would still expect the subnet to be part of HOME_NET. So I'm still trying to figure something out that works in most all cases (especially for the default HOME_NET). Maybe I can safely assume the interface with the default gateway is the WAN, and just whitelist the IP on that one and not the entire subnet.
I welcome any ideas from you experienced Snort users. :)
By the way, I think I found the "issue" that has been dogging some folks where their subnets have been getting blocked. There are two calls that work with HOME_NET and whitelists. One to generate the $HOME_NET variable in snort.conf, and the other to generate the whitelist file fed to the Spoink plugin to control IP blocking. On the second call a parameter is set to TRUE that causes only IP addresses and not subnets to be returned and included in the Spoink whitelist. This was there from the old days when Spoink could only take individual IPs. Ermal fixed Spoink so that it could handle IP ranges (or subnets), but the little piece of code that builds the whitelist did not get altered.
Maybe you should make a new topic with a new title for a new discussion on this subject. It is not really an issue with this version. People will not pay attention to this topic when they have no issues, I think.
-
I already was doing that and I had this on my wish list for Snort, since I noticed that on my WAN interface the whole subnet was on $HOME_NET and not just the WAN IP address and I don't like my neighbors there.
It is also possible to redefine $HOME_NET when editing the interface in "Advanced configuration pass through". I tested that a week ago.Yep, I don't like that "whole subnet" whitelisting on the WAN side either. I plan on fixing that, but there are some complicating factors caused by other interfaces that might have gateways. For example, my initial idea was to add the whole subnet as "friendly" on all interfaces EXCEPT those that had a gateway. For those, just add the interface IP. But that idea fell apart when I realized some other friendly interfaces may themselves have associated gateways, but where the user would still expect the subnet to be part of HOME_NET. So I'm still trying to figure something out that works in most all cases (especially for the default HOME_NET). Maybe I can safely assume the interface with the default gateway is the WAN, and just whitelist the IP on that one and not the entire subnet.
I welcome any ideas from you experienced Snort users. :)
By the way, I think I found the "issue" that has been dogging some folks where their subnets have been getting blocked. There are two calls that work with HOME_NET and whitelists. One to generate the $HOME_NET variable in snort.conf, and the other to generate the whitelist file fed to the Spoink plugin to control IP blocking. On the second call a parameter is set to TRUE that causes only IP addresses and not subnets to be returned and included in the Spoink whitelist. This was there from the old days when Spoink could only take individual IPs. Ermal fixed Spoink so that it could handle IP ranges (or subnets), but the little piece of code that builds the whitelist did not get altered.
Maybe you should make a new topic with a new title for a new discussion on this subject. It is not really an issue with this version. People will not pay attention to this topic when they have no issues, I think.
Will do.
Bill
-
For folks currently impacted by this, they can manually create a suitable Alias and then create a Whitelist from that Alias. Finally, on the Snort Interface Settings tab for the affected interface, set $HOME_NET to the created whitelist object.
I already was doing that and I had this on my wish list for Snort, since I noticed that on my WAN interface the whole subnet was on $HOME_NET and not just the WAN IP address and I don't like my neighbors there.
It is also possible to redefine $HOME_NET when editing the interface in "Advanced configuration pass through". I tested that a week ago.This workaround resolved the issue for me. I had to define my LAN subnet, set it as my $HOME_NET, and it wrote the config to snort.conf.
Define Local Network
var HOME_NET [127.0.0.1,192.168.1.0/27,192.168.1.1]
var EXTERNAL_NET [!$HOME_NET] -
Just a note about the snort config script.
Option 1.
It might be helpful to have it pull in the $HOME_NET info based on the the interface (LAN) IP address and subnet mask.
Option 2.
Or, allow a field in the snort interface config GUI area for the user to define the networks they want to monitor. It seems a bit redundant to use the Whitelist, since it will define your gateway address and the network you want to monitor.
The following was written to my snort.conf using the Whitelist I defined:
Define Local Network
var HOME_NET [127.0.0.1,192.168.1.0/27,192.168.1.1]
var EXTERNAL_NET [!$HOME_NET]192.168.1.1 is not needed since you are already watching the 192.168.1.0/27 network.
var HOME_NET [127.0.0.1,192.168.1.0/27]Option 2 might be the cleanest method.
-
Just a note about the snort config script.
Option 1.
It might be helpful to have it pull in the $HOME_NET info based on the the interface (LAN) IP address and subnet mask.
Option 2.
Or, allow a field in the snort interface config GUI area for the user to define the networks they want to monitor. It seems a bit redundant to use the Whitelist, since it will define your gateway address and the network you want to monitor.
The following was written to my snort.conf using the Whitelist I defined:
Define Local Network #
var HOME_NET [127.0.0.1,192.168.1.0/27,192.168.1.1]
var EXTERNAL_NET [!$HOME_NET]192.168.1.1 is not needed since you are already watching the 192.168.1.0/27 network.
var HOME_NET [127.0.0.1,192.168.1.0/27]Option 2 might be the cleanest method.
I have been studying the parts of the Snort package responsible for auto-populating the HOME_NET variable and the default whitelist for the Spoink module. I've identified some areas that I think can work better. One of them is being sure to include the entire network for the interfaces that are not the WAN. For the WAN, just include the actual interface IP and the far-end (presumably, the default) gateway. Also include the options for DNS servers, VPNs and VIPs if desired.
This part of the code contains some legacy stuff that worked with the limits of the original Spoink plugin. Last year Ermal modified the plugin to accept IP ranges in the whitelist. Prior to that, it only accepted individual IP addresses. This limitation was reflected in the HOME_NET and whitelist code. Now that Spoink can accept IP ranges (as in entire networks in CIDR notation), the old limitations can be removed from the HOME_NET and whitelist code. A limited tweak was done last year on the WAN side, but it currently results in the entire subnet on the WAN getting whitelisted (and shown in HOME_NET). That's probably not what most folks want. On the WAN side you would desire just the interface IP and the far-end gateway be in the whitelist and HOME_NET.
Bill
-
Yes that make sense.
-
Bill,
I still have issues with 2.5.7 that I don't understand.
Here is my log after a reboot.May 2 00:34:29 kernel: em0: promiscuous mode enabled May 2 00:33:58 kernel: em0: promiscuous mode disabled May 2 00:33:57 snort[68948]: SMTP reload: Changing the file_depth requires a restart. May 2 00:33:52 barnyard2[68778]: =============================================================================== May 2 00:33:52 barnyard2[68778]: Total: 12 May 2 00:33:52 barnyard2[68778]: S5 G 2: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: S5 G 1: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: InvChkSum: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: DISCARD: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: OTHER: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: MPLS: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: GRE LOOP: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: GRE IPX: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: GRE ARP: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: GRE PPTP: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: GRE IP6 E: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: GRE IPv6: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: GRE IPv4: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: GRE VLAN: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: GRE ETH: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: GRE: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: IPv6/IPv6: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: IPv6/IPv4: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: IPv4/IPv6: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: IPv4/IPv4: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: IPX: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: ETHLOOP: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: EAPOL: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: ARP: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: FRAG 6: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: FRAG: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: ICMPdis: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: UDPdisc: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: TCPdisc: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: ICMP: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: UDP: 4 (33.333%) May 2 00:33:52 barnyard2[68778]: TCP: 8 (66.667%) May 2 00:33:52 barnyard2[68778]: ICMP-IP: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: ICMP6: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: UDP 6: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: TCP 6: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: IP4disc: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: IP4: 12 (100.000%) May 2 00:33:52 barnyard2[68778]: IP6disc: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: IP6opts: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: IP6 EXT: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: IPV6: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: VLAN: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: ETHdisc: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: ETH: 12 (100.000%) May 2 00:33:52 barnyard2[68778]: Packet breakdown by protocol (includes rebuilt packets): May 2 00:33:52 barnyard2[68778]: =============================================================================== May 2 00:33:52 barnyard2[68778]: Unknown: 0 (0.000%) May 2 00:33:52 barnyard2[68778]: Packets: 12 (50.000%) May 2 00:33:52 barnyard2[68778]: Events: 12 (50.000%) May 2 00:33:52 barnyard2[68778]: Records: 24 May 2 00:33:52 barnyard2[68778]: Record Totals: May 2 00:33:52 barnyard2[68778]: =============================================================================== May 2 00:33:52 barnyard2[68778]: database: Closing connection to database "xxxxxxxxx" May 2 00:33:50 SnortStartup[69076]: Snort START for WAN(54477_em0)... May 2 00:33:49 barnyard2[68778]: Waiting for new data May 2 00:33:49 barnyard2[68778]: Opened spool file '/var/log/snort/snort_em054477/snort_54477_em0.u2.1367447629' May 2 00:33:49 barnyard2[68778]: Closing spool file '/var/log/snort/snort_em054477/snort_54477_em0.u2.1367402658'. Read 24 records May 2 00:33:49 kernel: em0: promiscuous mode enabled May 2 00:33:40 barnyard2[68778]: Waiting for new data May 2 00:33:40 barnyard2[68778]: Opened spool file '/var/log/snort/snort_em054477/snort_54477_em0.u2.1367402658' May 2 00:33:40 barnyard2[68778]: Using waldo file '/var/log/snort/snort_em054477/barnyard2/54477_em0.waldo': spool directory = /var/log/snort/snort_em054477 spool filebase = snort_54477_em0.u2 time_stamp = 1367402658 record_idx = 24 May 2 00:33:40 barnyard2[68778]: Barnyard2 initialization completed successfully (pid=68778) May 2 00:33:40 barnyard2[68778]: --== Initialization Complete ==-- May 2 00:33:40 barnyard2[68778]: May 2 00:33:40 barnyard2[68778]: database: using the "alert" facility May 2 00:33:40 barnyard2[68778]: database: ignore_bpf = no May 2 00:33:40 barnyard2[68778]: database: detail level = full May 2 00:33:40 barnyard2[68778]: database: data encoding = hex May 2 00:33:40 barnyard2[68778]: database: sensor cid = 878 May 2 00:33:40 barnyard2[68778]: database: sensor id = 1 May 2 00:33:40 barnyard2[68778]: database: sensor name = xxxxxxxxx:em0 May 2 00:33:40 barnyard2[68778]: database: database name = xxxxxxxxx May 2 00:33:40 barnyard2[68778]: database: user = xxxxxxxxx May 2 00:33:40 barnyard2[68778]: database: host = xxxxxxxxx May 2 00:33:40 barnyard2[68778]: database: schema version = 107 May 2 00:33:40 barnyard2[68778]: database: configured to use mysql May 2 00:33:40 barnyard2[68778]: database: compiled support for (mysql) May 2 00:33:15 barnyard2[68778]: Writing PID "68778" to file "/var/run/barnyard2_em054477.pid" May 2 00:33:15 barnyard2[68778]: PID path stat checked out ok, PID path set to /var/run May 2 00:33:15 barnyard2[68778]: Daemon initialized, signaled parent pid: 66241 May 2 00:33:15 barnyard2[66241]: Daemon parent exiting May 2 00:33:15 barnyard2[66241]: Initializing daemon mode May 2 00:33:15 barnyard2[66241]: INFO database: Defaulting Reconnect sleep time to 5 second May 2 00:33:15 barnyard2[66241]: INFO database: Defaulting Reconnect/Transaction Error limit to 10 May 2 00:33:15 barnyard2[66241]: Log directory = /var/log/snort/snort_em054477 May 2 00:33:15 barnyard2[66241]: Barnyard2 spooler: Event cache size set to [2048] May 2 00:33:15 barnyard2[66241]: Found pid path directive (/var/run) May 2 00:33:15 barnyard2[66241]: Parsing config file "/usr/pbi/snort-i386/etc/snort/snort_54477_em0/barnyard2.conf" May 2 00:33:15 barnyard2[66241]: Initializing Output Plugins! May 2 00:33:15 barnyard2[66241]: Initializing Input Plugins! May 2 00:33:15 barnyard2[66241]: --== Initializing Barnyard2 ==-- May 2 00:33:15 barnyard2[66241]: May 2 00:33:15 barnyard2[66241]: Running in Continuous mode May 2 00:33:15 barnyard2[66241]: Found pid path directive (/var/run) May 2 00:33:13 SnortStartup[61371]: Snort SOFT RESTART for WAN(54477_em0)... May 2 00:33:09 SnortStartup[54083]: Snort STOP for WAN(54477_em0)... May 2 00:33:08 SnortStartup[47312]: Snort STOP for WAN(54477_em0)...At 00:33:08 First sign of Snort starting up after reboot but why twice a STOP command?
At 00:33:13 Snort is starting, also Barnyard2, but why a SOFT restart?
At 00:33:50 Snort is starting again and Barnyard2 is stopping
At 00:33:57 Snort is restarting, but Barnyard2 stays silent.What could be the cause for another start at 00:33:50 and why doesn't Barnyard2 restart?
This also happened after an update of the 2.1 snapshot, but not exactly the same (not a Soft restart and not twice a STOP).
Here is the relevant output after the update:Apr 29 22:18:41 kernel: em0: promiscuous mode enabled Apr 29 22:18:08 kernel: em0: promiscuous mode disabled Apr 29 22:18:08 snort[69204]: SMTP reload: Changing the file_depth requires a restart. Apr 29 22:18:01 barnyard2[80411]: =============================================================================== Apr 29 22:18:01 barnyard2[80411]: Total: 0 Apr 29 22:18:01 barnyard2[80411]: S5 G 2: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: S5 G 1: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: InvChkSum: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: DISCARD: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: OTHER: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: MPLS: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: GRE LOOP: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: GRE IPX: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: GRE ARP: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: GRE PPTP: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: GRE IP6 E: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: GRE IPv6: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: GRE IPv4: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: GRE VLAN: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: GRE ETH: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: GRE: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: IPv6/IPv6: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: IPv6/IPv4: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: IPv4/IPv6: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: IPv4/IPv4: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: IPX: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: ETHLOOP: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: EAPOL: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: ARP: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: FRAG 6: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: FRAG: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: ICMPdis: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: UDPdisc: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: TCPdisc: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: ICMP: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: UDP: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: TCP: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: ICMP-IP: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: ICMP6: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: UDP 6: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: TCP 6: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: IP4disc: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: IP4: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: IP6disc: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: IP6opts: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: IP6 EXT: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: IPV6: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: VLAN: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: ETHdisc: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: ETH: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: Packet breakdown by protocol (includes rebuilt packets): Apr 29 22:18:01 barnyard2[80411]: =============================================================================== Apr 29 22:18:01 barnyard2[80411]: Unknown: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: Packets: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: Events: 0 (0.000%) Apr 29 22:18:01 barnyard2[80411]: Records: 0 Apr 29 22:18:01 barnyard2[80411]: Record Totals: Apr 29 22:18:01 barnyard2[80411]: =============================================================================== Apr 29 22:18:01 barnyard2[80411]: database: Closing connection to database "xxxxxxxxx" Apr 29 22:17:59 barnyard2[80411]: Waiting for new data Apr 29 22:17:59 barnyard2[80411]: Opened spool file '/var/log/snort/snort_em054477/snort_54477_em0.u2.1367266679' Apr 29 22:17:59 barnyard2[80411]: Closing spool file '/var/log/snort/snort_em054477/snort_54477_em0.u2.1367266360'. Read 0 records Apr 29 22:17:59 kernel: em0: promiscuous mode enabled Apr 29 22:17:59 SnortStartup[69497]: Snort START for WAN(54477_em0)... Apr 29 22:17:44 barnyard2[80411]: Waiting for new data Apr 29 22:17:44 barnyard2[80411]: Opened spool file '/var/log/snort/snort_em054477/snort_54477_em0.u2.1367266360' Apr 29 22:17:44 barnyard2[80411]: Using waldo file '/var/log/snort/snort_em054477/barnyard2/54477_em0.waldo': spool directory = /var/log/snort/snort_em054477 spool filebase = snort_54477_em0.u2 time_stamp = 1367266360 record_idx = 0 Apr 29 22:17:44 barnyard2[80411]: Barnyard2 initialization completed successfully (pid=80411) Apr 29 22:17:44 barnyard2[80411]: --== Initialization Complete ==-- Apr 29 22:17:44 barnyard2[80411]: Apr 29 22:17:44 barnyard2[80411]: database: using the "alert" facility Apr 29 22:17:44 barnyard2[80411]: database: ignore_bpf = no Apr 29 22:17:44 barnyard2[80411]: database: detail level = full Apr 29 22:17:44 barnyard2[80411]: database: data encoding = hex Apr 29 22:17:44 barnyard2[80411]: database: sensor cid = 813 Apr 29 22:17:44 barnyard2[80411]: database: sensor id = 1 Apr 29 22:17:44 barnyard2[80411]: database: sensor name = xxxxxxxxx:em0 Apr 29 22:17:44 barnyard2[80411]: database: database name = xxxxxxxxx Apr 29 22:17:44 barnyard2[80411]: database: user = xxxxxxxxx Apr 29 22:17:44 barnyard2[80411]: database: host = xxxxxxxxx Apr 29 22:17:44 barnyard2[80411]: database: schema version = 107 Apr 29 22:17:44 barnyard2[80411]: database: configured to use mysql Apr 29 22:17:44 barnyard2[80411]: database: compiled support for (mysql) Apr 29 22:17:19 barnyard2[80411]: Writing PID "80411" to file "/var/run/barnyard2_em054477.pid" Apr 29 22:17:19 barnyard2[80411]: PID path stat checked out ok, PID path set to /var/run Apr 29 22:17:19 barnyard2[80194]: Daemon parent exiting Apr 29 22:17:19 barnyard2[80411]: Daemon initialized, signaled parent pid: 80194 Apr 29 22:17:19 barnyard2[80194]: Initializing daemon mode Apr 29 22:17:19 barnyard2[80194]: INFO database: Defaulting Reconnect sleep time to 5 second Apr 29 22:17:19 barnyard2[80194]: INFO database: Defaulting Reconnect/Transaction Error limit to 10 Apr 29 22:17:19 barnyard2[80194]: Log directory = /var/log/snort/snort_em054477 Apr 29 22:17:19 barnyard2[80194]: Barnyard2 spooler: Event cache size set to [2048] Apr 29 22:17:19 barnyard2[80194]: Found pid path directive (/var/run) Apr 29 22:17:19 barnyard2[80194]: Parsing config file "/usr/pbi/snort-i386/etc/snort/snort_54477_em0/barnyard2.conf" Apr 29 22:17:19 barnyard2[80194]: Initializing Output Plugins! Apr 29 22:17:19 barnyard2[80194]: Initializing Input Plugins! Apr 29 22:17:18 barnyard2[80194]: --== Initializing Barnyard2 ==-- Apr 29 22:17:18 barnyard2[80194]: Apr 29 22:17:18 barnyard2[80194]: Running in Continuous mode Apr 29 22:17:18 barnyard2[80194]: Found pid path directive (/var/run) Apr 29 22:17:16 SnortStartup[79247]: Snort START for WAN(54477_em0)... Apr 29 22:17:16 SnortStartup[78296]: Snort STOP for WAN(54477_em0)... Apr 29 22:17:04 php: : Restarting/Starting all packages. Apr 29 22:17:00 php: : [Snort] Package post-installation tasks completed... Apr 29 22:16:58 php: : [Snort] Starting Snort using rebuilt configuration... Apr 29 22:16:58 php: : [Snort] Finished rebuilding installation from saved settings... Apr 29 22:16:57 php: : [Snort] Building new sig-msg.map file for WAN... Apr 29 22:16:48 php: : [Snort] Enabling any flowbit-required rules for: WAN... Apr 29 22:16:40 php: : [Snort] Updating rules configuration for: WAN ... Apr 29 22:16:40 php: : [Snort] The Rules update has finished. Apr 29 22:16:30 php: : [Snort] EmergingThreats rules file update downloaded successfully Apr 29 22:16:28 php: : [Snort] There is a new set of EmergingThreats rules posted. Downloading... Apr 29 22:16:27 php: : [Snort] Snort VRT Rules Attempts: 1 Apr 29 22:16:01 php: : [Snort] There is a new set of Snort VRT rules posted. Downloading... Apr 29 22:16:01 php: : [Snort] Snort MD5 Attempts: 1 Apr 29 22:16:01 php: : [Snort] Downloading and updating configured rule types... Apr 29 22:16:01 php: : [Snort] Saved settings detected... rebuilding installation with saved settings... Apr 29 22:14:45 php: : Beginning package installation for snort . Apr 29 22:14:43 php: : [Snort] Package deletion requested... removing all files...EDIT: after another 2.1 snapshot update everything was normal except that Barnyard2 could not connect to database, but that was a hiccup I think. Weird!
-
Bill,
I still have issues with 2.5.7 that I don't understand.
I don't fully understand the whole sequence for pfSense startups either, especially with snapshot updates. It seems that two processes in pfSense kick in during the reboot from a snapshot update. In my view, they sort of interfere with each other (or seem to anyway). Here is my theory. A pfSense expert may be able to debunk this, though. On a normal reboot, you have a process that kicks off to start the installed packages. That's well and good. On a snapshot update, you also have a package uninstall/reinstall process that kicks off to force reinstall all the installed packages. That will also trigger the start of all installed packages (Snort in this case).
So with the background above, here is the rest of the story. Folks wanted Snort to auto-restart following an uninstall/reinstall process, so I added a call to a pfSense service control function to start the Snort service at the end of the snort_post_install() function that gets called by the Package Manager code in pfSense. The first thing the pfSense service control function does is call STOP in the snort shell script to be sure nothing is running on the same interface. It then calls the START function within the shell script. If the START function detects a running instance (or my theory in this particular circumstance is a just-starting-up instance), it sends it the SOFT START SIGHUP command instead of a hard start. So I think that in some situations with snapshot updates, we have up to three things trying to start the Snort package on all the interfaces: the normal boot up script, the special "reinstall all packages script" from the snapshot update, and then the new code I inserted in the Snort package that tries to be sure the package starts on any uninstall/reinstall with save settings.
The only way to sort out all this is for pfSense itself to provide more "state information" to packages in terms of what's going on (such as normal boot, upgrade reinstall of all packages, regular Package Manager manual operations, etc.). That way packages can take context-appropriate actions. For example, Snort would never try to auto-start itself unless a manual, user-initiated uninstall/reinstall process was in progress. For any system-initiated things like reboots or "reinstall all packages from firmware update", it would just play dumb at the end of the install and let pfSense start things using its own processes.
Bill
-
The Snort package HOME_NET and whitelist discussion is moved to here:
http://forum.pfsense.org/index.php/topic,61891.msg334030.html#msg334030
Bill
-
Bill
for the reinstall during bootup i fixed it by this https://github.com/pfsense/pfsense-packages/commit/7a9c4f49b8fcb9b0d9eedd17046fc3b030c9bb96 -
@ermal:
Bill
for the reinstall during bootup i fixed it by this https://github.com/pfsense/pfsense-packages/commit/7a9c4f49b8fcb9b0d9eedd17046fc3b030c9bb96Thanks Ermal! I had actually put the same fix in my working directory copy of the code, but just had not committed it yet to my fork of the pfsense-packages repository. I discovered that trick while looking through some of the other pfSense PHP files.
Bill
