Wednesday, January 28, 2026
I still don’t understand this SYN attack, but now I can block it easily
It’s been almost six years since I first started seeing this attack, only now it’s no longer from European IP addresses. I’m still unsure what is going on with the attack. There will be up to around 100 connections to the web server in the SYN state, all with different IP addresses, but all apparently from networks in Brazil and it’s never enough to really affect the server. I finally got tired of whack-a-mole and filling up my firewall with scores of networks to block. I decided to see what data is actually being sent and hopefully find a better way to blo…
Wednesday, January 28, 2026
I still don’t understand this SYN attack, but now I can block it easily
It’s been almost six years since I first started seeing this attack, only now it’s no longer from European IP addresses. I’m still unsure what is going on with the attack. There will be up to around 100 connections to the web server in the SYN state, all with different IP addresses, but all apparently from networks in Brazil and it’s never enough to really affect the server. I finally got tired of whack-a-mole and filling up my firewall with scores of networks to block. I decided to see what data is actually being sent and hopefully find a better way to block such traffic.
I recalled there was a way to get iptables to log matches, and with some searching of documentation, I was able to get it working:
RootUnixPrompt>iptables -A INPUT -s 168.195.0.0/16 -j LOG --log-ip-options --log-tcp-options --log-tcp-sequence
Note: the options for the LOG target must be after the -j LOG option. I found that out the hard way. Also, the data may not make it to syslog—if it doesn’t, use dmesg to read them. Again, I found that out the hard way.
So with that out of the way, I was able to finally get some information about these mysterious SYN requests:
[4576126.770966] IN=venet0 OUT= MAC= SRC=168.195.XXXXXXX DST=66.252.224.242 LEN=52 TOS=0x08 PREC=0x40 TTL=116 ID=14490 DF PROTO=TCP SPT=30812 DPT=443 SEQ=1800275334 ACK=0 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405140103030801010402)
[4576126.842410] IN=venet0 OUT= MAC= SRC=168.195.XXXXXXX DST=66.252.224.242 LEN=52 TOS=0x08 PREC=0x40 TTL=118 ID=4029 DF PROTO=TCP SPT=17025 DPT=443 SEQ=1972924351 ACK=0 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405140103030801010402)
[4576126.899748] IN=venet0 OUT= MAC= SRC=168.195.XXXXXXX DST=66.252.224.242 LEN=52 TOS=0x08 PREC=0x40 TTL=120 ID=48610 DF PROTO=TCP SPT=55951 DPT=443 SEQ=1319626236 ACK=0 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405140103030801010402)
[4576127.200822] IN=venet0 OUT= MAC= SRC=168.195.XXXXXXX DST=66.252.224.242 LEN=52 TOS=0x08 PREC=0x40 TTL=108 ID=60712 DF PROTO=TCP SPT=877 DPT=443 SEQ=1363305157 ACK=0 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405140103030801010402)
[4576127.467747] IN=venet0 OUT= MAC= SRC=168.195.XXXXXXX DST=66.252.224.242 LEN=52 TOS=0x08 PREC=0x40 TTL=102 ID=39868 DF PROTO=TCP SPT=28345 DPT=443 SEQ=2567038192 ACK=0 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405140103030801010402)
[4576127.908861] IN=venet0 OUT= MAC= SRC=168.195.XXXXXXX DST=66.252.224.242 LEN=52 TOS=0x08 PREC=0x40 TTL=105 ID=52524 DF PROTO=TCP SPT=41729 DPT=443 SEQ=177291672 ACK=0 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405140103030801010402)
[4576127.915626] IN=venet0 OUT= MAC= SRC=168.195.XXXXXXX DST=66.252.224.242 LEN=52 TOS=0x08 PREC=0x40 TTL=106 ID=53787 DF PROTO=TCP SPT=61636 DPT=443 SEQ=3499780163 ACK=0 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405140103030801010402)
[4576128.022432] IN=venet0 OUT= MAC= SRC=168.195.XXXXXXX DST=66.252.224.242 LEN=52 TOS=0x08 PREC=0x40 TTL=118 ID=62833 DF PROTO=TCP SPT=38936 DPT=443 SEQ=1853541668 ACK=0 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405140103030801010402)
[4576128.112272] IN=venet0 OUT= MAC= SRC=168.195.XXXXXXX DST=66.252.224.242 LEN=52 TOS=0x08 PREC=0x40 TTL=113 ID=34813 DF PROTO=TCP SPT=50411 DPT=443 SEQ=2385563365 ACK=0 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405140103030801010402)
[4576128.350504] IN=venet0 OUT= MAC= SRC=168.195.XXXXXXX DST=66.252.224.242 LEN=52 TOS=0x08 PREC=0x40 TTL=117 ID=59160 DF PROTO=TCP SPT=23412 DPT=443 SEQ=2152520559 ACK=0 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405140103030801010402)
[4576128.853818] IN=venet0 OUT= MAC= SRC=168.195.XXXXXXX DST=66.252.224.242 LEN=52 TOS=0x08 PREC=0x40 TTL=105 ID=19965 DF PROTO=TCP SPT=17423 DPT=443 SEQ=2015225923 ACK=0 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405140103030801010402)
[4576129.421230] IN=venet0 OUT= MAC= SRC=168.195.XXXXXXX DST=66.252.224.242 LEN=52 TOS=0x08 PREC=0x40 TTL=115 ID=16281 DF PROTO=TCP SPT=31847 DPT=443 SEQ=2649527615 ACK=0 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405140103030801010402)
[4576129.493294] IN=venet0 OUT= MAC= SRC=168.195.XXXXXXX DST=66.252.224.242 LEN=52 TOS=0x08 PREC=0x40 TTL=118 ID=33977 DF PROTO=TCP SPT=52831 DPT=443 SEQ=2768111495 ACK=0 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405140103030801010402)
[4576129.718449] IN=venet0 OUT= MAC= SRC=168.195.XXXXXXX DST=66.252.224.242 LEN=52 TOS=0x08 PREC=0x40 TTL=103 ID=17382 DF PROTO=TCP SPT=37097 DPT=443 SEQ=1960327355 ACK=0 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405140103030801010402)
[4576130.468975] IN=venet0 OUT= MAC= SRC=168.195.XXXXXXX DST=66.252.224.242 LEN=52 TOS=0x08 PREC=0x40 TTL=101 ID=35434 DF PROTO=TCP SPT=54767 DPT=443 SEQ=1547341723 ACK=0 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405140103030801010402)
[4576130.663255] IN=venet0 OUT= MAC= SRC=168.195.XXXXXXX DST=66.252.224.242 LEN=52 TOS=0x08 PREC=0x40 TTL=115 ID=56729 DF PROTO=TCP SPT=22999 DPT=443 SEQ=2916546158 ACK=0 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405140103030801010402)
What leapt out at me is the TTL values—they were always larger than 99. From what I recall, a typical TTL is usually 64 or thereabouts in a normal TCP connection. So, making an executive decision, I ran the following command to block SYN packets with a TTL larger than 70:
RootUnixPrompt>iptables -A INPUT -m ttl --ttl-gt 70 -j DROP
It didn’t break anything apparent. My SSH connection was still live. The web server, gopher and Gemini servers are still getting traffic. I’m still getting email. But I’m no longer seeing connections stuck in the SYN state. It’s been about 16 hours or so, and I see I’ve blocked 171,194 connections. That one new firewall rule seems to have done the trick.
It still doesn’t answer why this is being done though. Weird.
You have my permission to link freely to any entry here. Go ahead, I won’t bite. I promise.
The dates are the permanent links to that day’s entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site: https://boston.conman.org/, then add the date you are interested in, say 2000/08/01, so that would make the final URL:
https://boston.conman.org/2000/08/01
You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.
You may also note subtle shading of the links and that’s intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It’s an experiment in using color shading to denote the distance a link is from here. If you don’t notice it, don’t worry; it’s not all that important.
It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.