Malformed TCP Packets
cowsaymoe opened this issue · 4 comments
When serializing your TCP packet here https://github.com/bilalcaliskan/syn-flood/blob/b0968ea02366ee662fea941f80a1ab0b0a9cbc03/internal/raw/raw.go#L82 you are adding an ethernet layer which causes the packet to be malformed. Therefore, the target will drop it and not respond with an ACK as intended with a SYN flood.
gopacket.SerializeLayers(buf, opts, a, b, c) firstPayload := buf.Bytes() // contains byte representation of a(b(c))
Since you are adding the IP header separately when writing the packet results in your layers being IP Layer(Ethernet Layer(TCP Layer(Payload)))). To fix this simply remove the ethernet layer when serializing the TCP payload buffer.
You can confirm this by capturing packets in Wireshark while running a SYN flood. The TCP Layer contains random malformed data.
hello, thank you for your attention and i think you are right. i am investigating the problem by checking wireshark.
You're welcome. Something else I forgot to mention was your method of MAC address randomization. Since the serialization is wrong you have not run across the problem with the MAC addresses you are setting but if you fix the previous issue you will. You should not be randomizing the destination MAC address. Only the source MAC address should be randomized. If you randomize the destination MAC address of the packets you can run into issues where your NIC does not know where to send the packets on the LAN or the router will not know the packet is intended for it.
For example, if the machine running this application is on a NAT the router will not know who the packet is intended for on the data link layer. It is possible with modern devices for it to be automatically corrected and routed properly but there is no benefit in randomizing the destination address.
Here is a good resource on the data link layer OSI Model Layer 2
This bot triages issues and PRs according to the following rules: - After 180d of inactivity, lifecycle/stale is applied. - After 90d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied and the issue is closed. You can: - Make a comment to remove the stale label and show your support. The 180d days reset. - If an issue has lifecycle/rotten and is closed, comment and ask maintainers if they'd be interseted in reopening
This bot triages issues and PRs according to the following rules: - After 180d of inactivity, lifecycle/stale is applied. - After 90d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied and the issue is closed. You can: - Make a comment to remove the stale label and show your support. The 180d days reset. - If an issue has lifecycle/rotten and is closed, comment and ask maintainers if they'd be interseted in reopening