Sorry, that would be mine. I'm building a new gateway and was having some issues, I'll disable that host asap. Josh - VK2HFF
-------- Original message -------- From: lleachii--- via 44Net 44net@hamradio.ucsd.edu Date: 28/06/2017 05:03 (GMT+10:00) To: 44net@hamradio.ucsd.edu Cc: lleachii@aol.com Subject: Re: [44net] SYN Flood, etc.
Rob,
It appears the SYN Flood are actually coming from AMPPRNet, not the Interent:
2017-06-27 13:16:16.705 3600.001 TCP 44.136.24.62:52055 -> 44.60.44.3:53 9 695 1 2017-06-27 13:16:16.705 3600.001 TCP 44.60.44.3:53 -> 44.136.24.62:52055 41 49452 1
2017-06-27 13:18:41.842 3600.004 TCP 44.136.24.62:51655 -> 44.60.44.3:53 4 306 1 2017-06-27 13:18:41.842 3600.004 TCP 44.60.44.3:53 -> 44.136.24.62:51655 28 37152 1
After closing tcp/53, this is the only host causing hits on my SYN Flood filter.
- KB3VWG
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Josh,
It's cool, no problem. I was actually going to inspect the packets later tonight to determine the issue.
Feel free to continue using the DNS and troubleshooting. Let me know if you need any assistance.
73,
- KB3VWG
So not sure if your concern is primarily about the SYN flood or something else, but the system tuning in SYN cookies is a great thing. Essentially it's a challenge-response for the users to do the heavy lifting before the host goes through the motions to set up a TCP flow and consume resources. Essentially this limits the 3WS to completing only for valid connections.
Said another way, unless you see tons of Syns coming in and consuming CPU to generate the SYN cookies, you're probably fine.
Andrew
On Jun 27, 2017, at 2:18 PM, lleachii--- via 44Net 44net@hamradio.ucsd.edu wrote:
Josh,
It's cool, no problem. I was actually going to inspect the packets later tonight to determine the issue.
Feel free to continue using the DNS and troubleshooting. Let me know if you need any assistance.
73,
- KB3VWG
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Andrew,
Yes, I noticed that my device is actually blocking the traffic by implementing SYN Cookies and SYN Flood firewall rules. It was logged by the system, but no SYN_Floods made it through.
Further inspecting the firewall, only 5 packets in over 20,000 were dropped. Perhaps the SYN Flood setting is too sensitive for a series of multiple DNS queries at the same time. The "block SYN Flood" setting is pre-built by LEDE, so I'll have to review the rules as they pertain to behavior with TCP DNS queries.
- KB3VWG
So not sure if your concern is primarily about the SYN flood or something else, but the system tuning in SYN cookies is a great thing. Essentially it's a challenge-response for the users to do the heavy lifting before the host goes through the motions to set up a TCP flow and consume resources. Essentially this limits the 3WS to completing only for valid connections.
Not many packets dropping might be ok. In fact, I'd expect it (and only would worry if most of the flood came back with ACKs).
SYN floods try to starve your memory resources by keeping TCP connections half open and wait for the timeout to sweep them out. But SYN cookies prevent that. So as long as memory allocation doesn't skyrocket when you don't see packet drops, that's a-ok.
Andrew
On Jun 27, 2017, at 3:19 PM, lleachii--- via 44Net 44net@hamradio.ucsd.edu wrote:
Andrew,
Yes, I noticed that my device is actually blocking the traffic by implementing SYN Cookies and SYN Flood firewall rules. It was logged by the system, but no SYN_Floods made it through.
Further inspecting the firewall, only 5 packets in over 20,000 were dropped. Perhaps the SYN Flood setting is too sensitive for a series of multiple DNS queries at the same time. The "block SYN Flood" setting is pre-built by LEDE, so I'll have to review the rules as they pertain to behavior with TCP DNS queries.
- KB3VWG
So not sure if your concern is primarily about the SYN flood or something else, but the system tuning in SYN cookies is a great thing. Essentially it's a challenge-response for the users to do the heavy lifting before the host goes through the motions to set up a TCP flow and consume resources. Essentially this limits the 3WS to completing only for valid connections.
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Andrew,
Absolutely, appears that some TCP DNS requests from a 44 host 'tripped the sensors'. LOL
My memory resources on my device remained OK, as well as CPU (minus the load logging into LEDE web GUI).
It appears my server received 0 SNY Floods. That was by design. I did notice those concerned about my 'open DNS' to the Public Internet. TCP/53 was opened on 44.60.44.3 to allow AXFR (and incidentally, allowing TCP DNS requests to 44.IN-ADDR.ARPA. and AMPR.ORG, since it's Authoritative), that rule now only allows 44.0.0.0/8.
Until today, I never noticed any DNS TCP requests that hit a threshold, and [still] none from the Internet. I'm honestly unaware of what 'stretchoid.com' means; but they don't seem to be the cause. My firewall's timing just seems to be fast...
- Lynwood KB3VWG
Not many packets dropping might be ok. In fact, I'd expect it (and only would worry if most of the flood came back with ACKs).
SYN floods try to starve your memory resources by keeping TCP connections half open and wait for the timeout to sweep them out. But SYN cookies prevent that. So as long as memory allocation doesn't skyrocket when you don't see packet drops, that's a-ok.
-
Andrew Ragone -
Josh -
lleachii＠aol.com