Just as I wanted to start writing an article here and I entered the URL of this blog into my browser I got no response from the webserver, zero, nothing.
First I thought the PHP fastcgi process for this virtual host died, but a quick check on another virtual host suggested that something else was going on.
So I guessed the lighttpd process itself must be experiencing problems of some sort, but after doing a "netstat -nat" I knew what was going on:
tcp6 1 1 83.65.62.72:80 61.135.190.248:12474 LAST_ACK
tcp6 1 1 83.65.62.72:80 61.135.190.234:39671 LAST_ACK
tcp6 1 1 83.65.62.72:80 61.135.190.253:39211 LAST_ACK
tcp6 1 1 83.65.62.72:80 61.135.190.234:55160 LAST_ACK
tcp6 1 1 83.65.62.72:80 61.135.190.230:25836 LAST_ACK
tcp6 1 1 83.65.62.72:80 61.135.190.231:16865 LAST_ACK
tcp6 1 1 83.65.62.72:80 61.135.190.232:24266 LAST_ACK
tcp6 1 1 83.65.62.72:80 61.135.190.240:38441 LAST_ACK
tcp6 1 1 83.65.62.72:80 61.135.190.243:17726 LAST_ACK
tcp6 1 1 83.65.62.72:80 61.135.190.241:38206 LAST_ACK
tcp6 1 1 83.65.62.72:80 61.135.190.251:23892 LAST_ACK
tcp6 1 1 83.65.62.72:80 61.135.190.225:29675 LAST_ACK
Plus "a few" more of those. Now I'm not entirely sure whether it's just some systems misbehaving or actually an attack, but my feelings told me this could have been intentional after all.
I did a quick whois on one of those IP addresses and came up with the 61.135.0.0/16 network which is owned by China Network Communications Group Corporation.
As the connections were made from pretty much every host in that network I had two choices: sit it out or block it.
I came to the conclusion that blocking the entire subnet from connecting to this system, at least temporarily, might be a viable solution and so I did.
However, afterwards I am asking myself whether I really had to block an entire 16-Bit network, so I am asking you: how do you handle such situations usually?
No comments:
Post a Comment