27 Jun
2017
27 Jun
'17
8:58 p.m.
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(a)hamradio.ucsd.edu>
Date: 28/06/2017 05:03 (GMT+10:00)
To: 44net(a)hamradio.ucsd.edu
Cc: lleachii(a)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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
27 Jun
27 Jun
9:17 p.m.
New subject: SYN Flood, etc.
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
9:47 p.m.
New subject: SYN Flood, etc.
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(a)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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
10:16 p.m.
New subject: SYN Flood, etc.
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.
11:33 p.m.
New subject: SYN Flood, etc.
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(a)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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
28 Jun
28 Jun
1:03 a.m.
New subject: SYN Flood, etc.
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.
2500
days inactive
2501
days old
5 comments
3 participants
participants (3)
-
Andrew Ragone -
Josh -
lleachii＠aol.com