Fair enough, (and I doubt I'm too young), however, back then, there was no 
difference.  There is now.  

When ISS RealSecure first starting coming out with the technology of sending 
RST packets, I remember people called it IPS back then too.  When tools that 
auto-blocked at firewalls started coming out, they called it IPS, when IPS 
without a failopen came along, people called it an IPS.  However, if we look at 
the landscape now, I argue that it's different and we wouldn't call IPS the 
same thing anymore.  Which is why I didn't.

I think it's important to understand not only where we've been, but where we 
are, and where we are going.  I work in the IPS industry (Sourcefire) as I am 
sure many others on this list do as well, and it's important (at least to me) 
that people understand the distinction.  I get the reaction all the time that 
"IPS doesn't work, because all it does is send RST packets", which in fact IPS 
is now a very mature technology.

I think it's important to understand the difference in the technologies.  Not 
everyone on the list has "been there and done that".  The beauty part about a 
list like this is it brings the seasoned and the new together in a common 
environment where the above can be discussed.

Joel

On Feb 18, 2011, at 9:21 AM, Curt Purdy wrote:

> If this were a literary list, we could argue semantics till the cows
> come home Joel. But being an information security list let's stick to
> technology. You may be too young to remember the very first Intrusion
> 'Protection' System that was not in-line at all. It was simply an IDS
> that added ACLs to the firewall to block the grievous party. Everyone
> accepted the developer's term 'IPS'.
> 
> Curt Purdy CISSP, GSNA, GSEC, MCSE+I, CCNA
> [email protected]
> [email protected]
> 
> 
> 
> On Tue, Feb 15, 2011 at 10:23 AM, Joel Esler <[email protected]> wrote:
>> On Feb 11, 2011, at 2:14 PM, Joel Jaeggli wrote:
>> 
>>> On 2/11/11 10:23 AM, Matthew Fitzgerald wrote:
>>>> Joel, its inline because prevention requires intervention.
>>> 
>>> It doesn't actually require that, plenty of ips systems can do their job
>>> with a tap and another port for injection.
>> 
>> I personally don't refer to that kind of a device as an IPS.  I refer to 
>> that as a "reactionary IDS".  For instance, if the goal is to send a RST 
>> packet back to the SRC IP that caused the IDS to alert, then the RST packet 
>> has to beat the /actual/ ACK packet from the true DST IP back to the 
>> machine.  This is essentially, for lack of a better term, a "race".  This 
>> does not control traffic.  Plus, it gives away the hop location of your IDS 
>> within the network to the attacker.  I think if you are going to try and 
>> control traffic the much preferred method of doing so is an IPS.  Traffic 
>> goes in one port, and it exits the other port.  While the traffic is inside 
>> the machine, the IPS makes the decision if the traffic should exist the 
>> other port, or it shouldn't.  That's a more controlling machine, thusly an 
>> IPS.
>> 
>>> the fact of the matter is if the ids can't keep up with the presented
>>> load that's going to be a problem whether it's inline or presented
>>> through a tap, in the later case however it's not going to cause an outage.
>> 
>> True points there.  However, if you purchase an IPS that is correctly 
>> spec'ed for your network (i.e. not putting a 1Gig IPS on a 2Gig link) you 
>> should have little problem being able to handle the traffic.  It's mostly a 
>> software/hardware problem.
>> 
>> If you get a big enough box that is appropriately sized to handle the 
>> traffic, you should be able to perform the IPS function properly.  Although 
>> I've seen wide variances in this.  I've seen a 2Gig box do 4Gig/second of 
>> traffic, and I've seen a 10Gig box do 2 Gig/second of traffic.  Test.
>> 
>> --
>> Joel Esler
>> http://www.joelesler.net
>> 
>> 
>> -----------------------------------------------------------------
>> Securing Your Online Data Transfer with SSL.
>> A guide to understanding SSL certificates, how they operate and their 
>> application. By making use of an SSL certificate on your web server, you can 
>> securely collect sensitive information online, and increase business by 
>> giving your customers confidence that their transactions are safe.
>> http://www.dinclinx.com/Redirect.aspx?36;5001;25;1371;0;1;946;9a80e04e1a17f194
>> 
>> 
>> 

--
Joel Esler
http://www.joelesler.net


-----------------------------------------------------------------
Securing Your Online Data Transfer with SSL.
A guide to understanding SSL certificates, how they operate and their 
application. By making use of an SSL certificate on your web server, you can 
securely collect sensitive information online, and increase business by giving 
your customers confidence that their transactions are safe.
http://www.dinclinx.com/Redirect.aspx?36;5001;25;1371;0;1;946;9a80e04e1a17f194


Reply via email to