Snort 2.9.4.6 pkg v2.6.1
-
Yes It was blocking DROP/Dshield/ET RBNs/CINS but i didnt see any CIARMY.
There were also blocked port scan sweeps and ET SCAN Sipvicious.
I didnt see any of that in Security Onion. I dont think I have ever seen one of those alerts.
https://code.google.com/p/security-onion/wiki/ManagingAlerts (They do have them as part of the rulesets.)
-
Hi Bill,
I removed all of my suppression lists to try to get something to come in and get an alert and I got an alert and a block but Security Onion still picked the blocked packets up even after my changes. Could there be some other setup/config issue that I could check?
The blocked ip is in the snort2c table.
I also found this interesting. I set a block on sig 1:2013504 (ET POLICY GNU/Linux APT User-Agent Outbound likely related to package management)
I requested apt-get updates on the Security Onion Box and part of the updates came thru before pfSense/Snort kicked in and blocked the remaining.
See attached Jpg.
-
Without reading the previous replies to this thread (just glanced at the above couple of posts tbh), you are seeing the intended behaviour of snort. Snort in pfsense is not running drop rules, but alert rules. The reason you might see traffic behind the snort box is that (as I said in the past) snort doesn't actually block any packets. I'll reuse a previous analogy I used:
Snort in pfsense (an IDS):guy sitting in a room, watching the CCTV feeds. He picks up the radio and radios to a security person "hey, guy in the red jacket, pick him up". The downside is that while the guy is watching the guy in the red jacket, the one in the blue jacket gets through. They later decide that no jacket guys are allowed, which prevends this from happening again (until pfsense decides to flush the block table,out of nowhere, of course).
Snort running drop rules (or any IPS): You wall off part of the corridor, and set up a metal detector, a security guard padding you down, full body search and all that. Everyone has to go through this to be let through.Summary: Snort will allow some packets through until the whole analyze/alert/ban cycle completes.
If I missed something, or I'm not making any sense, please do ignore me. It's too early in the morning and I haven't had the mandatory cafeine boost yet. Or the sleep.
-
Not if the one in the blue jacket gets blocked as well due to the "ET no jacket in the building" rule ;)
-
Not if the one in the blue jacket gets blocked as well due to the "ET no jacket in the building" rule ;)
What if the person observing them has a monitor in front of him, on which he watches the guy in the red jacket, while at the same time, the person in the blue jacket shows up on the monitor behind him? ;-)
What I was getting at is that some packets "leak through", I've seen it more than enough times by now. Sometimes, depending on the processing the snort box has to do, less packets get through before the eventual ban.
-
Snort strips him naked and scan his clothes without him noticing that… while stripping him naked, Snort discovers his jacket...and blocks him. ;)
-
So, to be perfectly clear, are you arguing that snort (as running in pfsense) should block packets (act as an IPS), or are you saying that snort should allow some packets through, while scanning them (act as an IDS)?
Because from what I've seen in multiple production environments, snort (as running in pfsense) acts as an IDS. Packets leak through, as I've said. -
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
-
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.
-
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.
-
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) -
Images didnt upload properly. See attached.
-
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:
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.
-
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 SnortIPS 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:
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
-
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
