Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Something can be improved #3

Closed
LEXUGE opened this issue Jul 27, 2018 · 3 comments
Closed

Something can be improved #3

LEXUGE opened this issue Jul 27, 2018 · 3 comments
Labels
question Further information is requested

Comments

@LEXUGE
Copy link

LEXUGE commented Jul 27, 2018 •
edited
Loading

I've done my project and I've discovered some way to improve the Synner maybe:

  1. The random<T>() costs a lot of time. So, I think you can choose Xorshift instead of regular random algorithm. The rand library has impled the Xorshift algorithm and I wrote a fast_random<T>():
pub fn fast_random<T>() -> Result<T, rand::Error>
where
    T: PartialOrd + SampleUniform,
    Standard: Distribution<T>,
{
    let mut rng = XorShiftRng::from_rng(EntropyRng::new())?;
    Ok(rng.gen())
}
  1. You can modify the Packet's source IP and source Port fields instead of creating whole new packet.
    I did this in build.rs. I created a struct and impled some methods for it.
  2. In Synner, for every single sending, you will create a new (mut tx,_) pair, which is needless. I think you can just use one tx, so you can save the time of creating tx.
    I did this in sender.rs.

And I think your demo is not right maybe? I think you couldn't SSH the server because your bandwidth has been blocked. If you run the synner, can you open Google or other website normally? If not, the demo cannot prove the Synner attacked the server.
@LEXUGE LEXUGE changed the title Some thing can be improved Something can be improved Jul 27, 2018
@JuxhinDB
Copy link
Owner

Hey @LEXUGE -- that's great! Well done and thank you for taking the time to come back and tell me what you did.

  1. Looking to implement this shortly.
  2. That's interesting and does make sense. Have a template packet where all you change is the srcport and dstport to some random value
  3. I don't believe I'm doing that. I'm only calling tcp::send_tcp_packets at entrypoint:

synner/src/main.rs

Lines 34 to 42 in fc0d56b

fn main() {
let parsed_args = parse_arguments().unwrap();
let count = 1;
send_tcp_packets(parsed_args.0, parsed_args.1, count);
println!("Sent {} packet(s)", &count);
}

So I'd be binding the interface only once, then using that same interface to send n number of packets.

Regarding the demo, I forgot how I had evaluated it but even after maxing out my network traffic as seen here:

image

I'm able to access the internet just fine, probably due to throttling. But that said, your analogy does make sense. When testing it from one DigitalOcean droplet to another however, the test worked. I was not able to access the dummy phpMyAdmin interface any longer and from tcptrack you can see all 314097 initiated TCP connections waiting to be handled by the server:

root@jdb-test-DELETE:~# tcptrack -i eth0
 206.189.110.8:2318    206.189.104.51:14423  SYN_SENT     31s    0 B/s
 206.189.110.8:3084    206.189.104.51:638    SYN_SENT     18s    0 B/s
 206.189.110.8:4590    206.189.104.51:241    SYN_SENT     25s    0 B/s
 206.189.110.8:51      206.189.104.51:429    SYN_SENT     29s    0 B/s
 206.189.110.8:961     206.189.104.51:30366  SYN_SENT     28s    0 B/s
 206.189.110.8:230     206.189.104.51:326    SYN_SENT     14s    0 B/s
 206.189.110.8:18711   206.189.104.51:9474   SYN_SENT     27s    0 B/s
 206.189.110.8:44724   206.189.104.51:13396  SYN_SENT     27s    0 B/s
 206.189.110.8:16668   206.189.104.51:24583  SYN_SENT     26s    0 B/s
 206.189.110.8:1353    206.189.104.51:37929  SYN_SENT     1s     0 B/s
 206.189.110.8:116     206.189.104.51:13377  SYN_SENT     17s    0 B/s
 206.189.110.8:1100    206.189.104.51:670    SYN_SENT     29s    0 B/s
 206.189.110.8:8966    206.189.104.51:13606  SYN_SENT     31s    0 B/s
 206.189.110.8:1363    206.189.104.51:4693   SYN_SENT     16s    0 B/s
 206.189.110.8:221     206.189.104.51:3008   SYN_SENT     27s    0 B/s
 206.189.110.8:2204    206.189.104.51:563    SYN_SENT     29s    0 B/s
 206.189.110.8:2359    206.189.104.51:1035   SYN_SENT     1s     0 B/s
 206.189.110.8:9747    206.189.104.51:58948  SYN_SENT     16s    0 B/s
 206.189.110.8:63382   206.189.104.51:61     SYN_SENT     5s     0 B/s
 206.189.110.8:286     206.189.104.51:60719  SYN_SENT     28s    0 B/s
 206.189.110.8:35491   206.189.104.51:1600   SYN_SENT     30s    0 B/s
 206.189.110.8:806     206.189.104.51:39     SYN_SENT     29s    0 B/s
 206.189.110.8:17286   206.189.104.51:6522   SYN_SENT     27s    0 B/s
 206.189.110.8:361     206.189.104.51:4338   SYN_SENT     27s    0 B/s
 206.189.110.8:64      206.189.104.51:270    SYN_SENT     25s    0 B/s
 206.189.110.8:145     206.189.104.51:242    SYN_SENT     31s    0 B/s
 206.189.110.8:8643    206.189.104.51:295    SYN_SENT     25s    0 B/s
 206.189.110.8:4590    206.189.104.51:3964   SYN_SENT     28s    0 B/s
 206.189.110.8:7874    206.189.104.51:363    SYN_SENT     14s    0 B/s
 206.189.110.8:8426    206.189.104.51:5451   SYN_SENT     21s    0 B/s
 206.189.110.8:7568    206.189.104.51:92     SYN_SENT     18s    0 B/s
 206.189.110.8:3280    206.189.104.51:2174   SYN_SENT     29s    0 B/s
 206.189.110.8:255     206.189.104.51:55524  SYN_SENT     31s    0 B/s
 206.189.110.8:197     206.189.104.51:439    SYN_SENT     15s    0 B/s
 206.189.110.8:7065    206.189.104.51:27954  SYN_SENT     25s    0 B/s
 206.189.110.8:3096    206.189.104.51:1200   SYN_SENT     1s     0 B/s
 206.189.110.8:65016   206.189.104.51:1600   SYN_SENT     30s    0 B/s
 206.189.110.8:23      206.189.104.51:641    SYN_SENT     30s    0 B/s
 206.189.110.8:43307   206.189.104.51:1079   SYN_SENT     31s    0 B/s
 206.189.110.8:451     206.189.104.51:63785  SYN_SENT     18s    0 B/s
 206.189.110.8:150     206.189.104.51:480    SYN_SENT     1s     0 B/s
 206.189.110.8:2425    206.189.104.51:466    SYN_SENT     23s    0 B/s
 206.189.110.8:8030    206.189.104.51:14315  SYN_SENT     29s    0 B/s
 206.189.110.8:814     206.189.104.51:12977  SYN_SENT     30s    0 B/s
 206.189.110.8:11524   206.189.104.51:13537  SYN_SENT     6s     0 B/s
 206.189.110.8:34467   206.189.104.51:3659   SYN_SENT     29s    0 B/s
 206.189.110.8:12406   206.189.104.51:64424  SYN_SENT     25s    0 B/s
 206.189.110.8:2530    206.189.104.51:2052   SYN_SENT     24s    0 B/s
 206.189.110.8:278     206.189.104.51:2826   SYN_SENT     26s    0 B/s
 206.189.110.8:258     206.189.104.51:11238  SYN_SENT     18s    0 B/s
 206.189.110.8:479     206.189.104.51:6803   SYN_SENT     23s    0 B/s
 TOTAL                                                           0 B/s
 Connections 1-84 of 314097                   Unpaused  UnsortedKilled

Truth is, this is going to be hard to achieve on a cheap network card on a local network with low bandwidth on one machine, such as mine, hence needing DigitalOcean. :-)

Hope this explains it.

@JuxhinDB JuxhinDB added the question Further information is requested label Jul 27, 2018
@LEXUGE
Copy link
Author

LEXUGE commented Jul 27, 2018

@JuxhinDB So, what's your DigitalCocean droplet's bandwidth?
I'm wondering why I can't do that also my code seens well.

@JuxhinDB
Copy link
Owner

Closing at it's an old issue. I'm not sure about the bandwidth available at the time, but I'm sure DO exposes this somewhere on their site. :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
question Further information is requested
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@JuxhinDB @LEXUGE