lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <AEEAKGKHCDMLEHCOGIBCCEFOCDAA.list.fulldisclosure@webscreen-technology.com>
From: list.fulldisclosure at webscreen-technology.com (Gareth Blades)
Subject: RE: Attack profiling tool?

> -----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.



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ