After putting my home server online running my blog and other applications accessible from the Internet, I left it unattended for a few days and then I found that I couldn’t access my blog from the Internet any more. It has been attacked by hackers using Denial-of-service attacks. Hackers created a large number of half-open TCP connections to the server and established connections to the Apache Web Server. The latter caused the Apache Web Server’s Prefork Multi-Processing Module (MPM) to spawn the maximum number of Processes allowed. This combination brought the server performance to a stand-still. The DMZ I created appears to be holding up as I did not find any evidence on hackers breaking through my second firewall.
I was naive in thinking: Who will attack a blog with no commercial value? Maybe some kids in high school want to prove that they can!
Further Isolation Using VLANs
I can’t help being paranoid after the initial attack although the attack did not seem to have penetrated the second firewall. I just want to make sure that even the attacker has gained total control (not evident so far) of the home server, he still cannot access my other devices on the LAN. I want to create VLANs isolating the home devices and devices in the DMZ as shown in the diagram at the top of the page.
The difference from the previous setup is that the Internet-facing router is connected to the switch, and the home server and second router are connected to the switch on different VLANs instead of directly to the router.
I went to the nearby computer hardware store and purchased an inexpensive TP-LINK SG108E smart switch.
This switch has many features including port mirroring, cable testing, QoS and VLAN support. The hardware is great but the manual is not of similar quality. There are three different types of VLANs that the switch supports:
- MTU VLAN – MTU stands for Multi Tenants Unit. MTU VLAN is the simplest to set up. By default, when enabled, it uses port 1 as the uplink and all other ports are virtually in a VLAN of their own ie, totally isolated from each other similar to the WIFI AP Isolation feature on some routers. This means that the device connected to one port cannot access devices on the other ports even they are in the same subnet.
- Port-based VLAN – this is also easy to setup. It allows you to assign different ports to different VLANs. The difference between this option and the 802.1Q-based VLAN is that port-based VLAN cannot extend to include particular ports on additional connected smart switches.
- 802.1Q-based VLAN – this is relatively more difficult to set up among the three. Unlike the port-based VLAN, a VLAN can be extended to include particular ports on additional connected smart switches.
I use MTU VLAN because it is easy to set up and it fits my plan to add IoT devices to the switch later on. Each additional IoT devices I connect to the switch will be isolated from each other. In the present scenario, the home server is connected to one port while the second router is connected to another port. This means that even if a hacker gains control to the home server, he will not be able to see the second router or any devices connected to it using either WIFI or wired connections. This gives me additional peace of mind.
Iptables is Your Ally
Iptables is an administration tool for packet filtering and Network Address Translation (NAT). It is a generic table structure for the definition of rulesets. Each rule within an IP table consists of a number of classifiers (iptables matches) and one connected action (iptables target). You can find out more about using iptables here.
I am using a simple ruleset to defend my home server against the attacks I witnessed so far. More rules will be added when I see new threats. This simple ruleset is shown below:
iptables -P INPUT ACCEPT iptables -F iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -s 220.127.116.11/24 -j REJECT ... iptables -A INPUT -p tcp --dport 80 -j ACCEPT ... iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT
- iptables -P INPUT ACCEPT - sets the default policy on the INPUT chain to ACCEPT in order to avoid being locked out when the current rules on the home server is flushed.
- iptables -F – flushes all existing rules to start afresh.
- iptables -A INPUT -i lo -j ACCEPT – adds a rule to the INPUT chain. Use the -i switch (for interface) to specify packets matching or destined for the lo (localhost, 127.0.0.1) interface and the -j option to ACCEPT the packets matching the rule . Accepting all incoming packets destined for the localhost interface is generally required for applications which expect being able to communicate with the localhost interface.
- iptables -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT – accepts packets for ESTABLISHED and RELATED connections. A packet can be in one of the following states: NEW, ESTABLISHED or RELATED. NEW refers to incoming packets that are new incoming connections. ESTABLISHED and RELATED refers to incoming packets that are part of an already established connection or related to an already established connection.
- iptables -A INPUT -s 18.104.22.168/24 -j REJECT – rejects input packets from network 22.214.171.124/24 where hacks originate. Note that the attacker may be spoofing the source address from which the attacks originate. There may be multiple such statements covering all the observed (using the netstat -nap command) attacking source networks.
- iptables -A INPUT -p tcp –dport 80 -j ACCEPT – allows HTTP traffic to tcp port 80. Multiple such statements can be added to allow for other protocols or tcp ports.
- iptables -P INPUT DROP – sets the default policy to drop all incoming packets if they do not match the above rules..
- iptables -P FORWARD DROP – sets the default policy on the FORWARD chain to DROP all packets.
- iptables -P OUTPUT ACCEPT – sets the default policy on the OUTPUT chain to ACCEPT all outgoing traffic
After I activated the ruleset, I noticed the attack stopped for a while and then started again from another IP address in another network. I inserted another REJECT rule to reject input packets from this network as follows:
iptables -I INPUT N -s xxx.yyy.zzz.0/24 -j REJECT – inserts this rule in the Nth position of my ruleset to reject input packets from the xxx.yyy.zzz.o/24 network. Just replace N and xxx.yyy.zzz with the appropriate values to address the attacking source network.
After repeating this process a few more times, the attack dies down and everything is back to normal again.
I think the hackers must have lost interest in hacking my home server as I have not seen any attacks since I implemented this change.
As a preventive measure, I wrote a shell script which monitors suspicious TCP connections and updates the iptables ruleset in an adaptive manner. As there are no more observed attacks, I can’t tell for sure if the script works as expected yet. But I am sure that I shall find out when the next attacks occur.
When you are allowing people to access your home server from the Internet, you must be prepared for attacks. I was not and I paid the price. It does not matter whether your site is a commercial site or just a hobbyist site like mine. I have no valuable personal or commercial information on the home server. It is inconvenient but not critical even if my home server is compromised as long as hackers cannot get into my home network. I am hoping that by putting the DMZ LAN and my home LAN on separate VLANs will make hacking my home LAN more difficult. Using iptables to defend hacking attacks works for me. I hope that it will work for you too. A better outcome is certainly not being attacked at all although it is unlikely and I am a perennial optimist