search

robertdavidgraham / masscan

TCP port scanner, spews SYN packets asynchronously, scanning entire Internet in under 5 minutes.
GNU Affero General Public License v3.0
23.26k stars 3.04k forks source link

Issue with LEDE firewall and masscan - Resolved #330

Open badgenes opened 6 years ago

badgenes commented 6 years ago

Masscan does not receive any responses from hosts behind a fresh installation of LEDE 17.01. I have read the notes on blocking RST packets from a host so SYN-ACK make it back but have no clue how to modify iptables on LEDE to accomplish the same thing. Any assistance is appreciated.

thanks badgenes

badgenes commented 6 years ago

Solved. LEDE comes with a couple of policies that drop or rate limit packets with SYN set one most likely as a means of DDOS prevention, another that rate limits outbound SYN packets perhaps aimed at crippling zombie systems ability to execute DDOS attacks on remote targets. Disable SYN Flood prevention on the LAN zone and find the two rules that specifically refer to packets with SYN set and remove them. Problem solved.

However, LEDE and perhaps other implementations of IPTables ships with an extremely low threshold for the netfilter connection tracking table. ~24000 entries in LEDE 17.01.4. To put that into perspective, 2kpps with default TCP syn sent connection timeout (120secs) equates to steady state of ~240,000 table entries (active connections). Edit /etc/sysctl.d/11-nf-conntrack.conf and set nf_conntrack_max=524288. sysctl -p to load config Reboot firewall and start scanning at 2-4kpps (if your firewall, modem and connection can handle it). If you experience firewall crashing and didn't carefully watch memory usage during a scan you probably ran out of memory before the table filled. Adjust and experiment.

EDIT: Upon further digging I realize all of the timeouts are easily modified by adding the variables to the aforementioned config file. /proc/sys/net/netfilter/ contains all of the netfilter parameters. Add them to the config and change, with caution. I am not sure if the 'half closed' connection state masscan results in is handled by 'syn sent' or 'generic timeout'. I'll update this when I determine which netfilter uses to track a half open connection.

✨ Netfilter does use nf_conntrack_timeout_syn_sent variable to track half open connections. I don't believe lowering this to 60 seconds will have any unintended consequences as some firewalls ship at 60 seconds while Windows used to be around 20 seconds. Add net.netfilter.nf_conntrack_timeout_syn_sent=60 to 11-nf-conntrack.conf (on LEDE) or /etc/sysctl.conf underneath the net.netfilter.nf_conntrack_max=524288 you added previously.

EDIT: ⚠️ By modifying only conntrack_max I was upsetting the balance built in to netfilter's connection tracking modules. Please see the link below for more info. The following formula is a rough approximation of how you should modify conntrack_hashsize in conjunction with conntrack_max. conntrack_max / 8 = conntrack_hashsize. Ideally no more than 8 connections should be tracked per hash entry. Hashtables are stored in kernel memory space, and modifying these values will have differing results on different hardware with similar amounts of system RAM. I would not go above 800000 / 100000 respectively without 1GB RAM.

https://timanovsky.wordpress.com/2009/04/10/tuning-linux-firewall-connection-tracker-ip_conntrack/

badgenes

RoganDawes commented 5 years ago

Thank you! This solved my problem with a host behind an OpenWRT firewall (GL.Inet Slate 750S) scanning upstream devices. With the "Syn Flood Protection" enabled, I had to scan at around 50 packets per second, with it turned off, I could scan at around 25000 packets per second before I started missing ports. Not fantastic, but an improvement!