Message-ID: <Pine.GSO.4.43.0307111139340.26986-100000@tundra.winternet.com>
From: dufresne at winternet.com (Ron DuFresne)
Subject: RE: Attack profiling tool?

This might be testing  of a new tool/toy in developement, and might
explain the icmp traffic your original posting of the packet traces
provided.

Thanks,

Ron DuFresne

On Fri, 11 Jul 2003, Gareth Blades wrote:

> > -----Original Message-----
> > From: Dimitris Chontzopoulos [mailto:dchontzo@....gr]
> > Sent: Friday, July 11, 2003 15:19
> > To: 'Gareth Blades'
> > Subject: RE: [Full-Disclosure] RE: Attack profiling tool?
> >
> >
> > <Sorry but I disagree. Firewalls don't defent against connection floods
> > (naptha type attacks) very well at all>
> >
> > And what exactly can protect you against these attacks, apart from one
> > (or more) Firewall(s), an IDS (or an IPS), TCP/IP stack tunning, and Web
> > Server incoming connections tunning (if possible) all-together?
>
> Well oviously our product can but it is not me going too much in depth about
> my opinion of our competition as my view will oviously be considered biased.
> >
> > <Take Cisco PIX as an example which has a setting where you can limit
> > the...>
> > <Firewall-1 is no better...>
> >
> > What you said though about FW-1 and CiSCO PIX is not correctly put. FW-1
> > can protect you against these kinds of attacks (connection flooding) if
> > and only if you know how to configure it. I am not trying to be a
> > wise-guy here or something, I am merely trying to tell you what is true
> > and what is not. Stateful Packet Inspection isn't there just to help you
> > against NOT 100% valid packets, it is there to do a lot of things far
> > from checking against the validity of packets. Both CiSCO PIX and
> > Checkpoint Firewall-1 support Stateful Packet Inspection.
>
> During testing of our product in conjunction with firewalls the FW-1
> reseller was unable to provide any configuration which caused FW-1 to defend
> against connection attacks. In order to defend against these attacks you
> have to make a decision to block one IP address but allow another to
> connect. This decision can be based on various factors including how many
> connections they currently have, are they a regular visitor, do they
> regularly have lots off connections (i.e are they a proxy server). FW-1 did
> not have any configuration in this area that we could see.
>
> > <Besides as I said originally our own defense product is sitting infront
> > and this does block this type of attack...>
> >
> > And how exactly is that done? Is it limiting the connections to the
> > target it is protecting or is it counting the established connections
> > from that source to the target it is protecting? If so, then you doing
> > nothing more than limiting the connections to the target you are
> > protecting, but from a different perspective and machine. Maybe you
> > should consider limitting the IP Addresses permitted to connect to your
> > protected host (or Webscreen Console to put it better).
>
> As the number of connections approaches the configured limit we decide if a
> new connection is permitted depending on the history recorded for the client
> and some other factors. Yes we are limiting the number of connections but we
> are doing it selectivly by not allowing the attacker to make new connections
> but allowing everyone else to. The particular machine is a demo server so
> anyone may connect.
>
> > <I have seen the exact same profile of probing from at least 4 different
> > IP addresses...>
> >
> > Have you considered that someone is spoofing some addresses? I can do
> > that if you want me to... Just create a batch file with Nmap, launch it
> > as many times as your machine is able to, tell it to use Connect Mode
> > Scan, give it a Port Range of 433-433 and give it some real Internet
> > Hosts to use as Decoys.
>
> They are TCP connections and as the client is completing the handshake they
> cannot be spoofing the source address. If the source address was spoofed
> then they would not get the SYN-ACK packet which they reply to, to complete
> the connection.
>
> > I tried to connect to the IP Address they are trying to access and I
> > think it is a "Webscreen Console", yes? Is it possible that the "Bad
> > guys" are trying to "Brute Force" your console? Maybe you should try
> > tools like "PortFuck" and such that flood their targets. You can search
> > for this tool at astalavista.box.sk and you will find it. Then you could
> > check the data pattern of "PortFuck" against the captured data. Another
> > tool could be Nmap or even Nessus, Satan, ISS Internet Scanner and many,
> > many, many, many others.
>
> I don't think they are trying to brute force the console as once the TCP
> connection is established there is no furthur data transfer until they close
> the connections.
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Cutting the space budget really restores my faith in humanity.  It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation." -- Johnny Hart
	***testing, only testing, and damn good at it too!***

OK, so you're a Ph.D.  Just don't touch anything.

Powered by blists - more mailing lists