Softpanorama

Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
May the source be with you, but remember the KISS principle ;-)
Bigger doesn't imply better. Bigger often is a sign of obesity, of lost control, of overcomplexity, of cancerous cells

Anomaly detection

News Recommended Books Recommended Links Recommended Papers Anomaly detection Event Correlation
Log analyzers Honeypots Network IDS(NIDS) Host-based IDS Integrity Checkers Architectural Issues of Intrusion Detection Infrastructure in Large Enterprises
Snort ACID Shadow White Paper Humor Etc
I personally think that IDS appliance are a mostly useless tool - especially the way it is typically implemented

[Oct 06, 2006] IDS Signature versus anomaly detection NETWORK SECURITY TACTICS IDS: Signature versus anomaly detection James C. Foster

05.27.2005 What you will learn from this tip: The strengths and weaknesses of signature and anomaly detection, and how the two detection methods complement each other.


A key decision during the intrusion-detection buying process used to be whether to go with a signature or anomaly detection engine. Where intrusion-detection systems (IDS) initially employed either detection method, vendors are becoming aware of the benefits of each and are incorporating both in their products. Understanding the strengths and weaknesses of both signature and anomaly detection reveals how they complement each another.

Signature detection

Signature detection involves searching network traffic for a series of bytes or packet sequences known to be malicious. A key advantage of this detection method is that signatures are easy to develop and understand if you know what network behavior you're trying to identify. For example, you might use a signature that looks for particular strings within an exploit payload to detect attacks that are attempting to exploit a particular buffer-overflow vulnerability. The events generated by a signature-based IDS can communicate what caused the alert. Also, pattern matching can be performed very quickly on modern systems so the amount of power needed to perform these checks is minimal for a confined rule set. For instance, if the systems you are protecting only communicate via DNS, ICMP and SMTP, all other signatures can be removed.

Signature engines also have their disadvantages. Because they only detect known attacks, a signature must be created for every attack, and novel attacks cannot be detected. Signature engines are also prone to false positives since they are commonly based on regular expressions and string matching. Both of these mechanisms merely look for strings within packets transmitting over the wire.

While signatures work well against attacks with a fixed behavioral pattern, they do not work well against the multitude of attack patterns created by a human or a worm with self-modifying behavioral characteristics. Detection is further complicated by advancing exploit technology that permits malicious users to conceal their attacks behind nop generators, payload encoders and encrypted data channels. The overall ability of a signature engine to scale against these changes is hamstrung by the fact that a new signature must be created for each variation, and as the rule set grows, the engine performance inevitably slows down. This is the very reason that most intrusion-detection appliances reside hardware that runs from two to as many as eight processors with multiple Gigabit network cards.

Essentially, the signature-based IDS boils down to an arms race between attackers and IDS signature developers, where the delta is the speed at which new signatures can be written and applied to the IDS engine.

Anomaly detection

The anomaly detection technique centers on the concept of a baseline for network behavior. This baseline is a description of accepted network behavior, which is learned or specified by the network administrators, or both. Events in an anomaly detection engine are caused by any behaviors that fall outside the predefined or accepted model of behavior.

An integral part of baselining network behavior is the engine's ability to dissect protocols at all layers. For every protocol that is being monitored, the engine must possess the ability to decode and process the protocol in order to understand its goal and the payload. This protocol "dissection" is initially computationally expensive, but it allows the engine to scale as the rule set grows and alert with fewer false positives when variances from the accepted behaviors are detected.

A disadvantage of anomaly-detection engines is the difficultly of defining rules. Each protocol being analyzed must be defined, implemented and tested for accuracy. The rule development process is also compounded by differences in vendor implementations of the various protocols. Custom protocols traversing the network cannot be analyzed without great effort. Moreover, detailed knowledge of normal network behavior must be constructed and transferred into the engine memory for detection to occur correctly. On the other hand, once a protocol has been built and a behavior defined, the engine can scale more quickly and easily than the signature-based model because a new signature does not have to be created for every attack and potential variant.

Another pitfall of anomaly detection is that malicious activity that falls within normal usage patterns is not detected. An activity such as directory traversal on a targeted vulnerable server, which complies with network protocol, easily goes unnoticed since it does not trigger any out-of-protocol, payload or bandwidth limitation flags.

However, anomaly detection has an advantage over signature-based engines in that a new attack for which a signature does not exist can be detected if it falls out of the normal traffic patterns. The best example of this is how such systems detect new automated worms. When a new system is infected with a worm it usually starts scanning for other vulnerable systems at an accelerated or abnormal rate flooding the network with malicious traffic, thus triggering a TCP connection or bandwidth abnormality rule.

You can see how the strengths of one detection method benefit the weaknesses of another and vice versa. Choosing a detection method is no longer an either/or proposition when buying an IDS.


MORE INFORMATION:

James C. Foster is the Deputy Director for Global Security Solution Development for Computer Sciences Corporation and the lead author for the new Syngress Application Security Series; Mr. Foster can be contacted at jamescfoster@gmail.com.  

The Great IDS Debate Signature Analysis Versus Protocol Analysis

Vulnerability detection vs anomaly detection

The Great IDS Debate : Signature Analysis Versus Protocol Analysis
Matthew Tanase 2003-02-05
 

The Great IDS Debate : Signature Analysis Versus Protocol Analysis
by Matt Tanase

Feb. 5, 2003 

Intrusion detection systems (IDS) have rapidly become a crucial component of any network defense strategy. Over the past few years, their popularity has soared as vendors have refined their results and increased performance capabilities. At the heart of intrusion detection systems lies the analysis engine. It reviews each packet, determines if it is malicious, and logs an alert if necessary – the core tasks of an IDS. Two different IDS techniques, each favored by separate and loyal camps, have emerged as the preferred engine behind the software. Despite the copious marketing material and fiery online debates, each method has distinct strengths and weaknesses. In this article, we'll examine and compare the two different techniques: signature analysis and protocol analysis.

Traditional Signature Analysis and Protocol Analysis

Before exploring the signature and protocol analysis methodologies, let's briefly review the fundamental IDS concepts. These devices, similar to firewalls, inspect incoming and outgoing network traffic. Unlike firewalls, however, they do not alter the traffic flow by dropping or passing certain packets. Rather, they look for malicious traffic that may be indicative of an attack or other misuse and log an alarm with specific data for administrative review. This discussion will focus on the techniques an IDS employs to catch malicious traffic.

Signature analysis was the first method implemented in intrusion detection. It is based on the simple concept of string matching, also known as pattern matching. In string matching, an incoming packet is compared, byte by byte, with a single signature, a string of code that indicates a particular characteristic of malicious traffic. That signature might contain a key phrase or command that is often associated with an attack. If a match is found, an alert is generated. If not, the data in the packet is then compared to the next signature on the list. Once all of the signatures have been checked, the next packet is read into memory and the process begins again. Critics of signature analysis often refer to it, somewhat accurately, as "packet grepping", a derogatory reference to the Unix string matching tool grep. They consider this type of IDS engine to be extremely elementary; something could be duplicated using a simple Unix command.

The second method of analysis focuses on reviewing the strictly formatted data of network traffic, otherwise known as protocols. Each packet is wrapped in predefined layers of different protocols. IDS authors, recognizing this, implemented engines that unwrap and inspect these layers, according to the protocol standards or RFC. Each wrapper has several fields with expected or normal values. Anything that violates or is outside of these standards is likely malicious. The IDS inspects each field of the different protocols of an incoming packet: IP, TCP, and UDP. If something violates a protocol rule, for instance, if it contains an unexpected value, an alert is generated. Protocol analysis uses a detailed knowledge of expected or normal packet field values to discover malicious traffic. This differs greatly from signature analysis, which uses known traits of an attack, to generate an alert.

Modern Day Signature and Protocol Analysis

The core concepts above describe rudimentary implementations of the signature and protocol analysis models. However, each has evolved significantly. Most products that employ signature analysis also use basic protocol analysis. Layers 3 (network) and 4 (transport) of the OSI model, which contain IP, TCP and UDP, are all examined. Current IDS implementations understand these protocols and the expected values of their respective fields. The signatures in use today often examine multiple fields from different protocols, such as source address, destination port, or TCP flags. Additionally, these systems, based on the decoded protocol results, know where to look for the packet payload, which is searched for specific strings that may indicate an attack. Such strings might include the code of an exploit or a command that would indicate a malicious attack. For example, the following Snort rule is for a Telnet login failure:

alert tcp $HOME_NET 23 -> $EXTERNAL_NET any (msg:"TELNET Bad 
Login"; content: "Login failed"; nocase; 
flow:from_server,established; classtype:bad-unknown; sid:492; rev:5;)

It’s important to note that the engine actually searches the payload for the “Login failed” string, as is evidenced by the “content:” field. If this string is found, or matched, an alert is generated.

IDSs based on protocol analysis have evolved as well. In addition to the layer 3 and 4 decoding discussed above, they also focus on a detailed analysis of layer 7 (application) protocols. Programmers have implemented several of the most popular protocols, such as HTTP, SMTP, and Telnet, all of which can be examined in detail for violations and abnormalities. These applications can now anticipate the expected response during key parts of a given transaction. Therefore, anomalies such as unexpected values, unusually large or small packets, or strange options, all of which may signal an attack, will be detected.

Strengths and Weaknesses: Signature Analysis

Signature analysis systems have a few key strengths.

On the flip side, signature-based IDS has definite weaknesses.

Strengths and Weaknesses: Protocol Analysis

The case for protocol analysis is very similar: it has distinct positives and negatives, most of which are in direct opposition to signature analysis. Due to the preprocessors required for advanced protocol examination, protocol analysis can be fairly slow to begin with.

The IDS Environment

Of course, the effectiveness of an IDS depends upon the environment in which it will be employed. Monitoring a large, diverse network is very different from smaller, homogenous environments. Signature analysis models are best suited for average-sized networks looking to catch standard threats. Administrators can draw on the fantastic community support for releasing updated signatures, and performance is not a crucial factor. However, a bigger, ever-changing network would likely benefit from some of the strengths of a protocol analysis system: performance, minimal false positives, and generalized alerts. A better, but more expensive solution, would be having an IDS deployment containing two machines, each employing a different model. Unfortunately, very few can afford such a luxury.

The Future: A Complementary Model?

Without a doubt, anyone choosing an IDS based on one of these techniques has several factors to consider. Each model excels in different arenas. Fortunately, it appears as though we're headed in the direction of a reconciliation between the two divergent methods. The engineers and programmers behind these systems recognize the obvious strengths and weaknesses of each approach. As can be expected, the developers are attempting to pull together the best components of each approach in order to provide a more robust product – a fact that is evident in several of the more recent IDS offerings. Currently, almost all of the protocol-based offerings perform pattern matching at some point in the application level decode. There are IDS systems that, even though they perform protocol analysis, also allow the user/operator the ability to create signatures for particular traffic. We can expect to see more of this as well. Similarly, signature-based systems are bundling application processors to more effectively recognize attacks.

Ultimately, we're moving toward a much more thorough design, one that will statefully examine the transactions and know what sort of client and server response to expect at a given point in the process. Hopefully, this competition between the camps of the two techniques will eventually reap dividends for the end user, and soon.

Conclusion

While the two intrusion detection camps, signature and protocol analysis, seem, at first, vastly different, a more philosophical study of the problem at hand reveals encouraging similarities. In the end, these security tools examine formatted data for attacks and anomalies. While the two techniques initially seemed unrelated, it is obvious by the overlap in modern product offerings that they can be very similar. Exploiting the inherent strengths of each approach while avoiding the weaknesses will lead to one end – a superior product.

Matt Tanase is President of Qaddisin. He and his company provide nationwide security consulting services. Additionally, he produces The Security Blog, a daily weblog dedicated to network security.

Top Visited
Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News

[Oct 6, 2006] An interesting IDS discussion in firewall wizards forum

[fw-wiz] FW appliance comparison - Seeking input for the forum

Paul Melson pmelson@gmail.com
Tue Jan 17 16:02:15 2006

-----Original Message-----
Subject: [fw-wiz] FW appliance comparison - Seeking input for the forum

> I'd like to ask the forum for any input (good or bad) on a comparison
between the Cisco ASA 
> 5510 and the Symantec SGS 5620 ...
>
> We're looking to replace our current firewall setup with an appliance type
approach.

If you buy into the vendorspeak, those two products sound awfully similar.
But they're not.  What they do have in common is that they are an amalgam of
products already on the market.  So I guess if you're also trying to
conserve rack space, these are the products for you. :-)

The ASA 5510 literally possesses the functionality of a PIX, SecureIDS
(formerly NetRanger), and a VPN 3000 Concentrator (formerly Allegro plus
some SSL VPN code from Twingo).  That's a fast stateful firewall, a lousy
NIDS appliance, and a VPN appliance with decent IPSec support, but a lousy
SSL VPN implementation.

The SGS 5620* possesses the functionality of Symantec Enterprise Firewall
(formerly Axent Raptor), Clientless Gateway VPN 4400 (formerly SafeWeb), and
Symantec Network Security 7100 (formerly Recourse ManHunt).  So that's a
slow proxy firewall with awkward IPSec support, a decent SSL VPN gateway,
and a faster but equally lousy NIDS product.


As you may have guessed, I'm not psyched about either of these products.
Both have given me headaches in the past.  It might cost you more, but you
ought to consider buying the components you need on a separate basis.

PaulM

* A marginally interesting side note, these are Sun-made x86 servers running
Linux.  This bizarre pedigree dates back to a contract that Axent had with
Cobalt to supply hardware (RaQ servers) for the VelociRaptor appliances.
Somehow this relationship has survived both of the original parties being
purchased (Sun bought Cobalt just a few months after Symantec bought Axent
in 2000).

[fw-wiz] FW appliance comparison - Seeking input for the forum

sai sonicsai@gmail.com
Wed Jan 18 11:52:53 2006


On 1/18/06, Paul Melson <pmelson@gmail.com> wrote:
> -----Original Message-----
> Subject: [fw-wiz] FW appliance comparison - Seeking input for the forum
>
> > I'd like to ask the forum for any input (good or bad) on a comparison
> between the Cisco ASA
> > 5510 and the Symantec SGS 5620 ...
> >
> > We're looking to replace our current firewall setup with an appliance t=
ype
> approach.
>

(many) appliances tend to be marketing led. I mean, the reasoning
behind developing the products comes from the marketing people rather
than techies. There are vendors out there that will sell you anti-spam
on firewall if you really want all-in-one boxes. Why would you want an
IDS on the same machine as a firewall? Its not going to work. It will
not have enough signatures to give you the sort of security you need.

sai

sai
Paul D. Robertson paul@compuwar.net
Wed Jan 18 13:30:02 2006
On Wed, 18 Jan 2006, sai wrote:

> on firewall if you really want all-in-one boxes. Why would you want an
> IDS on the same machine as a firewall? Its not going to work. It will
> not have enough signatures to give you the sort of security you need.
> 
[What the heck, no interesting debate in a while...]

I think there's a bigger question "why would you want an IDS?"  AFAICT, 
IDS's are only good for (a) stopping stuff your firewall rules should 
already stop or (b) stopping known-bad stuff you have to let in that 
almost always have patches or work-arounds and (c) if you're regulated 
into them (i.e. HIPPA.)

Since I tend to preach good firewall rulesets and strengthening the 
obvious vectors with good patching/strong configuration, I really fail to 
see situations where "If only we'd had an IDS/IPS" is the matra rather 
than "if only we'd patched/filtered" wasn't an altogether better mantra.

Maybe someone hitting the IDS pipe can come up with some good examples of 
when just doing the right thing wouldn't have stopped whatever it is that 
is known enough for signatures but not enough for configuring or 
patching... 

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
paul@compuwar.net       which may have no basis whatsoever in fact."
http://fora.compuwar.net      Infosec discussion boards 

Paul Melson pmelson@gmail.com
Wed Jan 18 19:58:01 2006


 

-----Original Message-----
Subject: Re: [fw-wiz] FW appliance comparison - Seeking input for the forum

> Maybe someone hitting the IDS pipe can come up with some good examples of
when just doing 
> the right thing wouldn't have stopped whatever it is that is known enough
for signatures but 
> not enough for configuring or patching... 

I don't know that I'm comfortible admitting to "hitting the IDS pipe" but I
will say that an IDS (or anything that can perform some sort of action based
on packet payload) will give you things that your firewall ACLs can't.

A recent real-life example is our guest network.  To accommodate visiting
contractors, auditors, etc. without just letting them plug into the internal
network, we have a WEP-enabled wireless network that they can use.  This
network only allows access to a handful of ports and protocols, essentially
enough for basic web browsing (80/443), VPN (PPTP and IPSec), and DNS (they
get a DHCP lease that gives them a DNS server address outside of our
network).  That's moderately restrictive, but we still regularly detect
peer-to-peer and IM traffic coming from that subnet.  And that's the
unencrypted stuff.  Many of these apps will work over ports reserved for
other common protocols or in the case of at least two IM clients, they will
work over HTTP and even through our proxies via GET/POST/POLL methods
(blocking CONNECT is no longer enough).

The moral of the story is that if you don't force all traffic through an
application proxy, you can stand to implement an IDS.  Even still, you
probably have traffic passing through your proxy that you think you're
stopping.

PaulM
Paul D. Robertson paul@compuwar.net
Wed Jan 18 20:39:03 2006
On Wed, 18 Jan 2006, Paul Melson wrote:

> A recent real-life example is our guest network.  To accommodate visiting
> contractors, auditors, etc. without just letting them plug into the internal
> network, we have a WEP-enabled wireless network that they can use.  This
> network only allows access to a handful of ports and protocols, essentially
> enough for basic web browsing (80/443), VPN (PPTP and IPSec), and DNS (they
> get a DHCP lease that gives them a DNS server address outside of our
> network).  That's moderately restrictive, but we still regularly detect
> peer-to-peer and IM traffic coming from that subnet.  And that's the

Peer-to-peer and IM are about controlling what someone does, not 
really security.  Both of those are controllable by local machine policy, 
especially in the Windows case- so an IDS is a pretty expensive thing to 
manage just so your visitors don't do something you don't want them to 
do- and QoS would be about as effective in the P2P space.

> unencrypted stuff.  Many of these apps will work over ports reserved for
> other common protocols or in the case of at least two IM clients, they will
> work over HTTP and even through our proxies via GET/POST/POLL methods
> (blocking CONNECT is no longer enough).

Yep, but I can certianly block the servers those clients connect to at my 
gateway.  I can tunnel everything over DNS too- that doesn't work in a 
proxy environment.

> The moral of the story is that if you don't force all traffic through an
> application proxy, you can stand to implement an IDS.  Even still, you
> probably have traffic passing through your proxy that you think you're
> stopping.

Actually, I think the moral of the story is it's still good to use a 
proxy...

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
paul@compuwar.net       which may have no basis whatsoever in fact."
http://fora.compuwar.net      Infosec discussion boards 
Paul Melson pmelson@gmail.com
Thu Jan 19 14:14:03 2006


-----Original Message-----
Subject: RE: [fw-wiz] FW appliance comparison - Seeking input for the forum


> Peer-to-peer and IM are about controlling what someone does, not really
security.  Both of 
> those are controllable by local machine policy, especially in the Windows
case- so an IDS is 
> a pretty expensive thing to manage just so your visitors don't do
something you don't want 
> them to do- and QoS would be about as effective in the P2P space.

I categorically disagree with your first statement.  To illustrate my point,
fire up your favorite Kazaa or Gnutella client and search for 'ntuser.dat'
And there's always: http://isc.sans.org/diary.php?storyid=917

There are more reasons why it's a bad idea to allow these things across your
Internet border, and since it's an issue of crossing that border, it's
easier to manage detection and enforcement at those points than it is to do
it directly at each desktop.


> Actually, I think the moral of the story is it's still good to use a
proxy...

But not just any proxy.  There are lots of proxies out there that simply
don't deliver the type of protocol control that is needed.  In fact, I would
say that none of the top 3 border proxies out there can stop IM tunneling
from clients like MSN or Yahoo.  

PaulM
Devdas Bhagat Devdas Bhagat <devdas@dvb.homelinux.org>
Wed Jan 18 19:59:06 2006


On 18/01/06 13:21 -0500, Paul D. Robertson wrote:
> On Wed, 18 Jan 2006, sai wrote:
> 
> > on firewall if you really want all-in-one boxes. Why would you want an
> > IDS on the same machine as a firewall? Its not going to work. It will
> > not have enough signatures to give you the sort of security you need.
> > 
> [What the heck, no interesting debate in a while...]
> 
> I think there's a bigger question "why would you want an IDS?"  AFAICT, 
> IDS's are only good for (a) stopping stuff your firewall rules should 
> already stop or (b) stopping known-bad stuff you have to let in that 
> almost always have patches or work-arounds and (c) if you're regulated 
> into them (i.e. HIPPA.)

An IDS is _not_ an IPS. An IDS monitors your system/network for failures
of security systems. It does not interfere with traffic.

An IDS helps in quantifying threats as well. "We got $n low threat port
scans, $v viruses incoming, $s spam..."

An IPS, OTOH, is a proxy with default allow. All your criticisms apply
there.

Devdas Bhagat
Paul D. Robertson paul@compuwar.net
Wed Jan 18 20:39:15 2006


On Thu, 19 Jan 2006, Devdas Bhagat wrote:

> > > IDS on the same machine as a firewall? Its not going to work. It will
> > > not have enough signatures to give you the sort of security you need.
> > > 
> > [What the heck, no interesting debate in a while...]
> > 
> > I think there's a bigger question "why would you want an IDS?"  AFAICT, 
> > IDS's are only good for (a) stopping stuff your firewall rules should 
> > already stop or (b) stopping known-bad stuff you have to let in that 
> > almost always have patches or work-arounds and (c) if you're regulated 
> > into them (i.e. HIPPA.)
> 
> An IDS is _not_ an IPS. An IDS monitors your system/network for failures
> of security systems. It does not interfere with traffic.
> 
> An IDS helps in quantifying threats as well. "We got $n low threat port
> scans, $v viruses incoming, $s spam..."

s/stopping/detecting and then allowing you to stop out of band/

> An IPS, OTOH, is a proxy with default allow. All your criticisms apply
> there.

Same pipe, different rocks. ;)

Paul

david_harris@arnotts.com david_harris@arnotts.com
Fri Jan 20 09:50:02 2006



> On Wed, 18 Jan 2006, sai wrote:
>
> > on firewall if you really want all-in-one boxes. Why would you want an
> > IDS on the same machine as a firewall? Its not going to work. It will
> > not have enough signatures to give you the sort of security you need.
> >
> [What the heck, no interesting debate in a while...]
>
> I think there's a bigger question "why would you want an IDS?"  AFAICT,
> IDS's are only good for (a) stopping stuff your firewall rules should
> already stop or (b) stopping known-bad stuff you have to let in that
> almost always have patches or work-arounds and (c) if you're regulated
> into them (i.e. HIPPA.)

I think it should be re-iterated that the D in IDS is 'Detection'. Alot of
people are using this term very loosely of late.

I agree that IDS is a waste of time except if you need to provide glossy
feel good reports to mgmt. Then theyr'e great!


>
> Since I tend to preach good firewall rulesets and strengthening the
> obvious vectors with good patching/strong configuration, I really fail to

> see situations where "If only we'd had an IDS/IPS" is the matra rather
> than "if only we'd patched/filtered" wasn't an altogether better mantra.
>
> Maybe someone hitting the IDS pipe can come up with some good examples of

> when just doing the right thing wouldn't have stopped whatever it is that

> is known enough for signatures but not enough for configuring or
> patching...
>
> Paul
>
-----------------------------------------------------------------------------

> Paul D. Robertson      "My statements in this message are personal
opinions
> paul@compuwar.net       which may have no basis whatsoever in fact."
> http://fora.compuwar.net      Infosec discussion boards
>
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards@honor.icsalabs.com
> http://honor.icsalabs.com/mailman/listinfo/firewall-wizards

**********************************************************************
This e-mail and any files transmitted with it may contain 
confidential information and is intended solely for use by 
the individual to whom it is addressed.  If you received
this e-mail in error, please notify the sender, do not 
disclose its contents to others and delete it from your 
system.

**********************************************************************

sai sonicsai@gmail.com
Fri Jan 20 09:50:16 2006


On 1/20/06, david_harris@arnotts.com <david_harris@arnotts.com> wrote:
>
> > On Wed, 18 Jan 2006, sai wrote:
> >
> > > on firewall if you really want all-in-one boxes. Why would you want a=
n
> > > IDS on the same machine as a firewall? Its not going to work. It will
> > > not have enough signatures to give you the sort of security you need.
> > >
> > [What the heck, no interesting debate in a while...]
> >
> > I think there's a bigger question "why would you want an IDS?"  AFAICT,
> > IDS's are only good for (a) stopping stuff your firewall rules should
> > already stop or (b) stopping known-bad stuff you have to let in that
> > almost always have patches or work-arounds and (c) if you're regulated
> > into them (i.e. HIPPA.)
>
> I think it should be re-iterated that the D in IDS is 'Detection'. Alot o=
f
> people are using this term very loosely of late.
>
> I agree that IDS is a waste of time except if you need to provide glossy
> feel good reports to mgmt. Then theyr'e great!
>

Ignorance is strenght? No way! IDS should help you figure out what is
happening on your network and its environs. Unfortunately keeping the
IDS updated takes time and/or money , plus you have to look at (and
understand) the reports (more time and effort).
Most people are able to get on with their jobs without knowing what
has attacked them, but its certainly good to know.

sai

Paul D. Robertson 
paul@compuwar.net

Fri Jan 20 10:09:17 2006


On Fri, 20 Jan 2006, sai wrote:

> Ignorance is strenght? No way! IDS should help you figure out what is
> happening on your network and its environs. Unfortunately keeping the

No, your *policy* should *dictate* what's happening on your network and 
its environs.  Your implementation of that policy should enforce it.

If IDS was an audit function, it'd have to be designed to audit against a 
policy, not be AV-on-the-wire.  Lots of people are using IDS as an excuse 
to not iterate or implement policy or protective controls, and that's a 
problem.

> IDS updated takes time and/or money , plus you have to look at (and
> understand) the reports (more time and effort).
> Most people are able to get on with their jobs without knowing what
> has attacked them, but its certainly good to know.

Again, this assumes that your policy implementation allows attacks to 
traverse your infrastructure *or* that you're wasting the organization's 
time passing around reports about how many times NIMDA tried to attack 
your Solaris box.  

This is one reason why people with sub-standard security don't get fired 
when there's an event they clearly should have created "the IDS signature 
didn't detect it" is becomming a bail-out when people really aren't 
implementing good security policies.

Here's a little tidbit that's about 4 years old now, but ponder it and ask 
yourself if the IDS is where people *should* be spending their time:

Approximately 74% of firewalls are either misconfigured or not configured 
to block attacks they're capable of blocking in normal operation[1].

Paul
[1] No, I don't mean "deny all."  Attacks without unduely hindering the 
organization by blocking legitimate traffic.
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
paul@compuwar.net       which may have no basis whatsoever in fact."
http://fora.compuwar.net      Infosec discussion boards 
Devdas Bhagat Devdas Bhagat <devdas@dvb.homelinux.org>
Mon Jan 23 12:35:18 2006


On 20/01/06 10:00 -0500, Paul D. Robertson wrote:
> On Fri, 20 Jan 2006, sai wrote:
> 
> > Ignorance is strenght? No way! IDS should help you figure out what is
> > happening on your network and its environs. Unfortunately keeping the
> 
> No, your *policy* should *dictate* what's happening on your network and 
> its environs.  Your implementation of that policy should enforce it.
> 
> If IDS was an audit function, it'd have to be designed to audit against a 
> policy, not be AV-on-the-wire.  Lots of people are using IDS as an excuse 
> to not iterate or implement policy or protective controls, and that's a 
> problem.

Isn't auditing against a policy exactly what an IDS is supposed to do?
It also verifies that your security policy has been implemented
correctly at the firewall(s).

> 
> > IDS updated takes time and/or money , plus you have to look at (and
> > understand) the reports (more time and effort).
> > Most people are able to get on with their jobs without knowing what
> > has attacked them, but its certainly good to know.
> 
> Again, this assumes that your policy implementation allows attacks to 
> traverse your infrastructure *or* that you're wasting the organization's 
> time passing around reports about how many times NIMDA tried to attack 
> your Solaris box.  
> 
Things change. IDS help detect unexpected changes. Again, IMHO, an IDS
also has a host based component which looks at (ab)normal statistics for
host traffic. A sudden increase in traffic or decrease can be
interesting events.

For instance, seeing traffic destined to port 25 from an unexpected host
is a good event to trigger IDS events. Even when your firewall blocks
this traffic, the log analysis of firewall logs and DHCP logs should
catch potential malicious traffic and possible further investigation.

This was discussed in a thread on the loganalysis mailing list by MJR.

> This is one reason why people with sub-standard security don't get fired 
> when there's an event they clearly should have created "the IDS signature 
> didn't detect it" is becomming a bail-out when people really aren't 
> implementing good security policies.
>
Which is _not_ the fault of the tools. Done right, a good firewall and
IDS combination should not need to be updated very often.

Devdas Bhagat
Paul D. Robertson paul@compuwar.net
Mon Jan 23 18:35:40 2006


On Sun, 22 Jan 2006, Devdas Bhagat wrote:

> Isn't auditing against a policy exactly what an IDS is supposed to do?

Not that I've ever seen.  Everything I've seen says they look for 
known-bad-stuff and produce alerts and false positives.  

;)

> It also verifies that your security policy has been implemented
> correctly at the firewall(s).

As I said, in an ideal world, sure- however I've yet to see an IDS that 
really and truly knows how to even express policy, let alone check against 
it (unless your policy is "no bad stuff the IDS can find!")  Heck, I've 
yet to see real policy<->firewall rule mapping done in an effective way 
without a human.

> > Again, this assumes that your policy implementation allows attacks to 
> > traverse your infrastructure *or* that you're wasting the organization's 
> > time passing around reports about how many times NIMDA tried to attack 
> > your Solaris box.  
> > 
> Things change. IDS help detect unexpected changes. Again, IMHO, an IDS

Really?  Care to elaborate on some unexpected changes IDS's routinely 
detect that aren't a matter of poor policy implementation or poor 
operational controls?  Just like AV, I can see a small just-after-zero-day 
window where you could trumpet them- but like AV it's about twice a year 
and IMNSHO not worth the effort of upkeep compared to working on things 
that will change your vulnerability surface...

> also has a host based component which looks at (ab)normal statistics for
> host traffic. A sudden increase in traffic or decrease can be
> interesting events.

Sure, they can be interesting, but normally (at least in my experience) 
they're due to a failure in process that needs fixing a lot more than IDS 
signatures need updating.

> For instance, seeing traffic destined to port 25 from an unexpected host
> is a good event to trigger IDS events. Even when your firewall blocks
> this traffic, the log analysis of firewall logs and DHCP logs should
> catch potential malicious traffic and possible further investigation.

If you mean "unexpected internal host" then again, I'll say that there's 
likey been a larger policy or implementation failure.  It doesn't take 
on-the-wire sniffing to see something new trying to relay through the 
relay host on my network.

If you mean "unexpected external host" then I've yet to see an IDS that 
knows the difference between "new business" and "one-off social 
engineering attack."

> This was discussed in a thread on the loganalysis mailing list by MJR.
> 
> > This is one reason why people with sub-standard security don't get fired 
> > when there's an event they clearly should have created "the IDS signature 
> > didn't detect it" is becomming a bail-out when people really aren't 
> > implementing good security policies.
> >
> Which is _not_ the fault of the tools. Done right, a good firewall and
> IDS combination should not need to be updated very often.

That's certainly a different line than most IDS vendors or IDS proponents 
use.  Normally I see "the new IDS signature can detect that!" bandied 
about.

To me, IDS is like a left-handed screwdriver, you can send someone around 
and waste their time with it, but when it comes to fixing something, it's 
not there.  If you need IDS, it's because of a failure elsewhere, and if 
you're done everything right, the value is negligable.

[PE]Don't believe the hype.[/PE]

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
paul@compuwar.net       which may have no basis whatsoever in fact."
http://fora.compuwar.net      Infosec discussion boards 


Ben Nagy ben@iagu.net
Tue Jan 24 08:00:17 2006


Hi Paul, Devdas!

> -----Original Message-----
> From: firewall-wizards-admin@honor.icsalabs.com
> [mailto:firewall-wizards-admin@honor.icsalabs.com] On Behalf
> Of Paul D. Robertson
[...]
[Devdas]
> > Things change. IDS help detect unexpected changes.
[...]
> > For instance, seeing traffic destined to port 25 from an
> > unexpected host is a good event to trigger IDS events.
> > Even when your firewall blocks this traffic, the log
> > analysis of firewall logs and DHCP logs should
> > catch potential malicious traffic and possible further
> > investigation.

This sounds sensible to me. Same for any protocol that detects as TFTP, IRC
from unauthorised hosts etc etc.

[Paul]
> If you mean "unexpected internal host" then again, I'll say
> that there's
> likey been a larger policy or implementation failure.  It
> doesn't take
> on-the-wire sniffing to see something new trying to relay through the
> relay host on my network.

What's your preferred method for noticing this stuff? (I'm certainly not
being sarcastic here)
If an internal host is trying to reach port 25 on an external host (or even
a non-mailserver on the inside) then how do you suggest that should be
detected? The firewall deny logs will catch the outbound traffic, but now
we're talking log analysis tools or SIM products to pull the data. What
about the internal traffic from trusted host -> trusted host?

[...]
> > Done right, a good firewall and IDS combination
> > should not need to be updated very often.
>
> That's certainly a different line than most IDS vendors or
> IDS proponents use.  Normally I see "the new IDS signature
> can detect that!" bandied about.

Yeah, it probably _is_ a different line, but it doesn't mean it's not a
sensible one. I saw a cool thing once, with a guy using MRTG as his 'IDS'.
He monitored the network but didn't have control over the servers (academics
did *shudder*). Every time one of the servers would be owned, the outbound
traffic would spike, because people used them to serve warez. So, any time
he saw an MRTG spike he'd go check out the server, work out why it got owned
and tell people to fix it up. Dumb security? Hell yeah, the owners should
have just kept the things hardened, but it's still a great illustration of
the principle. Even with no attack signatures at all, couldn't an IDS still
be useful? Perhaps even more useful, since it would cut down the noise...

I think there are actually products out there that do this using connection
tuples to construct some sort of graph and using some wacky fuzzy isomorphic
analysis, but they probably don't call themselves IDS.

I think I'm with Devdas - personally, the only time I'd deploy an IDS is
with all the attack signatures turned off and rules set up to flag
unexpected source / dest connections. All the rest seems to be a product of
the human quest for useless knowledge.

Cheers,

ben

Paul D. Robertson paul@compuwar.net
Mon Jan 23 18:35:40 2006


On Sun, 22 Jan 2006, Devdas Bhagat wrote:

> Isn't auditing against a policy exactly what an IDS is supposed to do?

Not that I've ever seen.  Everything I've seen says they look for 
known-bad-stuff and produce alerts and false positives.  

;)

> It also verifies that your security policy has been implemented
> correctly at the firewall(s).

As I said, in an ideal world, sure- however I've yet to see an IDS that 
really and truly knows how to even express policy, let alone check against 
it (unless your policy is "no bad stuff the IDS can find!")  Heck, I've 
yet to see real policy<->firewall rule mapping done in an effective way 
without a human.

> > Again, this assumes that your policy implementation allows attacks to 
> > traverse your infrastructure *or* that you're wasting the organization's 
> > time passing around reports about how many times NIMDA tried to attack 
> > your Solaris box.  
> > 
> Things change. IDS help detect unexpected changes. Again, IMHO, an IDS

Really?  Care to elaborate on some unexpected changes IDS's routinely 
detect that aren't a matter of poor policy implementation or poor 
operational controls?  Just like AV, I can see a small just-after-zero-day 
window where you could trumpet them- but like AV it's about twice a year 
and IMNSHO not worth the effort of upkeep compared to working on things 
that will change your vulnerability surface...

> also has a host based component which looks at (ab)normal statistics for
> host traffic. A sudden increase in traffic or decrease can be
> interesting events.

Sure, they can be interesting, but normally (at least in my experience) 
they're due to a failure in process that needs fixing a lot more than IDS 
signatures need updating.

> For instance, seeing traffic destined to port 25 from an unexpected host
> is a good event to trigger IDS events. Even when your firewall blocks
> this traffic, the log analysis of firewall logs and DHCP logs should
> catch potential malicious traffic and possible further investigation.

If you mean "unexpected internal host" then again, I'll say that there's 
likey been a larger policy or implementation failure.  It doesn't take 
on-the-wire sniffing to see something new trying to relay through the 
relay host on my network.

If you mean "unexpected external host" then I've yet to see an IDS that 
knows the difference between "new business" and "one-off social 
engineering attack."

> This was discussed in a thread on the loganalysis mailing list by MJR.
> 
> > This is one reason why people with sub-standard security don't get fired 
> > when there's an event they clearly should have created "the IDS signature 
> > didn't detect it" is becomming a bail-out when people really aren't 
> > implementing good security policies.
> >
> Which is _not_ the fault of the tools. Done right, a good firewall and
> IDS combination should not need to be updated very often.

That's certainly a different line than most IDS vendors or IDS proponents 
use.  Normally I see "the new IDS signature can detect that!" bandied 
about.

To me, IDS is like a left-handed screwdriver, you can send someone around 
and waste their time with it, but when it comes to fixing something, it's 
not there.  If you need IDS, it's because of a failure elsewhere, and if 
you're done everything right, the value is negligable.

[PE]Don't believe the hype.[/PE]

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
paul@compuwar.net       which may have no basis whatsoever in fact."
http://fora.compuwar.net      Infosec discussion boards 


Ben Nagy ben@iagu.net
Tue Jan 24 08:00:17 2006


Hi Paul, Devdas!

> -----Original Message-----
> From: firewall-wizards-admin@honor.icsalabs.com
> [mailto:firewall-wizards-admin@honor.icsalabs.com] On Behalf
> Of Paul D. Robertson
[...]
[Devdas]
> > Things change. IDS help detect unexpected changes.
[...]
> > For instance, seeing traffic destined to port 25 from an
> > unexpected host is a good event to trigger IDS events.
> > Even when your firewall blocks this traffic, the log
> > analysis of firewall logs and DHCP logs should
> > catch potential malicious traffic and possible further
> > investigation.

This sounds sensible to me. Same for any protocol that detects as TFTP, IRC
from unauthorised hosts etc etc.

[Paul]
> If you mean "unexpected internal host" then again, I'll say
> that there's
> likey been a larger policy or implementation failure.  It
> doesn't take
> on-the-wire sniffing to see something new trying to relay through the
> relay host on my network.

What's your preferred method for noticing this stuff? (I'm certainly not
being sarcastic here)
If an internal host is trying to reach port 25 on an external host (or even
a non-mailserver on the inside) then how do you suggest that should be
detected? The firewall deny logs will catch the outbound traffic, but now
we're talking log analysis tools or SIM products to pull the data. What
about the internal traffic from trusted host -> trusted host?

[...]
> > Done right, a good firewall and IDS combination
> > should not need to be updated very often.
>
> That's certainly a different line than most IDS vendors or
> IDS proponents use.  Normally I see "the new IDS signature
> can detect that!" bandied about.

Yeah, it probably _is_ a different line, but it doesn't mean it's not a
sensible one. I saw a cool thing once, with a guy using MRTG as his 'IDS'.
He monitored the network but didn't have control over the servers (academics
did *shudder*). Every time one of the servers would be owned, the outbound
traffic would spike, because people used them to serve warez. So, any time
he saw an MRTG spike he'd go check out the server, work out why it got owned
and tell people to fix it up. Dumb security? Hell yeah, the owners should
have just kept the things hardened, but it's still a great illustration of
the principle. Even with no attack signatures at all, couldn't an IDS still
be useful? Perhaps even more useful, since it would cut down the noise...

I think there are actually products out there that do this using connection
tuples to construct some sort of graph and using some wacky fuzzy isomorphic
analysis, but they probably don't call themselves IDS.

I think I'm with Devdas - personally, the only time I'd deploy an IDS is
with all the attack signatures turned off and rules set up to flag
unexpected source / dest connections. All the rest seems to be a product of
the human quest for useless knowledge.

Cheers,

ben
Chuck Swiger chuck@codefab.com
Tue Jan 24 08:39:01 2006


Ben Nagy wrote:
[ ... ]
> [Paul]
>> If you mean "unexpected internal host" then again, I'll say that there's 
>> likey been a larger policy or implementation failure. It doesn't take 
>> on-the-wire sniffing to see something new trying to relay through the relay
>> host on my network.
> 
> What's your preferred method for noticing this stuff? (I'm certainly not
> being sarcastic here)
> If an internal host is trying to reach port 25 on an external host (or even
> a non-mailserver on the inside) then how do you suggest that should be
> detected? The firewall deny logs will catch the outbound traffic, but now
> we're talking log analysis tools or SIM products to pull the data. What
> about the internal traffic from trusted host -> trusted host?

If you're not running a firewall that doesn't let you decide which rules should 
generate logging, then yes, you're going to need to do more work to analyze 
those logs.

However, some time ago, before viruses came with their own SMTP engines, an IPFW 
ruleset like this worked pretty well:

# permit SMTP exchange between pi and pong
add pass tcp from PI HIPORTS to PONG 25 setup
add pass tcp from PONG 25 to PI HIPORTS established

add pass tcp from PONG HIPORTS to PI 25 setup
add pass tcp from PI 25 to PONG HIPORTS established

# track SMTP from inside to outside and block SMTP from outside
add pass log logamount 20 tcp from INET HIPORTS to any 25 setup
add pass tcp from INET HIPORTS to any 25 established
add unreach filter-prohib log tcp from any to INET 25

[ Where PI and PONG are macros which expand to the IP addresses of my external 
MX relay and the internal reader box, HIPORTS means 1024-65535, and INET refers 
to the internal network. ]

-- 
-Chuck
Patrick M. Hausen hausen@punkt.de
Tue Jan 24 08:39:17 2006
Hi, all!

On Tue, Jan 24, 2006 at 11:38:52AM +0700, Ben Nagy wrote:

> What's your preferred method for noticing this stuff? (I'm certainly not
> being sarcastic here)

Your firewall doesn't trigger an alarm for every event that's
denied by policy?

That's the main reason why I don't like IDSs. A default deny
policy combined with "log everything" achieves just the same.

I concede there are nice UIs that let you do convenient analysis
and statistics - more often or better on IDS products than on
your common firewall. But it's the vendors that are to blame
here. Why not put the same effort into the firewall products?
Why bother if you can sell another box instead? Dunno.

Regards,
Patrick
-- 
punkt.de GmbH         Internet - Dienstleistungen - Beratung
Vorholzstr. 25        Tel. 0721 9109 -0 Fax: -100
76137 Karlsruhe       http://punkt.de

Cat Okita Cat Okita <cat@reptiles.org>
Tue Jan 24 21:26:01 2006


On Tue, 24 Jan 2006, Patrick M. Hausen wrote:
> On Tue, Jan 24, 2006 at 11:38:52AM +0700, Ben Nagy wrote:
>
>> What's your preferred method for noticing this stuff? (I'm certainly not
>> being sarcastic here)
>
> Your firewall doesn't trigger an alarm for every event that's
> denied by policy?
>
> That's the main reason why I don't like IDSs. A default deny
> policy combined with "log everything" achieves just the same.

*blink* You don't bog down your firewall to the point of being
unuseable doing that?!?

I think that there's a place and a use for IDS - but if your network
is small enough that running log everything won't bog down your
firewall(s), then - well - maybe they're not for you.

cheers!
==========================================================================
"A cat spends her life conflicted between a deep, passionate and profound
desire for fish and an equally deep, passionate and profound desire to
avoid getting wet.  This is the defining metaphor of my life right now."
Marcus J. Ranum mjr@ranum.com
Tue Jan 24 22:25:15 2006
Cat Okita wrote:
That's the main reason why I don't like IDSs. A default deny
>>policy combined with "log everything" achieves just the same.
>
>*blink* You don't bog down your firewall to the point of being
>unuseable doing that?!?

If your firewall bogs down because of a little bit of logging it is
a POS and should be used as a flower planter, not a security
device.

mjr.

Cat Okita cat@reptiles.org
Tue Jan 24 22:49:01 2006
On Tue, 24 Jan 2006, Marcus J. Ranum wrote:
> Cat Okita wrote:
>> ... but I'm not thinking of a 'little' bit of logging.  I'm thinking of
>> "look at everything that could -possibly- be of interest".
>
> Isn't that what a "firewall" does?? I mean how could you call
> the thing a "firewall" if it did less than that? That'd be pretty
> lame, wouldn't it?

Heh.  You're right - I should have said "record everything that could
possibly be of interest" (which is not what I want my firewall to do -
I'd like it to record things I'm sure I care about)

At any rate, I think of my IDS and my firewall as fufilling different
albeit complimentary functions.  I want the IDS to be an overly sensitive
touchy-feely creature, while my firewall is in staunch denial, and
allows only the barest minimum through to its delicate innards[0] - and
this translates to the amount of logging and capture I expect out of
each.

>From my IDS, the proverbial volumes of handwritten poorly spelled prose
and poetry decorated with florid petunias, and from my firewall the single 
typewritten sheet.

cheers!
[0] I suppose that the degree to which one might use 'delicate innards'
would vary according to the type of firewall - an application proxy
like Gaunlet might need to be considered a rumminant...
==========================================================================
"A cat spends her life conflicted between a deep, passionate and profound
desire for fish and an equally deep, passionate and profound desire to
avoid getting wet.  This is the defining metaphor of my life right now."
Joseph S D Yao jsdy@center.osis.gov
Wed Jan 25 11:24:03 2006
On Tue, Jan 24, 2006 at 10:49:29PM -0500, Cat Okita wrote:
> On Tue, 24 Jan 2006, Marcus J. Ranum wrote:
> >Cat Okita wrote:
> >>... but I'm not thinking of a 'little' bit of logging.  I'm thinking of
> >>"look at everything that could -possibly- be of interest".
> >
> >Isn't that what a "firewall" does?? I mean how could you call
> >the thing a "firewall" if it did less than that? That'd be pretty
> >lame, wouldn't it?
> 
> Heh.  You're right - I should have said "record everything that could
> possibly be of interest" (which is not what I want my firewall to do -
> I'd like it to record things I'm sure I care about)
> 
> At any rate, I think of my IDS and my firewall as fufilling different
> albeit complimentary functions.  I want the IDS to be an overly sensitive
> touchy-feely creature, while my firewall is in staunch denial, and
> allows only the barest minimum through to its delicate innards[0] - and
> this translates to the amount of logging and capture I expect out of
> each.
> 
> >From my IDS, the proverbial volumes of handwritten poorly spelled prose
> and poetry decorated with florid petunias, and from my firewall the single 
> typewritten sheet.
> 
> cheers!
> [0] I suppose that the degree to which one might use 'delicate innards'
> would vary according to the type of firewall - an application proxy
> like Gaunlet might need to be considered a rumminant...


;-)  Trust the Cat to come up with the above.  I like it.  [Except for
that last extra 'm' in "ruminant", sorry!]

ISTM that not too long ago [by my odd standards of time] a friend of
mine whose initials are something like MJR was ranting that one should
not bother storing log data unless one actually had something one could
do with it.  It sounds like this is pretty much what you are advocating
for your firewall.

OTOH, if the loganalysis people are actually able to milk more out of
the firewall logs than a human giving it the hairy eyeball, then the
amount of interest suddenly does become exponentially larger ...

[What, try to pun off the metaphor?  Me?  Don't have a cow.]


-- 
Joe Yao
-----------------------------------------------------------------------
   This message is not an official statement of OSIS Center policies.

chris@blask.org chris@blask.org
Wed Jan 25 02:28:07 2006


At 12:24 AM 25/01/2006, Marcus J. Ranum wrote:
 
Cat Okita wrote:
>> Would you care to elaborate on the way that you handle the vast 
>> amounts of data that you collect, then?  Sorting the gold from the 
>> dross is a monumental challenge on a good day.

Like he says. 
 
<lights cigarette, leans on post while Marcus paces and gestures>

> Use an artificial ignorance to weed out the majority of it, then
> revector stuff that should be counted and quantified into a
.d.
> For truly huge amounts of log data, you can use hardcoded
> tools and get amazing data rates out of them; for example,
> building a parse-tree out of nested calls to sscanf using the
> magic %n operator to offset directly into the last match.

Computers are fast and people are smart.  When you break down the logical structure of the problem you find that there are not significant hurdles that can't be knocked down with the usual brow sweat and frayed nerves of any technical endeavor.  
 
Once you accept the idea that your operational goal is to monitor the living bejesus out of everything, the model changes.  *Since* you can see everything (and if you can't you'll fix it), you can focus on dealing with what is happening, make more intelligent forecasts for planning, look back at what happened for analysis and reporting and basically take a more strategic role in making a network secure.

> System log processing remains a backwater in spite of the
> recent interest in the topic thanks to HIPAA and whatnot.
 
It's the calm before the storm.  More people need to (and will) contribute to the effort before it's really mature.

> www.loganalysis.org has some resources on some of
> this stuff. But it remains the land of do-it-yourselfers
> because log data is very site-specific. On the other hand
> it's not freakin' rocket science; if you just sit down and
> start eyeballing the stuff you'll get an idea what you
> need for your site within an hour or 2.
 
Agreed.  It has gotten to the point that when I see each new network it feels like 1995 ("well - since you've done *nothing*, and I can telnet directly into the middle of your network from home, and you make parts for manned spacecraft - any firewall might be a good start").  Except now it's: "Well, since you have no way to see even the *slightest* bit of what the hell is happening on your network while we're standing here drinking bottled water, even a crappy [within limits] SIM solution is probably a good idea."   
 
It is worth the effort to find a way to Manage the Information about the Security of your network (a SIM by any name would smell so sweet...).  The SIM vendorsphere is completely fubared (venodrs are easily recognizable: they're the ones saying, "well, we're not a *SIM*, we're a ....") , but there are workable bits of technology out there.  Applying some of the products and processes available is a good start.  
 
As always with fundamental shifts, it will take time for the solution providers to make the solutions fully respectable, but it will take time for the consumers to work through adoption pains as well so IMHO current solutions are fit for early adoption in volume.  By the time a company today adopts and deploys a solution to the point of being sore about solution shortcoming, they will have benefited directly from the effort, they will be better positioned to ask intelligent questions of the providers, and the solution choices will be richer.
 
-cheers!
 
-chris
 
[So, Paul.  Obviously I'm still sending html, eh?]
Paul D. Robertson paul@compuwar.net
Wed Jan 25 02:56:16 2006
On Tue, 24 Jan 2006 chris@blask.org wrote:

> of the devices and applications that make up that network.  The only
> reason not to focus on producing that telemetry and making sense of it
> is because there is too much, which becomes a lame excuse after a long
> enough time.

No, there's another reason not to collect it;  Everything you collect 
under almost all evnironments is ultimately legally discoverable.  

>  Devices should be able to report on everything they do, there should be
> someplace to put all this stuff, and there should be tools to digest it
> appropriately.  Some of the pieces necessary are coming together and
> it's generally the most usefull area to focus on.

Should be able to, sure- should always- not for me thanks.

Been there, done that, got the t-shirt.

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
paul@compuwar.net       which may have no basis whatsoever in fact."
http://fora.compuwar.net      Infosec discussion boards 

Marcus J. Ranum mjr@ranum.com
Wed Jan 25 08:07:01 2006


Paul D. Robertson wrote:
>No, there's another reason not to collect it;  Everything you collect 
>under almost all evnironments is ultimately legally discoverable.  

That's the dumbest argument against logging I've ever heard. :(

If it existed in your network in some form or other such that it
was transferred and could be logged, it's already legally discoverable.
It just becomes a question of how. Yes, you can carefully construct
your Email system to not retain anything but can you carefully
construct your users so they don't? Can you construct your
backup system so that only the "right" data is non-transitory?
Can you make your staff subpoena-proof? etc. That's where you
are much more likely to have problems, not in your logging system.

mjr. 
Paul D. Robertson paul@compuwar.net
Wed Jan 25 08:07:21 2006


On Wed, 25 Jan 2006, Marcus J. Ranum wrote:

> Paul D. Robertson wrote:
> >No, there's another reason not to collect it;  Everything you collect 
> >under almost all evnironments is ultimately legally discoverable.  
> 
> That's the dumbest argument against logging I've ever heard. :(

It's not an argument against logging, it's an argument against logging 
everything you could ever possibly log.  The delta between "I'm sorry we 
don't keep that data, it's transient" and "let us see what we have that 
matches that criteria" can be *very* costly in terms of simple people 
time. 

If you don't believe that, look at service provider lawsuits in the last 
5-10 years, and look at how companies like Yahoo are getting away with 
being able to *charge* for civil subpoena compliance.  Think they make a 
profit on that?

Now put yourself in Yahoo's shoes and ask yourself how much actual 
business they'd get done if they stored everything they could possibly 
store.  I guarantee you it'd be less than they get done today and it'd 
take them more people, more storage and the cost of storage for 
preservation letters alone would be pretty damn impressive.

Remember, every time one of Yahoo's customers gets murdered in the US, 
Yahoo is dealing with preservation letters, subpoenas, and other record 
requests.  Now, have them log every packet ever, and keep it all for 
analysis and see where that leads them- becuase I assure you that it 
wouldn't be pretty, dumbest idea ever against logging every packet or not.

> If it existed in your network in some form or other such that it
> was transferred and could be logged, it's already legally discoverable.

There's a reason IBM had Notes set to expire mail every 30 days.  It's 
kept even the over-volumous SCO discovery stuff a lot shorter than it 
would have been otherwise (and yes, that's including the fact that it's 
gone on seemingly forever.)

> It just becomes a question of how. Yes, you can carefully construct
> your Email system to not retain anything but can you carefully
> construct your users so they don't? Can you construct your

It doesn't matter that you can't do it perfectly, it may matter simply 
that you don't store everything as a matter of course.

> backup system so that only the "right" data is non-transitory?
> Can you make your staff subpoena-proof? etc. That's where you
> are much more likely to have problems, not in your logging system.

That depends totally on what you do, what the opposition is trying to 
discover, and how vulnerable you are to fishing expiditions.  If you don't 
log it as a matter of purpose, then it's at least mostly transitory unless 
it's a store-and-forward type communication.

The difference between a machine record (admissible) of everything that 
ever went on your network and testimony can really make a difference in a 
lot of packet-chasing lawsuits.  It's also signifcantly different in terms 
of what you might have to store, report on, be able to redact information 
from, etc.

Go ahead, store every IM in and out of a large organization, log every 
sender, recipient, message, IP address, etc.  Then, once you have to start 
dealing with every civil suit between employee and spouse, tell me how 
productive you're being.  Once you have to produce everything every time 
you get a wrongful dismissal case, tell me again how productive it is- 
especially if someone in a happens to win one because some dimwit in 
management IM'd the wrong thing to his golf buddy.  Now extend that out 
ten years and put it all on backup tapes and start thinking of how much 
work you're gonna have.  

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
paul@compuwar.net       which may have no basis whatsoever in fact."
http://fora.compuwar.net      Infosec discussion boards 

[fw-wiz] RE: IDS (was: FW appliance comparison)

Brian Loe knobdy@gmail.com
Wed Jan 25 10:53:02 2006
On 1/25/06, Paul D. Robertson <paul@compuwar.net> wrote:
> On Wed, 25 Jan 2006, Marcus J. Ranum wrote:
>
> > Paul D. Robertson wrote:
> > >No, there's another reason not to collect it;  Everything you collect
> > >under almost all evnironments is ultimately legally discoverable.
> >
> > That's the dumbest argument against logging I've ever heard. :(
>
> It's not an argument against logging, it's an argument against logging
> everything you could ever possibly log.  The delta between "I'm sorry we
> don't keep that data, it's transient" and "let us see what we have that
> matches that criteria" can be *very* costly in terms of simple people
> time.
>
> If you don't believe that, look at service provider lawsuits in the last
> 5-10 years, and look at how companies like Yahoo are getting away with
> being able to *charge* for civil subpoena compliance.  Think they make a
> profit on that?
>

Where I work, I'm not sure how we could do it. We're a transactions
company, and do thousands and thousands (and more at times) a second.
Debugging from ONE of our firewalls puts us int he gigabyte-per-hour
realm. I tried turning up a syslogging system here once... it died
three hours later. Maybe I wasn't using the greatest hardware,
database and reporting software - but where do you find that sort of
thing? 
With that much data, and 98% of it being useless, you kind have
to ask yourself, "what's the point?" IF we catch something it'll
probably still be too late - our IDS will have already been updated
with the new "something". I don't want to have to go to my manager and
say, "well, we spent 250k on a machine that would log every
transaction - no, sorry, PACKET - we ever passed and we still got
hacked because we didn't hire a new engineer to review the data
streaming out of the system and therefore see the new exploit in time
to shut it down. But, on the bright side, our 2k IDS system did
eventually begin blocking it from all but one customer site."
Marcus J. Ranum mjr@ranum.com
Fri Jan 27 21:01:08 2006
Brian Loe wrote:
>Where I work, I'm not sure how we could do it. We're a transactions
>company, and do thousands and thousands (and more at times) a second.

Would you like to think about that for maybe a second?? Logging
an event is, what, thousands of times less CPU and I/O intensive
than executing a transaction?? So how can you say that you're
not sure how to do something that's _easier_ than what you are
already doing??

>Debugging from ONE of our firewalls puts us int he gigabyte-per-hour
>realm.

Let's see - how exciting is that? 1024 megs in 3600 seconds is..
whoah!!! Holy moly - not very impressive, really. My _ipod_ can
move data faster than that; have you considered using one of those?
24 gigs per day? With compression, you might fit as much as a
month's worth of logs on a $750 LaCie "bigger disk" firewire
drive. Logs compress really well, which further reduces your
I/O requirements.

Sure, it's not something you'd want to handle with lightweight
tools or slow interpreted programming languages, but you are
not talking about spine-crushing data rates. 

> I tried turning up a syslogging system here once... it died
>three hours later. Maybe I wasn't using the greatest hardware,
>database and reporting software - but where do you find that sort of
>thing?

Syslog definitely has problems with high rates of input. See:
http://lists.jammed.com/loganalysis/2002/01/0054.html
but it's mostly due to UDP output queue overruns.

It's not a hardware problem... But - wait - you said "database"?
Please tell me you weren't trying to stick that much data into
a SQL database with indexes on your tables and an interpreted
query/optimizer engine on top of all that? If so, I'm not surprised
it didn't work -- but that's not a "logging is hard" problem that is
a "using a relational database for a write-heavy application is
the wrong tool" problem.

> With that much data, and 98% of it being useless, you kind have
>to ask yourself, "what's the point?"

I don't ask myself that. Because I don't agree that 98% of it is
useless. It's probably closer to 99.99999% of it is useless.
Except for the one or two lines that you might someday
really, really need.

> IF we catch something it'll
>probably still be too late - our IDS will have already been updated
>with the new "something".

That's the problem, then. You're assuming that your IDS is going
to know how to detect some site-specific hack that only works
against you. That's what the logging is for. It's for figuring out
what happened after it's too late. Sometimes being able to
determine if the customer database got out because of a SQL
injection attack through log examination can be quite
useful if management is otherwise convinced the problem is
an insider..  I once spent a few happy weeks poring through
40 gigs of transaction log data (yeah, 3 days' worth...) trying
to identify traces of a hithertofore unknown DOS attack. At
stake were a bunch of sysadmins' jobs. It was a very
intellectually stimulating mission.

> I don't want to have to go to my manager and
>say, "well, we spent 250k on a machine that would log every
>transaction - no, sorry, PACKET

Well, see, what you'd normally do is actually _think_ about
the problem a little bit - not just jump into it half-assed.
Most of the commercial logging tools are aimed at attempting
to "do everything" but you pay a lot for that - if you actually
know what you want to do, you can do it for not a whole lot.

> - we ever passed and we still got
>hacked because we didn't hire a new engineer to review the data
>streaming out of the system and therefore see the new exploit in time
>to shut it down.

If you are stupid about how you deploy technology, you
will usually get stupid results. Try explaining that to your
boss. No - wait - don't.

mjr. 
Devdas Bhagat Devdas Bhagat <devdas@dvb.homelinux.org>
Wed Jan 25 14:27:01 2006
On 23/01/06 18:30 -0500, Paul D. Robertson wrote:
> On Sun, 22 Jan 2006, Devdas Bhagat wrote:
> 
> > Isn't auditing against a policy exactly what an IDS is supposed to do?
> 
> Not that I've ever seen.  Everything I've seen says they look for 
> known-bad-stuff and produce alerts and false positives.  
> 
> ;)
> 
<chorus> BOO! </chorus>

> > It also verifies that your security policy has been implemented
> > correctly at the firewall(s).
> 
> As I said, in an ideal world, sure- however I've yet to see an IDS that 
> really and truly knows how to even express policy, let alone check against 
> it (unless your policy is "no bad stuff the IDS can find!")  Heck, I've 
> yet to see real policy<->firewall rule mapping done in an effective way 
> without a human.
> 
I suspect that my terminology has gotten disconnected with the marketing
driven real world again.

To me an IDS is not necessarily something that listens on the network
only. Stuff that looks at the integrity of files on hosts, stuff that
monitors and analyzes logs is part of the IDS too. The IDS is not a
simple, single application, but a set of applications which work
together to show the differences between operational and ideal
implementations.

A NIDS, or a HIDS is a part of the above, but is definitely not sufficient
by itself.

> > > Again, this assumes that your policy implementation allows attacks to 
> > > traverse your infrastructure *or* that you're wasting the organization's 
> > > time passing around reports about how many times NIMDA tried to attack 
> > > your Solaris box.  
> > > 
> > Things change. IDS help detect unexpected changes. Again, IMHO, an IDS
> 
> Really?  Care to elaborate on some unexpected changes IDS's routinely 
> detect that aren't a matter of poor policy implementation or poor 
> operational controls?  Just like AV, I can see a small just-after-zero-day 

Violation of operational controls does need to be detected. Poor policy
implementations need to be detected as well.

> window where you could trumpet them- but like AV it's about twice a year 
> and IMNSHO not worth the effort of upkeep compared to working on things 
> that will change your vulnerability surface...
> 
> > also has a host based component which looks at (ab)normal statistics for
> > host traffic. A sudden increase in traffic or decrease can be
> > interesting events.
> 
> Sure, they can be interesting, but normally (at least in my experience) 
> they're due to a failure in process that needs fixing a lot more than IDS 
> signatures need updating.
> 
I really don't care about specific signatures. Port 22 scans originating
from a host in my internal network to other hosts within my network? I
sure am interested in learning what failed, and why. This then serves as
input for fixing the process so that the failure does not happen next
time.

> > For instance, seeing traffic destined to port 25 from an unexpected host
> > is a good event to trigger IDS events. Even when your firewall blocks
> > this traffic, the log analysis of firewall logs and DHCP logs should
> > catch potential malicious traffic and possible further investigation.
> 
> If you mean "unexpected internal host" then again, I'll say that there's 
> likey been a larger policy or implementation failure.  It doesn't take 
> on-the-wire sniffing to see something new trying to relay through the 
> relay host on my network.
> 
And my IDS need not sniff on the wire. A simple Perl script which tail
-f 's the firewall logs and alerts on seeing a hit on the outbound port
25 logging rule is good too.

> If you mean "unexpected external host" then I've yet to see an IDS that 
> knows the difference between "new business" and "one-off social 
> engineering attack."
> 
> > This was discussed in a thread on the loganalysis mailing list by MJR.
> > 
> > > This is one reason why people with sub-standard security don't get fired 
> > > when there's an event they clearly should have created "the IDS signature 
> > > didn't detect it" is becomming a bail-out when people really aren't 
> > > implementing good security policies.
> > >
> > Which is _not_ the fault of the tools. Done right, a good firewall and
> > IDS combination should not need to be updated very often.
> 
> That's certainly a different line than most IDS vendors or IDS proponents 
> use.  Normally I see "the new IDS signature can detect that!" bandied 
> about.

If you do it right, you should never ever know that it exists.

Devdas Bhagat
Christine Kronberg Christine_Kronberg@genua.de
Tue Jan 24 08:00:44 2006
On Sun, 22 Jan 2006, Devdas Bhagat wrote:
> On 20/01/06 10:00 -0500, Paul D. Robertson wrote:

*snip*
>>
>> Again, this assumes that your policy implementation allows attacks to
>> traverse your infrastructure *or* that you're wasting the organization's
>> time passing around reports about how many times NIMDA tried to attack
>> your Solaris box.
>>
> Things change. IDS help detect unexpected changes. Again, IMHO, an IDS
> also has a host based component which looks at (ab)normal statistics for
> host traffic. A sudden increase in traffic or decrease can be
> interesting events.

   Can. Admitted. I can also mean that the holiday are over and people
   are back to work. You think of anomaly detection, don't you? But
   how solid is that art?

> For instance, seeing traffic destined to port 25 from an unexpected host
> is a good event to trigger IDS events. Even when your firewall blocks
> this traffic, the log analysis of firewall logs and DHCP logs should
> catch potential malicious traffic and possible further investigation.

   Why do I need the IDS for something like that? If an internal (external
   for that instance) is doing something funny and is blocked at my fire-
   wall, the firewall tells me. That is what logfiles are for. Why do I
   need an IDS to tell me what my firewall already told me?

   I found IDS pretty useful to locate misconfigured devices in networks.
   But that brings back the topic about the implemented policies and
   whether or not they are watched.

   Cheers,

   Chris Kronberg.

[fw-wiz] FW appliance comparison - Seeking input for the forum

Paul D. Robertson paul@compuwar.net
Fri Jan 20 10:09:02 2006
On Fri, 20 Jan 2006 david_harris@arnotts.com wrote:

> I think it should be re-iterated that the D in IDS is 'Detection'. Alot of
> people are using this term very loosely of late.

Well, we really don't need more terms every time someone adds a feature to 
a product- that's what the marketing weenies want.  You have to D before 
you can P, so they're the same family of products.

> I agree that IDS is a waste of time except if you need to provide glossy
> feel good reports to mgmt. Then theyr'e great!

I just get frustrated that we're getting caught up in the cycle of "glossy 
but useless" instead of educating and eradicating.

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
paul@compuwar.net       which may have no basis whatsoever in fact."
http://fora.compuwar.net      Infosec discussion boards 

[fw-wiz] FW appliance comparison - Seeking input for the forum

Greg Spath gkspath@armstrong.com
Fri Jan 20 14:50:01 2006
On Fri, 20 Jan 2006 15:43:33 +1100
david_harris@arnotts.com wrote:


> 
> I agree that IDS is a waste of time except if you need to provide
> glossy feel good reports to mgmt. Then theyr'e great!
> 

I tend to agree, but...

IDS comes in handy for detecting worm outbreaks on the inside, and are
useful at seeing attacks on ports you allow inbound on your DMZ
(although if whoever admins those services watches their logs, it
becomes apparent without an IDS).  Sendmail servers get hammered by
idiots on occassion.  An IDS can watch for that and let you know when
it is time to send a subnet to the bit void via the firewalls.

Use them to let you know when things aren't right within your
networks.  Using them to report on stuff you are already dealing with,
I agree, is a waste of resources.

--g

-- 
Greg Spath <gkspath@armstrong.com>                        
Infrastructure Security Analyst    
Armstrong World Industries, Inc.

[fw-wiz] FW appliance comparison - Seeking input for the forum

Patrick M. Hausen hausen@punkt.de
Wed Jan 18 14:11:05 2006
Hi!

On Wed, Jan 18, 2006 at 01:04:45PM +0500, sai wrote:

> Why would you want an
> IDS on the same machine as a firewall? Its not going to work. It will
> not have enough signatures to give you the sort of security you need.

Why would you want a signature based IDS at all? They don't work.
Period. Enumerating badness is a silly idea.

Develop a policy that explicitly defines every kind of network
traffic that is to be allowed to pass your perimeter. Application
X using a "proprietary protocol"? Sorry, not allowed.

Then use a firewall that only passes what is explicitly
allowed and raises an alarm for everything that isn't.
*Boom* as Steve Jobs would probably put it. Instant heuristic
proactive unknown and future attack aware IDS.

BTW:
http://www.ranum.com/security/computer_security/editorials/deepinspect/

HTH,
Patrick
-- 
punkt.de GmbH         Internet - Dienstleistungen - Beratung
Vorholzstr. 25        Tel. 0721 9109 -0 Fax: -100
76137 Karlsruhe       http://punkt.de

[fw-wiz] FW appliance comparison - Seeking input for the forum

Marcus J. Ranum mjr@ranum.com
Wed Jan 18 19:58:15 2006
Patrick M. Hausen wrote:
>Why would you want a signature based IDS at all? They don't work.
>Period. Enumerating badness is a silly idea.

Who am I to argue?!  But I'd like to comment...

There is a value to signatures (and enumerating badness) if your purpose
is diagnosis rather than prevention. Like Paul said, if you haven't covered
prevention don't even _think_ about detection - but - if you _have_ covered
prevention then detection is useful if you want burglar alarms (detection of
policy violation) or big picture diagnosis. "You have thrown away 12,000
Code Red attacks" is more readable than "here are 60,000 logged packets
that you may want to look at - see attachment."

>Develop a policy that explicitely defines every kind of network
>traffic that is to be allowed to pass your perimeter. Application
>X using a "propriatary protocol"? Sorry, not allowed.

I'd actually recommend going a step further and have a second
policy tier for your internal traffic, enforced at your core. Obviously
it might be less restrictive than your perimeter policy, but not
necessarily. Every time I hear about some critical network
getting a worm infection, I want to scream. There are a few
practitioners today going around talking about "compartmenting
networks" as if it's a new idea. I'll spare you my powerpoints
from 1989 on "service oriented requirements analysis" but they're
someplace in my backup disks...  Ah. I have an updated version
from '95 but the song remains the same:
http://www.ranum.com/security/computer_security/archives/requirements-analysis.pdf

>Then use a firewall that only passes what is explicitly
>allowed and raises an alarm for everything that isn't.
>*Boom* as Steve Jobs would probably put it. Instant heuristic
>proactive unkown and future attack aware IDS.

Again, I agree 100%; the caveat is that most of the "firewalls" that
are out there have only minimal processing going on at Layer 7
and are really very little more than pimped-up routers with a
security interface atop a simple state-machine rulesbase. If
you pay an extra $60,000 you can get the same pimped-up
router with a silicon regex jump-up and some poorly translated
snort rules in it. It may not do a lot of security processing, but
it's fast!!

The original concept of firewalls, back when we were trying to
really make them secure, was that they were software devices
that enforced correctness at Layer 7 and applied additional
policy atop that. For example, the DEC SEAL FTP proxy
"understood" FTP bounce attacks (it detected when PORT ip
address decoded to a different address than the calling client)
and denied them. While that was a legitimate operation in terms
of the FTP RFC, basically the author of the firewall (that's me)
had decided that the IETF got the protocol wrong, and the
firewall wasn't afraid to unilaterally fix it. The Gauntlet SMTP
proxy, for example, "understood" only the barest minimum of
SMTP necessary to get Email back and forth and rejected
everything else. Layered above that were additional sanity
checks where the author of the firewall (that's me, again)
decided the guys who'd written the RFC had done it wrong.
I.e.: the proxy didn't think certain punctuation characters
were appropriate in an Email address and if you wanted to be
joe-newline@someplace.com you could but your Email
was not going through the firewall. I actually had a mode that
rejected X.400 addresses but nobody thought that was as
funny as I did at the time - now everyone appreciates the
joke a lot better.

Anyhow, in firewalls, the design switched from conservative
default deny AT LAYER 7 to default permit. No longer did
your HTTP traffic have to look like HTTP - now it could look
like *anything* as long as it had a URL in front of it. Thus
the firewall became permeable to spyware, SOAP, trojans,
etc, etc.

Many customers considered this a big step forward. They
were wrong. But it's fast!

mjr. 

[fw-wiz] FW appliance comparison - Seeking input for the forum

Paul Melson pmelson@gmail.com
Wed Jan 18 19:58:40 2006
-----Original Message-----
Subject: Re: [fw-wiz] FW appliance comparison - Seeking input for the forum

> Why would you want a signature based IDS at all? They don't work.
> Period. Enumerating badness is a silly idea.

Sure they do.  The premise may be flawed, but the technology works, even if
it falls into the "better than nothing" category.  They're smoke detectors
for a small subset of possible fires.  Using one is still better than
letting the house burn to the ground each and every time there's a fire.


> Develop a policy that explicitely defines every kind of network traffic
that is to be 
> allowed to pass your perimeter. Application X using a "propriatary
protocol"? Sorry, not 
> allowed.

See my previous post.  Just because you enforce HTTP over TCP/80 with a
proxy doesn't mean you're keeping all of the garbage out... or in.  Not to
mention that there are plenty of standard, known protocols out there (think
SQL protocols) that lack a good proxy to manage the actual behavior of the
connections that cross them.


> Then use a firewall that only passes what is explicitly allowed and raises
an alarm for 
> everything that isn't.
> *Boom* as Steve Jobs would probably put it. Instant heuristic proactive
unkown and future 
> attack aware IDS.

And without packet payload data, those alerts border on useless.  Not to
mention that the real bad guys are tunneling across the allowed ports while
you sleep.

PaulM

[fw-wiz] FW appliance comparison - Seeking input for the forum

Patrick M. Hausen hausen@punkt.de
Wed Jan 18 19:59:18 2006
Hi!

On Wed, Jan 18, 2006 at 03:27:20PM -0500, Paul Melson wrote:

> > Why would you want a signature based IDS at all? They don't work.
> > Period. Enumerating badness is a silly idea.
> 
> Sure they do.  The premise may be flawed, but the technology works, even if
> it falls into the "better than nothing" category.  They're smoke detectors
> for a small subset of possible fires.  Using one is still better than
> letting the house burn to the ground each and every time there's a fire.

You are correct and I oversimplified the issue. They are useful.
They don't increase the "security" of flawed firewall
designs, though.

> See my previous post.  Just because you enforce HTTP over TCP/80 with a
> proxy doesn't mean you're keeping all of the garbage out... or in.

I'm not talking about enforcing HTTP. I'm talking about enforcing
application data. I know of a firewall vendor actively developing
an Active Directory proxy enforcing which side of the proxy is
allowed which methods and objects on the other side of the proxy.

There are products that let you configure a positive list of
URLs that your web application uses. Everything else will be
denied. This catches _all_ of "GET /../../../WINDOWS/SYSTEM32/CMD.EXE ..."
and the like. If configured correctly.

Mechanism is nothing without policy. And firewalls are mechanism.

> Not to
> mention that there are plenty of standard, known protocols out there (think
> SQL protocols) that lack a good proxy to manage the actual behavior of the
> connections that cross them.

The very same vendor has got an MS SQL proxy that actually understands
MS SQL.

> Not to mention that the real bad guys are tunneling across the
> allowed ports while you sleep.

Firewalls have never been about ports. Most current commercial
offerings are, but I hardly call _these_ firewalls.

Kind regards,
Patrick
-- 
punkt.de GmbH         Internet - Dienstleistungen - Beratung
Vorholzstr. 25        Tel. 0721 9109 -0 Fax: -100
76137 Karlsruhe       http://punkt.de
 

[fw-wiz] FW appliance comparison - Seeking input for the forum

Cat Okita Cat Okita <cat@reptiles.org>
Thu Jan 19 17:15:02 2006
On Thu, 19 Jan 2006, Paul Melson wrote:
> I immediately trained in on 'actively developing.'  Which means that 5 years
> after AD became widely used, there's still not a good proxy for it yet.  It
> shouldn't be rocket science since it's kerberos, LDAP, NetBIOS, RPC, and
> COM.  It also shouldn't have to come from a third party vendor.  But I
> digress.

... and I'll digress a bit further.  AD may be 'just' kerberos, LDAP,
NetBIOS, RPC and COM - but if you've ever spent any time doing integration
work with AD, it becomes quickly apparent that the combination is by
no means simple or straightforward.

> Right, but policy is equally useless without mechanisms capable of enforcing
> it.  And while there are vendors out there that write security proxies for
> specific applications and protocols, the products that are out there still
> only support a tiny fraction of the protocols present on the average
> corporate network.
>
> Not to discount the power of application proxies, but they're far from a
> single solution.

I think everybody on this list would agree that there's no single solution,
but that incremental improvements are far better than waiting for the
ultimate solution.

cheers!
==========================================================================
"A cat spends her life conflicted between a deep, passionate and profound
desire for fish and an equally deep, passionate and profound desire to
avoid getting wet.  This is the defining metaphor of my life right now."

Brian Loe knobdy@gmail.com
Thu Jan 26 21:13:01 2006


On 1/25/06, Marcus J. Ranum <mjr@ranum.com> wrote:
> Brian Loe wrote:
> >Where I work, I'm not sure how we could do it. We're a transactions
> >company, and do thousands and thousands (and more at times) a second.
>
> Would you like to think about that for maybe a second?? Logging
> an event is, what, thousands of times less CPU and I/O intensive
> than executing a transaction?? So how can you say that you're
> not sure how to do something that's _easier_ than what you are
> already doing??

To run the transactions they have a VERY large mainframe. To collect
logging I'm lucky to have gotten (since they got it for free
themselves) a pseries running linux. Slight difference.

> Sure, it's not something you'd want to handle with lightweight
> tools or slow interpreted programming languages, but you are
> not talking about spine-crushing data rates.

Without the sarcasm I fully understand what you are saying. But you
don't have to convince me, I have to convince my management - which
doesn't see a problem. They're running debug on every device they own
right now, they're just not logging it, tracking it, analyzing it..or
anything else with it - until there's a problem. You're stating that
they have to spend money  - at least for disk space. I'd be laughed
at...unless IBM or Cisco can do it with a "device".


> Syslog definitely has problems with high rates of input. See:
> http://lists.jammed.com/loganalysis/2002/01/0054.html
> but it's mostly due to UDP output queue overruns.


I'll take a look...

>
> It's not a hardware problem... But - wait - you said "database"?
> Please tell me you weren't trying to stick that much data into
> a SQL database with indexes on your tables and an interpreted
> query/optimizer engine on top of all that? If so, I'm not surprised
> it didn't work -- but that's not a "logging is hard" problem that is
> a "using a relational database for a write-heavy application is
> the wrong tool" problem.

I didn't realize what I was getting into, firstly. Secondly, what good
does the data do if you can't "do" anything with it? Without a system
to at least *help* you analyze it you're simply swimming in quicksand,
flailing in fact.


>
> > With that much data, and 98% of it being useless, you kind have
> >to ask yourself, "what's the point?"
>
> I don't ask myself that. Because I don't agree that 98% of it is
> useless. It's probably closer to 99.99999% of it is useless.
> Except for the one or two lines that you might someday
> really, really need.

Some day, somewhere, something like that might happen. Building a
business case for purchases on that line of reasoning doesn't work so
good though. If you know of a better way of doing this that doesn't
cost money, I'm all ears and management, well, they won't care either
way.

>
> That's the problem, then. You're assuming that your IDS is going
> to know how to detect some site-specific hack that only works
> against you. That's what the logging is for. It's for figuring out
> what happened after it's too late.

That's a good point - and one I hadn't though of. As for IDS, I
personally think its a mostly useless tool - especially the way they
have it implemented here.


> Sometimes being able to
> determine if the customer database got out because of a SQL
> injection attack through log examination can be quite
> useful if management is otherwise convinced the problem is
> an insider..  I once spent a few happy weeks poring through
> 40 gigs of transaction log data (yeah, 3 days' worth...) trying
> to identify traces of a hithertofore unknown DOS attack. At
> stake were a bunch of sysadmins' jobs. It was a very
> intellectually stimulating mission.

What did you use to pour through it? You have to be able to load that
40 gigs of data, or break it up into something semi-coherent, and then
you have to be able to scan it quickly enough to get it done within
the year but not so quick you miss something...

> Well, see, what you'd normally do is actually _think_ about
> the problem a little bit - not just jump into it half-assed.
> Most of the commercial logging tools are aimed at attempting
> to "do everything" but you pay a lot for that - if you actually
> know what you want to do, you can do it for not a whole lot.

Tell me d(&#$#!!! The how is what I'm obviously missing...

>
> > - we ever passed and we still got
> >hacked because we didn't hire a new engineer to review the data
> >streaming out of the system and therefore see the new exploit in time
> >to shut it down.
>
> If you are stupid about how you deploy technology, you
> will usually get stupid results. Try explaining that to your
> boss. No - wait - don't.

Yeah, that would be a mistake.

I don't want to be stupid about it, but outside of this list, you
don't hear anything but the marketing buzz on the latest "device" to
make the world a safer, happier place (and NSA compliant).

[fw-wiz] to IDS or not to IDS? [Re: FW appliance comparison - Seeking input for the forum]

Matthew.Harvey@usdoj.gov Matthew.Harvey@usdoj.gov
Fri Jan 27 21:00:23 2006
You're making a "straw man" argument -- I haven't heard anyone advocate
using IDS as a first OR only line of defense, nor has anyone on this
list advocated neglecting a good firewall with a good ruleset and
instead spending all one's time on IDS deployment instead (we are
"firewall wizards" after all, right?)

However, I WOULD argue that NO technology is a very good "first and
only" line of defense. The original post that started this discussion
asked "Why would you want an IDS?" You seemed to be arguing that IDS is
useless/unnecessary, and I am arguing that it a useful and sometimes
necessary adjunct to a good firewall:
1) IDS provides better visibility on traffic internally and at the
network boundaries. I want to monitor what is happening to assure myself
and my bosses/auditors that my perimeter controls are as good as I say
they are.
2) IDS is better than most firewalls at alerting on "unsuccessful"
attacks that "bounce off" of your firewall or get through but pose no
real danger to your systems which are patched, etc. This information is
useful, because I think it is prudent to detect and track or block
persistent attackers; their first attacks may have been futile, but
maybe they'll get smarter. I wouldn't ignore incoming gunfire just
because they seem to keep missing.


On Wed, 25 Jan 2006, paul@compuwar.net  wrote:

>> world no "bad" traffic can get through a properly configured proxy
>> firewall, BUT the bad guys have imaginations, too! Often better and
more
> evil imaginations that the guys who wrote the protocols and maybe even
>> better than the guy who wrote the proxy (sorry, MJR, but it is
>> possible).

>That doesn't change the fact that if you're not doing the basics right 
>then bells and whistles don't improve your overall security posture as 
>much as getting the basics right will.

>Look at Avishai's study- then tell me that more IDS is the first thing
we 
>need, and do it with a straight face.  Passive IR is a cool technology,

>but it sure as heck shouldn't be your first or only line of defense.

May 6, 2002 New Way to Nab Hackers By Dennis Fisher

Okena Inc. and IntruVert Networks Inc. this week will announce IDS (intrusion detection system) products that eschew the traditional signature-based approach to intrusion detection in favor of behavior monitoring and anomaly detection.

Okena's StormWatch 3.0 focuses on the behavior of applications and systems instead of relying on signatures from a database that needs constant updates. StormWatch intercepts function calls at the operating system level and is able to make real-time decisions about whether to allow or reject the application's behavior.

Each application is assigned to a specific class based on how it behaves, and systems administrators can apply policies to each class.

If an application attempts to perform a function that is out of line with its normal behavior, StormWatch stops the action and generates an alert. It can also prevent so-called untrusted applications from starting and using "trusted" applications, a common attack method.

The updated version of StormWatch, available now, includes protection for Windows and Solaris systems against heap buffer overflows, which are among the most common and easily exploitable vulnerabilities in software. Last year's Code Red and Nimda worms, for example, both exploited buffer overruns in Microsoft Corp.'s Internet Information Services Web server.

However, while many experts and vendors are touting such systems as the future of network security, others say there will always be a place for traditional IDSes.

"There's always going to be signature-based technology because it's valuable when there's a prescribed model on how things are supposed to go," said Becky Bace, a technologist at Trident Capital Inc., in Palo Alto, Calif., and an IDS expert, formerly with the National Security Agency.

"The key is, the faster you can converge on what's happening, the faster you can resolve it. IDS is like pharmaceuticals: There are some that go after very specific causes and others that have a broad sweep," Bace said.

Okena, in Waltham, Mass., is not the first vendor to take this approach. Companies such as Harris Corp. and Lancope Inc. also rely on a behavior-based approach. However, some IDS experts say anomaly detection alone is no better than using only signatures.

"The thing to realize about anomaly detection is that it assumes anything 'unusual' is wrong. So that means that the majority of behavior must be 'usual' and predictable," said Gene Spafford, a professor of computer science at Purdue University, in West Lafayette, Ind., and the designer of Tripwire, the first free IDS and one of the most widely deployed systems on the Internet.

"Anomaly systems tend to generate more false alarms in general," Spafford said. "Signatures alone work only on things that the signatures match. New attacks or variations on attacks can't be found. Adding signatures to anomaly systems helps cut down on the processing overhead for known attacks."

To that end, IntruVert's new appliances combine the signature-based approach of traditional IDSes with anomaly detection and the ability to detect and choke off denial-of-service attacks. The new I-4000 and I-2600 boxes can monitor how hosts interact with other hosts on the protected network and can identify illegitimate behavior.

The appliances, which are due this summer, also have a "micro-tuning" feature that enables administrators to set multiple policies on a single sensor and apply them to individual applications if they so choose.

"What we're trying to do is integrate the entire spectrum of detection technologies," said Ramesh Gupta, vice president of engineering at IntruVert, in San Jose, Calif.

The advantage of the systems that combine signatures and anomaly detection lies in their broader and deeper view of network activity, Trident Capital's Bace said.

"If you're in a position to pull cues from a greater portion of the environment, it's easier to find and fix any problems that might come up," she said. "The preponderance of signatures are simplistic, and the best they're able to do is raise a flag."

Recommended Links

Google matched content

Softpanorama Recommended

Top articles

Sites

Grid2007 Log Summarization and Anomaly Detection for Troubleshooting ...

InformIT Identifying and Classifying Network Security Threats Telemetry and Anomaly Detection

Data Mining Approaches for Intrusion Detection



Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least


Copyright © 1996-2018 by Dr. Nikolai Bezroukov. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

 

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: September, 12, 2017