|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
| News | Recommended Links | |||
| I personally think that IDS appliances is a mostly useless tool - especially the way it is typically implemented |
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:
- Our Snort Technical Guide offers answers to common operational questions.
- This primer on intrusion detection defines anomaly versus signature detection and network- versus host-based systems.
- Visit our intrusion detection resource center for more tips and expert advice on intrusion detection.
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 [email protected].
Vulnerability detection vs anomaly detection
The Great IDS Debate : Signature Analysis Versus Protocol Analysis
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.
|
|
Switchboard | ||||
| Latest | |||||
| Past week | |||||
| Past month | |||||
- Previous message: [fw-wiz] FW appliance comparison - Seeking input for the forum
- Next message: [fw-wiz] FW appliance comparison - Seeking input for the forum
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
-----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).
On 1/18/06, Paul Melson <[email protected]> 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
[email protected] 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
[email protected] which may have no basis whatsoever in fact."
http://fora.compuwar.net Infosec discussion boards
Paul Melson
[email protected]
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. PaulMPaul D. Robertson [email protected]
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
[email protected] which may have no basis whatsoever in fact."
http://fora.compuwar.net Infosec discussion boards
Paul Melson
[email protected]
-----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. PaulMDevdas Bhagat Devdas Bhagat <[email protected]>
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 BhagatPaul D. Robertson [email protected]
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
[email protected]
[email protected]
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 > [email protected] which may have no basis whatsoever in fact." > http://fora.compuwar.net Infosec discussion boards > > _______________________________________________ > firewall-wizards mailing list > [email protected] > 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 [email protected]
On 1/20/06, [email protected] <[email protected]> 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 [email protected]
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
[email protected] which may have no basis whatsoever in fact."
http://fora.compuwar.net Infosec discussion boards
Devdas Bhagat
Devdas Bhagat <[email protected]>
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 BhagatPaul D. Robertson [email protected]
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
[email protected] which may have no basis whatsoever in fact."
http://fora.compuwar.net Infosec discussion boards
Ben Nagy
[email protected]
Hi Paul, Devdas! > -----Original Message----- > From: [email protected] > [mailto:[email protected]] 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
[email protected]
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
[email protected] which may have no basis whatsoever in fact."
http://fora.compuwar.net Infosec discussion boards
Ben Nagy
[email protected]
Tue Jan 24 08:00:17 2006
Hi Paul, Devdas! > -----Original Message----- > From: [email protected] > [mailto:[email protected]] 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, benChuck Swiger [email protected]
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. ] -- -ChuckPatrick M. Hausen [email protected]
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 <[email protected]>
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 [email protected]
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 [email protected]
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 [email protected]
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.
[email protected]
[email protected]
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
[email protected] On Tue, 24 Jan 2006 [email protected] 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 [email protected] which may have no basis whatsoever in fact." http://fora.compuwar.net Infosec discussion boardsMarcus J. Ranum [email protected]
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 [email protected]
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
[email protected] which may have no basis whatsoever in fact."
http://fora.compuwar.net Infosec discussion boards
On 1/25/06, Paul D. Robertson <[email protected]> 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 [email protected]
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 <[email protected]>
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 BhagatChristine Kronberg [email protected]
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.
On Fri, 20 Jan 2006 [email protected] 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 [email protected] which may have no basis whatsoever in fact." http://fora.compuwar.net Infosec discussion boards
On Fri, 20 Jan 2006 15:43:33 +1100 [email protected] 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 <[email protected]> Infrastructure Security Analyst Armstrong World Industries, Inc.
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
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
[email protected] 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.
-----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
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
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
[email protected]
Thu Jan 26 21:13:01 2006
On 1/25/06, Marcus J. Ranum <[email protected]> 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]
[email protected] [email protected]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, [email protected] 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.
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 quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard 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 DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting 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-Month : How 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 Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) 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 to buy a cup of coffee for authors of this site |
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 Softpanorama society. 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 updated: August 15, 2009
