IP address and port restrictions to Ubuntu

Introduction

I had never set the firewall of Ubuntu, so I checked the command to see if it behaved as expected.

environment

[Host OS] ・ Ubuntu 18.04 LTS (on GCP)

How to set IP address / port restrictions

1. 1. Check the connection from the local PC to each port
2. 2. Firewall settings using the ufw command
3. 3. Connection restrictions using /etc/hosts.allow and /etc/hosts.deny

1. 1. Check the connection from the local PC to each port

First, make each service accessible from your local PC.

・ Telnet connection (default port: 23) -SSH connection (default port: 22)

• Refer to here for SSH connection to the VM instance of GCP. ・ Http access (port: 80)

※Advance preparation -Allow the above port connection to the global IP of the local PC from the firewall settings on GCP. -Execute the following to confirm http access.

python

#Update your package management tool to the latest
$ sudo apt update
$ sudo apt -y upgrade

#Apache installation
$ sudo apt install -y apache2

2. 2. Firewall settings using the ufw command

Check the default firewall status

python

$ sudo ufw status
Status: inactiveufw status

⇒ It is inactive by default.

First, allow SSH connections and try enabling the firewall.

python

$ sudo ufw allow ssh
Rule added
Rule added (v6)
#sudo ufw allow 22 ← Same with this command

$ sudo ufw enable
Rule added

$ sudo ufw status
Status: active
To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere                  
22/tcp (v6)                ALLOW       Anywhere (v6) 

• Note that the default is all deny, so if you enable it without setting any IP or port, you may not be able to enter it.

Of course, if you try to access http in this state, you can't.

Will this setting remain in effect after a reboot?

python

#Run again after reboot
$ sudo ufw status
Status: active
To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere                  
22/tcp (v6)                ALLOW       Anywhere (v6)         

It seems unlikely that the rules will disappear even after restarting.

A writing method that allows communication only with a specific IP address.

python

$ sudo ufw allow from xxx.xxx.xxx.xxx to any port 22
Rule added

$ sudo ufw reload
Firewall reloaded

$ sudo ufw status
Status: active
To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere                  
22/tcp                     ALLOW       xxx.xxx.xxx.xxx        
22/tcp (v6)                ALLOW       Anywhere (v6) 

How to write rule deletion.

python

$ sudo ufw delete allow from xxx.xxx.xxx.xxx to any port ssh
#If you want to allow at the network level,[from xxx.xxx.xxx.0/24 to]It's OK to write like this.
Rule deleted

$ sudo ufw status
Status: active
To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere                  
22/tcp (v6)                ALLOW       Anywhere (v6) 

3. 3. Connection restrictions using /etc/hosts.allow and /etc/hosts.deny

Basically, TCP Wrapper (tcpd daemon) uses /etc/hosts.allow to check the service connection permission information of the client in order to control access to the daemon started via the super daemon (xinetd). It refers to the host access file in /etc/hosts.deny. However, there are some that can control access even if they do not go through a super daemon such as "sshd".

• Before inetd (xinetd) calls each daemon, refer to the list of permission and non-permission (/etc/hosts.allow, /etc/hosts.deny file), and if permitted, start the corresponding daemon. ing. Since inted itself does not have an access control function, access control was performed in combination with this tcpd. However, tcpd access control was based only on the IP address of the connection destination, and it was only possible to monitor TCP ports used via inetd. Therefore, access control of tcpd is quite limited, and xinetd has come to be used as a super server that can make more detailed settings.

The rules seem to be as follows.

** (1) Allow access from the hosts described in /etc/hosts.allow (2) If 1 is not applicable, access from the host described in /etc/hosts.deny is denied. (3) If neither 1 nor 2 is applicable, all access is permitted **

SSH connection

If you try the SSH connection settings as follows, check if you can not connect from the local PC.

/etc/hosts.allow

ALL  127.0.0.1
sshd :[Internal IP of VM instance]

/etc/hosts.deny

ALL : ALL

There was no particular restart of services or systems, and I could not connect from the local PC.

• Since it is not cut off by the firewall, it is possible to enter user input and passphrase, but after that the connection cannot be established successfully.

After editing /etc/hosts.allow as shown below, check if you can connect from your local PC.

/etc/hosts.allow

ALL  127.0.0.1
sshd :[Internal IP of VM instance],[Global IP of local PC]

As expected, SSH connection is now possible.

http connection

If you check the http connection in the same way with the above settings, you can see this.

The reason is that the services that TCP Wrappers control are "TCP-wrapped services" and the http service is not included there.

(Reference 1) https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/6/html/security_guide/sect-security_guide-tcp_wrappers_and_xinetd-tcp_wrappers_configuration_files

(Reference 2) https://nwengblog.com/rhel-tcpwrapper/

Supplement

Services wrapped in TCP can be checked as follows.

python

#When checking about the sshd service
$ ldd /usr/sbin/sshd | grep libwrap
        libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f0cb589d000)

#apache2 service(http)When checking about
$ ldd /usr/sbin/apache2 | grep libwrap
  #No output.

• Since it is set for each library, it seems difficult to check it as a list.