Monday, 22 February 2021

Linux Admin - Set Up Perl for CentOS Linux

 Perl has been around for a long time. It was originally designed as a reporting language used for parsing text files. With increased popularity, Perl has added a module support or CPAN, sockets, threading, and other features needed in a powerful scripting language.

The biggest advantage of Perl over PHP, Python, or Ruby is: it gets things done with minimal fuss. This philosophy of Perl does not always mean it gets things done the right way. However, for administration tasks on Linux, Perl is considered as the go-to choice for a scripting language.

Some advantages of Perl over Python or Ruby are −

  • Powerful text processing

  • Perl makes writing scripts quick and dirty (usually a Perl script will be several dozen lines shorter than an equivalent in Python or Ruby)

  • Perl can do anything (almost)

Some drawbacks of Perl are −

  • Syntax can be confusing

  • Coding style in Perl can be unique and bog down collaboration

  • Perl is not really Object Oriented

  • Typically, there isn't a lot of thought put into standardization and best-practice when Perl is used.

When deciding whether to use Perl, Python or PHP; the following questions should be asked −

  • Will this application ever need versioning?
  • Will other people ever need to modify the code?
  • Will other people need to use this application?
  • Will this application ever be used on another machine or CPU architecture?

If the answers to all the above are "no", Perl is a good choice and may speed things up in terms of end-results.

With this mentioned, let's configure our CentOS server to use the most recent version of Perl.

Before installing Perl, we need to understand the support for Perl. Officially, Perl is only supported far back as the last two stable versions. So, we want to be sure to keep our development environment isolated from the CentOS version.

The reason for isolation is: if someone releases a tool in Perl to the CentOS community, more than likely it will be modified to work on Perl as shipped with CentOS. However, we also want to have the latest version installed for development purposes. Like Python, CentOS ships Perl focused on the reliability and not cutting edge.

Let's check our current version of Perl on CentOS 7.

[root@CentOS]# perl -v 
This is perl 5, version 16, subversion 3 (v5.16.3) built for x86_64-linux-thread-multi

We are currently running Perl 5.16.3. The most current version as of this writing is: perl-5.24.0

We definitely want to upgrade our version, being able to use up-to-date Perl modules in our code. Fortunately, there is a great tool for maintaining Perl environments and keeping our CentOS version of Perl isolated. It is called perlbrew.

Let's install Perl Brew.

[root@CentOS]# curl -L https://install.perlbrew.pl | bash 
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current 
                             Dload  Upload   Total   Spent    Left  Speed 
100   170  100   170    0     0    396      0 --:--:-- --:--:-- --:--:--   397 
100  1247  100  1247    0     0   1929      0 --:--:-- --:--:-- --:--:--  1929

Now that we have Perl Brew installed, let's make an environment for the latest version of Perl.

First, we will need the currently installed version of Perl to bootstrap the perlbrew install. Thus, let's get some needed Perl modules from the CentOS repository.

Note − When available we always want to use CentOS Perl modules versus CPAN with our CentOS Perl installation.

Step 1 − Install CentOS Perl Make::Maker module.

[root@CentOS]# yum -y install perl-ExtUtils-MakeMaker.noarch

Step 2 − Install the latest version of perl.

[root@CentOS build]# source ~/perl5/perlbrew/etc/bashrc
[root@CentOS build]# perlbrew install -n -j4 --threads perl-5.24.1

The options we chose for our Perl install are −

  • n − No tests

  • j4 − Execute 4 threads in parallel for the installation routines (we are using a quadcore CPU)

  • threads − Enable threading support for Perl

After our installation has been performed successfully, let's switch to our newest Perl environment.

[root@CentOS]# ~/perl5/perlbrew/bin/perlbrew use perl-5.24.1

A sub-shell is launched with perl-5.24.1 as the activated perl. Run 'exit' to finish it.

[root@CentOS]# perl -v

This is perl 5, version 24, subversion 1 (v5.24.1) built for x86_64-linuxthread-multi

(with 1 registered patch, see perl -V for more detail)

Copyright 1987-2017, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the GNU General
Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on this system 
using "man perl" or "perldoc perl".  If you have access to the Internet, point your 
browser at http://www.perl.org/, the Perl Home Page.

[root@CentOS]#

Simple perl script printing perl version running within the context of our perlbrew environment −

[root@CentOS]# cat ./ver.pl  
#!/usr/bin/perl
print $^V . "\n";

[root@CentOS]# perl ./ver.pl  
v5.24.1 
[root@CentOS]#

Once perl is installed, we can load cpan modules with perl brew's cpanm −

[root@CentOS]# perl-brew install-cpanm

Now let's use the cpanm installer to make the LWP module with our current Perl version of 5.24.1 in perl brew.

Step 1 − Switch to the context of our current Perl version.

[root@CentOS ~]# ~/perl5/perlbrew/bin/perlbrew use perl-5.24.1

A sub-shell is launched with perl-5.24.1 as the activated perl. Run 'exit' to finish it.

[root@CentOS ~]#

Step 2 − Install LWP User Agent Perl Module.

[root@CentOS ~]# ~/perl5/perlbrew/bin/cpanm -i LWP::UserAgent

Step 3 − Now let's test our Perl environment with the new CPAN module.

[root@CentOS ~]# cat ./get_header.pl  
#!/usr/bin/perl 
use LWP; 
my $browser = LWP::UserAgent->new(); 
my $response = $browser->get("http://www.slcc.edu/"); 
unless(!$response->is_success) { 
   print $response->header("Server"); 
}

[root@CentOS ~]# perl ./get_header.pl  
Microsoft-IIS/8.5 [root@CentOS ~]#

There you have it! Perl Brew makes isolating perl environments a snap and can be considered as a best practice as things get with Perl.

Configure Ruby on CentOS Linux

 Ruby is a great language for both web development and Linux Administration. Ruby provides many benefits found in all the previous languages discussed: PHP, Python, and Perl.

To install Ruby, it is best to bootstrap through the rbenv which allows the administrators to easily install and manage Ruby Environments.

The other method for installing Ruby is the standard CentOS packages for Ruby. It is advisable to use the rbenv method with all its benefits. CentOS packages will be easier for the non-Ruby savvy.

First, let's get some needed dependencies for rbenv installer.

  • git-core
  • zlib
  • zlib-devel
  • gcc-c++
  • patch
  • readline
  • readline-devel
  • libyaml-devel
  • libffi-devel
  • openssl-devel
  • make
  • bzzip2
  • autoconf
  • automake
  • libtool
  • bison
  • curl
  • sqlite-devel

Most of these packages may already be installed depending on the chosen options and roles when installing CentOS. It is good to install everything we are unsure about as this can lead to less headache when installing packages requiring dependencies.

[root@CentOS]# yum -y install git-core zlib zlib-devel gcc-c++ patch readline 
readline-devel libyaml-devel libffi-devel openssl-devel make bzip2 autoconf 
automake libtool bison curl sqlite-devel 

Method 1 − rbenv for Dynamic Ruby Development Environments

Now as the user who will be using Ruby −

[rdc@CentOS ~]$ git clone https://github.com/rbenv/rbenv.git
[rdc@CentOS ~]$  https://github.com/rbenv/ruby-build.git

ruby-build will provide installation features to rbenv −

Note − We need to switch to root or an administration user before running install.sh

[rdc@CentOS ruby-build]$ cd ~/ruby-build
[rdc@CentOS ruby-build]# ./install.sh

Let's set our shell for rbenv and assure we have installedthe correct options.

[rdc@CentOS ~]$ source ~/rbenv/rbenv.d/exec/gem-rehash.bash

[rdc@CentOS ruby-build]$ ~/rbenv/bin/rbenv  
rbenv 1.1.0-2-g4f8925a 
Usage: rbenv <command> [<args>]

Some useful rbenv commands are −

CommandsAction
localSets or shows the local application-specific Ruby version
globalSets or shows the global Ruby version
shellSets or shows the shell-specific Ruby version
installInstalls a Ruby version using ruby-build
uninstallUninstalls a specific Ruby version
rehashRehashes rbenv shims (run this after installing executables)
versionShows the current Ruby version and its origin
versionsLists all Ruby versions available to rbenv
whichDisplays the full path to an executable
whenceLists all Ruby versions that contain the given executable

Let's now install Ruby −

[rdc@CentOS bin]$ ~/rbenv/bin/rbenv install -v 2.2.1

After compilation completes −

[rdc@CentOS ~]$ ./ruby -v 
ruby 2.2.1p85 (2015-02-26 revision 49769) [x86_64-linux] 
[rdc@CentOS ~]$

We now have a working Ruby environment with an updated and working version of Ruby 2.X branch.

Method 2 − Install Ruby from CentOS Packages

This is the most simple method. However, it can be limited by the version and gems packaged from CentOS. For serious development work, it is highly recommended to use the rbenv method to install Ruby.

Install Ruby, needed development packages, and some common gems.

[root@CentOS rdc]# yum install -y ruby.x86_64 ruby-devel.x86_64 ruby-
libs.x86_64 ruby-gem-json.x86_64 rubygem-rake.noarch

Unfortunately, we are left with somewhat outdated version of Ruby.

[root@CentOS rdc]# ruby -v 
ruby 2.0.0p648 (2015-12-16) [x86_64-linux]
[root@CentOS rdc]#

Set Up Python with CentOS Linux

 Python is a widely used interpreted language that has brought professionalism to the world of coding scripted applications on Linux (and other operating systems). Where Perl was once the industry standard, Python has surpassed Perl in many respects.

Some strengths of Python versus Perl are −

  • Rapid progression in refinement

  • Libraries that are standard to the language

  • Readability of the code is thought out in language definition

  • Many professional frameworks for everything from GUI support to web-development

Python can do anything Perl can do, and in a lot of cases in a better manner. Though Perl still has its place amongst the toolbox of a Linux admin, learning Python is a great choice as a skill set.

The biggest drawbacks of Python are sometimes related to its strengths. In history, Python was originally designed to teach programming. At times, its core foundations of "easily readable" and "doing things the right way" can cause unnecessary complexities when writing a simple code. Also, its standard libraries have caused problems in transitioning from versions 2.X to 3.X.

Python scripts are actually used at the core of CentOS for functions vital to the functionality of the operating system. Because of this, it is important to isolate our development Python environment from CentOS' core Python environment.

For starters, there are currently two versions of Python − Python 2.X and Python 3.X.

Both stages are still in active production, though version 2.X is quickly closing in on depreciation (and has been for a few years). The reason for the two active versions of Python was basically fixing the shortcomings of version 2.X. This required some core functionality of version 3.X to be redone in ways it could not support some version 2.X scripts.

Basically, the best way to overcome this transition is − Develop for 3.X and keep up with the latest 2.X version for legacy scripts. Currently, CentOS 7.X relies on a semi-current revision of version 2.X.

As of this writing, the most current versions of Python are − 3.4.6 and 2.7.13.

Don't let this confuse or draw any conclusions of Python. Setting up a Python environment is really pretty simple. With Python frameworks and libraries, this task is actually really easy to accomplish.

Before setting up our Python environments, we need a sane environment. To start, let's make sure our CentOS install is fully updated and get some building utilities installed.

Step 1 − Update CentOS.

[root@CentOS]# yum -y update

Step 2 − Install build utilities.

[root@CentOS]# yum -y groupinstall "development tools"

Step 3 − Install some needed packages.

[root@CentOS]# yum install -y zlib-dev openssl-devel sqlite-devel bip2-devel

Now we need to install current Python 2.X and 3.X from source.

  • Download compressed archives
  • Extract files
  • Compile source code

Let's start by creating a build directory for each Python install in /usr/src/

[root@CentOS]# mkdir -p /usr/src/pythonSource

Now let's download the source tarballs for each −

[root@CentOS]# wget https://www.python.org/ftp/python/2.7.13/Python-2.7.13.tar.xz
[root@CentOS]# wget https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz

Now we need to extract each from the archive.

Step 1 − Install xz-libs and extract the tarballs.

[root@CentOS]# yum install xz-libs
[root@CentOS python3]# xz -d ./*.xz
[root@CentOS python3]# ls
Python-2.7.13.tar  Python-3.6.0.tar
[root@CentOS python3]#

Step 2 − Untar each installer from its tarball.

[root@CentOS]# tar -xvf ./Python-2.7.13.tar
[root@CentOS]# tar -xvf ./Python-3.6.0.tar

Step 3 − Enter each directory and run the configure script.

[root@CentOS]# ./configure --prefix=/usr/local 
root@CentOS]# make altinstall

Note − Be sure to use altinstall and not install. This will keep CentOS and development versions of Python separated. Otherwise, you may break the functionality of CentOS.

You will now see the compilation process begins. Grab a cup of coffee and take a 15minute break until completion. Since we installed all the needed dependencies for Python, the compilation process should complete without error.

Let's make sure we have the latest 2.X version of Python installed.

[root@CentOS Python-2.7.13]# /usr/local/bin/python2.7 -V 
Python 2.7.13
[root@CentOS Python-2.7.13]#

Note − You will want to prefix the shebang line pointing to our development environment for Python 2.X.

[root@CentOS Python-2.7.13]# cat ver.py  
#!/usr/local/bin/python2.7 
import sys 
print(sys.version)

[root@CentOS Python-2.7.13]# ./ver.py 
2.7.13 (default, Jan 29 2017, 02:24:08)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-11)]

Just like that, we have separate Python installs for versions 2.X and 3.X. From here, we can use each and utilities such as pip and virtualenv to further ease the burden of managing Python environments and package installation.

Configure PHP in CentOS Linux

 PHP is the one of the most prolific web languages in use today. Installing a LAMP Stack on CentOS is something every system administrator will need to perform, most likely sooner than later.

A traditional LAMP Stack consists of (L)inux (A)pache (M)ySQL (P)HP.

There are three main components to a LAMP Stack on CentOS −

  • Web Server
  • Web Development Platform / Language
  • Database Server

Note − The term LAMP Stack can also include the following technologies: PostgreSQL, MariaDB, Perl, Python, Ruby, NGINX Webserver.

For this tutorial, we will stick with the traditional LAMP Stack of CentOS GNU Linux: Apache web server, MySQL Database Server, and PHP.

We will actually be using MariaDB. MySQL configuration files, databases and tables are transparent to MariaDB. MariaDB is now included in the standard CentOS repository instead of MySQL. This is due to the limitations of licensing and open-source compliance, since Oracle has taken over the development of MySQL.

The first thing we need to do is install Apache.

[root@CentOS]# yum install httpd
Loaded plugins: fastestmirror, langpacks
base
| 3.6 kB  00:00:00
extras
| 3.4 kB  00:00:00
updates
| 3.4 kB  00:00:00
extras/7/x86_64/primary_d
| 121 kB  00:00:00
Loading mirror speeds from cached hostfile
* base: mirror.sigmanet.com
* extras: linux.mirrors.es.net
* updates: mirror.eboundhost.com
Resolving Dependencies
--> Running transaction check
---> Package httpd.x86_64 0:2.4.6-45.el7.centos will be installed
--> Processing Dependency: httpd-tools = 2.4.6-45.el7.centos for package:
httpd-2.4.6-45.el7.centos.x86_64
--> Processing Dependency: /etc/mime.types for package: httpd-2.4.645.el7.centos.x86_64
--> Running transaction check
---> Package httpd-tools.x86_64 0:2.4.6-45.el7.centos will be installed
---> Package mailcap.noarch 0:2.1.41-2.el7 will be installed
--> Finished Dependency Resolution
Installed:
httpd.x86_64 0:2.4.6-45.el7.centos

Dependency Installed:
httpd-tools.x86_64 0:2.4.6-45.el7.centos
mailcap.noarch 0:2.1.41-2.el7

Complete!
[root@CentOS]#

Let's configure httpd service.

[root@CentOS]# systemctl start httpd && systemctl enable httpd

Now, let's make sure the web-server is accessible through firewalld.

bash-3.2# nmap -sS -p 1-1024 -T 5  -sV 10.211.55.1 
Starting Nmap 7.30 ( https://nmap.org ) at 2017-01-28 02:00 MST 
Nmap scan report for centos.shared (10.211.55.1) 
Host is up (0.00054s latency). 
Not shown: 1022 filtered ports 
PORT   STATE SERVICE VERSION 
22/tcp open  ssh     OpenSSH 6.6.1 (protocol 2.0) 
80/tcp open  http    Apache httpd 2.4.6 ((CentOS))

Service detection performed. Please report any incorrect results at 
https://nmap.org/submit/ . 
Nmap done: 1 IP address (1 host up) scanned in 10.82 seconds bash-3.2#

As you can see by the nmap service probe, Apache webserver is listening and responding to requests on the CentOS host.

Install MySQL Database Server

[root@CentOS rdc]# yum install mariadb-server.x86_64 && yum install mariadb-
devel.x86_64 && mariadb.x86_64 && mariadb-libs.x86_64

We are installing the following repository packages for MariaDB −

mariadb-server.x86_64

The main MariaDB Server daemon package.

mariadb-devel.x86_64

Files need to compile from the source with MySQL/MariaDB compatibility.

mariadb.x86_64

MariaDB client utilities for administering MariaDB Server from the command line.

mariadb-libs.x86_64

Common libraries for MariaDB that could be needed for other applications compiled with MySQL/MariaDB support.

Now, let's start and enable the MariaDB Service.

[root@CentOS]# systemctl start mariadb 
[root@CentOS]# systemctl enable  mariadb

Note − Unlike Apache, we will not enable connections to MariaDB through our host-based firewall (firewalld). When using a database server, it's considered best security practice to only allow local socket connections, unless the remote socket access is specifically needed.

Let's make sure the MariaDB Server is accepting connections.

[root@CentOS#] netstat -lnt 
Active Internet connections (only servers) 
Proto     Recv-Q     Send-Q     Local Address        Foreign Address      State       
tcp            0          0     0.0.0.0:3306         0.0.0.0:*            LISTEN      
tcp            0          0     0.0.0.0:111          0.0.0.0:*            LISTEN      
tcp            0          0     192.168.122.1:53     0.0.0.0:*            LISTEN      
tcp            0          0     0.0.0.0:22           0.0.0.0:*            LISTEN      
tcp            0          0     127.0.0.1:631        0.0.0.0:*            LISTEN      
tcp            0          0     127.0.0.1:25         0.0.0.0:*            LISTEN 
     
[root@CentOS rdc]#

As we can see, MariaDB is listening on port 3306 tcp. We will leave our host-based firewall (firewalld) blocking incoming connections to port 3306.

Install and Configure PHP

[root@CentOS#]  yum install php.x86_64 && php-common.x86_64 && php-mysql.x86_64 
&& php-mysqlnd.x86_64 && php-pdo.x86_64 && php-soap.x86_64 && php-xml.x86_64

I'd recommend installing the following php packages for common compatibility −

  • php-common.x86_64
  • php-mysql.x86_64
  • php-mysqlnd.x86_64
  • php-pdo.x86_64
  • php-soap.x86_64
  • php-xml.x86_64
[root@CentOS]# yum install -y php-common.x86_64 php-mysql.x86_64 php-
mysqlnd.x86_64 php-pdo.x86_64 php-soap.x86_64 php-xml.x86_64

This is our simple php file located in the Apache webroot of /var/www/html/

[root@CentOS]# cat /var/www/html/index.php  
<html> 
   <head> 
      <title>PHP Test Page</title> 
   </head>
   
   <body> 
      PHP Install 
      <?php 
         echo "We are now running PHP on GNU Centos Linux!<br />" 
      ?> 
   </body> 
</html>

[root@CentOS]#

Let's change the owning group of our page to the system user our http daemon is running under.

[root@CentOS]# chgrp httpd /var/www/html/index.php && chmod g+rx /var/www/html/index.php
---

When requested manually via ncat.

bash-3.2# ncat 10.211.55.1 80 
   GET / index.php 
   HTTP/1.1 200 OK 
   Date: Sat, 28 Jan 2017 12:06:02 GMT 
   Server: Apache/2.4.6 (CentOS) PHP/5.4.16 
   X-Powered-By: PHP/5.4.16 
   Content-Length: 137 
   Connection: close 
   Content-Type: text/html; charset=UTF-8
   
<html> 
   <head> 
      <title>PHP Test Page</title> 
   </head>
   
   <body> 
      PHP Install 
      We are now running PHP on GNU Centos Linux!<br />
   </body> 
</html>

bash-3.2#

PHP and LAMP are very popular web-programming technologies. LAMP installation and configuration is sure to come up on your list of needs as a CentOS Administrator. Easy to use CentOS packages have taken a lot of work from compiling Apache, MySQL, and PHP from the source code.

Linux Admin - Firewall Setup

 firewalld is the default front-end controller for iptables on CentOS. The firewalld front-end has two main advantages over raw iptables −

  • Uses easy-to-configure and implement zones abstracting chains and rules.

  • Rulesets are dynamic, meaning stateful connections are uninterrupted when the settings are changed and/or modified.

Remember, firewalld is the wrapper for iptables - not a replacement. While custom iptables commands can be used with firewalld, it is recommended to use firewalld as to not break the firewall functionality.

First, let's make sure firewalld is both started and enabled.

[root@CentOS rdc]# systemctl status firewalld 
● firewalld.service - firewalld - dynamic firewall daemon 
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled) 
Active: active (running) since Thu 2017-01-26 21:42:05 MST; 3h 46min ago 
 Docs: man:firewalld(1) 
Main PID: 712 (firewalld) 
  Memory: 34.7M 
 CGroup: /system.slice/firewalld.service 
       └─712 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid

We can see, firewalld is both active (to start on boot) and currently running. If inactive or not started we can use −

systemctl start firewalld && systemctl enable firewalld

Now that we have our firewalld service configured, let's assure it is operational.

[root@CentOS]# firewall-cmd --state 
running 
[root@CentOS]#

We can see, the firewalld service is fully functional.

Firewalld works on the concept of zones. A zone is applied to network interfaces through the Network Manager. We will discuss this in configuring networking. But for now, by default, changing the default zone will change any network adapters left in the default state of "Default Zone".

Let's take a quick look at each zone that comes out-of-the-box with firewalld.

Sr.No.Zone & Description
1

drop

Low trust level. All incoming connections and packetsare dropped and only outgoing connections are possible via statefullness

2

block

Incoming connections are replied with an icmp message letting the initiator know the request is prohibited

3

public

All networks are restricted. However, selected incoming connections can be explicitly allowed

4

external

Configures firewalld for NAT. Internal network remains private but reachable

5

dmz

Only certain incoming connections are allowed. Used for systems in DMZ isolation

6

work

By default, trust more computers on the network assuming the system is in a secured work environment

7

hone

By default, more services are unfiltered. Assuming a system is on a home network where services such as NFS, SAMBA and SSDP will be used

8

trusted

All machines on the network are trusted. Most incoming connections are allowed unfettered. This is not meant for interfaces exposed to the Internet

The most common zones to use are:public, drop, work, and home.

Some scenarios where each common zone would be used are −

  • public − It is the most common zone used by an administrator. It will let you apply the custom settings and abide by RFC specifications for operations on a LAN.

  • drop − A good example of when to use drop is at a security conference, on public WiFi, or on an interface connected directly to the Internet. drop assumes all unsolicited requests are malicious including ICMP probes. So any request out of state will not receive a reply. The downside of drop is that it can break the functionality of applications in certain situations requiring strict RFC compliance.

  • work − You are on a semi-secure corporate LAN. Where all traffic can be assumed moderately safe. This means it is not WiFi and we possibly have IDS, IPS, and physical security or 802.1x in place. We also should be familiar with the people using the LAN.

  • home − You are on a home LAN. You are personally accountable for every system and the user on the LAN. You know every machine on the LAN and that none have been compromised. Often new services are brought up for media sharing amongst trusted individuals and you don't need to take extra time for the sake of security.

Zones and network interfaces work on a one to many level. One network interface can only have a single zone applied to it at a time. While, a zone can be applied to many interfaces simultaneously.

Let's see what zones are available and what are the currently applied zone.

[root@CentOS]# firewall-cmd --get-zones 
 work drop internal external trusted home dmz public block

[root@CentOS]# firewall-cmd --get-default-zone 
public
[root@CentOS]#

Ready to add some customized rules in firewalld?

First, let's see what our box looks like, to a portscanner from outside.

bash-3.2# nmap -sS -p 1-1024 -T 5  10.211.55.1
 
Starting Nmap 7.30 ( https://nmap.org ) at 2017-01-27 23:36 MST 
Nmap scan report for centos.shared (10.211.55.1) 
Host is up (0.00046s latency). 
Not shown: 1023 filtered ports 
PORT   STATE SERVICE 
22/tcp open  ssh


Nmap done: 1 IP address (1 host up) scanned in 3.71 seconds 
bash-3.2#

Let's allow the incoming requests to port 80.

First, check to see what zone is applied as default.

[root@CentOs]# firewall-cmd --get-default-zone 
public
[root@CentOS]#

Then, set the rule allowing port 80 to the current default zone.

[root@CentOS]# firewall-cmd --zone=public --add-port = 80/tcp 
success
[root@CentOS]#

Now, let's check our box after allowing port 80 connections.

bash-3.2# nmap -sS -p 1-1024 -T 5  10.211.55.1

Starting Nmap 7.30 ( https://nmap.org ) at 2017-01-27 23:42 MST 
Nmap scan report for centos.shared (10.211.55.1) 
Host is up (0.00053s latency). 
Not shown: 1022 filtered ports 
PORT   STATE  SERVICE 
22/tcp open   ssh 
80/tcp closed http

Nmap done: 1 IP address (1 host up) scanned in 3.67 seconds 
bash-3.2#

It now allows unsolicited traffic to 80.

Let's put the default zone to drop and see what happens to port scan.

[root@CentOS]# firewall-cmd --set-default-zone=drop 
success

[root@CentOS]# firewall-cmd --get-default-zone 
drop

[root@CentOs]#

Now let's scan the host with the network interface in a more secure zone.

bash-3.2# nmap -sS -p 1-1024 -T 5  10.211.55.1 
Starting Nmap 7.30 ( https://nmap.org ) at 2017-01-27 23:50 MST 
Nmap scan report for centos.shared (10.211.55.1) 
Host is up (0.00094s latency). 
All 1024 scanned ports on centos.shared (10.211.55.1) are filtered

Nmap done: 1 IP address (1 host up) scanned in 12.61 seconds 
bash-3.2#

Now, everything is filtered from outside.

As demonstrated below, the host will not even respond to ICMP ping requests when in drop.

bash-3.2# ping 10.211.55.1 
PING 10.211.55.1 (10.211.55.1): 56 data bytes 
Request timeout for icmp_seq 0 
Request timeout for icmp_seq 1 
Request timeout for icmp_seq 2

Let's set the default zone to public again.

[root@CentOs]# firewall-cmd --set-default-zone=public 
success

[root@CentOS]# firewall-cmd --get-default-zone 
public

[root@CentOS]#

Now let's check our current filtering ruleset in public.

[root@CentOS]# firewall-cmd --zone=public --list-all 
public (active) 
target: default 
icmp-block-inversion: no 
interfaces: enp0s5 
sources:  
services: dhcpv6-client ssh 
ports: 80/tcp 
protocols:  
masquerade: no 
forward-ports:  
sourceports:  
icmp-blocks:  
rich rules:

[root@CentOS rdc]#

As configured, our port 80 filter rule is only within the context of the running configuration. This means once the system is rebooted or the firewalld service is restarted, our rule will be discarded.

We will be configuring an httpd daemon soon, so let's make our changes persistent −

[root@CentOS]# firewall-cmd --zone=public --add-port=80/tcp --permanent 
success

[root@CentOS]# systemctl restart firewalld

[root@CentOS]#

Now our port 80 rule in the public zone is persistent across reboots and service restarts.

Following are the common firewalld commands applied with firewall-cmd.

CommandAction
firewall-cmd --get-zonesLists all zones that can be applied to an interface
firewall-cmd —statusReturns the currents status of the firewalld service
firewall-cmd --get-default-zoneGets the current default zone
firewall-cmd --set-default-zone=<zone>Sets the default zone into the current context
firewall-cmd --get-active-zoneGets the current zones in context as applied to an interface
firewall-cmd --zone=<zone> --list-allLists the configuration of supplied zone
firewall-cmd --zone=<zone> --addport=<port/transport protocol>Applies a port rule to the zone filter
--permanentMakes changes to the zone persistent. Flag is used inline with modification commands

These are the basic concepts of administrating and configuring firewalld.

Configuring host-based firewall services in CentOS can be a complex task in more sophisticated networking scenarios. Advanced usage and configuration of firewalld and iptables in CentOS can take an entire tutorial. However, we have presented the basics that should be enough to complete a majority of daily tasks.