Problem with provider IP address

rchurch

I just installed a cloud VM with a popular provider and it seem that the IP was previously running some service which is resulting in the http logs being flooded with junk and filling up rapidly.

I'm going to request a new IP from them but I'd like to know what kind of traffic it is.

What kind of service could it have been running for the logs to be filled with requests like these?

This is the kind of entry I'm seeing in the access logs.

89.47.131.165 - - [15/Mar/2021:23:18:15 +0000] "w\xDD\xBD8/\xECBk\x998\x93\x8Fi\xC9\xC2Y/\xF
2\xC4\xDA\xF2\x04\xA8\x8C\xE6c\xF5\xF0\x1C\xE0\x06\xBE\x94\xC9\xFA\x9B!\xF1h\x82\xDD\xBDD\x9
6\xA0Y\xCD1/\xEC\x7F\xEF\xEC\xA5\xBC\x16\xFE\xCA\xFA\xF9\xD9~W\x90\x03\xB5\xA6i\xF4\x11\x85\
x90\xFB\x0BNX\xE26\xB6Mq\xA3?1\xBD\xCC\x08\xE1\xC7\xCD\xD8\xF3\x15\xEE\x85\x87\xFE\xBB\x0C<\
x7F\xD4\x82\x1F\x9Df\xC99[\x8D\xAEK\xA8\x02\x11\xA6\xBBG\xCE:\x98\xF8\xE2\x95\x05\x9E\x88f\x
D4\xD0\x1D-\x8E\x9E\x19\x00\xC9\x11GnP\xC2\xE7\xEESJ.y\x15\x04gA\x06\xD4\x06f%\xF1\xCE\xD5\x
97\xA9\xEB\xB6\xEB%\xDE\xD3\x0B\xB4]\xA3\xFE\xDB2m\x81\xE12Q[\x92\xD0\xE4\xC35\x16\xB2\xAB\x
96\x97\xA2\x99\x87h" 400 173 "-" "-"

and this is what the nginx error logs look like

2021/03/16 00:11:52 [crit] 31562#31562: *84534 SSL_do_handshake() failed (SSL: error:
1408F0C6:SSL routines:ssl3_get_record:packet length too long) while SSL handshaking,
client: 216.177.133.23, server: 0.0.0.0:443
2021/03/16 00:11:55 [crit] 31562#31562: *84818 SSL_do_handshake() failed (SSL: error:
1408F0C6:SSL routines:ssl3_get_record:packet length too long) while SSL handshaking,
client: 5.122.58.225, server: 0.0.0.0:443
2021/03/16 00:12:07 [crit] 31563#31563: *86020 SSL_do_handshake() failed (SSL: error:
1408F0C6:SSL routines:ssl3_get_record:packet length too long) while SSL handshaking,
client: 89.34.96.57, server: 0.0.0.0:443
2021/03/16 00:12:09 [crit] 31563#31563: *86217 SSL_do_handshake() failed (SSL: error:
1408F0C6:SSL routines:ssl3_get_record:packet length too long) while SSL handshaking,
client: 5.127.252.219, server: 0.0.0.0:443

jar

I don’t recognize the encoding but getting an IP that hasn’t at one point or another hosted something that was vulnerable is difficult, and anything that was once found vulnerable is going around on lists to be tested against. Could be good source material for web app optimization.

rchurch

Are you with xargs?

I have created this command which gets the offending IPs

grep "400 173" /var/log/nginx/access.log | cut -f 1 -d ' ' | sort | uniq and I want to insert them into iptables -A INPUT -s X.X.X.X -j DROP commands

jar

@rchurch said:
Are you with xargs?

I have created this command which gets the offending IPs

grep "400 173" /var/log/nginx/access.log | cut -f 1 -d ' ' | sort | uniq and I want to insert them into iptables -A INPUT -s X.X.X.X -j DROP commands

In some rare cases xargs can have an unintended impact. In most common use cases it’s inefficient anyway, just an old habit for some. I’d do:

for i in $(grep "400 173" /var/log/nginx/access.log | cut -f 1 -d ' ' | sort | uniq); do ip route add blackhole $i; done

rchurch

@jar said: do ip route add blackhole $i;

Thanks a lot.

Do these settings persist after restarting the server?

benj0x

@rchurch said:

@jar said: do ip route add blackhole $i;

Thanks a lot.

Do these settings persist after restarting the server?

No. Just add them again. Add this command to your crontab for rebooting to get a permanent effect.