|
Softpanorama
(slightly skeptical)
Open Source Software Educational Society |
May the
source be with you,
but remember the KISS principle ;-)
|
Vulnerability analysis vs anomaly detection
| I personally think that IDS appliances is a mostly useless tool - especially
the way it is typically implemented |
- With that much data, and 98% of it being
useless, you kind have to ask yourself, "what's the point?"
- Everything
I've seen says they look for known-bad-stuff and produce alerts and false positives.
- 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!
-
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.
- 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.
-
That's the main reason why I don't like IDSs. A default deny
policy combined with "log everything" achieves just the same.
[Oct 06, 2006]
IDS Signature versus anomaly detectionNETWORK 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.
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.
-
They are very
fast, since packet matching is a relatively non-processor intensive task.
-
The rules
are easy to write and understand, as well as very customizable.
-
Additionally, there
is fantastic community support for rapidly generating signatures for new alerts
and warnings.
-
These systems excel at catching low level, simple attacks since they
tend to employ prepackaged exploits that are easy to recognize.
-
Lastly, signature-based
analysis conveys exactly what has happened very well, since it takes a very specific
event to trigger an alert.
On the flip side, signature-based IDS has definite weaknesses.
-
While
initially very fast, this performance edge slips away as the ruleset grows. This
is particularly problematic as the ruleset can grow very fast – basically, for each
attack or exploit that is created by attackers, a new rule must be created to detect
it.
-
Despite data normalizers and packet reassembly, both of which eliminate some
evasion techniques, uncountable variations of attacks can slip by a signature-based
system.
-
Application level attacks such as Unicode, multiple variations similar to
those found in SNMP community strings, and evasion programs that morph shell code
like ADMutate can cause serious problems for any signature system.
-
The slightest
variation in an attack is often enough to defeat a signature.
-
The only solution
is more rules, which eats away at performance and increases complexity.
-
And as any
IDS admin can confirm, such systems generate loads of false positives due to the
sometimes simplistic nature of their packet evaluations and the sheer number of
rules in place.
-
This leads to an associated problem: because they work by comparing
a list of signatures to the packet data, signature-based attacks can only catch
attacks that are known and for which signatures have been created.
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.
-
Furthermore, the rules for a protocol system are
difficult to write and understand. In some ways, it's extremely vendor dependent,
since a processor is required for each protocol that is to be reviewed, and the
rules are relatively complex. T
-
he increasingly complex and frequently ignored protocol
standards and RFCs pose an additional problem for IDS developers, making it difficult
to write accurate processors.
-
While at first glance protocol-based IDSs are slower than signature-based
systems, they more than make up ground in terms of scalability and performance as
signature-based rulesets grow.
-
Furthermore, since they search for generic violations,
protocol analysis engines can often catch zero-day exploits, something that is impossible
for a signature system; unfortunately, they can sometimes miss obviously deviant
events, such as a root Telnet session, that do not violate any protocol.
-
Protocol-based
systems keep the false alarms to a minimum, since they log real violations.
-
Unfortunately,
they often don't provide enough information. Instead, they merely note the anomaly,
placing the burden of investigation on the admin.
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.
Notes:
- Those pages are written by people for whom English is not a
native language. Some amount of grammar and spelling errors
should be expected.
- This is a Spartan WHYFF (We Help You For Free) site. It
cannot replace the best teachers and
the
best books.
- The site contain some obsolete pages as it develops like a
living tree... Some links on older pages
are broken. Please
try to use Google, Open directory, etc. to find a replacement link
(see
HOWTO search the WEB for details).
We would appreciate if you can
mail us a correct link.
|
|
[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</