The importance of locking down your boxes

I was prompted to write this article because of a customers system that was being used as part of a DDOS attack. In this case a clients system was part of a DNS reflection attack (https://deepthought.isc.org/article/AA-00897/0/What-is-a-DNS-Amplification-Attack.html). The client had a cluster of servers setup with bind installed with the configuration which accepts and responds to all requests that it gets. The boxes were hosted on AWS. As soon as AWS contacted our client they came to us and it was fairly easy to show where their engineer messed up. Port 53 should have only allowed established traffic.

Security is ever more important these days. You have rouge states, script kiddies and gangs for hire that will launch a DDOS attack for a few dollars. They prey on the n00b’s that don’t know much about security that have boxes that are wide open. With all the available hosts out there, it’s fairly easy to spin up a VM of your favorite distro and have a completely open system waiting for thugs to exploit. I recall the first time I set up a box I set the root password to root. Within five minutes of it being on the public internet the box was compromised. I have a come a long way  and learned a lot since. A good rule of thumb is anyone or anything that does not need access should not get it. If you do need to have something open to the world be smart about it. For instance if you have to have SSH open A) Change the port from 22 to something else such as 7232 and B) only allow access to a set of IP’s (though not always do you have static IP’s that you can limit your access from). If you are using SIP change from the default port of 5060 to something else like 5999. On every machine that we set up we have a default iptables setup which blocks everything except SSH. For this particular client below is the set up that we have:

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1067342:31256460588]
-A INPUT -m state –state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
# The next line is for access from any other node in this region on AWS
-A INPUT -s 10.0.0.0/24 -j ACCEPT
#The next line is for SSH access from any host
-A INPUT -p tcp -m tcp –dport 7232 -j ACCEPT
#The next line is to allow all traffic from the office
-A INPUT -s 100.133.27.54/32 -j ACCEPT
#The next line is to log all dropped traffic so if we to see dropped packets we can see where they came from and what they were for
-A INPUT -j LOG –log-prefix “INPUT:DROP:” –log-level 6
-A INPUT -p udp -m udp –dport 53 -j DROP
-A INPUT -j DROP
COMMIT

As you can see we only allow traffic from:

  1. The loopback interface
  2. The network range 10.0.0.0/24 which is the IP’s used on AWS
  3. Traffic to port 7323 which is used for SSH
  4. All traffic from 100.133.27.54 which is the office IP

We drop traffic:

  1. With a destination port of 53
  2. All other traffic

In truth we don’t need a special rule for port 53 but we put it in so we can easily see how many packets destined for port 53 were being dropped. About 10 minutes after we updated iptables we checked:

[dovid@my_host ~]# iptables -L -nv
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination
9369 2122K ACCEPT     all  —  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
0     0 ACCEPT     all  —  lo     *       0.0.0.0/0            0.0.0.0/0
0     0 ACCEPT     all  —  *      *       10.0.0.0/24          0.0.0.0/0
0     0 ACCEPT     tcp  —  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:7323
0     0 ACCEPT     all  —  *      *       100.133.27.54        0.0.0.0/0
83  6212 LOG        all  —  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 6 prefix “INPUT:DROP:”
28  1680 DROP       udp  —  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53
55  4532 DROP       all  —  *      *       0.0.0.0/0            0.0.0.0/0

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 9810 packets, 2463K bytes)
pkts bytes target     prot opt in     out     source               destination
[dovid@my_host ~]#

 

And as you can see we were being targeted. When we looked through the logs:

[dovid@my_host ~]# tail -n 5 /var/log/messages | grep DROP
Apr  6 15:50:07 my_host kernel: [782606.651379] SRC=162.8.120.17 DST=10.0.0.4 LEN=68 TOS=0x00 PREC=0x00 TTL=48 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=53313 SEQ=18336
Apr  6 15:50:07 my_host kernel: [782606.851357] SRC=162.8.120.18 DST=10.0.0.4 LEN=68 TOS=0x00 PREC=0x00 TTL=47 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=5384 SEQ=18629
Apr  6 15:50:07 my_host kernel: [782607.050859] SRC=162.8.120.20 DST=10.0.0.4 LEN=68 TOS=0x00 PREC=0x00 TTL=48 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=40526 SEQ=18907
Apr  6 15:50:18 my_host kernel: [782617.379855] SRC=219.254.13.194 DST=10.0.0.4 LEN=102 TOS=0x18 PREC=0x00 TTL=37 ID=6995 PROTO=ICMP TYPE=3 CODE=3 [SRC=10.0.0.4 DST=219.254.13.194 LEN=74 TOS=0x00 PREC=0x00 TTL=242 ID=4738 DF PROTO=UDP SPT=59551 DPT=53 LEN=54 ]
Apr  6 15:50:29 my_host kernel: [782628.991666] SRC=213.76.131.143 DST=10.0.0.4 LEN=74 TOS=0x00 PREC=0x00 TTL=110 ID=15903 PROTO=UDP SPT=53 DPT=59551 LEN=54
[dovid@my_host ~]#

The above shows how important a firewall such as iptables is and how you should have a clear policy that states what should and should not be allowed. The more you lock out the better.

 

 

Leave a comment

Leave a Reply