News archive October 2019 - Koos van den Hout

It seems the TCP reflective SYN attacks are continuing. In researching my options I saw the option to use a netmask with the iptables recent module.

This helps a bit with the attacks trying to flood an entire block. I've updated the filtering to work by the /24, start a check on a SYN from such a block, end when an ACK flies by and start dropping when the rate is over 10 per 2 minutes.

iptables -A INPUT -p tcp -m tcp --tcp-flags SYN,ACK SYN -m recent --update --seconds 120 --hitcount 10 --name tcpsyn --mask 255.255.255.0 --rsource -j LOGDROP
iptables -A INPUT -p tcp -m tcp --tcp-flags SYN,ACK SYN -m recent --set --name tcpsyn --mask 255.255.255.0 --rsource
iptables -A INPUT -p tcp -m tcp --tcp-flags SYN,ACK ACK -m recent --remove --name tcpsyn --mask 255.255.255.0 --rsource

LOGDROP is a rule to drop packets and ratelimit the logging of dropped packets, to avoid turning a network attack into a disk attack.

But I have to be careful not to make services hard to reach for legitimate clients. The above is working, and during attacks I don't see a single SYN_RECV socket.

Sometimes you really wonder about the amount of errors made by noisy attacks. I noticed the following pattern in the system logs:

nnrpd[7029]: 189.243.177.73 unrecognized Accept-Encoding: identity
nnrpd[7029]: 189.243.177.73 unrecognized Content-Length: 586
nnrpd[7029]: 189.243.177.73 unrecognized Accept-Language: en-us
nnrpd[7029]: 189.243.177.73 unrecognized Host: 74.219.111.25
nnrpd[7029]: 189.243.177.73 unrecognized Accept: */*
nnrpd[7029]: 189.243.177.73 unrecognized User-Agent: ApiTool
nnrpd[7029]: 189.243.177.73 unrecognized Connection: close
nnrpd[7029]: 189.243.177.73 unrecognized Cache-Control: max-age=0
nnrpd[7029]: 189.243.177.73 unrecognized Content-Type: text/xml
nnrpd[7029]: 189.243.177.73 unrecognized Authorization: Basic YWRtaW46ezEyMjEzQkQ...

With some searching I eventually found exploit code for certain series of digital video recorders which can be anywhere on the wide Internet.

The whole protocol mismatch makes this a lot noisier via the nntp port than via http, but I also see some attempts via the http port.

Update: Suricata doesn't recognize the specific attack, but it does notice the HTTP basic auth in the traffic:

11/13/2019-20:12:33.772828  [**] [1:2006402:11] ET POLICY Incoming Basic Auth Base64 HTTP Password detected unencrypted [**] [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 188.59.207.57:43753 -> 82.95.196.202:119

I'm seeing lots of sockets in state SYN_RECV again and noticed this time my earlier iptables rules to not respond to tcp syn packets that don't build up a connection aren't working. Between two syn packets from the same source there is 5 minutes, so my system responds to all of them. Ranges of addresses in the same block are used as source IPv4 addresses. For one address the traffic is very minimal:

22:40:51.600077 IP 112.175.120.39.58275 > 82.95.196.202.22: Flags [S], seq 720891004, win 29200, length 0
22:40:51.600392 IP 82.95.196.202.22 > 112.175.120.39.58275: Flags [S.], seq 1729897232, ack 720891005, win 29200, options [mss 1460], length 0
22:40:52.612035 IP 82.95.196.202.22 > 112.175.120.39.58275: Flags [S.], seq 1729897232, ack 720891005, win 29200, options [mss 1460], length 0
22:40:54.628048 IP 82.95.196.202.22 > 112.175.120.39.58275: Flags [S.], seq 1729897232, ack 720891005, win 29200, options [mss 1460], length 0
22:40:58.660031 IP 82.95.196.202.22 > 112.175.120.39.58275: Flags [S.], seq 1729897232, ack 720891005, win 29200, options [mss 1460], length 0
22:41:06.851865 IP 82.95.196.202.22 > 112.175.120.39.58275: Flags [S.], seq 1729897232, ack 720891005, win 29200, options [mss 1460], length 0
22:41:22.980000 IP 82.95.196.202.22 > 112.175.120.39.58275: Flags [S.], seq 1729897232, ack 720891005, win 29200, options [mss 1460], length 0
22:45:18.565999 IP 112.175.120.39.41767 > 82.95.196.202.465: Flags [S], seq 910623633, win 29200, length 0
22:45:18.566415 IP 82.95.196.202.465 > 112.175.120.39.41767: Flags [S.], seq 3977721413, ack 910623634, win 29200, options [mss 1460], length 0
22:45:19.588000 IP 82.95.196.202.465 > 112.175.120.39.41767: Flags [S.], seq 3977721413, ack 910623634, win 29200, options [mss 1460], length 0
22:45:21.604022 IP 82.95.196.202.465 > 112.175.120.39.41767: Flags [S.], seq 3977721413, ack 910623634, win 29200, options [mss 1460], length 0
22:45:25.667936 IP 82.95.196.202.465 > 112.175.120.39.41767: Flags [S.], seq 3977721413, ack 910623634, win 29200, options [mss 1460], length 0
22:45:33.860000 IP 82.95.196.202.465 > 112.175.120.39.41767: Flags [S.], seq 3977721413, ack 910623634, win 29200, options [mss 1460], length 0
22:45:49.987965 IP 82.95.196.202.465 > 112.175.120.39.41767: Flags [S.], seq 3977721413, ack 910623634, win 29200, options [mss 1460], length 0

But multiply this with several source IPs in the same IPv4 /24 block and a lot of open servers in the world and suddenly you get a lot of return traffic.

Ik ontdekte dat de website van de HCC PCgg netwerkgroep nog prima draait maar wel als onveilig in een moderne browser werd aangemerkt omdat er invoervelden in zitten.

Ook al is de laatste activiteit op de site van Augustus 2012 wil ik toch deze site in de lucht houden omdat ik toen heel veel lol heb gehad met de netwerkgroep en het leuk was om daar presentaties te geven en dingen uit te zoeken.

Dus de site draait nu met een LetsEncrypt certificaat op https. En het was een mooi moment om gelijk de versie van serendipity zelf bij te werken.

Update: Ik zie nu ook browsers die alle http gewoon als onveilig melden. Het is denk ik tijd om de laatste sites ook over te zetten naar https.

I was looking at the overview of most requested but not available URLs and noticed there is still traffic to http://webcam.idefix.net/. For years that was the webcam site when I still had access to a reasonable location for putting up a webcam. First a good view at my previous house, and later a window with a good view from a server room at work.

So I dug up the archived images and scripts, cleaned them up and made them available again. There are no fresh images, just the aged archives.

I noticed some really unused records in one zone which is now DNSSEC signed. For example I still had gplus.idefix.net to point at my Google+ page.

So I removed them and did the signing after increasing the serial number. Indeed the records that had no update kept their original signature and the records that where changed (such as the SOA because of the serial number) were signed with new signatures.

Today I was reminded of the first zone I signed with DNSSEC and did the check again with DNSViz. And I saw a lot of error messages. Some searching found that I let all the signatures expire (after the default time of 30 days).

Solution: re-sign the zone and have a careful look at when I need to sign the zones again. Officially just in time for expiry time of the signature (default 30 days) minus TTL of the record.

Obviously this process has to be automated. In the first go I decided to force new signatures after 21 days. But I tested some things later and decided to go for more regular checks of the ages of the signatures and refresh the signatures that are about to expire. This is usually reserved for 'big' zones with lots of resolvers querying them but I decided to implement this myself to avoid problems, and learn more about DNSSEC.

The magic signing command is now:

-zone-signedserial:
    named-checkzone $* $^
    ./SOA.pl $^
    dnssec-signzone -S -K /etc/bind/keys -g -a -r /dev/random -D -S -e +2592000 -i 604800 -j 86400 -o $* $^
    rndc reload $*
    touch $@

The expiry is set with -e at 30 days, the checkinterval with -i at 7 days and the jitter factor with -j at 1 day.

Now there is a special part in the Makefile to be called from cron on a regular basis. It won't produce any output when there is nothing to update.

agecheck:
    @for zone in $(SIGNEDZONES); do if [ `find $${zone}-signedserial -mtime +7 -print` ]; then touch $${zone}-zone ; $(MAKE) --no-print-directory $${zone}-signedserial; fi ;done

The Make variable SIGNEDZONES is filled with the zonenames of the zones that have to be kept DNSSEC signed. File structure for each forward zone is as listed in first zone with valid DNSSEC signatures.

So now almost all my domains are DNSSEC signed. A learning experience and a good level of security.

Since January 2015 I've been using CQRLOG as the main amateur radio logging program. So each contact that I make ends up in the databases of this program eventually.

Being the person I am I added some scripts of my own to export data from CQRLOG to the PE4KH amateur radio station website in several formats.

I've made a few of these scripts available for the public via KHoos/CQRLOG-scripts: A collection of scripts around the CQRLOG amateur radio logging software on github. I've set the license to GPLv2, but I may have to change this as one script contains a lot of imported code.

Anyway, share and enjoy. Maybe these are of use to someone. Or someone adds the enhancements I've been thinking about but never got around to.

While looking at some network issues at home I noticed some weird traffic coming in from the outside: forged SYN traffic. Fast enough to trigger my iptables rules to stop being part of tcp syn attacks so all traffic gets dropped. Searching for a bit finds Hell of a Handshake: Abusing TCP forReflective Amplification DDoS Attacks - usenix which discusses this kind of attack.

At the moment it's about 1 or 2 packets per second. The traffic itself isn't notable on my connection and even without the firewall rules it still wouldn't impact my system. But do this with a lot of systems on the Internet running some tcp service and quite some traffic will go to the targeted IP address.

I guess someone doesn't like some Maltese Casino website. I don't like casino websites either because they promote addictive behaviour but I'm not about to use a DDoS.

The last years I've been dealing with increasing levels of interference on the HF bands at home. One clear source is the rising numbers of solar panel installations, with a clear difference between hiring the cheapest installer versus hiring a good installer but paying more.

I don't want to start discussions with all neighbours about their solar installation and the latest news seems to be that the Dutch telecoms regulator takes the stance of solar panels being needed for our economy so radio amateurs have to accept the interference.

Moving house is not in our plans for the coming years so I started reading about the options for remote operations, where I can sit at home with the microphone and morse key looking at the display of the radio and hearing the audio while the receiving/sending part is at a remote site with a lot less interference.

I found out about RemoteRig which does just that, and with the right choice of radio allows complete remote operation over the Internet. With their offering I started looking at compatible HF radios and found a nice secondhand Kenwood TS-480SAT. This radio has better filtering options for SSB and morse than my Yaesu FT-857D.

The radio is now at home and I made the first few SSB contacts with it. The filtering already helped me understand stations better.

Now for the next steps, cables, remoterig units and other things. And a remote location. I have an offer from a fellow radio amateur to do the first tests at his house. When all that works out I'll go and find a nearby location to do the complete installation.