From: Sels, Roger (roger.sels@gov-fbi.net)
Date: Mon May 09 2005 - 09:12:00 EDT
Hello Julian,
Concerning limiting the bandwith utilization, wouldn't it be easiest if
you put a small firewall before your pentest box ? e.g. a linux iptables
fw with additional QOS rules.
You can find good doc on http://www.lartc.org (Linux Advanced Routing And
Traffic Control) on how to set this up.
Added advantage: your pentest box is not "out there and naked".
It should not be directly connected to any of your networks (if possible)
or be _very_ restricted by a firewall ( between the pentest box and your
network).
I see no harm in making sure you're not being attacked on the ingress
interface either.
And you don't need an advanced flooding tool to SYNflood a box. If
creative, you could very easily script this yourself. ( e.g. a couple of
hundred telnet sessions/second, sleep a bit , start all over.
Season to taste ;-) )
Your second question seems quite the oppossite from the first. Why flood
their line if all you want is to demonstrate resource exhaustion on 1
server ?
If you really want to (D)DoS the line, your 2Mbit won't do the trick for a
10Mbit line, no.
Unless you could/would possibly do a Smurf attack, but involving other
(unsuspecting/unprotected) networks is a highly doubtfull practice and
should not be considered an option.
You don't need to fill the line, you need to send SYN's faster than the
connection attempt times out.
Will your spoofed packets even get in ?
Most well-configured firewalls perform anti-spoofing, thus your packets
should not even enter the network.
This of course is assuming you want to use RFC1918 address space for your
spoofed hosts.
If you are spoofing private addresses "blindly", yes, that could backfire
to the rightfull owners of those IP's, leading them to believe their
network is under attack by your customer !
"Unfortunately" with valid IP's you will need a rather constant stream of
traffic to flood the box, whereas if you had unreachable IP's the box
would need to wait for a time-out before freeing the resources again.
You can simulate this situation however by dropping the SYN/ACK's on your
FW (again, a good reason to have that FW before your pentestbox ), which
will cause your customer's server to keep the connection in SYN_RECV until
it times out.
This seems like a cleaner approach to what you are trying to do, but the
feasibility all depends on the hardware involved, OS being used, FW's at
your customer's side etc...
Kr
Roger
-- When did I first realize I was God ? Well, I was praying. And suddenly, I realized I was talking to myself. On Fri, May 6, 2005 9:44 am, Julian Totzek said: > Hi group, > > within a pentest we trying to offer the possibility of a DDos Foold for > our customers. I know there are many tools to do a flood from a single PC, > but all of these tools just send as many syn's as the can. Does anybody > know a tool where I'm able to limit the bandwidth? I don’t want to get a > bandwidth overload, I just want to show that the server is not able to > handle all the syn packets. > > An other question is from where would I start such a attack? We only have > a 2Mbit line here in the office, so if I need to flood a 10Mbit line there > will not be enough packets to do this, right? Maybe there is a provider > out there who already offers this service! > > The third question is what will be the side effects if I send packets with > spoofed sources? As you all know I don't a answer to my packets, but would > it be a DDos to all spoofed sources then? How can you ensure that only the > main target is getting flooded? > > > Best regards > > Julian Totzek > > THE BRISTOL GROUP Deutschland GmbH > Robert-Bosch-Straße 11 > 63225 Langen > Telefon +49 (0) 6103 20 55 300 > Telefax +49 (0) 6103 70 27 87 > Emergency Phone 0190/858 979 000 (1,86€/min) > julian.totzek@bristol.de > www.bristol.de > > > HTTPS, HTTP, SMTP, IMAP, POP3 und FTP > Kostenloser 14-Tage-Test einer CP Secure Antivirus Appliance > http://www.bristol.de/testing.htm > >
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:54:20 EDT