|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: Fulton L. Preston Jr. (fulton
PRESTONS.ORG)Date: Wed Apr 04 2001 - 23:24:14 CDT
Excellent views on the problem Jon. Now the question: What to do about
it?
Not much can be done on our end is my answer. The correct answer would
be "The vendor should release a secure product." In reality this isn't
an obtainable goal. The coders can not possibly think of every known
possible way a deviant mind might find a weakness into their product.
This is why Bugtraq is here, to help the world and the developers know
what the deviants (and the curious) have found with their products.
Using IDS could be a way to signal NEW attacks if one takes the time to
customize the signatures of their "normal network traffic" to a
particular server. If 99% of your traffic to a specific host is nothing
more than normal gets of "index.html" and the images that accompany such
a request, then writing a signature to match ANYTHING outside of this is
pretty straightforward. If a server does not normally receive anything
other than the request for port XXX (insert your favorite port here),
again, customizing a rule to fit this is easy.
I don't think at this time there is any product out there that will
discover and report unknowns unless they match an already existing
pattern. My response to this is an IDS per server that is open to the
public. Write the rule sets per IDS based on what that specific server
is supposed to receive, anything else report and alert! Of course a
"generic" IDS at the border of the network always helps though the
"false positives" will be higher, with a layered IDS system you can
dismiss them rather quickly. An IDS at the border, an IDS in the
subnet, and an IDS per host (can be hosted on the host itself, though
this is up to you) with each IDS alerting going from careless to more
paranoid the deeper into the infrastructure works very well for me.
Just my two cents.
Fulton Preston.
PS: Again, this closely represents anti-virus rules for large networks:
Block known hostile extensions at the firewalls (exe, vbs, etc..), scan
the attachments at the internal email server, and have active virus
scanning on the clients. Multi-layer defenses do help. They don't
catch everything but they keep you from being a 100% open network to a
1% open network (percentages and mileage may vary!)
-----Original Message-----
From: Jon Gary [mailto:jgary
CLICKTOSECURE.COM]
Sent: Wednesday, April 04, 2001 10:54 PM
To: FOCUS-IDS
SECURITYFOCUS.COM
Subject: Re: Can (packet sniffers)ids not like AntiVirus
I've actually done quite a bit of thinking about this problem myself.
This
problem is deeper than IDS systems, as it applies in at least some way
to AV
and security scanners also. The time-honored method is still the same
as it
was in AV a decade ago. Signatures seem to be the way to go. I really
wish
this weren't true. Perhaps it's not worth the effort to improve upon
the
model, but I think it could be done. Heuristic models that have been
created in the past to baseline data and then compare new data to the
baseline, or that look at patterns to detect anomalies always seem
frought
with false-positives, and often have performance problems. The current
offering of IDS solutions seems to be a good solution for now, but I
think
the future is going to prove a bit harsh for signature-based models.
IMHO, the days of Bugtraq and full-disclosure are fast coming to a
close.
Corporations can no longer afford to disclose vulnerabilities as the
once
did, for fear of legal repercussion if the vulnerability is used in a
crime.
Black-hats and grey-hats (with a few notable exceptions) are taking
their
work back underground at a startling rate. Elite hacker groups with
closely-guarded, private libraries of hundreds of undisclosed exploits
used
to look like a myth to me, but lately, it seems that the break-ins we
are
dealing with are increasingly unfamiliar. Many hackers are getting sick
of
giving away the "keys to the kingdom" as it were, and would rather keep
the
vulnerabilities to themselves.
Long term, I think we have to address the reality that the next IIS
remote
exploit might not appear on CNN. I guess I'm degrading into a general
discussion of code quality and my problems with prior-knowledge based
products, but I honestly think that we are going to have to address this
sooner than we think.
Jon Gary
Engineer
Click To Secure, Inc.
-----Original Message-----
From: Focus on Intrusion Detection Systems
[mailto:FOCUS-IDS
SECURITYFOCUS.COM]On Behalf Of Joe Carnahan
Sent: Wednesday, April 04, 2001 3:08 PM
To: FOCUS-IDS
SECURITYFOCUS.COM
Subject: Re: Can (packet sniffers)ids not like AntiVirus
--- darkeyes <darkeyes
263.NET> wrote:
> hi all:
> In my finish college project i will make a
> IDS based libpcap & libnids.But after these days , i
> found that the packet sniffers ids is like some
> AntiVirus software such as McAfee. We can only
> analyse the exploit on the specifically System to
> collect the rules.
Or in other words, how could you ever detect a new
exploit before the vendor releases a new "exploit
definition" and you install that definition? It's
true, with most IDSes, you're screwed. One approach
that I've used in writing filters for SHADOW is to
define my filters as something like
tcp and not (
<all acceptable traffic>
)
Now, here's the big problem with my own suggestion:
That's good if you're just watching traffic patterns,
since the set of "acceptable" things is finite. But,
there's a limitless amount of acceptable content, so
for content filtering, I don't know how you could
improve on the signature-based model.
Just some thoughts,
Joe
=====
Joseph Carnahan
haq4jc
yahoo.com
Home: (540) 361-4345
Work: (540) 653-5798
or (703) 697-6318
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]