44net-request(a)hamradio.ucsd.edu wrote: There are at least two different kinds of attack: 1. the ones that try to connect to your system to scan for vulnerabilities (including Heartbleed) 2. the ones that try to use your system for reflection to another victim. I have seen many of the second kind lately. Note that it is no use to complain to the owner of the "sending address" in this case, because it is spoofed and not the real sender. it is the intended victim of the attack! The symptom is many incoming connections in SYN_RECV state in the netstat -t output. What happens is you receive a SYN with a spoofed sender address, and you are supposed to send a number of SYN ACK packets to the "sender". As this is done repeatedly and to many different destinations, the "sender" (the victim) is hammered with traffic. The real cause of this problem is the lack of uptake of BCP38 (SAF, source address filtering). While "we" are sometimes suffering because of source address filtering when we want to dump traffic sourced in net 44 directly on the internet (instead of tunneling it back via amprgw), SAF in fact is a very good thing, and providers not doing it should be convinced to implement it to end those spoofed address attacks. Back to the SYN problem. I see two different schemes of this attack: 1. the SYN packets are sent with a source port that is a well-known service, like 80, 443, 119, 110 2. the SYN packets are sent with the usual random high-numbered port. The first ones are easily filtered with an iptables rule: iptables -A (chainname) -p tcp --syn -m multiport --source-ports 0:1023 -j DROP This blocks all connects from a privileged port, and should not hurt any normal operation. In fact it would be good if this rule was applied externally at amprgw, so that all this crap does not enter our tunnels. I have added it to several of my systems and the systems at work already. The second ones are a bit more tricky. You cannot simply block those as they look similar to normal traffic. However, if you have the typical low-traffic amateur radio system, you can use the "recent" module to limit unanswered traffic from the same IP address. iptables -A (chainname) -p tcp ! --syn -m recent --name tcp --remove iptables -A (chainname) -p tcp --syn -m recent --name tcp --set iptables -A (chainname) -p tcp --syn -m recent --name tcp --update --seconds 30 --hitcount 5 -j DROP What we do here is limit the number of "open" SYN packets from the same IP address to 5 in 30 seconds. When a SYN comes in, the second and third rules setup a bucket for the sending address in which those events are counted. When another packet comes in, the first rule resets that bucket and traffic from that system is allowed. So for normal incoming connections there is no impact, as the SYN/SYN ACK/ACK 3-way handshake quickly removes the special treatment of the client. However, for those spoofed SYN packets for which there is never any followup traffic, after 5 of those from the same system the "sender" is blocked from further access until they stop doing that for another 30 seconds. Works fine, this rule blocks tens of thousands of packets a day here and ends the issue of many incoming connections in SYN_RECV state. Note that these rules (or at least the first one) should be inserted BEFORE the typical "-m state -state ESTABLISHED,RELATED -j ACCEPT" rule that is often near the beginning of the list, because that rule will match on the followup packets of the connection so the --remove rule will never be reached, and the result would be that a client cannot make more than 5 connects in 30 seconds. Not a problem for telnet, but will be a problem when you run a website. Unfortunately this kind of "recent traffic" rule does not lend itself well for application at amprgw, because it has to maintain a lot of state and will probably be overloaded by the traffic being handled there. Rob