Friday, November 6, 2015

Protecting Your DNS Server Against DDoS Attacks

One of the most destructive Web-based attacks a server can face is a distributed denial of service (DDoS) attack. Unfortunately, this sort of attack has become extremely prevalent in recent years, and very little can be done to totally stop it. Attackers will use multiple tactics when targeting servers. Lately, we have seem a resurgence in the use of  DNS amplification while sending DDoS attacks. However, a few steps can be taken to minimize the risk of your DNS server being use to be part of such attacks and to protect your DNS server from becoming unresponsive as a result of such an attack.
dos attack schema

How DNS amplification DDoS Attacks Work

For how effective they can be, DDoS attacks are actually quite simple. The perpetrators query name servers from thousands of computers that have been infected and converted into slave systems. However, instead of using the actual IP address of each querying computer, the target’s IP address is spoofed and sent in its place. As part of the attack, each query instigates a response that is larger than usual in order to maximize the damage.
One reason that DDoS attacks have been able to succeed begins with the implementation of EDNS0, which is a series of DNS extensions that allow DNS messages to be up to 4,096 bytes in size even though most queries and responses are no larger than 100 bytes. In addition, DNS security extensions (DNSSEC) have made it a simple matter to store large digital signatures and encryption keys in responses.
When a DDoS attack is triggered, thousands of computers begin to rapidly send DNS queries with the spoofed IP address. This forces your server to use its entire bandwidth allotment sending responses to these requests, which means legitimate traffic cannot be received.

Monitoring Your Server For DDos Activities

ddos monitoring
Commonly, the first step in protecting your DNS server from DDoS attacks is to monitor the server so that you know when an attack is occurring. Many administrators do not have a clue as to their average query rates and could never recognize an attack for what it is. Although several methods and outside software can be used for monitoring purposes, it is really as simply as using the built-in statistics from BIND. You can configure a standard interval for the BIND name server to send you its statistics, which include your query rate. Keep in mind that since DNS use UDP, other services using UDP(such as SNMP, NTP, etc.) can also be exploited into amplification attacks.

Distribute Your DNS Servers

distributing dns serverAfter you have your server set to monitor for DDoS attacks, you can help prevent them by configuring the Internet-facing systems on your server. These configurations include the name servers that you use, your switches and routers, your Internet connections and firewalls. Instead of limiting yourself to a single, authoritative, external name server, you may want to consider using a broad range of name servers from around the world. This will stop attacks coming from a single area or that primarily use a single, weak DNS server.
One way to easily distribute your DNS servers is to use Anycast, which allows multiple servers, including name servers, to share IP addresses. This permits you to route your traffic through two or more different channels instead of only one. Many hosting providers and other cloud-based companies offer Anycast services for a nominal charge, and several options are available, including the following:
• Anycast IP addresses can be configured into the network.
• Software can be implemented to support host-based routing.
• Name servers can be set to listen to DNS queries through Anycast IP addresses.
• Loopback interfaces can be established that include Anycast addresses.

Overprovision Your Server

You can also overprovision your server’s infrastructure to handle large numbers of queries. However, some DDoS attacks can exceed 100 Gbps of bandwidth, which can be very expensive to provision. The positive side of overprovisioning is that your server will be ready to handle increased traffic should your business and online presence grow.

Use High Availability

Because DNS servers are critical to most online businesses and organizations, servers should be configured as a high-availability (HA) pair. A sudden overload that causes one DNS server to slow or fail can be set to trigger a standby server to take over the task of receiving queries and sending responses.

Set Response Rate Limits

Response rate limits can be configured to help prevent DDoS attacks. Response rates can be limited by both the source IP address and the destination IP address. By limiting source addresses, only so many requests can be accepted in a given time period, and by limiting destination addresses, you can shut down an attack before it hits your server in force.

Protecting your DNS servers

dns server protectionIn order to minimize the chances of being part of a DNS amplification attack, there is one simple step that you can achieve on your DNS server to prevent it. It is important to disable the feature that allows your DNS server to answer to recursive queries. The first thing to do is to check if your DNS server is able to resolve a dig or a NS lookup of a domain name on your DNS server. To do so, in a terminal or a CMD, type :

Using Dig

dig @yourdnsserver.com www.domainexample.com

Using NS lookup

nslookup
> server yourdnsserver.com
> www.domainexample.com

 Dig answer example

$ dig @yourdnsserver.com www.domainexample.com
; <<>> DiG 9.8.3-P1 <<>> @yourdnsserver.com www.domainexample.com
; (1 server found)
;; global options: +cmd
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34294
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

NS lookup answer example :

Non-authoritative answer:
Name:    www.domainexample.com
Address: 8.8.8.8

In both cases, if an IP is returned for www.domainexample.com, the DNS server is vulnerable.
Next thing is to disable the features on your DNS server. Here’s how you can do it on Windows :
Run this command in a cmd:
dnscmd . /Config /NoRecursion 1
Or follow this procedure:
Start | Administrative Tools | DNS (DNS manager)
Right click DNS server |
Properties |
Advanced |
Server options |
Disable recursion -> Yes, OK

For  Linux :

Add this to the “options” section of /etc/named.conf :
recursion no;
additional-from-auth no;
additional-from-cache no;

Then restart named so that it will use the new secure options:
/etc/init.d/named restart
OR
If your DNS server is used only by the machine on which you are running it, you can block external queries by performing the following steps:
(Before implementing any new firewall rules, make sure that the following iptables rules are applicable in your case.)
iptables -A  INPUT -p udp -m udp –dport 53 -i ! lo -j DROP
These iptables firewall rules will prohibit ANY queries to a non-recursive DNS:
iptables -A  INPUT -p udp -m udp –dport 53 \
-m string –hex-string “|0000ff0001|”  –algo bm –from 48 –to 65535 \
-m recent –set –name anydnsquery  –rsource

iptables -A INPUT -p udp -m udp –dport 53 \
-m string –hex-string  “|0000ff0001|” –algo bm –from 48 –to 65535 \
-m recent –rcheck  –seconds 60 –hitcount 5 –name anydnsquery –rsource \
-j DROP

If you for some reason have to run an open DNS resolver, you can limit rate limit the rate at which you will accept queries:
iptables -A INPUT -p udp –dport 53 -m hashlimit \
–hashlimit-name DNS –hashlimit-above 20/second –hashlimit-mode srcip \
–hashlimit-burst 100 –hashlimit-srcmask 28 -j DROP

There’s no real way to fully protect yourself against a DDos attack as your server needs to respond to certain query. It’s not possible to block every request that comes from external sources as your server might be useless. Though, you can protect your system against usual DDos attacks like DNS amplification attack. It is also possible to reroute the heavy requests that are made from a third-party client.

Prevent DOS with iptables


After a recent conversation on the Ubuntu Forums I wanted to post an example of using iptables.
Of course there are several types of DOS attacks , in this post I will demonstrating the use if iptables to limit the traffic on port 80.
The goal is to keep your web server “responsive” to legitimate traffic, but to throttle back on excessive (potential DOS) traffic.
In this demonstration iptables is configured :
  1. The default policy is ACCEPT (to prevent lockout in the event of flushing the rules with iptables -F).
  2. “Legitimate” traffic is then allowed. In this example I am allowing traffic only on port 80.
  3. All other traffic is then blocked at the end of the INPUT chain (the final rule in the INPUT chain is to DROP all traffic).
The rules I will demonstrate are as follows:

First rule : Limit NEW traffic on port 80

sudo iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m limit --limit 50/minute --limit-burst 200 -j ACCEPT
Lets break that rule down into intelligible chunks.
-p tcp --dport 80 => Specifies traffic on port 80 (Normally Apache, but as you can see here I am using nginx).
-m state NEW => This rule applies to NEW connections.
-m limit --limit 50/minute --limit-burst 200 -j ACCEPT =>This is the essence of preventing DOS.
  • “--limit-burst” is a bit confusing, but in a nutshell 200 new connections (packets really) are allowed before the limit of 50 NEW connections (packets) per minute is applied.
For a more technical review of this rule, see this netfilet page. Scroll down to a bit to the “limit” section.

Second rule – Limit established traffic

This rule applies to RELATED and ESTABLISHED all traffic on all ports, but is very liberal (and thus should not affect traffic on port 22 or DNS).
If you understood the above rule, you should understand this one as well.
sudo iptables -A INPUT -m state --state RELATED,ESTABLISHED -m limit --limit 50/second --limit-burst 50 -j ACCEPT
In summary, 50 ESTABLISHED (and/or RELATED) connections (packets really) are allowed before the limit of 50 ESTABLISHED (and/or RELATED) connections (packets) per second is applied.
Do not let that rule fool you, although it seems very open, it does put some limits on your connections.
Test it for yourself, try using the first rule with and without the second rule.

Full set of rules

After the above commands, here is the complete set of rules I am testing:
iptables-save
# Generated by iptables-save v1.4.4 on --
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
# Completed on --
# Generated by iptables-save --
*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
# Completed on --
# Generated by iptables-save v1.4.4 on --
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -m limit --limit 50/sec \
--limit-burst 50 -j ACCEPT
-A INPUT -p icmp -m limit --limit 1/sec -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -m state --state NEW -m limit --limit 50/min \
--limit-burst 200 -j ACCEPT
-A INPUT -j LOG
-A INPUT -j DROP
-A FORWARD -j DROP
-A OUTPUT -o lo -j ACCEPT
COMMIT
# Completed on --
This rule set is for demonstration only and is NOT a complete set of rules for a web server. Do no use this rule set unmodified on a production server.

Testing the rule set

Human interaction

Open Firefox, point it to your web page. The web page should load nice and fast.
Hit F5 repetitively, load the page as fast as you can. Your web site should remain nice and responsive.
So far, so good, we want our site to remain responsive.

Simulated DOS

Actual DOS attacks are many times faster then humans, here I will use ab.
See this link or the Apache documentation for information of ab.

Baseline, without the above 2 rules

ab -n 100 -c 10 http://bodhi's_test_server.com/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking bodhi's_test_server.com (be patient).....done


Server Software:        nginx
Server Hostname:       bodhi's_test_server.com
Server Port:            80

Document Path:          /
Document Length:        59786 bytes

Concurrency Level:      10
Time taken for tests:   13.174 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      6002700 bytes
HTML transferred:       5978600 bytes
Requests per second:    7.59 [#/sec] (mean)
Time per request:       1317.369 [ms] (mean)
Time per request:       131.737 [ms] (mean, across all concurrent requests)
Transfer rate:          444.98 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:      122  129   2.2    128     134
Processing:  1151 1182  19.1   1177    1260
Waiting:      125  132   8.2    128     170
Total:       1280 1310  19.3   1305    1390

Percentage of the requests served within a certain time (ms)
  50%   1305
  66%   1313
  75%   1316
  80%   1321
  90%   1328
  95%   1354
  98%   1386
  99%   1390
 100%   1390 (longest request)
Notice:
Requests per second: 7.59 [#/sec] .
Total time for requests: 13 seconds .
(Data) Transfer rate: 444.98 [Kbytes/sec] .

With the above rules

First attempt:
ab -n 100 -c 10 http://bodhi's_test_server.com/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking bodhi's_test_server.com (be patient)...
apr_poll: The timeout specified has expired (70007)
Total of 99 requests completed
Oh no ! timed out, LOL
Second attempt (I reduced the number of requests to 90):
ab -n 90 -c 10 http://bodhi's_test_server.com/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking bodhi's_test_server.com (be patient).....done


Server Software:        nginx
Server Hostname:       bodhi's_test_server.com
Server Port:            80

Document Path:          /
Document Length:        59786 bytes

Concurrency Level:      10
Time taken for tests:   69.684 seconds
Complete requests:      90
Failed requests:        0
Write errors:           0
Total transferred:      5402430 bytes
HTML transferred:       5380740 bytes
Requests per second:    1.29 [#/sec] (mean)
Time per request:       7742.658 [ms] (mean)
Time per request:       774.266 [ms] (mean, across all concurrent requests)
Transfer rate:          75.71 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:      123  128   4.3    127     155
Processing:  1036 6269 10081.4   1921   51059
Waiting:      125 1240 5908.7    128   49656
Total:       1159 6396 10081.1   2044   51186

Percentage of the requests served within a certain time (ms)
  50%   2044
  66%   2981
  75%   5478
  80%   7047
  90%  20358
  95%  27356
  98%  48218
  99%  51186
 100%  51186 (longest request)
Notice :
Requests per second: 1.29 [#/sec] (mean)
Total time for requests: 69 seconds.
(Data) Transfer rate: 75.71 [Kbytes/sec] [Kbytes/sec].

For those unfamiliar with ab, that is a “minor” DOS

For comparison, here is what ab can do to the server (iptables was flushed [disabled]):
ab -n 1000 -c 100 http://bodhi's_test_server.com/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking bodhi's_test_server.com (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        nginx
Server Hostname:       bodhi's_test_server.com
Server Port:               80

Document Path:          /
Document Length:        58708 bytes

Concurrency Level:      100
Time taken for tests:   59.324 seconds
Complete requests:      1000
Failed requests:        945
   (Connect: 0, Receive: 0, Length: 945, Exceptions: 0)
Write errors:           0
Total transferred:      59190450 bytes
HTML transferred:       58945935 bytes
Requests per second:    16.86 [#/sec] (mean)
Time per request:       5932.368 [ms] (mean)
Time per request:       59.324 [ms] (mean, across all concurrent requests)
Transfer rate:          974.37 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:      127  908 817.9    788    8016
Processing:   735 4779 1805.2   4368   15707
Waiting:      128  981 827.2    811   12143
Total:       1058 5687 1880.8   5269   17450

Percentage of the requests served within a certain time (ms)
  50%   5269
  66%   5899
  75%   6340
  80%   6863
  90%   8078
  95%   9001
  98%  10937
  99%  11730
 100%  17450 (longest request)

Notice :
Requests per second: 16.86 [#/sec]
Total time for requests: 69 seconds.
(Data) Transfer rate: 974.37 [Kbytes/sec] .
As you can see, the server has no problem dishing out 974.37 [Kbytes/sec] !!!

Closing remarks

Hopefully you now understand this “simple” example limiting a DOS on port 80.
With these rules your web site remains responsive to human interaction in firefox. Go ahead, hit F5 (refresh the page) as fast as you can, see if you can get your web page to slow down =) .
The difference is that as with a DOS attack, ab is hitting the server faster then you can with F5 , so your site is responsive to “normal” activity, but blocks DOS.
Obviously this is but one example and there are several types of DOS attacks. The goal is to demonstrate the use of iptables using a few “simple” rules.
You task is to take this knowledge and apply it to you own server.

Wednesday, November 4, 2015

Scatterplot in R


Here is an example:

data <- read.table("Z:\\wangz\\exome-homodel-results\\RD1-gc-cov.txt",header=TRUE,sep='\t')
attach(data)
plot(data$GC, data$cov, main="Scatterplot", xlab="GC content ", ylab="Coverage ")




Tuesday, November 3, 2015

PyTables example

import tables
from tables import *
import tables
import numpy
class Particle(IsDescription):
     name      = StringCol(16)  
     idnumber  = Int64Col()     
     ADCcount  = UInt16Col()    
     TDCcount  = UInt8Col()     
     grid_i    = Int32Col()     
     grid_j    = Int32Col()     
     pressure  = Float32Col()   
     energy    = Float64Col()

h5file = open_file("tutorial1.h5", mode = "w", title = "Test file")
group = h5file.create_group("/", 'detector', 'Detector information')
table = h5file.create_table(group, 'readout', Particle, "Readout example")
print(h5file)
h5file
particle = table.row

for i in xrange(10):
     particle['name']  = 'Particle: %6d' % (i)
     particle['TDCcount'] = i % 256
     particle['ADCcount'] = (i * 256) % (1 << 16)
     particle['grid_i'] = i
     particle['grid_j'] = 10 - i
     particle['pressure'] = float(i*i)
     particle['energy'] = float(particle['pressure'] ** 4)
     particle['idnumber'] = i * (2 ** 34)
     # Insert a new particle record
     particle.append()

table.flush()

table = h5file.root.detector.readout
pressure = [x['pressure'] for x in table.iterrows() if x['TDCcount'] > 3 and 20 <= x['pressure'] < 50]
pressure

Python: Calculate GC content for a BAM file

import pysam
from sys import argv

bam_file = argv[1]
bed_file = argv[2]

bam = pysam.AlignmentFile(bam_file, 'rb')
with open(bed_file) as bf:
    for line in bf:
        line_parts = line.strip().split()
        chr = line_parts[0]
        start = int(line_parts[1])
        end = int(line_parts[2])
        read_data = bam.fetch(chr, start, end)
        total_bases = 0
        gc_bases = 0
        for read in read_data:
            seq = read.query_sequence
            total_bases += len(seq)
            gc_bases += len([x for x in seq if x == 'C' or x == 'G'])
        if total_bases == 0:
            gc_percent = 'No Reads'
        else:
            gc_percent = '{0:.2f}%'.format(float(gc_bases)/total_bases * 100)
        print '{0}\t{1}'.format(line.strip(), gc_percent) 
You need to have Pysam installed.

Monday, November 2, 2015

Strengthening Diffie-Hellman in SSH and TLS

Conjecture on cracked primes for the Diffie-Hellman asymmetric algorithm is in recent news, suggesting that several nations have broken primes in common use and can read all traffic:
http://www.theregister.co.uk/2015/10/19/nsa_crypto_breaking_theory/

https://freedom-to-tinker.com/blog/haldermanheninger/how-is-nsa-breaking-so-much-crypto/To protect ssh, edit the file /etc/ssh/moduli and comment lines where the 5th field is less than 2047:

#    $OpenBSD: moduli,v 1.8 2012/08/29 05:06:54 dtucker Exp $
# Time Type Tests Tries Size Generator Modulus
#20120821044040 2 6 100 1023 5 D9277DAA27DB131C03B108D41A76B4DA8ACEECCCAE73D2E48CEDAAA70B09EF9F04FB020DCF36C51B8E485B26FABE0337E24232BE4F4E693548310244937433FB1A5758195DC73B84ADEF8237472C46747D79DC0A2CF8A57CE8DBD8F466A20F8551E7B1B824B2E4987A8816D9BC0741C2798F3EBAD3ADEBCC78FCE6A770E2EC9F
…
#20120821044502 2 6 100 1535 5 D1391174233D315398FE2830AC6B2B66BCCD01B0A634899F339B7879F1DB85712E9DC4E4B1C6C8355570C1D2DCB53493DF18175A9C53D1128B592B4C72D97136F5542FEB981CBFE8012FDD30361F288A42BD5EBB08BAB0A5640E1AC48763B2ABD1945FEE36B2D55E1D50A1C86CED9DD141C4E7BE2D32D9B562A0F8E2E927020E91F58B57EB9ACDDA106A59302D7E92AD5F6E851A45FA1CFE86029A0F727F65A8F475F33572E2FDAB6073F0C21B8B54C3823DB2EF068927E5D747498F96361507
…
20120821045639 2 6 100 2047 2 DD2047CBDBB6F8E919BC63DE885B34D0FD6E3DB2887D8B46FE249886ACED6B46DFCD5553168185FD376122171CD8927E60120FA8D01F01D03E58281FEA9A1ABE97631C828E41815F34FDCDF787419FE13A3137649AA93D2584230DF5F24B5C00C88B7D7DE4367693428C730376F218A53E853B0851BAB7C53C15DA7839CBE1285DB63F6FA45C1BB59FE1C5BB918F0F8459D7EF60ACFF5C0FA0F3FCAD1C5F4CE4416D4F4B36B05CDCEBE4FB879E95847EFBC6449CD190248843BC7EDB145FBFC4EDBB1A3C959298F08F3BA2CFBE231BBE204BE6F906209D28BD4820AB3E7BE96C26AE8A809ADD8D1A5A0B008E9570FA4C4697E116B8119892C604293680B09D63
 
To protect TLS for HTTPS, compute your own Diffie-Hellman primes like so:

[root@host ~]# openssl dhparam -out foo 2048
Generating DH parameters, 2048 bit long safe prime, generator 2
This is going to take a long time
................................................................................................................................................................................................................................................................................+..................................................................+..............................................................................................................................................................+................+.................................................................................................................................................................+......................................................................................+..................................................+...................+................................................+....+.........................+...............................................................................................................................................................................................................................................................+...........................................................................+.....................................................................................................................................................+.....+................................................................................................................+..++*++*
[root@limsprd ~]# cat foo
-----BEGIN DH PARAMETERS-----
MIIBCAKCAQEAnRcLNdZeit18uYSAtEeumAOKIlAvkH5XLVw3V+jbltAjH09RJa8i
n+8bZlLGO7Rg01Exlf3FqMyK5uJTE3FkkCD2Xmv/UR+YS2c4XjzBfxELVC1C8V0J
fvgge4plUX04gG1AN3uwsLp6DgC4Ee06hEuKG6Nh6YX5tHawmPwsRqPM7GRjD4Rc
GYUJCWxh6lKuf63rHUwBH8i44FrQtJHL4lbbqxqQM1K3c2R/g+EcPoTd2VLxlT8y
gbN2rKsSi6/VggOSZ9f8DHNJB5lpuZgd6k7VymCAvc+mtFWVpBvSOWxaT7Wo5wLe
ID3exEDZl/DTDuijs/Tc0zPtoyC7vOPxawIBAg==
-----END DH PARAMETERS-----
 
Then add the BEGIN/END block above immediately after the “END CERTIFICATE” statement for your public key.
______________________Charles Fisher has an electrical engineering degree from the University of Iowa and works as a systems and database administrator for a Fortune 500 mining and manufacturing corporation.