[tech] hydra

[James Andrewartha]

On Sat, 1 Sep 2001, Bryden Quirk wrote:

> > > what is ip_conntrack  and what is that buffer refing to ?
> > 
> > When I am asked such questions where 10 minutes of research will
> > discover the answer, I usually subscribe to the teach a man to fish
> > philosophy and reply, "RTFM."
> > 
> > But I am unable to supress the rage to shout, "IT TRACKS
> > CONNECTIONS, YOU IDIOT."
> 
> I was after alittle more detail as to what spisificly about the
> connections it was tracking in what manner and for what purpose in this
> situation.

I don't know what connections exactly it is tracking, apart from (at least
some) of the connections that are made through hydra, even those that
aren't NATted.

> I dont belive the kernal documentation will have alittle note about what
> the ucc dose with this.

UCC doesn't use it for any specific purpose, it just happnes to be a
module used by the ip_nat and ip_nat_ftp modules, which are loaded when
someone adds a NAT rule to iptables. As such, UCC uses it exactly as it would
be documented in the kernel docs (if it is documented there - I couldn't find
it with 10 seconds of grepping). When I googled for it all it said was
basically that it tracks connections, and that if you get the error that was
on hydra's console (maximum number of connections exceeded or whatever it
was), you might be under a DoS attack.

> aka is it appart of the charged tunnle, coke , etc..
> dose the ucc use it as a primitive netflow alternitive
> or is it being used for pointless statistial infomation ?

UCC doesn't it it for anything - it's part of the kernel part of iptables, and
is used to keep track of connections for NAT. UCC does use NAT, although at
the moment it's only used to forward some ports to get around firewalls (ie
people connect to 130.95.13.8 (which isn't an acutal machine) on port 80 and
hydra NATs the connection to mooneye:4242 (flame), so people who are
firewalled on port 4242 can still connect to flame). There's 3 or 4 of these
rules in the nat table. There's also some firewall rules to limit people
coming from flying (and hence the wireless network) to 130.95.13.0/24.

> > > not what you whould relly describe as being particuly efective
> > > Denyal of service attack over a ethernet connection however in this
> > > instance it appears to have had that efect.  for which im quite
> > > sorry.
> > > 
> > > am i missing a obvius reson why hydra should have fallen down so
> > > helplessly ?
> > 
> > I assume the problem with hydra is that ip_conntrack makes an attempt to
> > track UDP "connections", which don't ever have a formal disconnect.  So
> > I think it must use a timeout, which desn't work if its being flooded.
> 
> ok well i didnt know that before and ill know for next time.
> 
> > Of course, why are we using ip_conntrack?  Well it probably seemed like
> > a good idea at the time, but I don't think we actually need it.
>
> it probobly did at the time and may still be.

As I said above, UCC is not using ip_conntrack in and of itself, but because
it's a module used by iptables.

> this whole thing rases a few questions in my mind.
> 
> I can tell you for a fact that the atual data rate was quite low i can run
> the same scripts at home and keep the link latency at 40ms (its just
> losts of little connections)  
> 
> so
> 
> dose this mean that machines setup this way are vunrable to this kind of
> attack by somone who may actuly want to inflict harm ?

Yes.

> (keeping in mind that whould bee machine power independent becuse if the
> table size is of a definable and preset value (which i whoudl assume
> becuse james was able to set its size) then it chould fill up just as
> quicly whether the machine was a 386 or a P4.

The default is set by the kernel depending on the memory size of the machine.
Since hydra has 16 MB of RAM, the limit was set to 1024. Each extra connection
requires 500 bytes of non-swappable kernel memory apparently. You can alter
this value (in /proc/sys/net/ipv4/ip_conntrack), and I did, to 2048 and 4096,
but it was filled up in about 5 seconds so I took it back down.

>  i whould imagen that this whould be quite diffrent from a syn attack
> becuse the router whould not be the machine having conection requests made
> to.

Yes it is quite different - althought the machines on the network function
quite happily, network connections can take a while to establish due to the
packets being dropped on the floor by the router. EG windows took a while to
appear on the xterms.

> and i dont think this whould be much difrent in nature to somone strobing
> a network behind the machine  (which like it or not happens all the time
> alltho prehaps not for such a prelonged period at a time)

Not much different - if someone did that to UCC hydra would probably die in
the same way.

> and out of intrest how oftern is this feture used ?

Presumably on every iptables NATing firewall out there.

> at least it was more subtle than the time i pulled the plug to the machine
> room :P

I did netstat on the user machines (and mooneye), but I couldn't see an
unusually large number of connections, nor when I looked at
/proc/net/ip_conntrack on hydra - I must have picked a time when the program
wasn't running. And when I asked Grahame to check for someone DoSing UCC, it
didn't show up because all the nameservers were internal.


-- 
"There's nobody getting rich  |  TRS-80                UCC Treasurer
 writing software that I      |  Email:    trs80(a)ucc.gu.uwa.edu.au
 know of" - Bill Gates, 1980  |  Web:       http://trs80.ucc.asn.au/