One of the most worrying aspects of security is network-level security; as it is the area where teams are most exposed and where they are most likely to take control of their team. Obviously, there are more “doors” to access a team. There is a very popular saying that perfect security can only be achieved by having a team within a Faraday cage without an Internet connection and praying that no one steals the key to open that cage.
But it is undeniable that generally, we try to access a team remotely at the network level. That is why sometimes you have to consider the possibility that a team can be violated and that from there try to “jump” to other teams with which the team has communication. There comes into play a very important and useful concept called DMZ.
A DMZ (Demilitarized Zone) is a “special” zone that is exposed to the network and is prone to receive attacks from cyber-criminals. This “zone” is composed of servers, emails, DNS and the web among others; i.e., servers that have to be exposed to the public. The best is to never harm any of these, but this situation is utopian and we cannot simply think that it would never happen, either because we think our security measures are very good or because we think we are good at security. They are going to look at our servers.
That is why we have to prepare ourselves for the worst possible situation. That is to say the situation of obtaining access to one of these servers. The situation in which the use of the DMZs makes sense because its function is so simple as to allow access from the outside to this zone, which from the Inside, the “corporate” network can also be accessed, but the DMZ cannot access the corporate network. That is isolated. To better understand this example, here is the small scheme:
As you see the objective is very clear, in my opinion, it is quite understandable. The issue is that, generally, to achieve such a purpose, we would require a firewall or a switch with these capabilities. This usually requires an economic investment and we cannot do that sometimes. Fortunately, we can choose to make a DMZ with a computer that simply has 3 network cards and Linux installed. Specifically, with the same configuration as shown in the diagram above, that is to say:
- A network interface named eth0 with mask 255.255.255.0 IP 192.168.1.2 and that would be connected to the router.
- A network interface name eth1 with mask 255.255.255.0 IP 192.168.2.1 and that would be connected to the DMZ, that is the area which will receive a “special” treatment.
- A network interface name eth2 with mask 255.255.255.0 IP 192.168.3.1 and that would be connected to the local network.
Having this clear network interface layout, we need to be clear on what goal to achieve and how to do it. With the above schematic and clear network interfaces, knowing the purpose of a DMZ we would see that the objective would be:
- The requests to certain ports of the interface eth0 will be redirected to eth1 (DMZ).
- The traffic coming from the eth0 interface to eth1 interface, pass without any problems.
- The traffic going from the eth1 to eth0 interface, traffic is only in response to requests that have been made to the servers in the DMZ.
- The traffic coming from the eth2 interface to the eth1 interface also pass without any problems.
- The only traffic that can come from the DMZ (eth1) to the local network is caused by the responses to requests from the local network (eth2).
Also check: Security Questions to Ask Hosting Providers
Could we achieve all this? With IPTables of course! Everything discussed above, we would achieve with this simple script that only had to be executed to have our DMZ operational. It should be noted that this configuration would be intended for a DMZ that has a web server and a DNS server, i.e., it would be prepared to redirect the requests to ports 53 and 80. The script in question could be called DMZ.sh
#! / Bin / bash
Echo 1 > / proc / sys / net / ipv4 / ip_forward
iptables -t nat -F
iptables -A INPUT -j DROP
iptables -A FORWARD -j DROP
iptables -A OUTPUT -j ACCEPT
#FORWARD'S RULES WE WISH
# LET'S ALL TRAFFIC GO FROM ETH0 TO ETH1
iptables -A FORWARD -i eth0 -o eth1 -s state --state NEW, ESTABLISHED, RELATED -j ACCEPT
# LET'S THE RESPONSE ONLY GO TO PETITIONS FROM ETH1 TO ETH0
iptables -A FORWARD -i eth1 -o eth0 -s state --state ESTABLISHED, RELATED -j ACCEPT
# LET'S ALL TRAFFIC GO FROM ETH2 TO ETH1
iptables -A FORWARD -i eth2 -o eth1 -s state --state NEW, ESTABLISHED, RELATED -j ACCEPT
# LETS ONLY PASSES RESPONSES TO PETITIONS FROM ETH1 TO ETH2
iptables -A FORWARD -i eth1 , or eth2 -s state --state ESTABLISHED, RELATED -j ACCEPT
#PRIORITIZE REDIRECTIONS FROM THE OUTSIDE TO THE DMZ
# REDUCTED POINTS 53 AND 80
#IPS FICTICS THAT ARE WITHIN THE ETH1 RANGE
#PUT 53, TCP AND UDP
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 53 -j DNAT --to 192.168.2.4: 53
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 53 -j DNAT --to 192.168.2.4: 53
#PUERTO 80 TCP: WEB
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to 192.168.2.5: 80
With this little script, we would already have the equipment ready to act as a firewall and to convert the zone connected to the eth1 interface in a DMZ.
As you see, the creation of this type of environments is not excessively complicated. It simply requires having certain bases of IPTables to be able to develop us with freedom, which demonstrates, once again, the enormous utility of this tool.
I hope you have found it useful.