snort: restarting needed if IP list edited?

Reply to snort: restarting needed if IP list edited? on Thu, 03 Feb 2022 13:57:08 GMT

bmeeks — Thu, 03 Feb 2022 13:57:08 GMT

@digidax said in snort: restarting needed if IP list edited?:

@bmeeks
OK, will take a look into the logs to see, if the updates of the list are imported successful.

OT Question: in the blocked tab, I see the "Last 500 Hosts Blocked by Snort ". In the browser, I can use CTRL+f to search for an IP.

a) is it possible, as a future feature, to get a search filed for an IP when the list is larger, > 2000 entries?

I don't really understand why you would want the block list to grow like that. The suggested setup is to enable the automatic cron task (on the GENERAL SETTINGS tab) that clears blocked hosts who have seen no traffic for the interval specified in the parameter on that tab. For example, if you choose 1 hour, then any IP in the block list that has seen no traffic for the last hour will be automatically removed from the block list after the interval has expired.

There is really no point in maintaining huge block lists. If the same host attacks again, then Snort will detect and block it again. It is usually sufficient to block a host for 15 minutes to an hour. If you have not already, I strongly recommend you enable that setting and configure it for either 30 minutes or 1 hour max.

Snort blocks by making a pfSense system call and inserting the offending IP into a pf table called snort2c. That table is created by pfSense during bootup, and it is a RAM construct. So when the firewall is restarted, that table is recreated from scratch.

b) can I use a command line command to search for a blocked IP and remove it from snort's blocklist?

You can manage the pf firewall engine using the pfctl utility. Here is a link to its documentation: https://www.freebsd.org/cgi/man.cgi?query=pfctl&sektion=8.

Thanks, Frank

Reply to snort: restarting needed if IP list edited? on Thu, 03 Feb 2022 05:11:11 GMT

digidax — Thu, 03 Feb 2022 05:11:11 GMT

@bmeeks
OK, will take a look into the logs to see, if the updates of the list are imported successful.

OT Question: in the blocked tab, I see the "Last 500 Hosts Blocked by Snort ". In the browser, I can use CTRL+f to search for an IP.

a) is it possible, as a future feature, to get a search filed for an IP when the list is larger, > 2000 entries?

b) can I use a command line command to search for a blocked IP and remove it from snort's blocklist?

Thanks, Frank

Reply to snort: restarting needed if IP list edited? on Tue, 01 Feb 2022 14:14:59 GMT

bmeeks — Tue, 01 Feb 2022 14:14:59 GMT

@digidax:
You are getting those messages because you have multiple Snort instances running on what amounts to the same interface (your WAN). I see you have VLANs defined there, but for Snort or any other IDS/IPS, you should instead put a single Snort instance on the parent interface. That will save lots of CPU and RAM resources. Snort runs the NIC in promiscuous mode, so each instance is seeing all traffic (including the other VLANs). Same thing would happen if you just ran a single instance on the parent physical interface.

When Snort starts, it queries pfSense for all of the local addresses and networks defined on the firewall. It adds those to the various HOME_NET and default Pass List settings. Due to you have three WAN interfaces (via the VLANs, I assume), Snort is collecting the same addresses multiple times and adding them to HOME_NET. That's triggering the "re-defined address" warnings. They are harmless messages, though.

And to answer your original question, "yes", those messages show that Snort is reloading its configuration when it receives the SIGHUP command.

Reply to snort: restarting needed if IP list edited? on Tue, 01 Feb 2022 05:24:25 GMT

digidax — Tue, 01 Feb 2022 05:24:25 GMT

@bmeeks said in snort: restarting needed if IP list edited?:

@digidax said in snort: restarting needed if IP list edited?:
@digidax said in snort: restarting needed if IP list edited?:

@bmeeks said in snort: restarting needed if IP list edited?:

You can also send the running Snort process a SIGHUP signal to tell it to reload its configuration. That will prompt the running process to read the snort.conf file again and reload the configuration including rules and IP reputation files. In order to do thisk, you will need to identify the PID of the running Snort process that you want to send the signal to. Then use the pkill command to send SIGHUP to the running Snort PID.

IIn reference to https://www.snort.org/faq/readme-reload and the procedure you wrote above, it's based on the fact, that snort was compiled with the "–enable-reload" option a configure stage.

So how can I find out, which compiling options are used for snort?

Thanks for your help, Frank

When I execute
pkill -SIGHUP snort
then the system log of snort facility begin to displaying redefined addresses. Does this indicated a successful reload?
Since you did not post the log, I can only assume that the reload configuration worked if you saw messages in the pfSense system log. That's where Snort logs its startup and shutdown (and error) messages.

Be aware that the command you indicated is somewhat global -- meaning it is not restricting itself to a single PID. If you only have Snort running on one interface, then it does not really matter. But if you have multiple Snort instances configured on different interfaces, you may want to be more specific with the instance to signal with the "reload" command by using the process ID (PID) of the Snort process on that interface.

Yes I know, but at the moment snort is used on 3 WAN interfaces and the block IP list is also used on all of them. When I add snort to other interfaces, I will do force the reload only on that interfaces which are needed reloaded after changing the IP list from which is reading after the download of the update.

Here is the log after sending a SIGHUP at Feb 1 06:15:00 time order is DESCending.

Feb 1 06:15:07 	snort 	16581 	[136:1:1] (spp_reputation) packets block-list [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 185.181.102.18:11747 -> 94.100.xxx.xxx:179
Feb 1 06:15:02 	snort 	17766 	Additional duplicate addresses were not listed.
Feb 1 06:15:02 	snort 	17245 	Additional duplicate addresses were not listed.
Feb 1 06:15:02 	snort 	17766 	(1309) => Re-defined address: '107.189.6.161'
Feb 1 06:15:02 	snort 	17766 	(1304) => Re-defined address: '107.189.31.191'
Feb 1 06:15:02 	snort 	17766 	(1297) => Re-defined address: '107.189.29.142'
Feb 1 06:15:02 	snort 	17766 	(1291) => Re-defined address: '107.189.14.34'
Feb 1 06:15:02 	snort 	17766 	(1289) => Re-defined address: '107.189.14.180'
Feb 1 06:15:02 	snort 	17766 	(1288) => Re-defined address: '107.189.12.34'
Feb 1 06:15:02 	snort 	17766 	(1280) => Re-defined address: '107.189.1.92'
Feb 1 06:15:02 	snort 	17766 	(1258) => Re-defined address: '107.174.138.172'
Feb 1 06:15:02 	snort 	17766 	(1219) => Re-defined address: '106.75.79.172'
Feb 1 06:15:02 	snort 	17766 	(1216) => Re-defined address: '106.75.64.59'
Feb 1 06:15:02 	snort 	17766 	(1202) => Re-defined address: '106.75.223.50'
Feb 1 06:15:02 	snort 	17766 	(1198) => Re-defined address: '106.75.22.49'
Feb 1 06:15:02 	snort 	17766 	(1190) => Re-defined address: '106.75.184.237'
Feb 1 06:15:02 	snort 	17766 	(1182) => Re-defined address: '106.75.154.53'
Feb 1 06:15:02 	snort 	17766 	(898) => Re-defined address: '104.248.82.49'
Feb 1 06:15:02 	snort 	17766 	(863) => Re-defined address: '104.244.79.120'
Feb 1 06:15:02 	snort 	17766 	(861) => Re-defined address: '104.244.78.148'
Feb 1 06:15:02 	snort 	17766 	(848) => Re-defined address: '104.244.74.28'
Feb 1 06:15:02 	snort 	17766 	(847) => Re-defined address: '104.244.74.253'
Feb 1 06:15:02 	snort 	17766 	(321) => Re-defined address: '101.35.6.240'
Feb 1 06:15:02 	snort 	17245 	(1309) => Re-defined address: '107.189.6.161'
Feb 1 06:15:02 	snort 	17245 	(1304) => Re-defined address: '107.189.31.191'
Feb 1 06:15:02 	snort 	17245 	(1297) => Re-defined address: '107.189.29.142'
Feb 1 06:15:02 	snort 	17245 	(1291) => Re-defined address: '107.189.14.34'
Feb 1 06:15:02 	snort 	17245 	(1289) => Re-defined address: '107.189.14.180'
Feb 1 06:15:02 	snort 	17245 	(1288) => Re-defined address: '107.189.12.34'
Feb 1 06:15:02 	snort 	17245 	(1280) => Re-defined address: '107.189.1.92'
Feb 1 06:15:02 	snort 	17245 	(1258) => Re-defined address: '107.174.138.172'
Feb 1 06:15:02 	snort 	17245 	(1219) => Re-defined address: '106.75.79.172'
Feb 1 06:15:02 	snort 	17245 	(1216) => Re-defined address: '106.75.64.59'
Feb 1 06:15:02 	snort 	17245 	(1202) => Re-defined address: '106.75.223.50'
Feb 1 06:15:02 	snort 	17245 	(1198) => Re-defined address: '106.75.22.49'
Feb 1 06:15:02 	snort 	17245 	(1190) => Re-defined address: '106.75.184.237'
Feb 1 06:15:02 	snort 	17245 	(1182) => Re-defined address: '106.75.154.53'
Feb 1 06:15:02 	snort 	17245 	(898) => Re-defined address: '104.248.82.49'
Feb 1 06:15:02 	snort 	17245 	(863) => Re-defined address: '104.244.79.120'
Feb 1 06:15:02 	snort 	17245 	(861) => Re-defined address: '104.244.78.148'
Feb 1 06:15:02 	snort 	17245 	(848) => Re-defined address: '104.244.74.28'
Feb 1 06:15:02 	snort 	17245 	(847) => Re-defined address: '104.244.74.253'
Feb 1 06:15:02 	snort 	17245 	(321) => Re-defined address: '101.35.6.240'
Feb 1 06:15:01 	snort 	16581 	Additional duplicate addresses were not listed.
Feb 1 06:15:01 	snort 	16581 	(42) => Re-defined address: '107.189.6.161'
Feb 1 06:15:01 	snort 	16581 	(41) => Re-defined address: '107.189.31.191'
Feb 1 06:15:01 	snort 	16581 	(39) => Re-defined address: '107.189.29.142'
Feb 1 06:15:01 	snort 	16581 	(38) => Re-defined address: '107.189.1.92'
Feb 1 06:15:01 	snort 	16581 	(37) => Re-defined address: '107.189.14.34'
Feb 1 06:15:01 	snort 	16581 	(36) => Re-defined address: '107.189.14.180'
Feb 1 06:15:01 	snort 	16581 	(34) => Re-defined address: '107.189.12.34'
Feb 1 06:15:01 	snort 	16581 	(31) => Re-defined address: '107.174.138.172'
Feb 1 06:15:01 	snort 	16581 	(30) => Re-defined address: '106.75.79.172'
Feb 1 06:15:01 	snort 	16581 	(29) => Re-defined address: '106.75.64.59'
Feb 1 06:15:01 	snort 	16581 	(27) => Re-defined address: '106.75.22.49'
Feb 1 06:15:01 	snort 	16581 	(26) => Re-defined address: '106.75.223.50'
Feb 1 06:15:01 	snort 	16581 	(24) => Re-defined address: '106.75.184.237'
Feb 1 06:15:01 	snort 	16581 	(22) => Re-defined address: '106.75.154.53'
Feb 1 06:15:01 	snort 	16581 	(20) => Re-defined address: '104.248.82.49'
Feb 1 06:15:01 	snort 	16581 	(12) => Re-defined address: '104.244.79.120'
Feb 1 06:15:01 	snort 	16581 	(11) => Re-defined address: '104.244.78.148'
Feb 1 06:15:01 	snort 	16581 	(9) => Re-defined address: '104.244.74.28'
Feb 1 06:15:01 	snort 	16581 	(8) => Re-defined address: '104.244.74.253'
Feb 1 06:15:01 	snort 	16581 	(1) => Re-defined address: '101.35.6.240'

When I do comapre it with a "snort restart" command, the lines are identical, additional "SnortStartup 17114 Snort START for WAN1STM(em0)" and the other interfaces where snort is activated are seen with the restart command.

Thanks for your help,
Frank

Reply to snort: restarting needed if IP list edited? on Mon, 31 Jan 2022 19:09:27 GMT

bmeeks — Mon, 31 Jan 2022 19:09:27 GMT

@digidax said in snort: restarting needed if IP list edited?:

@digidax said in snort: restarting needed if IP list edited?:

@bmeeks said in snort: restarting needed if IP list edited?:

You can also send the running Snort process a SIGHUP signal to tell it to reload its configuration. That will prompt the running process to read the snort.conf file again and reload the configuration including rules and IP reputation files. In order to do thisk, you will need to identify the PID of the running Snort process that you want to send the signal to. Then use the pkill command to send SIGHUP to the running Snort PID.

IIn reference to https://www.snort.org/faq/readme-reload and the procedure you wrote above, it's based on the fact, that snort was compiled with the "–enable-reload" option a configure stage.

So how can I find out, which compiling options are used for snort?

Thanks for your help, Frank

When I execute
pkill -SIGHUP snort
then the system log of snort facility begin to displaying redefined addresses. Does this indicated a successful reload?

Since you did not post the log, I can only assume that the reload configuration worked if you saw messages in the pfSense system log. That's where Snort logs its startup and shutdown (and error) messages.

Be aware that the command you indicated is somewhat global -- meaning it is not restricting itself to a single PID. If you only have Snort running on one interface, then it does not really matter. But if you have multiple Snort instances configured on different interfaces, you may want to be more specific with the instance to signal with the "reload" command by using the process ID (PID) of the Snort process on that interface.

Reply to snort: restarting needed if IP list edited? on Mon, 31 Jan 2022 19:06:21 GMT

bmeeks — Mon, 31 Jan 2022 19:06:21 GMT

@digidax said in snort: restarting needed if IP list edited?:

So how can I find out, which compiling options are used for snort?

Thanks for your help, Frank

You would look in the Makefile of the associated binary in the FreeBSD ports tree on GitHub. Here is a direct link: https://github.com/pfsense/FreeBSD-ports/blob/devel/security/snort/Makefile.

I don't recall offhand if there is a command-line option to print out the compile options in the binary.

The "reload" option is enabled in the pfSense package.

Reply to snort: restarting needed if IP list edited? on Mon, 31 Jan 2022 07:04:25 GMT

digidax — Mon, 31 Jan 2022 07:04:25 GMT

@digidax said in snort: restarting needed if IP list edited?:

@bmeeks said in snort: restarting needed if IP list edited?:

You can also send the running Snort process a SIGHUP signal to tell it to reload its configuration. That will prompt the running process to read the snort.conf file again and reload the configuration including rules and IP reputation files. In order to do thisk, you will need to identify the PID of the running Snort process that you want to send the signal to. Then use the pkill command to send SIGHUP to the running Snort PID.

IIn reference to https://www.snort.org/faq/readme-reload and the procedure you wrote above, it's based on the fact, that snort was compiled with the "–enable-reload" option a configure stage.

So how can I find out, which compiling options are used for snort?

Thanks for your help, Frank

When I execute

pkill -SIGHUP snort

then the system log of snort facility begin to displaying redefined addresses. Does this indicated a successful reload?

Reply to snort: restarting needed if IP list edited? on Mon, 31 Jan 2022 05:27:39 GMT

digidax — Mon, 31 Jan 2022 05:27:39 GMT

@bmeeks said in snort: restarting needed if IP list edited?:

You can also send the running Snort process a SIGHUP signal to tell it to reload its configuration. That will prompt the running process to read the snort.conf file again and reload the configuration including rules and IP reputation files. In order to do thisk, you will need to identify the PID of the running Snort process that you want to send the signal to. Then use the pkill command to send SIGHUP to the running Snort PID.

IIn reference to https://www.snort.org/faq/readme-reload and the procedure you wrote above, it's based on the fact, that snort was compiled with the "–enable-reload" option a configure stage.

So how can I find out, which compiling options are used for snort?

Thanks for your help, Frank

Reply to snort: restarting needed if IP list edited? on Sun, 30 Jan 2022 18:48:42 GMT

bmeeks — Sun, 30 Jan 2022 18:48:42 GMT

@digidax said in snort: restarting needed if IP list edited?:

Hello,
With a honey pot, I generate a IP text file list with bad IPs. With cron job and curl I download the file into the snort ip reputation folder. The file is setup in the IP File list and used by the interfaces successfully. Bad hosts are blocked.

Question:
After downloading a new txt file with same filename (overwrite), do I have to restart snort? If so, I would add after curl command this:
&& sleep(1) && /usr/local/etc/rc.d/snort.sh restart
Is this prodcedure right or is there a better way?

all the best, Frank

That command you have will work. It will just restart Snort on all the configured interfaces (which may be what you want).

You can also send the running Snort process a SIGHUP signal to tell it to reload its configuration. That will prompt the running process to read the snort.conf file again and reload the configuration including rules and IP reputation files. In order to do thisk, you will need to identify the PID of the running Snort process that you want to send the signal to. Then use the pkill command to send SIGHUP to the running Snort PID.