News items for tag security - Koos van den Hout

2019-11-15 Suricata IDS showing amusing results 5 days ago
Some things noticed by Suricata IDS are amusing to me. When looking at lines like:
11/15/2019-13:14:35.001691  [**] [1:2402000:5363] ET DROP Dshield Block Listed Source group 1 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 185.156.73.11:46843 -> 82.95.196.202:41505
11/15/2019-13:15:06.794357  [**] [1:2402000:5363] ET DROP Dshield Block Listed Source group 1 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 88.214.26.102:42131 -> 82.95.196.202:8703
11/15/2019-13:15:06.794357  [**] [1:2403384:53195] ET CINS Active Threat Intelligence Poor Reputation IP group 85 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 88.214.26.102:42131 -> 82.95.196.202:8703
11/15/2019-13:15:20.065796  [**] [1:2403393:53195] ET CINS Active Threat Intelligence Poor Reputation IP group 94 [**] [Classification: Misc Attack] [Priority: 2] {UDP} 93.174.95.106:27221 -> 82.95.196.202:7
11/15/2019-13:15:32.845110  [**] [1:2402000:5363] ET DROP Dshield Block Listed Source group 1 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 185.156.73.21:44503 -> 82.95.196.202:43935
11/15/2019-13:16:23.399397  [**] [1:2402000:5363] ET DROP Dshield Block Listed Source group 1 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 185.175.93.27:58989 -> 82.95.196.202:53166
All 'Dshield Block Listed' and 'Poor Reputation IP' traffic is port scans to ports that are blocked. So it's not a surprise those IPs have a poor reputation or a Dshield listing.

Tags: ,
2019-11-13 Trying Suricata intrusion detection system (IDS) 1 week ago
After hearing about intrusion detection systems a few times I decided to give one a try at home. Although a lot of attacks are blocked I sometimes see weird attacks and it would be nice to have a better idea of what exactly the attack was.

Yes, I have weird interests sometimes. I'm glad I have an ISP (xs4all) where I can select the option 'give me the completely unfiltered Internet connection' so I even see SMB protocol attempts.

I first tried 'snort' but that doesn't deal with PPP interfaces by default. It can be recompiled to accept those but I did not want that. The next option I heard about is 'Suricata' which is running at the moment.

I was amused by the reports of DDoS-like NTP traffic. Those are caused by the NTP statistics gathering. I know NTP can be abused for generating DDoS traffic but all security reports about NTP servers I manage have been false positives.

Anyway it's running and complaining a lot about the traffic it sees. For example the IPv6 port scan/network mapping attempts I noticed two months ago are still active.
11/13/2019-15:06:59.703451  [**] [1:2002911:6] ET SCAN Potential VNC Scan 5900-5920 [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 240e:00f7:4f01:000c:0000:0000:0000:0003:6050 -> 2001:0980:14ca:0001:020d:56ff:fece:ffe1:5901
11/13/2019-15:08:39.645780  [**] [1:2002911:6] ET SCAN Potential VNC Scan 5900-5920 [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 240e:00f7:4f01:000c:0000:0000:0000:0003:5167 -> 2001:0980:14ca:0001:020d:56ff:fece:ffe6:5901

Tags: , ,
2019-10-28 TCP reflective SYNs: blocking by the /24 3 weeks ago
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.

Tags: ,
2019-10-27 Attempts to hack digital video recorders over http via the nntp port 3 weeks ago
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

Tags: ,
2019-10-25 Slow(ish) syn floods getting more complicated to filter 3 weeks ago
Cybercriminal 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.

Tags: , ,
2019-10-17 Tested incremental DNSSEC signing 1 month ago
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.

Tags: , ,
2019-10-16 The signatures for the first DNSSEC signed zone expired, and I signed the rest 1 month ago
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.

Tags: , , ,
2019-10-11 Slow(ish) syn floods probably targetting Maltese Casino websites 1 month ago
Cybercriminal 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.

Tags: ,
2019-09-27 SSH user names are not very creative 1 month ago
A search for the top 10 tried usernames for ssh gives a nice list:
     52 admin
     23 pi
     19 test
      7 oracle
      6 support
      6 nagios
      5 user
      5 ubnt
      4 ftpuser
      3 virtualbookcase

Tags: ,
2019-09-19 Real IPv6 port scan/network mapping attempts 2 months ago
I noticed some interesting traffic in my home network this morning, an attempt at finding IPv6 systems. Since IPv6 privacy enhancements are enabled on most systems this is exactly like finding a needle in a haystack.

I noticed an amount of outgoing icmpv6 traffic, and looking at the destination addresses and the type of traffic found lots of 'unreachable route' messages to a few Chinese IPv6 addresses. Searching for the netblock '240e:f7:4f01:c' finds more reports of portscanning activity.
10:14:27.761704 IP6 (hlim 239, next-header TCP (6) payload length: 24) 240e:f7:4f01:c::3.12980 > 2001:980:14ca:1:5054:ff:feae:17.902: Flags [S], cksum 0xd0a9 (correct), seq 3726392987, win 29200, options [mss 1460], length 0
10:14:28.278108 IP6 (hlim 239, next-header TCP (6) payload length: 24) 240e:f7:4f01:c::3.19933 > 2001:980:14ca:1:5054:ff:feae:8003.12587: Flags [S], cksum 0xe1cc (correct), seq 95632679, win 29200, options [mss 1460], length 0
10:14:29.219766 IP6 (hlim 239, next-header TCP (6) payload length: 24) 240e:f7:4f01:c::3.41487 > 2001:980:14ca:1:5054:ff:feae:fff2.902: Flags [S], cksum 0x3c31 (correct), seq 500442149, win 29200, options [mss 1460], length 0
10:14:33.637405 IP6 (hlim 239, next-header TCP (6) payload length: 24) 240e:f7:4f01:c::3.35832 > 2001:980:14ca:1:5054:ff:feae:15.902: Flags [S], cksum 0xa6ea (correct), seq 2324914849, win 29200, options [mss 1460], length 0
10:14:34.468975 IP6 (hlim 239, next-header TCP (6) payload length: 24) 240e:f7:4f01:c::3.12470 > 2001:980:14ca:42::ffe8.16992: Flags [S], cksum 0x5a72 (correct), seq 3249792078, win 29200, options [mss 1460], length 0
10:14:34.469038 IP6 (flowlabel 0x63971, hlim 64, next-header ICMPv6 (58) payload length: 72) 2001:980:14ca:61::13 > 240e:f7:4f01:c::3: [icmp6 sum ok] ICMP6, destination unreachable, unreachable route 2001:980:14ca:42::ffe8
10:14:35.230776 IP6 (hlim 239, next-header TCP (6) payload length: 24) 240e:f7:4f01:c::3.63145 > 2001:980:14ca:1:20d:56ff:fece:8006.19: Flags [S], cksum 0xb87b (correct), seq 4259180220, win 29200, options [mss 1460], length 0
10:14:35.952841 IP6 (hlim 239, next-header TCP (6) payload length: 24) 240e:f7:4f01:c::3.9056 > 2001:980:14ca:42::8013.16992: Flags [S], cksum 0xbb3b (correct), seq 2896438720, win 29200, options [mss 1460], length 0
10:14:35.952880 IP6 (flowlabel 0x63971, hlim 64, next-header ICMPv6 (58) payload length: 72) 2001:980:14ca:61::13 > 240e:f7:4f01:c::3: [icmp6 sum ok] ICMP6, destination unreachable, unreachable route 2001:980:14ca:42::8013

Tags: , ,
2019-09-11 First zone with valid DNSSEC signatures 2 months ago
My previous test with DNSSEC zone signing showed a problem with entropy in virtual machines. Today I had time to reboot the home server running the virtual machines including the virtual machine with the nameserver, based on bind9.

Now I can create DNSSEC signatures for zonefiles at high speed (0.028 seconds) with enough entropy available. My first test is with camp-wireless.com which is a domainname for redirecting to Camp Wireless but since that variant was mentioned somewhere I had to generate the redirects to the right version.

The next step was to upload the DS records for the zone to my registrar and get them entered into the top level domain. This failed on the first attempt, the DS records have to be entered very carefully at the registrar.

I tested the result with dnsviz for camp-wireless.com and found an error in the first try: I updated the serial after signing the zone. So the soa record wasn't signed correctly anymore.

I updated my zonefile Makefile to do the steps in the right order:
-zone-signedserial:
        named-checkzone $* $^
        ./SOA.pl $^
        dnssec-signzone -S -K /etc/bind/keys -g -a -r /dev/random -D -S -o $* $^
        rndc reload $*
        touch $@
For the zone camp-wireless.com the original data is in camp-wireless.com-zone, the DNSSEC signatures in camp-wireless.com-zone.signed. And make will abort when one of the commands gives an error level, so it will for example stop completely when I make a typo in the zonefile which will make named-checkzone fail. The -D option creates a file to be used with $INCLUDE in the original zonefile. This does create a circular dependency: named-checkzone will fail when the -signedserial file isn't available on the first run. So the first run will have to be manually.

So now the zone is signed correctly. The next developments will be to find out how to monitor this extensively so I won't be surprised by problems and to redo the signing from time to time to make DNSSEC zone walking very hard.

And when I trust all of this I will implement it on other domain names that I manage.
Read the rest of First zone with valid DNSSEC signatures

Tags: , , ,
2019-09-08 A thumbs up for robust scripts 2 months ago
Encrypt all the things meme Today some of the letsencrypt certificates were older than 60 days, so the renewal script started to kick in. Last year I completely automated the certificate renewal of letsencrypt certificates with dehydrated and wrote some scripts around the renewal process with hopefully enough error handling.

Today some of the error handling got tested, one renewal gave an error:
  + ERROR: An error occurred while sending post-request to https://acme-v02.api.letsencrypt.org/acme/new-order (Status 500)
And indeed the dehydrated script gave an error level, the resulting (empty!) .crt file wasn't copied and nothing happened. On the next run of the renewal script this certificate will still be older than 60 days and therefore the renewal will be tried again.

Tags: , , ,
2019-08-01 IPv6 growing up: ssh attempts to an inside machine 3 months ago
IPv6 is growing up: I saw an ssh attempt to an inside machine, reachable only via IPv6. The source was a Chinese IPv6 address which had not tried anything on any other public service.
Jul 30 18:39:02 ritchie sshd[27454]: Bad protocol version identification '\026\003\001' from 240e:d9:d800:200::212 port 44926

Tags: , ,
2019-07-15 Still SMTP floods from 185.222.211.x addresses 4 months ago
Cybercriminal A month later I'm still seeing SMTP floods from 185.222.211.11 and adjacent addresses. I activated the sendmail-reject filter ruleset in fail2ban which keeps several addresses in that range blocked most of the time.

Given reports like 185.222.211.238 | Cloud Core LP | AbuseIPDB and 185.222.211.243 | Cloud Core LP | AbuseIPDB I'm not the only one seeing abuse from this range.

Tags: , ,
2019-07-04 First tests with dnssec show a serious lack of entropy 4 months ago
I was looking at the options for implementing DNSSEC on the domains I have, and started doing this on a domain name that is just used for web redirects, so I won't break anything serious when I make an error. And I am looking at monitoring options at the same time.

Looking for usable documentation I found DNSSEC signatures in BIND named - sidn.nl which shows and explains a lot of the options for doing this with bind9, including full automation. I want to take steps I understand, so I will start with careful minimal automation on a domain name that I can 'break'.

Following that documentation I created a key-signing key (KSK) and a zone-signing key (ZSK). I used the /etc/bind/keys directory which is the standard location.

The first dnssec-signzone action took 54 minutes. After waiting for a bit I started wondering what was happening and it turned out to be a problem with entropy: the signing uses a lot of data from /dev/random. I have the virtio-rng module loaded but the host wasn't making randomness available to the guest operating system. The host server does run randomsound to get more entropy since there is no hardware random number generator available.

Documentation on how to 'forward' randomness from the host to the client virtual machine: Random number generator device - Domain XML format

So I did some tests with a test virtual machine with a similar configuration. The results:
  • Just software kernel rng in the virtual machine: 54 minutes.
  • Offering virtio-rng randomness from the host from /dev/urandom running randomsound: less than 1 second.
  • Offering virtio-rng randomness from the host from /dev/random running randomsound: 11 minutes 10 seconds.
  • Offering virtio-rng randomness from the host from /dev/random running randomsound and haveged: less than 1 second.
Installing haveged which gathers entropy from hardware processes fixes the whole problem.

Now to implement the same settings for the virtual machine running the production nameserver and I'll be able to take the next step.

Tags: , , ,
2019-06-30 Interesting domainname probing 4 months ago
I noticed a really big load of probes for names under idefix.net, maybe looking for possible ways to attack systems. Source is a resolver at a VPS hoster (linode). I can find websites that will do such a search for me (some even hosted at linode) but in a quick search I can't get the same pattern in names.
30-Jun-2019 03:53:24.538 client @0x7f578c0c7230 45.33.59.87#11197 (sync.idefix.net): query: sync.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.539 client @0x7f578c0c7230 45.33.59.87#9151 (bugzilla.idefix.net): query: bugzilla.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.540 client @0x7f578c0c7230 45.33.59.87#64181 (mailgw.idefix.net): query: mailgw.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.540 client @0x7f578c0c7230 45.33.59.87#46518 (se.idefix.net): query: se.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.542 client @0x7f578c0c7230 45.33.59.87#31554 (tw.idefix.net): query: tw.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.544 client @0x7f578c0c7230 45.33.59.87#56050 (origin-www.idefix.net): query: origin-www.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.547 client @0x7f578c0c7230 45.33.59.87#24795 (bugzilla.idefix.net): query: bugzilla.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.558 client @0x7f578c0c7230 45.33.59.87#60127 (log.idefix.net): query: log.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.564 client @0x7f578c0c7230 45.33.59.87#16816 (reseller.idefix.net): query: reseller.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.564 client @0x7f578c0c7230 45.33.59.87#46743 (cdn3.idefix.net): query: cdn3.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.567 client @0x7f578c0c7230 45.33.59.87#15593 (books.idefix.net): query: books.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.568 client @0x7f578c0c7230 45.33.59.87#23918 (adv.idefix.net): query: adv.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.570 client @0x7f578c0c7230 45.33.59.87#24503 (srv1.idefix.net): query: srv1.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.570 client @0x7f578c0c7230 45.33.59.87#20759 (cacti.idefix.net): query: cacti.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.571 client @0x7f578c0c7230 45.33.59.87#62846 (developer.idefix.net): query: developer.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.571 client @0x7f578c0c7230 45.33.59.87#40156 (delta.idefix.net): query: delta.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.571 client @0x7f578c0c7230 45.33.59.87#42375 (logs.idefix.net): query: logs.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.571 client @0x7f578c0c7230 45.33.59.87#25727 (delta.idefix.net): query: delta.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.572 client @0x7f578c0c7230 45.33.59.87#19060 (wpad.idefix.net): query: wpad.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.572 client @0x7f578c0c7230 45.33.59.87#63258 (katalog.idefix.net): query: katalog.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.572 client @0x7f578c0c7230 45.33.59.87#35848 (ftp3.idefix.net): query: ftp3.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.574 client @0x7f578c0c7230 45.33.59.87#50079 (archives.idefix.net): query: archives.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.575 client @0x7f578c0c7230 45.33.59.87#18507 (pg.idefix.net): query: pg.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.577 client @0x7f578c0c7230 45.33.59.87#62479 (manager.idefix.net): query: manager.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.577 client @0x7f578c0c7230 45.33.59.87#41830 (wwwtest.idefix.net): query: wwwtest.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.578 client @0x7f578c0c7230 45.33.59.87#14914 (ocs.idefix.net): query: ocs.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.581 client @0x7f578c0c7230 45.33.59.87#25754 (auction.idefix.net): query: auction.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.582 client @0x7f578c0c7230 45.33.59.87#42057 (students.idefix.net): query: students.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.729 client @0x7f578c0c7230 45.33.59.87#63617 (gosper.idefix.net): query: gosper.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.866 client @0x7f578c4feb30 45.33.59.87#57706 (books.idefix.net): query: books.idefix.net IN A -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:24.870 client @0x7f578c0d59c0 45.33.59.87#57714 (delta.idefix.net): query: delta.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:24.872 client @0x7f578c51d780 45.33.59.87#57718 (delta.idefix.net): query: delta.idefix.net IN A -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:24.874 client @0x7f578c0d59c0 45.33.59.87#57722 (archives.idefix.net): query: archives.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:24.874 client @0x7f578c4feb30 45.33.59.87#57726 (wwwtest.idefix.net): query: wwwtest.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:24.875 client @0x7f578c52bda0 45.33.59.87#57728 (auction.idefix.net): query: auction.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:24.876 client @0x7f578c51d780 45.33.59.87#57708 (katalog.idefix.net): query: katalog.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:24.879 client @0x7f578c0d59c0 45.33.59.87#57712 (srv1.idefix.net): query: srv1.idefix.net IN A -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:24.943 client @0x7f578c0c7230 45.33.59.87#50168 (wpad.idefix.net): query: wpad.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.945 client @0x7f578c0c7230 45.33.59.87#59186 (cacti.idefix.net): query: cacti.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.947 client @0x7f578c0c7230 45.33.59.87#30509 (ftp3.idefix.net): query: ftp3.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.948 client @0x7f578c0c7230 45.33.59.87#25611 (manager.idefix.net): query: manager.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.948 client @0x7f578c0c7230 45.33.59.87#53201 (adv.idefix.net): query: adv.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.950 client @0x7f578c0c7230 45.33.59.87#25331 (students.idefix.net): query: students.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.954 client @0x7f578c0c7230 45.33.59.87#44043 (logs.idefix.net): query: logs.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.954 client @0x7f578c0c7230 45.33.59.87#9075 (ocs.idefix.net): query: ocs.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.236 client @0x7f578c4feb30 45.33.59.87#57748 (wpad.idefix.net): query: wpad.idefix.net IN A -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.245 client @0x7f578c52bda0 45.33.59.87#57752 (adv.idefix.net): query: adv.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.250 client @0x7f578c51d780 45.33.59.87#57750 (ftp3.idefix.net): query: ftp3.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.257 client @0x7f578c0c7230 45.33.59.87#46992 (katalog.idefix.net): query: katalog.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.259 client @0x7f578c0d59c0 45.33.59.87#57754 (logs.idefix.net): query: logs.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.263 client @0x7f578c0c7230 45.33.59.87#50662 (ns9.idefix.net): query: ns9.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.264 client @0x7f578c0c7230 45.33.59.87#23392 (eu.idefix.net): query: eu.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.271 client @0x7f578c0c7230 45.33.59.87#62305 (app2.idefix.net): query: app2.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.293 client @0x7f578c0c7230 45.33.48.143#45998 (sam.idefix.net): query: sam.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.293 client @0x7f578c0c7230 45.33.59.87#43255 (banners.idefix.net): query: banners.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.299 client @0x7f578c0c7230 45.33.59.87#29869 (click.idefix.net): query: click.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.302 client @0x7f578c0c7230 45.33.59.87#36595 (customer.idefix.net): query: customer.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.322 client @0x7f578c0c7230 45.33.59.87#6272 (cgi.idefix.net): query: cgi.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.327 client @0x7f578c0c7230 45.33.59.87#23561 (awstats.idefix.net): query: awstats.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.331 client @0x7f578c0c7230 45.33.59.87#58477 (wwwtest.idefix.net): query: wwwtest.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.334 client @0x7f578c0c7230 45.33.59.87#12998 (cgi.idefix.net): query: cgi.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.335 client @0x7f578c0c7230 45.33.59.87#41654 (meeting.idefix.net): query: meeting.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.335 client @0x7f578c0c7230 45.33.59.87#36692 (hd.idefix.net): query: hd.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.337 client @0x7f578c0c7230 45.33.59.87#52048 (webapps.idefix.net): query: webapps.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.471 client @0x7f578c0c7230 45.33.59.87#11817 (ns9.idefix.net): query: ns9.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.479 client @0x7f578c0c7230 45.33.59.87#40723 (webgreenblatt.idefix.net): query: webgreenblatt.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.481 client @0x7f578c0c7230 45.33.59.87#57833 (app2.idefix.net): query: app2.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.499 client @0x7f578c0c7230 45.33.59.87#26285 (click.idefix.net): query: click.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.525 client @0x7f578c0c7230 45.33.59.87#51562 (cgi.idefix.net): query: cgi.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.533 client @0x7f578c0c7230 45.33.59.87#32101 (wwwtest.idefix.net): query: wwwtest.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.534 client @0x7f578c0c7230 45.33.59.87#36210 (meeting.idefix.net): query: meeting.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.543 client @0x7f578c0c7230 45.33.59.87#57693 (webapps.idefix.net): query: webapps.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.568 client @0x7f578c53a3c0 45.33.59.87#57768 (katalog.idefix.net): query: katalog.idefix.net IN A -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.569 client @0x7f578c565900 45.33.59.87#57772 (eu.idefix.net): query: eu.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.598 client @0x7f578c557170 45.33.59.87#57776 (banners.idefix.net): query: banners.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.617 client @0x7f578c590fb0 45.33.59.87#57780 (customer.idefix.net): query: customer.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.620 client @0x7f578c52bda0 45.33.59.87#57782 (awstats.idefix.net): query: awstats.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.630 client @0x7f578c0d59c0 45.33.59.87#57790 (hd.idefix.net): query: hd.idefix.net IN A -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.637 client @0x7f578c5489e0 45.33.59.87#57788 (cgi.idefix.net): query: cgi.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.664 client @0x7f578c0c7230 45.33.59.87#35680 (app2.idefix.net): query: app2.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.765 client @0x7f578c582820 45.33.59.87#57800 (ns9.idefix.net): query: ns9.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.786 client @0x7f578c0c7230 45.33.59.87#59047 (sk.idefix.net): query: sk.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.805 client @0x7f578c565900 45.33.59.87#57802 (click.idefix.net): query: click.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.825 client @0x7f578c590fb0 45.33.59.87#57804 (wwwtest.idefix.net): query: wwwtest.idefix.net IN A -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.840 client @0x7f578c0c7230 45.33.59.87#6873 (app2.idefix.net): query: app2.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.843 client @0x7f578c0c7230 45.33.49.87#39819 (img4.idefix.net): query: img4.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.848 client @0x7f578c0c7230 45.33.49.87#35699 (registration.idefix.net): query: registration.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.856 client @0x7f578c0d59c0 45.33.59.87#57806 (webapps.idefix.net): query: webapps.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.942 client @0x7f578c0c7230 45.33.49.87#49819 (registration.idefix.net): query: registration.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:26.081 client @0x7f578c51d780 45.33.59.87#57816 (sk.idefix.net): query: sk.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:26.288 client @0x7f578c0c7230 45.33.59.87#49749 (meeting.idefix.net): query: meeting.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:26.309 client @0x7f578c0c7230 45.33.59.87#57344 (ocs.idefix.net): query: ocs.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:26.399 client @0x7f578c0c7230 45.33.59.87#44649 (develop.idefix.net): query: develop.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:26.583 client @0x7f578c50d150 45.33.59.87#57826 (meeting.idefix.net): query: meeting.idefix.net IN A -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:26.634 client @0x7f578c0c7230 45.33.49.87#9259 (ares.idefix.net): query: ares.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:26.662 client @0x7f578c0c7230 45.33.59.87#9440 (ocs.idefix.net): query: ocs.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:26.694 client @0x7f578c53a3c0 45.33.59.87#57830 (develop.idefix.net): query: develop.idefix.net IN A -E(0)TDC (194.145.201.42)

Tags: ,
2019-06-18 Scriptkiddies being especially stupid 5 months ago
Cybercriminal Checking how fail2ban was doing on a wordpress site I noticed the following error in the log:
46.105.99.163 - - [18/Jun/2019:09:03:46 +0200] "GET /wp-content/plugins/ungallery/source_vuln.php?pic=../../../../../wp-config.php HTTP/1.1" 404 15933 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0"
which is never going to work as an exploit. A full explanation in Hackers Will Try To Exploit Vulnerabilities in WordPress Plugins in Ways That Will Never Succeed - Plugin Vulnerabilities but this entire attempt is based on just the description of a vulnerability and can never ever have succeeded, not even on a system with the vulnerable version of the ungallery plugin.

Tags: , ,
2019-06-08 SMTP floods from 185.222.211.11 5 months ago
Cybercriminal Noticed in the recent logs, lots of variations on:
Jun  6 19:15:41 gosper sm-mta[22475]: x56HFc06022475: <mail@some.domain>... No such user in domain 
Jun  6 19:15:41 gosper sm-mta[22475]: x56HFc06022475: <support@some.domain>... No such user in domain 
Jun  6 19:15:41 gosper sm-mta[22475]: x56HFc06022475: <reply@some.domain>... No such user in domain 
Jun  6 19:15:41 gosper sm-mta[22475]: x56HFc06022475: srv-eml.info [185.222.211.11]: Possible SMTP RCPT flood, throttling.
Jun  6 19:15:41 gosper sm-mta[22466]: x56HFCbH022466: <financeiro@some.domain>... No such user in domain 
Jun  6 19:15:42 gosper sm-mta[22473]: x56HFVoi022473: <biuro@some.domain>... No such user in domain 
Jun  6 19:15:42 gosper sm-mta[22468]: x56HFItg022468: <michael@some.domain>... No such user in domain 
Jun  6 19:15:42 gosper sm-mta[22471]: x56HFPIC022471: <chris@some.domain>... No such user in domain 
Jun  6 19:16:51 gosper sm-mta[22466]: x56HFCbH022466: lost input channel from srv-eml.info [185.222.211.11] to MTA-v6 after rcpt
Jun  6 19:17:16 gosper sm-mta[22475]: x56HFc06022475: <jobs@some.domain>... No such user in domain 
Jun  6 19:17:17 gosper sm-mta[22475]: x56HFc06022475: <wh5gkoxp5wqk@some.domain>... No such user in domain 
Jun  6 19:17:18 gosper sm-mta[22475]: x56HFc06022475: lost input channel from srv-eml.info [185.222.211.11] to MTA-v6 after rcpt
Jun  6 19:17:18 gosper sm-mta[22475]: x56HFc06022475: from=<20tv13b4bu0h2107@europcar.ua>, size=0, class=0, nrcpts=1, proto=ESMTP, daemon=MTA-v6, relay=srv-eml.info [185.222.211.11]
All from the same IP, trying a lot of addresses (and failing), with a retry later trying all those addresses again.

Tags: , ,
2019-05-06 Good security tips in an e-mail with a virus attached 6 months ago
Just seen in an e-mail with a virus, looking like it's something from a bank:
Security tips

1. Install virus detection software and personal firewall on your computer. This software needs to be updated regularly to ensure you have the latest protection.
2. To prevent viruses or other unwanted problems, do not open attachments from unknown or non-trustworthy sources.
3. If you discover any unusual activity, please contact the remitter of this payment as soon as possible. 
But the attachment has malware.

Tags: ,
2019-05-04 Considering enabling Server Name Indication (SNI) on my webserver 6 months ago
Encrypt all the things meme While making a lot of my websites available via HTTPS I started wondering about enabling Server Name Indication (SNI) because the list of hostnames in the one certificate (subjectAltName parameter) keeps growing and they aren't all related.

So on a test system with haproxy I created two separate private keys, two separate certificate signing requests and requested two separate certificates. One for the variants of camp-wireless.org and one for most of the idefix.net names. The whole requesting procedure happened on the system where my automated renewal and deployment of LetsEncrypt certificates with dehydrated happens so the request went fine. For the configuration of haproxy I was following HAProxy SNI where 'terminating SSL on the haproxy with SNI' gets a short mention.

So I implemented the configuration as shown in that document and got greeted with an error:
haproxy[ALERT] 123/155523 (3435) : parsing [/etc/haproxy/haproxy.cfg:86] : 'bind :::443' unknown keyword '/etc/haproxy/ssl/webserver-idefix-main.pem'.
And found out that the crt keyword has to be repeated.

This is why I like having a test environment for things like this. Making errors in the certificate configuration on the 'production' server will give visitors scary and/or incomprehensible errors.

So the right configuration for my test is now:
frontend https-in
    bind :::443 v4v6 ssl crt /etc/haproxy/ssl/webserver-campwireless.pem crt /etc/haproxy/ssl/webserver-idefix-main.pem
And testing it shows the different certificates in use when I use the -servername parameter for openssl s_client to test things.
$ openssl s_client -connect testrouter.idefix.net:443 -servername idefix.net -showcerts -verify 3
..
Server certificate
subject=/CN=idefix.net
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
..
Verification: OK
$ openssl s_client -connect testrouter.idefix.net:443 -servername camp-wireless.org -showcerts -verify 3
..
Server certificate
subject=/CN=www.camp-wireless.org
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
..
Verification: OK
The certificates are quite separate. Generating the certificate signing requests with a separate private key for each request works fine.

So if I upgrade my certificate management to renew, transport, test and install multiple certificate for the main webserver it would work.
Read the rest of Considering enabling Server Name Indication (SNI) on my webserver

Tags: , , , ,
  Older news items for tag security ⇒
, reachable as koos+website@idefix.net. PGP encrypted e-mail preferred.

PGP key 5BA9 368B E6F3 34E4 local copy PGP key 5BA9 368B E6F3 34E4 via keyservers pgp key statistics for 0x5BA9368BE6F334E4 Koos van den Hout
RSS
Other webprojects: Camp Wireless, wireless Internet access at campsites, The Virtual Bookcase, book reviews