Snort 2.9.4.6 pkg v2.6.1
-
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
-
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."
-
:D
(my only comment to this)
-
: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 -
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.
-
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...
-
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 ;)
-
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 mumbleSo, 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
-
: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%.
-
Hi, great work. Thanks for the support. I keep getting a lot of (spp_sip) Maximum dialogs within a session reached alerts and then the IPs get blocked. Anyway to change the rule on this alert? They are basically false positives at this point. If I change the host attribute settings, does it affect this alert in anyway?
-
Use the suppress icon to filter away blocks because of that SID.