Alastor | Python DDoS program – Digitalmunition

Home Forums Alastor | Python DDoS program

This topic contains 1 reply, has 2 voices, and was last updated by  tweedge 1 month, 2 weeks ago.

  • Author
  • #352188



  • #352189


    Why are all these headers and referrers stored inline? Load them from another file. For each [line] in [file] append it to headers. Same for referrers. Hard to read and work with as is.

    Will review further when I’m not on mobile and can actually scroll past all this.

    Edit, additional review. This is me going through and actually code reviewing your stuff. Some people love feedback. Others don’t. My goal is to be pragmatic, but since it’s Reddit, a little comedic too. I hope the author (whether or not that’s OP) or others reading along find value in my commentary. Above all, I do want to applaud the author for taking the time to make something, and thus learn about its components in a deep and thorough way.

    Anyway, think of this as “nice, and is how you can take it to version 2.0” –

    * First and foremost: this won’t defeat *any* system greater than a potato. Why? Because it’s using threading, and threading depends on threads using Python’s Global Interpreter Lock, which pins all activity to one core. Sure you have 700 threads, but due to the GIL, only *ever* one core will be processing the actions for those threads. So why didn’t the author notice this? Because urllib2 releases the GIL whenever it’s in IO, which is most of making web requests anyway, so the throughput is probably still quite good. But on other machines, this becomes a massive limitation. See the second bullet.
    * That’s not to say no system can be defeated by this. Plenty of amateur sites are run on hosts with the equivalent capacity of a potato. But when shopping around for DDoS tools, I’d rather bring a hand grenade than a potato slicer.
    * This needs arguments. Argparse: learn it, love it, live it. There are lots of magic numbers sprinkled in here which means the code is relatively inflexible without chopping it up a bit, which while doable, isn’t a great user experience (esp. with the minimal documentation). Why does this matter? Because 700 threads is paltry when I have 48 *physical* threads to throw at this from my workstation alone. Being able to let people say “I want to test this on a local machine with 4 threads to see what the traffic logs look like!” or “it’s time to see what 10k threads looks like in htop!” is much better than “ah fuck, now I need to edit this.”
    * Consider proxy/Tor/etc. support. Don’t get me wrong, I do like this, and I especially like that it has referrers so not all traffic is “direct.” But random samples of that traffic pattern coming from a specific IP makes it more suspicious and bannable, not less. A VK referrer, an MIT referred, and a carolinashealthcare(dor)org referrer in the same five seconds? I cannot imagine the person who would make those legitimately 😉
    * This lowers throughput substantially if enabled, unless very many proxies or Tor circuits could be opened, in which case throughput would still be lower due to resource consumption by that action but not as much as otherwise. But it’s pretty standard fare for other tools of this kind (e.g. slowloris’s Python demo)
    * And then finally, could this be parameterized to have multiple attack modes? Slowloris was just mentioned – could you adapt its work to make the beginnings of an L7 DoS monster tool?

    Hope this gives you some good ideas (*to use responsibly*) and happy to answer any questions.

  • #352190


    Seems to be missing the first D in DDoS..

  • #352191



  • #352192


    Immediately got a calender subscription alert on clicking that link XD

  • #352193



You must be logged in to reply to this topic.