@skogs Hey mate, sorry for not giving you any meaningful information, but you guessed it right.
SID 2035190 was the one that caused issues to me. And yes, we were using lets encrypt for some of our stuff.
Thanks for the valuable info though.
I'm pretty beginner on firewalls. I have a senior admin who mostly look into such sort of things, but I'm trying to be as helpful as I can!
@bmeeks Yep, did that, my idea was to simply set $HTTP_PORTS to the port range 1-65535 so that all traffic is inspected (no idea how bad this would be for performance, it was just for testing). However, it's not that easy. The ports in this variable are written to snort.conf, which can't hold more than 32000 characters in one line, which is way less than needed for all 65535 ports. That means, if you do what I did and set $HTTP_PORTS to 1-65535, Snort will not be able to start on the corresponding interface as the config file cannot be loaded.
There are limits on the size of things, so you need to more carefully analyze what you actually want to look for and then modify the variables appropriately. Looking for HTTP traffic on every conceivable port is not really realistic in my view.
The suggestion about HOME_NET and EXTERNAL_NET was a long shot mentioned just in case you had done some customization. The default settings usually work fine and capture all of the local firewall interfaces via pfSense system API calls. It also grabs things like defined DNS servers, so that's why those external DNS servers are there. They must be defined elsewhere in the pfSense configuration.
Here are two simple flow diagrams that illustrate how packets flow when either of the IDS/IPS packages are installed on pfSense.
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?
Might be a browser caching issue -- maybe with stored credentials and auto-login enabled for the browser.
There is nothing in the Suricata package at all related to logging in to pfSense. The suricata_interfaces.php page is the default landing page when you click Suricata under the SERVICES menu in pfSense.
Did you perhaps have multiple tabs open? Or maybe had an open, but expired, tab on the Suricata Interfaces page and then opened a different tab to login to the firewall GUI?
@bmeeks Thanks for responding, I'm using pfsense, from the gui there is no more data that it doesn't start, there is nothing else, so I start it by ssh but I can't think of much else
I don't think you understand how Suricata works on pfSense. You MUST use the GUI for everything. You CANNOT do things from the command-line -- including starting it by SSH. The suricata.yaml file you see in /usr/local/etc/suricata is not the file used by the Suricata processes on pfSense. Each configured instance (in the GUI) has its own unique subdirectory underneath /usr/local/etc/suricata/, and all of the configuration information for that instance resides in the subdirectory. At startup time, the suricata.yaml file is created from scratch using information stored by the GUI code in the firewall's config.xml file.
The errors in the startup log clearly indicate issues with your NIC driver. It is not playing well with Suricata. I have no idea why, but it is not. Notice these two lines:
Hello, just to let you know the workaround works
I put a higher value in the "overlap-limit", then save the configuration, returned the value to zero, check the snort.conf file and this time it saved the value. Finally, I started the service and now it's working
Thanks for your help
Glad you got it working. That was an unusual issue. Sounds like something weird got saved in the config.xml file for that particular parameter.
Well I'm not smart enough to make a custom feed; but did find good stuff to ease my mind.
SID 2527000 and 2527001
The message portion states ET Threatview.io High Confidence Cobalt Strike C2 IP group 1 and group 2. So...that is what I was looking for.
Comes into the system with the emerging-threatview_CS_c2.rules category.
Thanks for the brainpower expended.
@patch I am learning how to use Haproxy's reverse proxy and using private domain (secret TLS/SNI) to help make the PBX more secure in the DMZ...very interesting...I'll post in the proxy section questions I may have.
If you went the bare metal way with inline IPS as I recommend, you would get full line rate with no sweat.
Do you have any suggestions where I can get a start on sourcing info to head in this direction?
I appreciate your input @bmeeks and you taking the time out of your day to give me guidance on this matter.
First, you will need to get comfortable working with either FreeBSD or Linux at the command line interface. Both are more or less the same. I would tilt towards FreeBSD simply because that is what pfSense is based on, and FreeBSD is said to have the better network stack.
Install FreeBSD (or Linux) on suitable hardware. As I mentioned, you will need three NICs to make things easy. One is your managment interface and should get an IP address from your LAN. The other two get no address assigned. They are simply going to be input and output ports running in promiscuous mode.
Next you install Suricata on the machine. On FreeBSD, there is a package in the ports tree. For Linux, there are also suitable packages available for installation.
One last thing I will mention is that administering an IPS is a big challenge and requires quite a bit of knowledge and experience. If you are new to this, prepare to be very frustrated initially by false positive blocks. For that reason, you really should run a setup in IDS mode for a month to see what alerts get triggered on your network. You then selectively "tune" your rule set to get rid of false positives. Only then should you turn on the blocking of traffic using IPS mode.
No, Suricata has no feature to allow that. The closest you can get is to create your own cron tasks (two of them) that stop Suricata for the duration of your scan, and then start it again when the scan is complete.
You can stop and start Suricata using the shell script /usr/local/etc/rc.d/suricata.sh.
Yeah I have a server (unRAID) with docker containers.
I have a domain name that forwards to my public IP of my WAN.
Then pfSense picks up the domain and provides SSL and allows access to my services behind pfSense.
Normal proxy stuff, nothing really distinct about this setup.
When I rebuild my pfSense I will probably setup VPN and kill publicly accessible stuff and just VPN in instead.
That's how it appears. Or at least it "thinks" it can't see the Internet. The connection attempts on port 443 (HTTPS, or SSL connection) is timing out. That means either the remote site is down, or your personal connection is unable to reach the remote site.
Since this is happening for both Snort and Emerging Threats rules, I would think it unlikely for BOTH remote sites to be down at the same time. Thus that would point the finger over to your end of the connection as where the problem is likely to reside.
Your post is not entirely clear. Perhaps it is a language translation issue ???
Are you saying that now your pfSense box is behind some kind of double-NAT? You must eventually have a public IP in order to route traffic (not an RFC 1918 address). However, if your pfSense box now communicates with some upstream host that in turn provides a NAT to some type of public routable IP, then your Snort rules update should still work.
I assume other Internet traffic through the pfSense box works?? Or do you really mean to say you have isolated this pfSense box from the Internet? If that is the case, then there is no method for an offline update in the Snort package. It requires Internet access to update its rules.
If you are 100% certain the origin of the traffic is from a device running the Signal app, and the captured session is from an active Signal session, then I would tend towards ruling it "false positive".
But if there is any doubt, then a thorough virus/malware scan of the machine would be in order to make sure there is no infection. That is an old worm, though. And so far as I know, there never was a mobile app variation of it -- only PC.
You need to learn to use the features on the SID MGMT tab. Go to that tab, enable the feature by checking the box, then read through all the provided sample conf files for hints on how to use the feature.
Be advised, though, that wholesale changes of the rules is not supported. The feature is mainly for selecting which rules to enable or disable using regex matching, and for altering certain rules actions from say "alert" to "drop".
If you want to create your own rules, then use the Custom Rules option on the RULES tab for an interface. On that tab, choose "Custom Rules" in the Category dropdown, and then type (or paste) your own custom rule (or rules) into the text box. Once done, save the change. Those rules will survive any rules update.
So far as I know, this limitation still exists. Suricata can log the XFF in the EVE output, but XFF cannot be used in detection rules, and thus cannot trigger alerts (which would be required to initiate a block).
Here also. My problem was that I had unchecked that box before so I lost all my setting because I had to un- and reinstall, it wouldn't run anymore.
Anyways, I will have another look if suricata will block my LAN again. 😉
So far so good, although to early to say something definite. What has changed other then the Suricata version is that I don't run any snort rules anymore.
@bmeeks I've taken your advice and switched to inline mode. Thank you for the help.
log4j is still hitting suricata but I no longer see any log4j traffic in the nginx log. So it would seem to have been leakage under legacy mode.
Under inline mode, I'm targetting rules in my dropsid.conf largely by classtype attributes. This seems to be a good compromise between granularity and not having too much config.
What is the significance of the caret in interface names (eve logs and suricata.log)?
26/12/2021 -- 15:10:00 - <Info> -- Using 2 live device(s).
26/12/2021 -- 15:10:00 - <Notice> -- opened netmap:vtnet2/R from vtnet2: 0x81c606000
26/12/2021 -- 15:10:00 - <Notice> -- opened netmap:vtnet2^ from vtnet2^: 0x81c606300
26/12/2021 -- 15:10:00 - <Notice> -- opened netmap:vtnet2^ from vtnet2^: 0x8345fd000
26/12/2021 -- 15:10:00 - <Notice> -- opened netmap:vtnet2/T from vtnet2: 0x8345fd300
The caret interface suffix denotes the OS endpoint of a netmap pipe. In order for Inline IPS Mode to function, two netmap pipes are created- one to send traffic, and one to receive traffic. Each pipe has an OS endpoint (called the host stack endpoint) and a NIC endpoint. Additionally, if your NIC supports multiple queues, you will see more netmap connections created for each supported queue.
So those lines in your log snippet show one netmap connection from host stack to NIC, and another from NIC to host stack. The "R" and "T" values indicate "receive" and "transmit", respectively.
In terms of protocol decoders and logging options, Suricata wins hands down. The one feature Snort has that Suricata lacks is the OpenAppID Layer 7 capability. But that feature is really only of use in certain business environments where there is a desire to either prohibit, or severely limit, social media and streaming content access for employees during working hours. OpenAppID really has no valid application in home networks the way I see it.
The threading features net out a wash (or dead heat, if you prefer). But don't put too much faith in multithreading itself when talking about network traffic. There is the reality that a given flow must be processed by the same thread. And to really take advantage of threading with multiple flows, you need an OS stack and NIC driver combination that is very good at implementing RSS in order to actually spread the traffic load over available CPU cores. Having a multithreaded application is only the beginning of what is required to actually realize substantial performance boosts.
Any IDS/IPS package is really running on borrowed time in terms of the future unless you are willing to implement a full man-in-the-middle scheme to break the end-to-end encryption that is so common with all traffic these days. Even DNS traffic is becoming encrypted more and more often. Email has been encrypted for quite a long time now. And nearly 100% of web traffic is HTTPS (so encrypted as well). Without MITM, an IDS/IPS has practically zero visibility into packet payloads. The best it can do is examine the unencrypted header sections (source and destination IP addresses and ports), and maybe catch a glimpse of the initial cert info exchange between server and client to see what domain is being visited. That's pretty much how OpenAppID works. It's not actually looking at the raw data - just some header stuff.
I am not a fan of Snort3. The complete change in how you configure it sort of soured me on it because porting 2.9.x installations over to Snort3 is a large pain (I'm talking here from the point of view of auto-migrating someone's pfSense installation, for example). I also think the Snort team took way too long to get Snort3 out. I'm afraid they may have missed the boat as Suricata adoption increased during that long drought of Snort3's alpha and beta development time.
This fine tuned it. The issue was with SQUID and SSL use. I needed to just add in the aliasis inside of squid's general setting to pass the traffic to the firewall and not proxy it for Disney plus. It fixed it, no more random issues, and I still have the proxy for the desktop and laptops.
Bill, I agree with you that LAN is the interface that Snort should be run on for the reasons that you state. It would save a lot of confusion for new users if YOU ALL (not sure who YOU ALL is) would update the documentation, help tips in the package and defaults to state this. Right now, all the documentation, help tips and defaults state to configure Snort to run on the WAN interface.
The same should be updated for the Suricata package as well.
You can open Redmine requests to have the documentation updated if desired.
Across interfaces on the same box, "no". Across interfaces on different firewalls, "yes" (provided the two firewalls have identical NIC hardware and the same interface layout).
You can clone an existing interface when creating a new one. That makes the new interface identical to its parent. But this is a one-time event. They do not then auto-sync with each other going forward.
You could accomplish synchronzing rules using the SID MGMT tab feature. Simply assign the same SID conf files to each interface.
@bmeeks Don't get me wrong I love to talk shop it is its own language talking about firewalls with other people. Thank you for all you do. Have a great day. On Palo Alto's side you have to install certificates on the devices so it is encrypted again as it leaves the firewall to the lan side. Maybe the proxy is encrypted also.