[tech] hydra

[Bryden Quirk]

> You are so cool.

yes i am just l33t3 :P

but just not as cool as you becuse i actuly bother to try stuff out
which is apparantly not "the done thing" :)  <- *note the smily*

evan if sompthing odd goes to shit the way it goes to shit is still very
intresting. :)

> > 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 dont belive the kernal documentation will have alittle note about what
the ucc dose with this.

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 ?


> 
> > the dnsquerys where being made one after another with 5 processes running
> > in parralell (i doubt it that in excess of 2 requests per second whould
> > have ever been acchived )
> 
> You may have underestimated things a little.  When I straced one, the
> connections were flying up the screen.

probobly becuse it was instently failing or getting connection refused
when hydra was down :)


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

this whole thing rases a few questions in my mind.

(no im not about to go into a rant about how the UCC router
(spicificly) should have been better etc becuse thats not relly the point)

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 ?

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

 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.

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)


and out of intrest how oftern is this feture used ?


at any rate i appologies (again) to the people whos time this wasted.

But "shit happens" :)

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