A Raspberry Pi firewall: Package filter - 05 Understanding the whats and whys to manage a service

 

To recap. Until now we create: 

• Some rules in our chains INPUT and OUTPUT to allow some traffic to specific ports
• A backup of our rules and configure iptables to load these rules on the boot process
• A group to manage rules 
• Some of these rules to log the network activity

With all this basic information, we are able to create a host package filter and troubleshoot related to traffic from and to our host. 

Before we continue with more technical knowledge about iptables is important to understand there are administrative actions to take in count when we manage this tool.

Why open a port? The answer to this question could be obvious, but we really need to open that port? Who authorizes open this port? What implication comes with this decision? is there another option we can take?

Let's take this example. This server host a public website, all the Internet can see it, and for the business its important because there is the e-commerce platform, without it, there is not a business.

In this case, our package filter has to keep open port 443 (we are talking about security, for this reason, we avoid use port 80 for an e-commerce platform).  It is important for the business and the general board allow to keep open this port.

A web developer works from home, and she needs to update some images stored in the same server (yes, it is a bad practice, but is just an example).  She asks the server administration to allow her to connect using SSH from her home to the server. Open port 22 to allow connections from the Internet, couldn't be the best option. There are many possible threats and vulnerabilities that could put in risk the server like brute force attacks, bad service configurations, unparched services, etc. Also, this service is not strategic for the business and is safer to allow connections to this port from the LAN. In this case, the developer could use a VPN to connect to the internal network and use SSH to access the server.

How to manage the rules? We can create and delete rules, but if some one deletes the ssh rules and father that nobody can access the server again? If its new rule is temporal Who is going to delete it? Is there a reminder to delete that rule?

If there are more than 1 administrator, she or he have to create an user account for each user, and the users should use commands like sudo to have root privileges. Whit this action its possible have  accountability about the changes in the package filter rules. Of course the users couldn't have to the log files.

A last basic recommendation is create registry of all the actions taken in the rules management , system updates and backup crations. Take note of the date and time when the changes were made and use comments or autodocument the rules. It is importan have a periodic revition of these registries. If for example there is a note about to erase a rule, it's ease identify if that rule was erased or not and take an action.All this rules have to be documented in a policy. The policy have to have a role and responsibility section, and have to be accepted for the managers and the sysadmins.

Do yo thing there is a basic recommendation to include? Leave it in the comments.

A Raspberry Pi firewall: Package filter - 04 New rules and more logs

 Great!!! Now we are ready to create more rules in our chains, but, what happens if we start to have many rules? How can we know what they do in an easier way? Well there are two different approaches to solve this.

One of them is trying to auto document it, this is put something in the rule that helps us to identify it, and a possible way is to create a new chain and make something in it.

Let's take our ssh rule. We have a rule in input and output to allow the connections to our Raspberry using ssh. When we list the rules running in our iptables is clear to see these are rules to ssh, because in the description we can see the word 'ssh'.

 

But if we need to open a not well-known port? In this case, we can create a new Chain with a descriptive name. for example

iptables -N MYSQL

inside this chain, we can create the following rule

iptables -A MYSQL -j ACCEPT

Now in the INPUT and OUTPUT chain, we write the following rules.

iptables -A INPUT -tcp -dport 3306 -j MYSQL

iptables -A OUTPUT -tcp -sport 3306 -j MYSQL

In this case, the new chain helps us in many ways:

• We auto document our rule because at a first shot we know this rule is related wit mysql DMBS
• We can create more rules only for mysql without including more complexity to the INPUT and OUTPUT chains.
• Our chains's rules are more clear.

Now, if auto document is not enough and we need more information about our rule, we can use the module 'comment' in the following way:

iptables -A INPUT -p tcp -dport 22 -m comment --comment "This rule is to allow local ssh connections" -j SSH

Excellent, now it's possible to create a large number of rules, document it and organize.

 Now If we need to fix a situation and we don't have a clear with the rule is not working well. In this case, we can use our old target friend LOG, but if we create many rules with LOG How can identify each one in the logs?

Easy, at the end of the rule include this:

iptables -A INPUT -p tcp -dport 22 -j LOG --log-prefix "SSH" 

If the information in the logs is not enough to identify the problem it is possible to add at the end a different level of the log.

iptables -A INPUT -p tcp -dport 22 -j LOG --log-prefix "SSH" --log-level 7

 

A Raspberry Pi firewall: Package filter - 03 Logging and rules management

 Now we have two rules to connect to the raspberry, and we know it is working because we can connect to it using ssh. Now, how can we know if someone else is training to connect to it? We can create a rule every ssh connection to the raspberry is logged.

To do this, let's create the following rule

iptables -A INPUT -p tcp -dport 22 -i eth0 -j LOG

As you can see, is the same rule that we create before, but the target is LOG instead of ACCEPT.

If we try to connect to our Rasberry again, we will have access to it.

This rule, write a log entry in /etc/var/kern.log but, if we look at the end of this file we will not find anything related to our new rule. This is because the rules in a chain are executed in descending order, in this case, the rule with the ACCEPT is executed before the LOG rule. When iptables find a rule that jumps to ACCEPT, DROP or REJECT, it finish looking for a rule and the following rules are not executed.

To fix this, let's move our LOG rule.

 First, we need to know the rules created, so run the following command (you know this one):

iptables -L

we can see a tabular representation of our rule. now lets run again the same command but now wue are going to add a new option

iptables -L --line-n

Now we have the same result with the last command but at the beginning of each line, we have a number. This number is an identification of each rule on each chain. So we can delete the rule with the command

iptables -D INPUT 2

OK, but what happens if we have tens of hundreds of lines and can identify a specific rule to erase it in the tabular view? We can delete the rule  rewriting the rule, changing the option "A" for a "D"

iptables -D INPUT -p tcp -dport 22 -i eth0 -j LOG

OK, now we want to put our rule before of that where we open the communication with ssh. Lets Inset the new rule:

iptables -I INPUT 1 -p tcp -dport 22 -i eth0 -j LOG

In this case, 1 is the position where we want to include our new rule. If you run the command to show the tabular rules table, you will see there is a new order in the rules, first comes the LOG rule and after the ACCEPT rule.

In this case, the rule with LOG doesn't break the order of reading rules, iptables find this rule, execute it and continue with the next one.

A Raspberry Pi firewall: Package filter - 02 - Introduction

 WARNING: The commands in this post could break the communications from or to your iptbales device and network(s). For this reason, don't use them in a production system or if you are remotely connected.

First a backup

Before we start to play with some commands, is important to create a backup of our rules. We can use iptables-persistent package to create a backup of the current rules. Once installed write the following command:

iptables-save > /etc/iptables/rulesv4

Iptables use this file to reconfigure the seated rules on reboots.

To recover the previously configured rules from /etc/iptables/rulesv4 run the following command:

iptables-restore < /etc/iptables/rulesv4

There is another useful command to use when we start to create rules in our Linux box:

iptables -F

This command flushes the rules configurated, but don't change the chains' policies.

Allow all vs deny all

When we configure a firewall it is possible to have 2 different approaches: 

• allow all the connections and deny some of them. 
• deny all connections and allows someones. 

Choose some of this approaches depends on the necessities that you or your organization require.

Lest take the approaches to deny all. To make this we have to change our Chins' policies to Drop.

iptables -P INPUT DROP

iptables -P OUTPUT DROP

iptables -P FORWARD DROP

Be careful with these commands, if you are connected remotely using ssh, for example, you will lose the communication because all of them are not allowed after run these commands.

Excellent now nothing can go out, come in or pass throw our computer. Now our computer is totally secure... and useless, for this reason, let's configure some rules to connect to it remotely.

I mentioned in the last post, I'm using ssh to connect remotely to my raspberry pi and manage it.  To allow this connection I need to know the protocol used by ssh and the port where the ssh service listens. in this case, ssh has a TCP/22 port in my raspberry pi.

 

As we can see, external communication comes IN to the TCP/22 port in our Rasberry, for this reason, we are going to create a rule to exempt the DROP general policy in our INPUT chain. To do this, let's create a rule. 

Wait!! Don't run anything yet. 

The basic of our rule is this:  

 iptables -A INPUT -j ACCEPT

we can see two of the three parts that compose a rule, the first part is the name of the chain where we are going to Append the rule.

 -A INPUT   (-A can be changed for --append)

The last part is what we are going to do with the rule. in this case, accept

-j ACCEPT (-j for jump, in following examples we are going to understand why jump)

The second and most important part of our rule is not present in this example but it is the "why" the exception

If we run this command at is, this going to allow all the coming in communications to the computer, overwriting the default Policy DROP.

OK, lest doing something with this, let's include what we know about our service ssh

iptables -A INPUT -p tcp -dport 22 -j ACCEPT

We are including the protocol TCP and the destination port:22. I don't see a problem with the protocol, but Why a dport or destination port?

When we try to connect from our computer to our raspberry, the raspberry has open the port 22. When we start the communication from our computer the destination of this communication is the raspberry and its port 22.

Great now we can configure this rule in our raspberry but...wait. This configuration allows a connection to the port 22 from any of the nets connected to the raspberry. and we just want to connect to port 22 from our LAN... we can specify from which interface we allow the connection

  iptables -A INPUT -p tcp -dport 22 -i eth0 -j ACCEPT

Now it looks better. Let's run our command, try it and... it fails. Why? Because we configured the general Policy for our OUTPUT chain with DROP, for this reason, the communication answers from the raspberry never go out. To fix this lets create a new rule

iptables -A OUTPUT -p tcp -sport 22 -o eth0 -j ACCEPT

These rules have two important changes:

the option to declare the port changed to "sport" or "source port". This is because the responses come from port 22 in the Rasberry Pi to our remote computer.

The other change is the option to declare the interface. It change to "o" (output) is because when we want to specify an interface we have to indicate if it is an interface to receive or to send a communication.

Now you are able to connect using ssh to your raspberry, and is a good moment to create a backup of our rules.

A Raspberry Pi firewall: Package filter - 01 Introduction

 There are many posts about how to create a firewall using Linux, and probably this could be one more, but I'll try to make it different. First, because the things that I write here, are things I'm currently using, and are working to me. Second because, learn iptables is not an easy task, especially at the beginning, but when you finally get a reasonable idea of how it is working, use it is quite easy and I'll try to explain who iptables works in an easy way.

Introduction.

I'm using a raspberry pi that connects to my ISP using a WiFi network (don't ask why). I'm using the raspberry built-in wifi adapter for this proposal, and a wifi router connected to the pi's ethernet port to have my local wifi network and connects my devices to the personal WiFi net and not to the ISP provider network like some other people do.

To manage my Raspberry Pi, I have open ports TCP/22 (SSH) and to download updates for this box, I use ports TCP/80 TCP/443 (HTTP and https) and UDP/53 (DNS). Of curse, I going to manage my raspberry from my internal network, for this reason, SSH will listen to and answer from the ethernet interface only, and the requires HTTP and DNS traffic will go out and return using the WiFi adapter.

Iptables: The basics.

To work with tables we need to know there are three basic elements used in tables: Policies, Chains and Rules.

The policies control the main behaviour of the chains, and the rules are exceptions to the policies into the chains. Ok, this sounds a little confusing but this going to be clear when we start to make some examples.

The Policies and the rules have 3 possible states: Accept, Drop and Reject. and there are 3 basic chains INPUT, OUTPUT and FORWARD. It is possible create more chains but we are in the basic explanation.

Ok, is time to push the gas...

Let's make an analogy whit physical country frontiers: Lest takes the 3 countries of North America, Canada, US and Mexico. 

Imagine that you live in Canada or Mexico. If you want to go IN to US, you are using the INPUT chain. If you want to go OUT to US, you use the OUTPUT chain. if you want to go to Mexico or Canada crossing US you use the chain FORWARD.

With the computers is the same, US is the computer with iptables, Canada and Mexico are two networks that you want to connect using the iptables box.

Ok, now the Policiescontrol the general behaviour of a chain, if you configure your INPUT chain the policy ACCEPT, all the things that you want to introduce from Mexico or Canada to US you will be allowed to do, everything.

The same with the chain OUTPUT, if you configure the policy ACCEPT you can move everything from US to Canada or Mexico, everything.

With FORWARD is the same, you can move whatever you want from Canada to Mexico using US as a bridge.

If you are running a Linux box, execute this command (you'll need root privileges):

iptables -L

You can see that your tables have this configuration:

This configuration allow all kind of traffic flow from and to your computer without restrictions.

As you can see there are the three chains INPUT, OUTPUT and FORWARD and all of them with the policy ACCEPT.

If you are using a Linux distribution like CentOS or other distro based on RedHat, it is probably you get other responses but don't worry, in the next posts we will see whats it's meaning and how to work with them.

Conclusion

In this first part of the introduction, we know there are three basic elements to understand to work in iptables Policies, Chains and Rules.

Policies are the Chains' default rule (the no write rule in each chain). But we can create rules in each chain to create exemptions to the policies.

Both the policies and the rules have three possible states ACCEPT, DROP and REJECT 

To show the configuration of the iptable we use the command iptables -L as root 

To finish this first part of the introduction, let me ask you something... What happens if we change the chains' policy to DROP?

Connect a Raspberry Pi to a wpa enterprise network

Configure a WiFi network protected with WPA2 in Raspberry Pi is as simple as running the configuration tool raspi-config in Raspberry Pi OS, but the thinks are different when you try to configure a WPA Enterprise WiFi Network.

First, you need to run the automatic raspi-conf tool to generate the file /etc/wpa_supplicant/wpa_supplicant.conf. You can use dummy info in this steep. After you will have a file with the following content.

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=[Contry code]
network={
ssid="[SSID configurated with raspi-config]"
        psk ="[Password configurated with raspi-config]"
}

Second, change the content of the file as follow:

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=[Contry code]
network={
ssid="[SSID configurated with raspi-config]"
key_mgmt=WPA-EAP
        eap=PEAP
        identity="[User name]"
        password="[password]"
phase2="MSCHAPV2"
}

Third, It is probably that this configuration could be all to connect to the WiFi network, but if your Rasberry Pi, don't negotiate a DHCP configuration, you need to include the following lines at the end of /etc/dhcpcd.conf

interface wlan0

env ifwireless=1

env wpa_supplicant_driver=wext

This last step avoid include a file into /etc/network/interfaces.d/ and avoid the conflict between interfaces and dhcpcd, and leave dhcpcd (pre configurated in Rasberry Pi OS), manage the interface configuration.  

Ansible as a security tool

I'm on the path to learning ansible, but in this short time I found some interesting characteristics about these tools that could help in the process to implement an security framework like ISO-27002 or PCI-DSS.

Eliminate default or weak configurations. Ansible is not enough smart to identify the correct configuration for services, in this case, it is important the experience of the administrator to identify the correct changes to keep it secure. Ansible helps no only to centralize the configuration, even help to implement these configurations around the infrastructure without leaving any system out.

Generate secure baselines. Once you have a playlist ready to probation a server or a service, it can be used to keep the same base configuration to the rest of the infrastructure. In the case of need to modify a configuration, it can be done using the playlist and leave it ready for the next provision. Another advantage is that the playlist auto document the configuration. 

Maintain an updated assets inventory. The inventories are the cornerstone of Ansible. It is not only a list of hosts under the control of Ansible but the administrator can also generate groups to identify hosts easily. Another advantage is that these inventories can be generated automatically. 

But Ansible is not only hunky-dory. There are som important characteristics that if are not well managed could be a security risk.

User access to manage services. Ansible allows access to the host using even privileged used account. Probably this is the easer practice, but not the best. It is important to manage the ssh service to avoid Ansible log in as root user. and use unprivileged accounts to access and escalate privileges using become.

Protect the account where you are running ansible.  Like any other digital tool, like your email client, the person seat in front of the computer could have access to Ansible, and perform any action. It's important to keep secure the computer where you use Asinbile. Block the screen when you don't attend it. Use a strong password o passphrase and keep it updated.

If you are using Ansible and identify any other advantage or how you can improve its security, share with us your thoughts and leave a comment to help me and others to learn more about this important tool.