IDS/IPS from local list
-
Am considering setting up pfSense as an IDS/IPS but I've got intrusion messages appearing in another machine's syslog that I need to block. How can I get those new (updating all the time in fact) IP addresses into pfSense on an automatic basis? Something like snort I'm guessing but with an internal rule list? I've search the forums but not found anything that remotely points me to a solution, any ideas, please anyone?
-
Not too clear on what exactly you are trying to achieve.
Whats your existing setup and where do you plan to insert pfsense/snort into that network?
Intrusion messages coming into syslog on a machine from a known fixed/static ip machine can be blocked with just a firewall rule, but if you want some syslog messages to go to the destination machine, then snort could be adapted/tweaked to block by src & destination ip address, as well as crafting a unique signature you want snort to block on.
-
Requirements: to set up pfSense as and IDS/IPS on network periphery (its the only firewall I have). I receive syslog messages not related to pfSense on another internal server. I need pfSense/Snort to create new rules based on this source of data. I.e. someone repeatedly logs into my windows server and locks an accout, that gets syslogged across to internal server. How do I get pfSense to pick that event up and block it.
-
This is potentially possible with Snort providing it can see the traffic between the two hosts (the victim where the password is being brute-forced and the attacker that is trying). You can use the threshold keyword in Snort rules to trigger after a specified number of events have fired from that rule. Here is a link to the Snort docs describing the threshold keyword: http://manual.snort.org/node35.html.
There is no built-in way to easily do this with the Snort package today. It is not designed to take "remote inputs". However, if it was on a mirror port such that it could see the traffic exchanged between the hosts, then you could write a custom rule that would fire after a specified number of attempts. Any "alert" generated by Snort on pfSense results in a block of the offending IP when "block offenders" is enabled.
Bill
-
Ooo thanks….reads....
Hmm...Snort would definitely be seeing the traffic. But how would it know about the login failure? Or are you suggesting that >"threshold" attempts from any IP address should trigger a block?
-
Ooo thanks….reads....
Hmm...Snort would definitely be seeing the traffic. But how would it know about the login failure? Or are you suggesting that >"threshold" attempts from any IP address should trigger a block?
You will have to write your own custom rule for detecting login failures from the OS in question. You might find some already written ones on the web. A Google search might show something. Basically you would have to analyze the packet content of a "failed login request" and create a Snort rule that would fire on that specific content. Then you can set the threshold level for that rule.
In the link above there are links to more Snort documentation on writing rules.
Bill
-
Ah so we write a rule that triggers on the reply not the failure in the event logs?
-
Ah so we write a rule that triggers on the reply not the failure in the event logs?
Correct. Here is a link to some examples: http://www.aldeid.com/wiki/Suricata-vs-snort/Test-cases/Multiple-failed-logins. Search Google for the phrase "snort failed login attempts" and go from there. You should find some additional examples. Snort will see the "error code or text" coming back from the victim host. You just have to tell Snort what that "failed login" message looks like. Once it can detect, then you can set a threshold for how many times that rule can fire before triggering an alert.
Bill
-
The key to writing the rule is to make it detect specifically what you want without generating false positive alerts. Some trial and error will be required along with packet captures unless you can find an online example where someone else has already done the work.
Note there are a handful of "failed login" rules in the Snort VRT and Emerging Threats rule packages, but they tend to be for stuff like SSH and maybe FTP. I'm not specifically aware of any for Windows, but that does not mean there might not be some in there.
Bill
-
applauds
Thanks, Bill.
-
applauds
Thanks, Bill.
You are welcome. Here is one more link I found where someone did this eons ago for Windows 2000. This is the Google cached version: http://webcache.googleusercontent.com/search?q=cache:LqAyrNNeSmQJ:sourceforge.net/p/snort/mailman/message/7666254/+&cd=10&hl=en&ct=clnk&gl=us.
The original link appeared to be dead. Here is the text in case the link is dead for you –
-----Original Message----- From: McCammon, Keith [mailto:Keith.McCammon@...] Sent: Friday, July 26, 2002 11:36 AM To: snort-sigs@... Subject: [Snort-sigs] Signature for W2K Login Failure Hey all, I caught that request a few days back for a netbios login failure and started tooling around with the concept of detecting Windows network login failures. However, I don't have access to any 95/98/NT systems (which I couldn't be happier about), so I couldn't hammer out much netbios. But I did manage this: alert udp any 88 -> any any (msg: "W2K Kerberos Login Failure"; content: "|24 30 22|"; content: "krbtgt"; dsize: <300; classtype: unsuccessful-user; rev: 1;) If you're running an AD domain (native mode, which uses Kerberos by default), this should catch failed login attempts. I've done a good bit of testing on a smaller segment without any false positives or negatives. Hopefully you'll have the same results... Cheers Keith
Bill