Snort 2.9.4.6 pkg v2.6.1

BBcan177

What logs can I look at to see if Snorts performance ie-dropping packets or CPU/Memory issues?

From the main pfsense:Dashboard I never see any performance issues that would cause any concerns.

I have Snort blocking on the WAN SRC/DST and killing states. I also have Security Onion running immediately after pfSense performing Full Packet Capture and I am seeing every blocked alert from pfSenses Snort in my Security Onion Alert System. Both Running the same rulesets (Snort and ET)

Dropping packets in snort terms means blocking the packet. The reason that we say that they are being dropped it's that the rules actually start with drop instead of alert.

I'm guessing that you actually get alerts behind pfsense, because by the time that snort is finished with analysing the packet and sets up the ban, the packet is not actually stopped from going through the network. Imagine the packet getting copied on the fly, a copy is sent down the network, and the other copy is sent for analysis (overly simplified, gets the point across though). I'm willing to bet money that if you trigger a rule a second time, with some time between the triggers (let's say a couple of minutes just to be sure) you will not get the alert/lights/fireworks on the box behind pfsense for the second time.

A single host network (pfsense running snort, protecting 1 server/pc behind it) doesn't actually make a lot of sense. Sure you get alerts, but by the time the alerts are generated, the packets have already reached their destination. A multi-host network (pfsense running snort, protecting a dozen servers/pcs) makes a lot more sense.
Let's take this scenario (which is actually what I described in the past, about detecting network scans on multiple hosts): pfsense 192.168.1.1, host a 192.168.1.2, host b 192.168.1.3 and so on and so forth, until host xyz 192.168.1.100
An attacker sets up a network scan for an open port 22, pressumably because he forgot that this is 2013 and password based ssh logins are forbidden by international law and treaties (SET UP KEY BASED LOGINS NOW!). The scan (actually the program generating the scan) starts sending packets asking for a connection to port 22 (let's say simple syn packets for argument's sake). There are a total of 100 packets that should reach our network of 192.168.1.1-192.168.1.100. The packets start arriving at the pfsense host and start going through it (assuming that there is a port forward for port 22, just play along and stop arguing :p ). At this point, let's say that hosts 192.168.1.2-192.168.1.5 saw the packets and actually answered. Snort already picked up that this is a network scan for an open port, since it has a rule that says: "if x packets destined for y hosts arrive in z seconds, assume that a network scan is in progress and raise an alert". The process of banning a host has started, since the alert was raised. Packets are still flowing up to this point through the pfsense box, and hosts behind it are still answering those connection requests. By now hosts 192.168.1.1 up to 192.168.1.50 have actually answered those connections. The banning process is complete, and the firewall states are killed. This interrupts the flow of those suspicious packets through the network. It might sound futile, but you have actually protected the other 50 hosts just by using the 50 hosts that answered as a "decoy". The second time round, this time the attacker decides to scan for open port 25, the ban is already in place (assuming that you have snort fine tuned to the point of being called a psychiatrically unstable person and have the max ban time set at 28 days, hint hint). No packets are allowed through the firewall, and the entire network is protected. The bonus thing is, since snort actually raised an alert the second time round (imagine it as if snort is running in front of pf, it's extremely close to how it actually works in reality) since the packets get analyzed before being dropped (blocked) by pf, the "last time this host was bad" gets updated, and the remaining days to unban gets reset.

That was a long post, but I tried my best to explain why you see packets flowing through the snort/pfsense box. If something is not along those lines ie. the alert is already raised, the banned hosts table is not automatically cleared, and the ban in other words should be effective but it's not, something is wrong with the pfsense rule blocking(dropping) those packets. By the time snort stands up and shouts "IT'S HIM, I'VE SEEN HIM!", the suspect is already identified and flagged as "most wanted". The second time round, no packets should be allowed through, and this actually has nothing to do with snort, it's all pf from there on.

Troubleshooting:
Start your packet capture behind pfsense. Manage to trigger an alert using an outside host (a host not part of your home network). Make sure that the alert is raised, and the host is added to the blocked tab (MAKE A NOTE OF THE TIME SHOWN HERE). Go into Diagnostics>tables>snort2c (off the top of my head, could be wrong) and verify the host is there. This completes snort's part. If the host is there, snort is working as expected. If the host is not there, snort is not adding it to the blocked table. The packet capture should show packets arriving behind pfsense, since this is the first time round.
Leave the packet capture running, and trigger the alert after a couple of minutes (to account for table refresh, updates to rules, cosmic events, etc etc) This time you should see an alert generated by snort, The blocked tab should by updated by the new time (since technically this is a new alert). The packet capture should NOT show any packets arriving behind pfsense. If it shows packets arriving behind it, then there is something wrong with the rule that pfsense uses to block hosts (using the snort2c table).

Short summary for the impatient: First time round, you will see packets flowing through (a typical IDS). Second time round no packets should flow through.

Edit: fixing typos

Supermule

Look…

Qoute from Snort.org

Snort is an open source network intrusion prevention system, capable of performing real-time traffic analysis and packet logging on IP networks. It can perform protocol analysis, content searching/matching, and can be used to detect a variety of attacks and probes, such as buffer overflows, stealth port scans, CGI attacks, SMB probes, OS fingerprinting attempts, and much more.

Notice the REALTIME traffic analysis part....

In sniffer mode, the program will read network packets and display them on the console. In packet logger mode, the program will log packets to the disk. In intrusion detection mode, the program will monitor network traffic and analyze it against a rule set defined by the user. The program will then perform a specific action based on what has been identified....

Notice that part where its says it will perform a specific action based on what has been identified.

Packet comes in at WAN -> gets analyzed -> put up against a predefined ruleset -> block or pass.

This happens in realtime!

So youre wrong.

@Supermule:

Look…

Qoute from Snort.org

Snort is an open source network intrusion prevention system, capable of performing real-time traffic analysis and packet logging on IP networks. It can perform protocol analysis, content searching/matching, and can be used to detect a variety of attacks and probes, such as buffer overflows, stealth port scans, CGI attacks, SMB probes, OS fingerprinting attempts, and much more.

Notice the REALTIME traffic analysis part....

In sniffer mode, the program will read network packets and display them on the console. In packet logger mode, the program will log packets to the disk. In intrusion detection mode, the program will monitor network traffic and analyze it against a rule set defined by the user. The program will then perform a specific action based on what has been identified....

Notice that part where its says it will perform a specific action based on what has been identified.

Packet comes in at WAN -> gets analyzed -> put up against a predefined ruleset -> block or pass.

This happens in realtime!

So youre wrong.

I accept your apology (which will come after you re-read the documentation, no offence meant).
I've already stated the difference between an IDS and an IPS (multiple times, multiple threads, no one seems to understand it so far). I'll have another go at it.

Intrusion Detection System:
Snort NOT running drop rules (rules that start with the word drop) >>>AND<<< not running in inline mode (see next paragraph) will NOT "hold" the packets, but instead let them through, capture a copy in realtime, and analyze the copy instead, then perform the action stated by the rule (alert for example). I will NOT accept any statement stating anything to the contrary. It's the way it was,is and will be.

Intrusion Prevention System:
Snort running drop rules >>>AND<<< running in inline mode. Snort sees the packet, "holds" the actual packet for further processing, processes it, then performs the action based on the rule (drop for example).

Notice the >>>AND<<< part above. Snort in pfsense is NOT running in inline mode. There might be rules starting with drop, but since the critical "hey I must stop this packet, hold it and analyze it, then perform an action" part is missing, snort on pfsense doesn't actually know how to stop a packet from passing through it.

Again, I accept your apology, after all we are all here to learn.

BBcan177

I had this alert this morning (EST Time)

and the Security Onion Alert (UTC time)

I have also attached the SO pcap files (gzip and a Bro pcap)

I confirmed with the user that generated this alert that he did get a "Reload" web page and hit "Reload" a few times but nothing showed up in his browser.

So good news.

[Pcap gzip.txt](/public/imported_attachments/1/Pcap gzip.txt)
[pcap Bro.txt](/public/imported_attachments/1/pcap Bro.txt)

BBcan177

Images didnt upload properly. See attached.

Alert.jpg_thumb

Supermule

Are you drunk??

Under the WAN categories in Pfsense there is the following:

Snort IPS Policy selection

Use IPS Policy If checked, Snort will use rules from the pre-defined IPS policy selected below.

Note: You must be using the Snort VRT rules to use this option. Selecting this option disables manual selection of Snort VRT categories in the list below, although Emerging Threats categories may still be selected if enabled on the Global Settings tab. These will be added to the pre-defined Snort

IPS policy rules from the Snort VRT.

IPS Policy Snort IPS policies are: Connectivity, Balanced or Security.

Connectivity blocks most major threats with few or no false positives. Balanced is a good starter policy. It is speedy, has good base coverage level, and covers most threats of the day. It includes all rules in Connectivity.Security is a stringent policy. It contains everything in the first two plus policy-type rules such as Flash in an Excel file.

Are you saying it doesnt block even if stated when checking the IPS policy tick box??

Notice by the way it says IPS…and NOT IDS!

@jflsakfja:

@Supermule:

Look…

Qoute from Snort.org

Snort is an open source network intrusion prevention system, capable of performing real-time traffic analysis and packet logging on IP networks. It can perform protocol analysis, content searching/matching, and can be used to detect a variety of attacks and probes, such as buffer overflows, stealth port scans, CGI attacks, SMB probes, OS fingerprinting attempts, and much more.

Notice the REALTIME traffic analysis part....

In sniffer mode, the program will read network packets and display them on the console. In packet logger mode, the program will log packets to the disk. In intrusion detection mode, the program will monitor network traffic and analyze it against a rule set defined by the user. The program will then perform a specific action based on what has been identified....

Notice that part where its says it will perform a specific action based on what has been identified.

Packet comes in at WAN -> gets analyzed -> put up against a predefined ruleset -> block or pass.

This happens in realtime!

So youre wrong.

I accept your apology (which will come after you re-read the documentation, no offence meant).
I've already stated the difference between an IDS and an IPS (multiple times, multiple threads, no one seems to understand it so far). I'll have another go at it.

Intrusion Detection System:
Snort NOT running drop rules (rules that start with the word drop) >>>AND<<< not running in inline mode (see next paragraph) will NOT "hold" the packets, but instead let them through, capture a copy in realtime, and analyze the copy instead, then perform the action stated by the rule (alert for example). I will NOT accept any statement stating anything to the contrary. It's the way it was,is and will be.

Intrusion Prevention System:
Snort running drop rules >>>AND<<< running in inline mode. Snort sees the packet, "holds" the actual packet for further processing, processes it, then performs the action based on the rule (drop for example).

Notice the >>>AND<<< part above. Snort in pfsense is NOT running in inline mode. There might be rules starting with drop, but since the critical "hey I must stop this packet, hold it and analyze it, then perform an action" part is missing, snort on pfsense doesn't actually know how to stop a packet from passing through it.

Again, I accept your apology, after all we are all here to learn.

bmeeks

@Supermule:

Are you drunk??

Under the WAN categories in Pfsense there is the following:

Snort IPS Policy selection

Use IPS Policy If checked, Snort will use rules from the pre-defined IPS policy selected below.

Note: You must be using the Snort VRT rules to use this option. Selecting this option disables manual selection of Snort VRT categories in the list below, although Emerging Threats categories may still be selected if enabled on the Global Settings tab. These will be added to the pre-defined Snort

IPS policy rules from the Snort VRT.

IPS Policy Snort IPS policies are: Connectivity, Balanced or Security.

Connectivity blocks most major threats with few or no false positives. Balanced is a good starter policy. It is speedy, has good base coverage level, and covers most threats of the day. It includes all rules in Connectivity.Security is a stringent policy. It contains everything in the first two plus policy-type rules such as Flash in an Excel file.

Are you saying it doesnt block even if stated when checking the IPS policy tick box??

Notice by the way it says IPS…and NOT IDS!

@jflsakfja:

@Supermule:

Look…

Qoute from Snort.org

Snort is an open source network intrusion prevention system, capable of performing real-time traffic analysis and packet logging on IP networks. It can perform protocol analysis, content searching/matching, and can be used to detect a variety of attacks and probes, such as buffer overflows, stealth port scans, CGI attacks, SMB probes, OS fingerprinting attempts, and much more.

Notice the REALTIME traffic analysis part....

In sniffer mode, the program will read network packets and display them on the console. In packet logger mode, the program will log packets to the disk. In intrusion detection mode, the program will monitor network traffic and analyze it against a rule set defined by the user. The program will then perform a specific action based on what has been identified....

Notice that part where its says it will perform a specific action based on what has been identified.

Packet comes in at WAN -> gets analyzed -> put up against a predefined ruleset -> block or pass.

This happens in realtime!

So youre wrong.

I accept your apology (which will come after you re-read the documentation, no offence meant).
I've already stated the difference between an IDS and an IPS (multiple times, multiple threads, no one seems to understand it so far). I'll have another go at it.

Intrusion Detection System:
Snort NOT running drop rules (rules that start with the word drop) >>>AND<<< not running in inline mode (see next paragraph) will NOT "hold" the packets, but instead let them through, capture a copy in realtime, and analyze the copy instead, then perform the action stated by the rule (alert for example). I will NOT accept any statement stating anything to the contrary. It's the way it was,is and will be.

Intrusion Prevention System:
Snort running drop rules >>>AND<<< running in inline mode. Snort sees the packet, "holds" the actual packet for further processing, processes it, then performs the action based on the rule (drop for example).

Notice the >>>AND<<< part above. Snort in pfsense is NOT running in inline mode. There might be rules starting with drop, but since the critical "hey I must stop this packet, hold it and analyze it, then perform an action" part is missing, snort on pfsense doesn't actually know how to stop a packet from passing through it.

Again, I accept your apology, after all we are all here to learn.

Guys:

Let me see if I can interject here. You are both sort of right. Snort on pfSense is an unique animal. It is a hybrid IPS/IDS. It is true that the Snort binary is not literally operating in the "inline mode" because that would require really deep hooks into the kernel and network stack. Instead, it uses the built-in pfSense firewall to insert blocks after it detects a threat (an alert). I don't know exactly how the internals of the pfSense packet filter engine work, but I suspect it is true that one or two packets might "leak through" Snort before the firewall block is inserted and further packets dropped.

So it does block offending traffic eventually, it's just that one or two packets might make it through during the "grabbing and analyzing" phase. So it's not a pure IDS because it does block the bulk of the traffic. It's not a true IPS either, because it is not operating in literal inline mode on pfSense.

Bill

BBcan17:
It's my understanding that the issue you were having has been explained and snort was confirmed to be working as expected. Correct?

Supermule:
Trust me, I know what I'm talking about. I don't like arguments about my work area.

bmeeks:
It's either a Prevention system (no packets going through it unless specifically allowed to), or a Detection system (packets flow through while the analysis happens). You cannot have a hybrid system.

I'll try and explain why a hybrid system can not exist:
Disclaimer: The following paragraph is purely theoretical. Software creators and/or vendors should not consider it as stating true facts.

A new openssh buffer overflow was found. Snort's signature creators (let's go with ET) have identified it, and created the appropriate signature for it. The unique thing about this new overflow is that within a single packet a buffer can be overflowed to the point that a listening process (openssh in this case) can be made to accept incoming commands and execute them immediately. You as the system admin, do not have the knowledge to patch your openssh binary and are waiting for the new update to come out.
You sit at the NOC (Network Operations Center, ie. the monitor attached to a P4 box that you use to make sure pfsense is working) and start seeing alerts showing up in snort's tab. You check to make sure that the host is added to the blocked tabs and go on with your day. What has actually happened is that 20 of your servers have had their buffer overflowed and have actually executed the incoming commands the attacker has sent. I'll go with the add a new user example. The other 80 servers behind your pfsense box have not had their buffers overflowed simply because the packets never actually reached them, since snort had already raised an alert and pf took over.
At this point, using pure definitions an intrusion has already happened. The systems in place detected it and reacted to it. Since the intrusion has already happened, the systems in place did not prevent it. Therefore, using pure definitions the system is acting like a true IDS.
A couple of days later, the malicious user returns, this time with a new IP. Snort doesn't detect anything suspicious about him, because the user simply connected to the openssh servers as an authorised user, with the correct password. After connecting to the already compromised servers, he executes his exploit script. This time the traffic is internal to the network (doesn't actually reach the firewall, this is extremely important, please re-read it). I already see the "are you drunk comments". An exploit executed using IPs has nothing to do with the firewall, assuming that all the hosts are in the same subnet. It's actually in the first paragraph of every single book written about networking. Snort never sees the traffic, although the sys admin was using best practices and even set up snort to listen on the internal interfaces. Nothing suspicious shows up anywhere. The truth is that every single server behind the pfsense box is already compromised, new users have been added to the system, log's tampered with, rkhunter's propupd was executed so nothing suspicious will show up (the admins will get an alert saying to inspect the server, but upon login and executing rkhunter –sk -c they get no warnings and figure out it was a fluke), The only place the entire intrusion shows up is in a log file on the centralised syslog server. The attacker being an actual hacker and not a script kiddie, and actually using his head, checks all the system's syslog configs and already knows that the sys admin messed and used a syslog server with an IP in the same subnet as the hosts it was supposed to log, executes his exploit and compromises that system as well.
6 months later a new sysadmin notices that sexykitten1 was not supposed to exist in the user's file and investigates further. He has to deliver the bad news that no logs show up anything, therefore there is no proof for legal prosecution. The attacker got away completely clean, simply because the system had a D instead of a P. There can never be a hybrid system.
You either act on the intrusion attempt, or re-act to the attempt. Acting is not raising an alert. Acting is holding the packet in your hand while you make up your mind if it needs to be let through or not.

Edit:typos

Supermule

And Snort does that realtime!

All packets flow through are analyzed before going to the servers and compared to the snort rulesets!

And either blocked or not.

If I trigger anything in pfsense then my connection is dead and doesnt come back unless I clear i manually.

Supermule, please understand that I have nothing against you, but please also understand this. You might have noticed that I have never cited anything from the snort documentation. This could be to due to the following reasons:
a) I have absolutely no idea what I'm talking about, and I'm pulling this out of my ….
b) I have the entire snort documentation memorised in my head.

Snort is NOT snort inline. Inline was abandoned because the suricata project basically took over the development. This is not something that I say just for saying it. The source is here: http://snort-inline.sourceforge.net/

This website (http://snort-inline.sourceforge.net/oldhome.html)
"What is snort_inline?
snort_inline is basically a modified version of Snort that accepts packets from iptables and IPFW via libipq(linux) or divert sockets(FreeBSD), instead of libpcap. It then uses new rule types (drop, sdrop, reject) to tell iptables/IPFW whether the packet should be dropped, rejected, modified, or allowed to pass based on a snort rule set. Think of this as an Intrusion Prevention System (IPS) that uses existing Intrusion Detection System (IDS) signatures to make decisions on packets that traverse snort_inline."

To be perfectly, crystal clear. Snort in pfsense does NOT block any packets. This is were you are misunderstanding both the documentation and explanations. Up until the point that pf is aware that the traffic should be blocked, packets are still flowing through the box. This is basically the 2 seconds it takes for snort to analyse the COPY of the packets, raise an alert, the "module" that's responsible for looking through the alerts and blocking hosts becomes aware of the new alert, add the host to the snort2c table, and THEN pf becomes aware of the block.
If you saw any behavior contradicting this, you have basically proven both me (I will not publish who I am, trust me I do know a lot about this) and the package maintainer that did not implement the inline mode in the package. In other words you have a pfsense box running snort in inline mode, at which point please publish how you did it, it will be a HUGE (huge is actually a very small word to describe it) advantage to the entire Internet community. Quantum computing is dwarfed and will be forgotten if you managed to get snort to run inline on a regular pfsense box. A couple of posts up was the actual maintainer of the snort package basically telling you,us, all of us, that snort inline is a huge amount of work to be implemented in pfsense. I would love to have snort inline running in pfsense, or better still suricata, but for now, it's not happening. The way it works was explained by me, in details. Plenty of details.
No matter how much of the documentation you cite, it does not contradict any of my statements. Snort is reacting to a COPY of the packet, the actual packet is not affected in ANY way. The actual packet travels along the network as it should. To be able to keep up with any huge amount of traffic, you do not mess with the traffic, but take a copy of the traffic and mess with that, taking all the time you need for analysis.
Hint: Want me to analyse how the boxes set up by the world's most favourite three letter agency, to capture insane amounts of traffic (in the order of multiple 10Gb/s connections) work? I'll analyse it. Our favourite privacy invading three letter agency has set up a few hundred boxes that basically bridge connection A to connection B. Traffic flows through that bridge, while a copy is captured and sent down connection C. "You have no idea what you are talking about". I do. Splicing a fiber cable in the middle of the ocean, without anyone noticing means that you do NOT mess with the traffic flowing through it. The traffic needs to flow exactly as it was before. A couple of ms of delay could go unnoticed, but a 10Gb/s connection suddenly working as 1Gb/s WILL be noticed. So we have established that traffic is bridged from point A (let's say West side of the cable) to point B (East side of the cable). The Y splicer (basically a bridge in 2 of its points) splits the signal (a laser beam) down 2 paths. At this point you should consider that traffic being copied and dumped into the middle of the ocean is of no use to anyone. The traffic needs to travel a down a separate connection to a server were it is processed. So far I'm talking about the fiber splicers, which went unnoticed for the past 10 years. And most of those splicers are still unnoticed, and will never be noticed. Why? Simply because noone will bother to check every single inch of a multiple hunder km cable. Nobody even now has any idea on the amount of cables that were compromised by this. Let's just say that ALL fiber cables running into ALL countries are compromised. I will not cite anything to confirm this, you just have to take my word on it. What happens when you want to capture a traffic flow on an copper wire? You either leave the wire untouched, and act on the magnetic field around it (this is NOT theoretical, electricity flowing down a cable produces a magnetic field around the cable, but doesn't work all the time, takes a lot of effort to get it to work right) or you simply cut the wire, put a couple of ethernet plugs on either end, plug them into a box, and bridge the 2 connections. A small tip: MAC addresses. Then a packet capture on that flow is sent down a third connection, where it takes all the time it needs to flow and be written to disk (or multiple PCI-E SSDs). The users of the regular copper connection might see an outage lasting a couple of minutes, no harm done. As you can see, to keep up with any flow of traffic, you do NOT delay the actual traffic. This is not some made up story for scaring kids, it's actual facts scaring (as it should) sys admins around the world. The sooner we all wake up to this, the better for us all. Hell a spy station is a 5 minutes drive from my house, come on, complete with fiber lines running to it, I was there when the trenches were dug up in the roads, as well as 2 huge sattelite relay antennas (a bridge capturing traffic while is sent from 1 sattelite to another? sounds interesting).

Your system might be so fast that the connection is dropped extremely fast. Extremely fast is NOT realtime. Even a 0.000000000000000001 nanosecond delay is NOT realtime. And please don't forget that the actual packet, as described in my earlier openssh exploit example, HAS actually reached the boxes it was meant for. I have even written troubleshooting instructions to confirm this. You don't even need a separate box, you can do this on pfsense. Set up a packet capture on your DMZ side, and trigger an alert using an outside host (not part of DMZ, with traffic destined for DMZ). Packets WILL reach the DMZ, maybe 1 packet, maybe 100, depending on your connection.

Since this discussion actually happened a couple of times now, I propose that the pfsense documentation is updated, stating that snort acts as an IDS. I would hate to be that guy that thinks snort in pfsense is an IPS, and finding out a couple years later that that was not the case.

Again, I have nothing against anyone, and have tremendous respect for all you guys, but as Theodore H. White said "The most difficult thing in the world is to know how to do a thing and silently watch someone else do it wrong."

Supermule

:D

(my only comment to this)

@Supermule:

:D

(my only comment to this)

Others buy flowers to apologize, others smile. As I said, I already accepted your apology.
No harm done, I just hope we all learned something new today :D

demco

jflsakfja:
Thanks for the detailed explanation.

Can snort be a true IPS (without leaking the initial offending packets), maybe under different OS/configuration? Or is it an inherent limitation on the software itself? So for a true IPS, we have to look for other software (suricata?) or commercial solutions.

Supermule

Dont listen to him seriuosly…

He hasnt proved anything besides "I am SO good and cant tell you where I work, but take my word for it".....

http://en.wikipedia.org/wiki/Intrusion_prevention_system

The main difference between IDS and IPS is that IPS acts actively and does something to the packet/intruder/IP sending the traffic that is caught by IDS.

Snort does a great job in PFSense whether it takes 0,0000000000000000001 second for the packet to be analyzed and thereby not beeing "inline" or "realtime" to someone!

I could easily state that I work for some government agency that wants access everywhere....and therefore be a trusted person. But I am not. I try to keep them out of what I have and so far so good.

They need to combat several obstacles to get in and PFsense with Snort is one of them...

@demco:

jflsakfja:
Thanks for the detailed explanation.

Can snort be a true IPS (without leaking the initial offending packets), maybe under different OS/configuration? Or is it an inherent limitation on the software itself? So for a true IPS, we have to look for other software (suricata?) or commercial solutions.

Snort can be a true IPS if it's running in inline mode and all rules are changed to drop (or reject, but who wants to let an intruder know that someone is not home?).
Inline mode alters the way the whole system handles packets (there will be persons that scream at the top of their lungs that this is not the case, I'm explaining it as simply as I can). Basically instead of a packet coming in, the system (os,routing,pf etc etc) deciding what to do with the packet then forwarding it on to its destination, snort inline simply hooks into the system just before the routing. So, a packet comes in, the actual packet is forwarded to snort, snort analyses it, makes the decision of if it should allow it to pass through, then forwards the actual packet down the line (on to routing etc etc). If it's not allowed, snort discards the packet (assuming the rule says so, otherwise rejects it or allows it). If the packet is discarded, no packets travel through the system. If it is rejected, a packet rejecting the original packet will be sent down the incoming connection (wan side?).

As I said before, snort inline was abandoned in favor of suricata. I would choose to go with suricata if you want a true IPS. Don't know your requirements with regards to the connection speed, but there was work a couple years back to implement GPU processing of the packets in suricata, don't know how far that got. GPU processing means that you will max out the connection before maxing out the system, in other words you can handle all the traffic you want without breaking a sweat. That should rule out most commercial "IPS" systems.

Another tip (who am I to know right?) NEVER blacklist on an IPS (allow all, then decide what to reject). ALWAYS whitelist (block all, then allow what needs to pass through). Blacklisting basically makes the IPS useless. Whitelisting is a lot of work, but it is extremely worth it. Want to go all out with security? Install an IPS, then implement MLS on the systems behind it. Or just go with MLS and forget about the rest. This leads you to a system capable of storing above TOP SECRET stuff and if done right even the admin will have no control over it, and sure as hell is not required by most people. Last I heard there were about 200 people worldwide that knew what MLS stands for, and of those, 12 knew how to implement a true MLS system. 5 commited suicide when they started reading documentation about it, 34 were commited (they still fill all the walls they come across with jubberish) and 9 were never seen again. Dunno what happened to the rest of them. :D
Disclaimer: I'm not responsible if insanity takes over you. It takes upwards of 5 years to build a true MLS system, because a true MLS system always assumes it is compromised, at multiple points (physical, network stack, interprocess communication etc. etc.). You basically only allow what needs to be allowed, EVERYWHERE. Even the system does not trust itself, ie sha512sums of a process BEFORE running a process, which is in turn limited to the bare minimum that it needs access to. The only way to get into the system is with a sledgehammer, then again alarms will go off. Yes even compiling code pulled from multiple sources,multiple times, comparing sums of the files it produces, to update itself (code that's well inspected before by people in the know). Thinking about sniffing traffic between processes? Thought that ssh was the only use of encryption? And still think that the same key is used 5 minutes down the road? And no, getting into it at the hardware level doesn't work. Who said you can trust one of its CPUs is not be compromised? If the sys admin is trusted (ie NOT the run of the mill 5 masters, 2 PhDs and 50 years of experience) the system is as secure as it gets.

PS. I never said I work for the government. The government wasn't born knowing all the stuff it knows though ;)

Supermule

You run the Bell-LaPadula model??

@jflsakfja:

snip…
mumble mumble....
ah, this is interesting: It takes upwards of 5 years to build a true MLS system, because a true MLS system always assumes it is compromised, at multiple points (physical, network stack, interprocess communication etc. etc.).
mumble mumble

So, it's not the BLP. (insert X sound here).You lost the chance to win the big price. Don't be dissapointed, you can try again next time. To all the people watching us at home, have a great weekend, goodnight everybody.

BLP trusts that Bob (who has a TOP SECRET clearance) does not take a document and de-classifies it himself. So BLP is build on a trust model where you trust the upper guys not to leak anything to the lower guys. The system I described is the ultra-paranoid conspiracy theorist from hell. It assumes, from the time of its first power up, that everybody out there is out to get it. Trust is an unknown word for it. It doesn't trust you in any way, you WILL be leaking stuff down to lower guys. That's the design goal anyways. Users get access to fragments of the documents they have clearance for (wouldn't want them memorizing the entrire document and verbally leaking it), and admins get no access to documents the users are producing (an admin sure as hell doesn't pass a top secret validation. All the admins that got it up to now, was out of neccessity). The highest level is the system. It makes the decissions, everybody else follows them. Hasn't evolved to the Matrix (yet). It did show sentient behaviour though when Lora typed in a cyber warfare document. She went missing 5 days later :D

Supermule

:D You watched WarGames to many times!

I'm actually still looking for the old VHS with the original one on it, the new one is not so interesting. It's (in a reality distorted way of saying) really close to how a true MLS system behaves. It makes most decisions on its own.

AI is not something that's coming in the future. It was here 15 years ago. Imagine the thinking that went into the designing of a system (for lack of better term, a mini datacenter) that welds the door shut behind you (not rocket science, heat detectors to see no one is inside, a simple welder electrically ignited if the door is closed and the room is empty and travelling on a rail or a robotic welder to keep it all nice and tidy) because it doesn't expect any maintenance in the next 30 years (since most components are n+5 (n+five)). When the contract is over (talking about 7 or 8 figures here) no one will mind the 30K it takes for an armoured door to be rebuilt (they still use those 10K hammers right?).

I'll put my army hat on and say that most civilians should never need anything close to it. It's actually quite true. As you said, a simple firewall with a good IDS keeps out 99% of the bad guys (even a certain 192.17x.x.x/24 network. (extra x added so that I don't get droned to death ;)) BLP:This statement was never made (see the flaw?). Make the assumption that no services are running behind that box and that percentage just shot up to 99.99%.