How to Set Up a DMZ with Linux?

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 “demilitarized zone in networking” is composed of servers, emails, DNS and the web among others; i.e., servers that have to be exposed to the public. For this, you need operating systems like Linux where you can configure the DMZ Linux environment. 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. If you are going to execute these processes in the Linux DMZ shared environment, these Linux shared hosting servers are vulnerable to cybercriminals.

What Is A DMZ Server?

DMZ based servers are networked through the DMZ network. The DMZ network acts like a buffer zone between the public internet and the private internal network. Imagine it like a small, controlled island between the wild internet and your company’s local network.

What it Gives?

• Isolation: The DMZ network is isolated from the internal network with firewalls. This creates an extra layer of security. If a hacker were to breach a server in the DMZ, they wouldn’t be able to easily access the private network where sensitive data is stored. You can get the same kind of isolation in our dedicated hosting servers. 
• Public-Facing Services: Think of the DMZ as the shop front of your network. It’s where you place servers that need to be accessed from the internet, such as web servers, email servers, or DNS servers.
• Controlled Access: While the DMZ is accessible to the internet, access is highly controlled. Firewalls carefully filter incoming and outgoing traffic, only allowing authorized connections.

Advantages of DMZ Configuration

• Enhanced Security: By isolating public-facing services, it makes it harder for attackers to infiltrate the core network. For more security, encrypting SSL certificates on your domain is a positive measure to implement. 
• Improved Performance: Traffic on the internal network is separated from internet traffic, which can help improve performance for internal users.
• Flexibility: The DMZ provides a place to host external-facing services without compromising internal security. Our cloud hosting servers give you the perfect example of flexibility.

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).

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

#BASIC RULES 

Echo  1  >  / proc / sys / net / ipv4 / ip_forward

iptables  -F

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.