BPF Filter Limitations - Prevent Sweeping Attacks #5

New Issue

Closed

opened 2024-04-08 04:24:36 +00:00 by steven · 2 comments

steven commented

2024-04-08 04:24:36 +00:00

Owner

Having a BPF filter on the pcap highly reduces overhead / load of hypd, however it makes you more susceptible to sweep attacks (i.e. where an adversary continuous just keeps trying random ports). An adversary may get the first port correct as part of a random port scan. They may continue randomly scanning until they get the second port correct, if a packet doesn't match the BPF filter, then it's not getting sent to handlePacket() and won't reset the knock sequence.

Odds are the adversary will hit on another port that's part of a different sequence or different iteration of the current sequence and that will reset the progress, however this is still definitely a weakness that should be corrected.

First impelement hypd configuration files

Then we can eliminate the tight port list on the BPF filter completely and capture all UDP datagrams in handlePacket(). We can make it a configurable options to disableExtendedSweepProtection and if set to true then it reverts to the current behavior. It may be desireable to disableExtendedSweepProtection in some use cases if you want minimal compute resource overhead for hypd.

Having a BPF filter on the pcap highly reduces overhead / load of hypd, however it makes you *more* susceptible to sweep attacks (i.e. where an adversary continuous just keeps trying random ports). An adversary may get the first port correct as part of a random port scan. They may continue randomly scanning until they get the second port correct, if a packet doesn't match the BPF filter, then it's not getting sent to handlePacket() and won't reset the knock sequence. Odds are the adversary will hit on another port that's part of a different sequence or different iteration of the current sequence and that *will* reset the progress, however this is still definitely a weakness that should be corrected. ## First impelement hypd configuration files Then we can eliminate the tight port list on the BPF filter completely and capture all UDP datagrams in handlePacket(). We can make it a configurable options to disableExtendedSweepProtection and if set to true then it reverts to the current behavior. It may be desireable to disableExtendedSweepProtection in some use cases if you want minimal compute resource overhead for hypd.

steven added the

enhancement

hypd / Server

labels 2024-04-08 04:24:36 +00:00

steven self-assigned this 2024-04-08 04:24:36 +00:00

steven commented

2024-04-11 04:02:34 +00:00

Author

Owner

Need to get some benchmarks with wide open filter compared to constraining to just the ports required for the authentic knock sequence.

I can only test this on a 1Gbps line at the moment

Also, in the call to pcap.OpenLive, perhaps we don't need promiscuous mode, and we don't need 1600 bytes to be read since all we care about is the UDP header - 8 bytes, but we don't know what the IP header length is necessary, or the L2 header length.

Ethernet dest MAC = 6 bytes
Ethernet src MAC = 6 bytes
Ethertype = 2 bytes
IPv4 = 40 bytes
UDP = 8 bytes

Total = 60 bytes... anything over this can be dropped because it's not a knock

There could be be other header types on different kinds of networks, but they will be unsupported at this time. Only Ethernet with IPv4.

Need to get some benchmarks with wide open filter compared to constraining to just the ports required for the authentic knock sequence. I can only test this on a 1Gbps line at the moment Also, in the call to pcap.OpenLive, perhaps we don't need promiscuous mode, and we don't need 1600 bytes to be read since all we care about is the UDP header - 8 bytes, but we don't know what the IP header length is necessary, or the L2 header length. Ethernet dest MAC = 6 bytes Ethernet src MAC = 6 bytes Ethertype = 2 bytes IPv4 = 40 bytes UDP = 8 bytes Total = 60 bytes... anything over this can be dropped because it's not a knock There could be be other header types on different kinds of networks, but they will be unsupported at this time. Only Ethernet with IPv4.

steven commented

2024-04-14 04:32:34 +00:00

Author

Owner

sweep attacks are effectively mitigated in 0ad3e2b0d4

Since implementing eBPF, all packets can be sent to handleKnock and so the sequence progress can be invalidated on the first wrong knock attempt.

sweep attacks are effectively mitigated in 0ad3e2b0d4914bc0670f0acaad799839ae7726f3 Since implementing eBPF, all packets can be sent to handleKnock and so the sequence progress can be invalidated on the first wrong knock attempt.

steven closed this issue

2024-04-14 04:32:34 +00:00