Outgoing TLS port Denial of Service – Fixed

Lawrence Sheed // 5 Jan 2010 // Comments Off on Outgoing TLS port Denial of Service – Fixed

Noticed that our incoming TLS connection queue was a little high – running at 60 concurrent connections for an hour or so.

A check of the queue revealed that all the connections were coming from a single IP – and were tying up the queue, making it a denial of service attack. This one ip address was connecting and reconnecting multiple times, hogging up all the connections.

I’ve blocked that ip address, and restarted the TLS service, its back at normal levels now.

For the interested –

Connections:

mail:/var/log/qmail/qmail-tls# netstat -an –numeric-ports | grep 587 | grep 58.246.24.242
tcp 0 0 61.129.49.190:587 58.246.24.242:24384 ESTABLISHED
tcp 1 0 61.129.49.190:587 58.246.24.242:39581 CLOSE_WAIT
tcp 0 0 61.129.49.190:587 58.246.24.242:11625 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:42614 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:46630 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:20802 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:51956 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:4463 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:39878 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:43678 ESTABLISHED
tcp 1 0 61.129.49.190:587 58.246.24.242:39181 CLOSE_WAIT
tcp 0 0 61.129.49.190:587 58.246.24.242:62054 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:64421 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:24326 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:58740 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:25779 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:50209 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:41358 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:32383 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:27925 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:46540 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:7049 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:13999 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:62962 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:19771 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:43604 ESTABLISHED
tcp 1 0 61.129.49.190:587 58.246.24.242:38757 CLOSE_WAIT
tcp 0 0 61.129.49.190:587 58.246.24.242:39909 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:30470 ESTABLISHED
tcp 1 0 61.129.49.190:587 58.246.24.242:39754 CLOSE_WAIT
tcp 0 0 61.129.49.190:587 58.246.24.242:61393 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:52072 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:22294 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:60398 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:60530 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:36049 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:1426 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:40190 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:15402 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:23457 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:65187 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:39910 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:23181 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:3286 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:40540 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:12957 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:39829 ESTABLISHED
tcp 0 0 61.129.49.190:587 58.246.24.242:19748 ESTABLISHED

IP Owner:

mail:/var/log/qmail/qmail-tls# whois 58.246.24.242

% [whois.apnic.net node-2]
% Whois data copyright terms http://www.apnic.net/db/dbcopyright.html

inetnum: 58.246.24.240 – 58.246.24.247
netname: SH-Ribeira
country: cn
descr: Ribeira (Shanghai) Business Consulting Co., Ltd.
admin-c: YR194-AP
tech-c: YR194-AP
status: ASSIGNED NON-PORTABLE
changed: sh-ipmaster@chinaunicom.cn 20081125
mnt-by: MAINT-CNCGROUP-SH
source: APNIC

I’ve sent a note to China Unicom, but don’t expect any reply. A google of Ribiera Shanghai doesn’t reveal any obvious people to complain to either.

Yet another instance where I should put some active logging into the server to notify me when queue / connection sizes stay at high levels…