headers
Bojidar Tzendov | 2 Jun 2003 08:10

Network IDS overcoming


Dear All,

I am very interested for a statistic that depicts NIDS systems resistance 
against hacker attacks directed directly to NIDS sensor.
I mean attacks us defragmantation, overloading, etc.

Can someone give me statistic documents or url.
That matter is important because you know NIDS is open-failure

Thanks in advance

Bojidar 

-------------------------------------------------------------------------------
INTRUSION PREVENTION: READY FOR PRIME TIME?

IntruShield now offers unprecedented Intrusion IntelligenceTM capabilities 
- including intrusion identification, relevancy, direction, impact and analysis 
- enabling a path to prevention.

Download the latest white paper "Intrusion Prevention: Myths, Challenges, and Requirements" at: 
http://www.securityfocus.com/IntruVert-focus-ids2
-------------------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
Jimi Thompson | 2 Jun 2003 04:30
Picon

Re: IDS thoughts

><SNIP>
>
>>  I don't think anyone has forgotten anomaly-based detection.  Most
>>  players are taking a hybrid approach.
>
>This is what they say, but beyond marketing hype and some small, limited
>attempt at portscan detection, there is nothing of the kind in production
>system. I welcome counter-examples of course !
>
</SNIP>

I recently finished a lengthy stint with a fortune 10 company web 
site and would agree with you.  While we had various vendors in and 
and evaluated a lot of products, we finally had some in house 
developers write a custom system based around AI engine to handle 
heuristic and anomaly detection.  It was fairly good at detecting 
stealthy port scans and initiating appropriate counter-measures.  It 
took us a LONG time (over a year) to get it trained and operating 
properly.  Even then, it still routed a goodly number of things to 
humans for evaluation.
--

-- 
Thanks,

Ms. Jimi Thompson, CISSP, Rev.

"Those who are too smart to engage in politics are punished by being 
governed by those who are dumber." --Plato

-------------------------------------------------------------------------------
INTRUSION PREVENTION: READY FOR PRIME TIME?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marcelo Olguin | 2 Jun 2003 16:38
Picon

Re: Detecting Connections in Snort

I understand that exists a particular funcionality in portscan snort's 
preprocessor, which let you set a threshold for connections. You can 
find more information en Snort 2.0 book (Syngress).

Bye

Marcelo
-.-


Faiz Ahmad Shuja wrote:

>Does anybody have idea about detecting multiple connections from a
>single IP in Snort?. I want to detect multiple connection request from a
>single IP to mail server [port 25]. Somtimes a single IP have taken up
>all the connection slots. Is there anyway to set a threshold?. If I am
>getting multiple connections from a single host to any service and it
>reaches a specific count, I get the alert?.
>
>Please advise.
>
>Thanks!
>
>
>Regards,
>Faiz
>  
>

-------------------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 1 comment |
headers
Lance Spitzner | 2 Jun 2003 16:52
Favicon

May's SotM challenge results

Raul Garcia of the Mexico Honeynet Project has released the
results of May's Scan of the Month challenge. We received 
39 submissions, many of these were some of the best submissions
we have seen, so juding was very tough.  In this challenge, you 
were to analyze a network capture of Italian blackhats breaking 
into a Solaris server, then communicating over IPv6 tunneling.  
You can find the results online at

      http://www.honeynet.org/scans/scan28/

There will be no challenge for the month of June.  Instead, 
we are preparing for July's SotM challenge.  For July's 
challenge, we will be attempting something new, something we 
have never tried before.  The analysis of a live, hacked
system :)

Thanks!

lance

-------------------------------------------------------------------------------
INTRUSION PREVENTION: READY FOR PRIME TIME?

IntruShield now offers unprecedented Intrusion IntelligenceTM capabilities 
- including intrusion identification, relevancy, direction, impact and analysis 
- enabling a path to prevention.

Download the latest white paper "Intrusion Prevention: Myths, Challenges, and Requirements" at: 
http://www.securityfocus.com/IntruVert-focus-ids2
-------------------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
Darren Bounds | 2 Jun 2003 17:05

Packit 0.6.0 Released!

Hello all,

Just thought I'd let you know that this morning Packit 0.6.0 was
released to http://packit.sourceforge.net. It should also be available
shortly on http://www.packetfactory.net.

Check out http://packit.sourceforge.net/ChangeLog for a list of changes.

Description:

Packit is a network auditing tool. Its value is derived from its ability
to customize, inject, monitor, and manipulate IP traffic. By allowing
you to define (spoof) nearly all TCP, UDP, ICMP, IP, ARP, RARP, and
Ethernet header options, Packit can be useful in testing firewalls,
intrusion detection systems, port scanning, simulating network traffic,
and general TCP/IP auditing. Packit is also an excellent tool for
learning TCP/IP. 

Packit requires libnet 1.1 or greater as well as libpcap. It has been
successfully compiled and tested to run on FreeBSD, NetBSD, OpenBSD,
MacOS X and Linux. 

Thanks

Darren Bounds

--
Intrusense - Securing Business As Usual

-------------------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
Faiz Ahmad Shuja | 2 Jun 2003 17:34
Picon
Favicon

RE: Detecting Connections in Snort

Snort's portscan processor works on TCP connection attempts to more than
P ports in T seconds or UDP packets sent to more than P ports in T
seconds. It doesn't work for number of C connections  to P destination
port in T seconds. 

currently the format is:

portscan: <monitor network> <number of ports> <detection period> <file
path>

it should be something like:

portscan: <monitor network> <number of connections> <dst port>
<detection period> <file path>

Though, this preprocessor has capability that alerts would only show
once per scan, rather than once for each packet. So it can be modified
for specific number of connection threshold for single alert.

Is this possible?

Regards,
Faiz

-----Original Message-----
From: Marcelo Olguin [mailto:molguin <at> inf.utfsm.cl] 
Sent: Monday, June 02, 2003 7:38 PM
To: Faiz Ahmad Shuja; focus-ids <at> securityfocus.com
Subject: Re: Detecting Connections in Snort
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephen P. Berry | 3 Jun 2003 04:00

Re: IDS thoughts


Stefano Zanero writes:

> Here you are talking about enforcement, not detection... as long as you can
> enforce a rule, there's no need to resort to detection. Detection is useful
> when you cannot state or enforce an a priori rule on something.

I disagree.  Anytime you have an interface between zones of different risk,
liability, threat, or whatever, there should be:

	-A policy which enunciates and addresses this difference
	-A mechanism for enforcing this policy
	-A mechanism for auditing the enforcement of this policy

As I have (publically, and quite possibly on this list) opined before, to
do otherwise is to rely on voodoo and wishful thinking.

A full-bore formal policy document, firewall-type perimeter defence, and
NIDS architecture is not, of course, necessary for all such interfaces.  For
some, voodoo and wishful thinking may well be sufficient.  But just because
you've got an enforcement mechanism in place in no way suggests that you
don't need a policy monitoring system.

Indeed, I think it's a (prevalent) GCE not to assume that (all else being
equal) there should be -discrete- enforcement and monitoring mechanisms.  My
contention is:

	-The most important behaviour of any security device is its failure
	 mode
	-Very few security devices can be relied upon to provide rigourous
(Continue reading)

Permalink | Reply | 1 comment |
headers
Aaron Turner | 3 Jun 2003 18:03
Picon
Favicon

Tcpreplay 1.4.3 released & a call for testers

<marketing cap>
Attention all IDS testers and libnet junkies!

Tcpreplay 1.4.3 has been released which contains a bunch of important 
bug fixes over earlier 1.4.x releases as well as new features and 
performance enhancements over the 1.3.x tree.  And as a special bonus,
tcpreplay now contains a pretty FAQ full of example uses of tcpreplay
and it's sister program tcpprep.  All this and more for the low, low
price of $0 after instant rebate when you download it at:

http://tcpreplay.sourceforge.net/

</marketing cap>

On another note, 1.5 development is well underway, and I'm looking for a
few testers who'd be interested in testing and providing feedback on the
latest tool in the tcpreplay suite: flowreplay.  Flowreplay can read the
same pcap files as tcpreplay, only it actually connects to server(s) and
replay's the client side of the connection.  Perfect for testing HIDS
or tcpdump captures of exploits in the wild against vulnerable/patched
servers.  

Flowreplay is still under heavy development and is considered alpha at
best.  However, I'd love to hear feedback from the user community
regarding feature requests or ideas you have to improve on the basic
concept.  Of course, if you are interested in testing this tool with 
your pcap files, let me know.

--

-- 
Aaron Turner <aturner at pobox.com|synfin.net>  http://synfin.net/aturner
(Continue reading)

Permalink | Reply | 0 comments |
headers
Magnus Almgren | 3 Jun 2003 08:47
Picon
Picon

Re: Random IDS Thoughts [WAS: Re: IDS thoughts]

> > could be beaten by flooding a network with "anomalous" traffic
>
> Rather naive. If you have a product that does not "adapt", this is obviously
> not a problem (i.e., you deploy it, you train it, then you "lock" it).
> Letting an algorithm learn by itself and still not get fooled by a semantic
> drift (this it one of the current names for the effect you described) is not
> an easy task [...]

There is a recent interesting paper about anomaly detection systems.  The
authors discuss two different methods to avoid an anomaly detection
system. First, you can corrupt the training data so that the detector
judge attacks to be accepted behavior. This is non-trivial for the
attacker. Second, you can change the attack to not generate events
that manifest themselves in an anomalous (thus detectable) way by the
detector. This is the approach they have followed in this paper. They
have taken a research prototype and demonstrated how they can change
previously detected attacks to become invisible to the detector.

It is a good article, and I recommend it.

Tan, Kymie M. C.; Killourhy, Kevin S. and Maxion, Roy A. "Undermining
an Anomaly-Based Intrusion Detection System Using Common Exploits." In
Fifth International Symposium on Recent Advances in Intrusion
Detection (RAID-2002), Andreas Wespi, Giovanni Vigna and Luca Deri
(Eds.), 16-18 October 2002, Zurich, Switzerland, pp. 54-73. Lecture
Notes in Computer Science #2516, Springer-Verlag, Berlin, 2002.

If you have access to Springer, you can find the article at
  http://search.springer.de/link-cgi/view-hd.pl?/search97cgi/s97_cgi?action=view&queryZIP=%28%22Maxion%22%29&vdkVgwKey=%2Fglobal%2Fdata%2Fverity%2Flink%2Fabstracts%2Fjour%2Fseries%2F0558%2Fbibs%2F2516%2F25160054.htm&strURL=http://link.springer.de/link/service/series/0558/papers/2516/25160054.pdf&strXML=http://search.springer.de:80/search97cgi/s97_cgi?action=view&collection=springer02&doctype=xml&vdkVgwKey=%2Fjour%2Fseries%2F0558%2Fpapers%2F2516%2F25160054.pdf&queryZIP=%28%22Maxion%22%29
(Continue reading)

Permalink | Reply | 0 comments |
headers
Raistlin | 3 Jun 2003 09:15

Re: IDS thoughts

> I disagree.  Anytime you have an interface between zones of different
risk,
> liability, threat, or whatever, there should be:
> -A policy which enunciates and addresses this difference
> -A mechanism for enforcing this policy
> -A mechanism for auditing the enforcement of this policy

Yes. But, as long as you can clearly DEFINE this policy, the enforcement
mechanism and the detection mechanism can be the same. If you check twice
against the same rule, you are not doing "anomaly detection" - at least, not
in my concept :-)

You are doing anomaly detection if you hunt down anomalous data in a dataset
which is not, a priori, defined by a set of formally specificable rules.

Stefano "Raistlin" Zanero
System Administrator Gioco.Net
public PGP key block at http://gioco.net/pgpkeys

-------------------------------------------------------------------------------
INTRUSION PREVENTION: READY FOR PRIME TIME?

IntruShield now offers unprecedented Intrusion IntelligenceTM capabilities 
- including intrusion identification, relevancy, direction, impact and analysis 
- enabling a path to prevention.

Download the latest white paper "Intrusion Prevention: Myths, Challenges, and Requirements" at: 
http://www.securityfocus.com/IntruVert-focus-ids2
-------------------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |

Gmane