Configuring firewalld on Linux systems – zone creation

Firewalld is the default firewall module on newer Linux distributions that replaced its ancestor iptables.

One of its biggest advantage is firewall-cmd tool that makes easy to configure your own policies/zones through command line.

When installed, firewalld should be enabled and started.

systemctl enable firewalld; systemctl start firewalld

The default zone that is configured after installation is public on which the default network interface is added.

You can get a list of services allowed with the command:

firewall-cmd --zone=public --list-all

For the sake of the article we will create a new zone and allow some services on it.

Create a new zone with:

firewall-cmd --permanent --new-zone=custom

Make custom zone your default:

firewall-cmd --set-default-zone=custom

Reload firewalld module so that changes take place. Everytime you need to change a firewall setting a reload must take place.

systemctl reload firewalld

Add a custom ssh or application port on your created zone

firewall-cmd --permanent --add-port=11233/tcp --zone=custom

Add a build in service with a known port:

firewall-cmd --permanent --add-service=https --zone=custom

Add an IP address that could access your zone:

firewall-cmd --permanent --zone=custom --add-source=192.168.1.254

Restrict public IP addresses on ssh – Redhat/centOS 8 edition

I have explained on a previous article how to restrict public IP addresses on redhat 7 systems through /etc/hosts.allow and /etc/hosts.deny files. As RedHat explains this is not an option anymore on RHEL8 and this should be enforced by the firewalld package.

You can find the detailed article here

However you can implement the same behavior through sshd configuration with AllowUsers setting.

Edit your /etc/ssh/sshd_config file and add a rule. My created one allows all users to login but only from the specified public IP addresses. If I try to login from another location I will get rejected.

AllowUsers *@public_IP

A more detailed explanation on how to use AllowUsers to block users or groups can be found here.

Testing the behavior with a non allowed IP address will reject me although the key is correct.

The login attempt is logged on the system and can be found with the below command:

 ausearch --message USER_LOGIN --success no --interpret

proxy server used to verify if connection attempt is successful.

You can also integrate fail2ban package in order to block more than X login attempts from malicious users.

Cisco switch flooded with MAC Addresses VMware Distributed switch

Recently a client had a problem with some VM’s on its infrastructure. In more detail it was detected that some packets were missing/not transmitting correctly to some virtual servers.

The investigation of the vendor (Cisco) showed that the problem was due to a hard limitation of MAC addresses on the switch. It seemed that a limitation of 70.000 MAC addresses created this problem. But how so many addresses have been created on VMware infrastructure?

In the infrastructure two new chassis with Flex nodes have been added. Those chassis contain around 20 servers each that were included in the virtual Distributed switch. In the vDS existed around 210 VLAN’s. Everytime a new chassis was active on the switch around 3000 new MAC addresses created. This number is approximately the number of VLANs x host number = 20 x 210 = 4200

The problem occurred due to Distributed switch health check mechanism. As VMware states:

vSphere Distributed Switch health check helps you identify and troubleshoot configuration problems with the vSphere Distributed Switch (VDS), and mismatched configurations between the VDS and your environment’s physical network. By default, health check is turned off. You can enable health check to identify and resolve network problems you might be experiencing. Depending on the options that you select, vSphere Distributed Switch health check can generate a significant number of MAC addresses for testing teaming policy, MTU size, and VLAN configuration. These MAC addresses result in extra network traffic, which can affect network performance.

Important:

Use health check to troubleshoot network problems, and then disable it after you identify and resolve the problem. After you disable vSphere Distributed Switch health check, the generated MAC addresses age out of your physical network environment according to your network policy. For more information, see Knowledge Base article KB 2034795.

As a result only enable virtual distributed switch health check mechanism for troubleshooting and disable on production environments as it may cause problems on your VM’s.

https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.networking.doc/GUID-6D155482-0743-4252-A8DC-3F608AB3654A.html