@TEP71:

Bill,

Thank you very much. I understand I will have to change this every time there is an update. It wasn't a hard change to make and it is something I can do when needed. Thank you again for your time.

–Thom

Glad to be of help.

Bill

That's happening because of a SIP rule (spp_sip)… and yeah, a web address URL for many sites would certainly be too long for SIP. The better question would be why a SIP rule is being triggered for a web connection.

Your rule is missing the proper action keyword and a classification parameter.  The valid action keywords are generally "alert" or "drop".  On pfSense, "alert" is the only valid keyword.  The classification is a parameter string obtained from the classification.config file.

One easy way to test Snort is to enable the Emerging-Threats Scan rules, then visit one of the online scanner web sites and have it scan your public IP for exposed services.  That should trigger Snort.  You can do the same by scanning your WAN IP (assuming that's where Snort is installed) with nmap.

Saves you the problem of writing a custom rule.  Snort is quite unforgiving with syntax errors as you see.

Bill

Not Nano - full standard install from .iso onto 90gb SSD.

Yes, I did a complete wipe and installed 2.3 Release, then set up pfBlockerNG and Suricata. I couldn't get suricata to work at all. I disabled it, installed Snort, set up and it is working. Then, I upgraded to 2.3.1 Dev and it is still all working.

I think i may have the netmap issues going on. I'll wait until problem is solved before tackling Suricata again. Thank you for your help and your comments in other threads about issues with netmap.

@pfsenseboonie:

Wishlist Item

When listing internal IPs in alerts tab it uses the real IP and not the IP of the external pfsense interface.

For example…
client = 1.2.3.4
router external iface = 2.2.3.4
ISP modem = 2.2.3.1

ping from any client to ISP modem.
In alerts log would be DST = 2.2.3.1 and SRC = 2.2.3.4

Running Suricata (or Snort) on the WAN means the sensor sees inbound traffic before any NAT rules have applied, and outbound traffic after NAT rules have been applied.  Either way internal hosts are generally not visible if you use NAT and have Suricata or Snort on the WAN.  The solution to this problem is to run the sensor on your LAN interface(s) and not the WAN when using NAT.

Bill

Bill:

Thanks for the update. You have confirmed the issue.

Howard

@vbentley:

I am unfamiliar with bootstrap, but I think this is a style sheet issue. I have had a quick look but run out of time today to actually start experimenting with changes.

In pfSense.css it look like this style dictates the width

.col-sm-10 .form-control {     width: calc(50% - 15px); }

I will try and get back to this later in the week.

You are correct it can be fixed by modifying the CSS, but it would not be good behavior for a package to do that.  You can override the Bootstrap default style for any object (HTML element, actually) by adding the appropriate attribute on the page.  I've done that in other places within the GUI for Snort and Suricata for textarea controls.  I will do the same for this control.

If you want to experiment (and maybe learn a little about Bootstrap), here is an example of adding the additional attributes to the textarea control –

$modal->addInput(new Form_Textarea ( 'logtext', '', '...Loading...' ))->removeClass('form-control')->addClass('row-fluid col-sm-10')->setAttribute('rows', '10')->setAttribute('wrap', 'off');

In Bootstrap, the class "col-sm-10" sets the width of an element relative to Bootstrap's 12-column grid.  It assumes the display device's screen is evenly divided into 12 columns.  So the widget above is set to be 10 columns wide.  Ignore the use of $modal.  In the file we are discussing for editing a Suppress List, the variable name is $section.

Bill

Thanks!
I'll re-enable it for 1 time per second and disable that rule in suricata.

No i its not a fancy setup just connected to the ISP fiber router/switch/modem.

@lokapal:

I guess real busyness environments will use Cisco solutions anyway in most cases  ::)
My case is much more similar to educational organization campus. Do you like to explain to x00 linuxoids why they can't download at lightspeed their favorites ubuntus, debians, gentoos and scientific linuxes via bittorrent at least after worktime? 8) The same thing with online gaming…  ;D

Why don't you create a Guest Wireless Network and give greater freedom there, but restrict its access to your school LAN?  Do you let the folks install and run P2P clients and games on your business or school machines?  If so, I would say that is a bad policy.

At any rate, the answer to your original question is that currently neither IDS/IPS package offers such scheduling (it is not present in the underlying binaries anyway), and such a feature is not currently on the long-term planning radar.  You can schedule firewall rules within pfSense itself, but using those will be problematic because you would need to capture all the IP addresses of the potential P2P and gaming sites.  That is hard because the IPs can change frequently.

Bill

I suspect it is working now.  That bug with the number of entries to display on the BLOCKS tab would cause it to by default display just one row.  Forcibly saving a new numerical value would fix any bogus value that might have gotten saved when the bug was in the code.

All these things are fallout from the Bootstrap conversion of the package.  Bootstrap implements things a bit differently than the old system, and lots of things related to form input elements had to be changed in the GUI code.

Bill

Firewall rules have nothing at all to do with your Snort rules update problem.  It is complaining about the certificate trust chain.  There either is, or your configuration makes cURL think there is, a self-signed certificate in the chain.

Have you tried removing Squid entirely for a test to see if the rules download then?  The Snort code uses the built-in system function cURL() to download updates.  That function is called with a parameter set to verify SSL peers (in other words, check the certification trust chain).  That check is failing on your system because of the some specific configuration you have.  My bet is the problem is with Squid.

Bill

@ntct:

Maybe similar problems about netmap.

https://github.com/luigirizzo/netmap/issues/156

https://github.com/luigirizzo/netmap/issues/134

Hmm…might be some Netmap problems that are not directly related to Suricata.  pfSense 2.3 now compiles Netmap support into the kernel by default.

Bill

There was a bug in the Suppress List code early on immediately after the initial Bootstrap version of the package was released.  It was eventually fixed, but it is possible it caused some junk to be left behind in your configuration.

Bill

Good point and that is exactly what I was experiencing with Snort.  Seems to be working OK now after reinstall.  And just to follow up on my CRON issues that has cleared up as well. One of my CRON entries uses the wget command.  I'd forgotten I had to install that command as it is not native to the pFsense package.  So, for the machine I updated to 2.3 the wget command was already there and CRON worked.  For the machine I installed a fresh 2.3 the wget command was not there so CRON did not work and I assumed it was for some other reason.  Once I had time to look closer I realized the problem.  All is running smoothly now.  Again, thanks for your response.

@pfsenseboonie:

Hi bmeeks, another one.

When operating in legacy mode, blocks are shown on the blocks tab (https://<url>/suricata/suricata_blocked.php).
Say I have list of blocks on this tab #1 - #7, If i want to delete block #3 and do so then blocks #3 - #7 are deleted instead of only #3</url>

I will check this out.  I have some other fixes to put into the Suricata package as well.

Bill

i have that rule in my supress List

suppress gen_id 137, sig_id 1

Seems this issue resolved itself when I updated to the 3.2.9.1_11 package so I'm marking it at solved.

@nfr:

This is now fixed since 3.2.9.1_11. I also had some old information in the configuration from years ago when when using squid proxy. I removed a bunch of lines that were related to that and did a restore configuration from file. When the system rebooted everything came up correctly as well as upgrading to 3.2.9.1_11 from 3.2.9.1_10.

On a unrelated item I noticed that the <blockoffendersip>both</blockoffendersip> setting got cleared when comparing configuration files. I was able to change this back in the web interface and it created a <blockoffendersip>2</blockoffendersip> .

Whoa.  The <blockoffiendersip>setting is not correct.  It should be "both".  Looks like another Bootstrap conversion boo-boo due to how combo select boxes are coded in Bootstrap.  That might explain what some other folks are seeing.  I will investigate the code to be sure.  In the meantime, that value in your config.xml really should be the string "both".

UPDATE:  I found the source of that incorrect setting. The fix will be out soon.

Thanks for reporting this to me.

Bill</blockoffiendersip>