Optimal Security Settings on Centos

How to configure optimal IPtables security settings

CentOS has an extremely powerful firewall built in, commonly referred to as iptables, but more accurately is iptables/netfilter. Iptables is the userspace module, the bit that you, the user, interact with at the command line to enter firewall rules into predefined tables. Netfilter is a kernel module, built into the kernel, that actually does the filtering. There are many GUI front ends for iptables that allow users to add or define rules based on a point and click user interface, but these often lack the flexibility of using the command line interface and limit the users understanding of what's really happening. We're going to learn the command line interface of iptables.

Iptables places rules into predefined chains (INPUT, OUTPUT and FORWARD) that are checked against any network traffic (IP packets) relevant to those chains and a decision is made about what to do with each packet based upon the outcome of those rules, i.e. accepting or dropping the packet. These actions are referred to as targets, of which the two most common predefined targets are DROP to drop a packet or ACCEPT to accept a packet.

Chains

These are 3 predefined chains in the filter table to which we can add rules for processing IP packets passing through those chains. These chains are:

INPUT - All packets destined for the host computer.

OUTPUT - All packets originating from the host computer.

FORWARD - All packets neither destined for nor originating from the host computer, but passing through (routed by) the host computer. This chain is used if you are using your computer as a router.

For the most part, we are going to be dealing with the INPUT chain to filter packets entering our machine - that is, keeping the bad guys out.

So let us see the initial CLI commands. All of the freshly installed Centos machines have not IPTables rules defined. But just to be sure we will flush all of the settings.

iptables -F

Another rule we can add is to prevent SYN flood attacks, and to block the TCP packets that have the NULL value in the header. These packets are usually destined to DDOS the remote server.

iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP

iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

In information technology, a Christmas tree packet is a packet with every single option set for whatever protocol is in use. We should also apply a packet filter to deny the XMAS packets.

iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP

Now we can start adding selected services to our firewall filter. The first such thing is a localhost interface. We tell iptables to add (-A) a rule to the incoming (INPUT) filter table any trafic that comes to localhost interface (-i lo) and to accept (-j ACCEPT) it. Localhost is often used for, ie. your website or email server communicating with a database locally installed.

iptables -A INPUT -i lo -j ACCEPT

Now we should add some basic input chain filter for WEB and SMTP traffic.

iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT

The next thing is to allow SSH traffic for remote managament of the Centos server.

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

To wrap up the CHAIN settings we should allow ESTABLISHED connections out of the Centos Server.

iptables -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

The last setting before saving the iptables rules is to allow all OUTGOING connections and to block every other traffic towards our Centos Server.

iptables -P OUTPUT ACCEPT

iptables -P INPUT DROP

Finally , when we have done the basic setup we must save all of the settings to a file.

iptables-save /etc/sysconfig/iptables

This is all that is needed for an optimal Firewall settings. More to come.

Feel free to comment.

Useful Linux Commands

10 Useful Linux Commands

Simply put, the command line is powerful; an army of tools exist that can take what would be a tedious job in a graphical program and turn it into a task that takes just a few seconds. Removing the last four lines in every row of a large file would be a lengthy process in a graphical application, but can become trivial and automated on the command line.

Flexibility aside, it's also important to note that some Linux systems lack a graphical interface at all and that some systems may become damaged in such a way as to make it impossible to bring up anything other than the command prompt. In these cases it's important to be able to navigate on the command line with enough proficiency to perform whatever tasks need to be done from backing up some files to disabling a dying piece of hardware.

The commands used at the command line may seem a little cryptic due to their tendency to be very short. This is because the roots of the Linux command line are from systems where a single letter entry could take a significant amount of time to travel from a terminal, to a central server and back to the terminal where it was printed onto a roll of paper. In those old systems, the shorter the input was, the better, as it meant less time waiting to issue your command and receive output. The best thing you can do to remember what commands stand for is to find out what word the command is an abbreviation for. This can go a long way to remembering the command later.

1. Command is LS

The command “ls” stands for (List Directory Contents), List the contents of the folder, be it file or folder, from which it runs.

Command “ls -a“, list the content of folder, including hidden files starting with ‘.’.

2. Command is LSBLK

The “lsblk” stands for (List Block Devices), print block devices by their assigned name (but not RAM) on the standard output in a tree-like fashion.

Note: lsblk is very useful and easiest way to know the name of New Usb Device you just plugged in, especially when you have to deal with disk/blocks in terminal.

3. Command is MD5SUM

The “md5sum” stands for (Compute and Check MD5 Message Digest), md5 checksum (commonly called hash) is used to match or verify integrity of files that may have changed as a result of a faulty file transfer, a disk error or non-malicious interference.

4. Command UNAME

The “uname” command stands for (Unix Name), print detailed information about the machine name, Operating System and Kernel.

5. Command HISTORY

The “history” command stands for History (Event) Record, it prints the history of long list of executed commands in terminal.

6. Command SUDO

The “sudo” (super user do) command allows a permitted user to execute a command as the superuser or another user, as specified by the security policy in the sudoers list.

7. Command MKDIR

The “mkdir” (Make directory) command create a new directory with name path. However is the directory already exists, it will return an error message “cannot create folder, folder already exists”.

8. Command TOUCH

The “touch” command stands for (Update the access and modification times of each FILE to the current time). touch command creates the file, only if it doesn’t exist. If the file already exists it will update the timestamp and not the contents of the file.

9. Command CHMOD

The Linux “chmod” command stands for (change file mode bits). chmod changes the file mode (permission) of each given file, folder, script, etc.. according to mode asked for.

There exist 3 types of permission on a file (folder or anything but to keep things simple we will be using file).

10. Command CP

The “copy” stands for (Copy), it copies a file from one location to another location.

There are more useful commands to implement in Linux enviroment. This are some 10 basic day to day commands.

Feel free to comment.

Netapp Intial Setup

Netapp Storage Initial Setup

Before we start to setup the Netapp storage filers and appliance, one must create a Netapp NOW account. This can be done via the http://now.netapp.com web site. 

The usual waiting period is about 24/48 hours until you receive the notification email. The Now account gives you access to the documentation and the community. Depending on your license you can get the complete 24/7 support. This is very good in situations where you get stuck and do not have enough time to solve the problems with your storage. I will not provide informations on how to setup and cable the equipment in the Rack, because I am using the virtualized appliance to simulate all the setups in this blog. The initial setup would be started using the console cable, but in this scenario we are using VMware to simulate the console. When starting up the filer and connecting to the management console (serial cable, COM1 etc, all default settings if using a Windows machine with Putty) you'll see a configuration setup. Simply answer the questions, and don't be shy if you're not sure, everything can be changed afterwards.

We can take a look at the boot options that our virtualized Netapp Storage systems offers us. 

I have choosen the Option 4 to have a clean install , as a fabric deployment of the Netapp filer. After zeroing the hard disks inside the filer , we get the first option to change and that is the 1. Hostname of the filer. I will use the testfiler hostname. Tip: When Netapp support refer to your controllers, they refer to them as top or bottom.

2. Do you want to configure interface groups ? (On the back of our FAS we have 4 gigethernet ports named e0a, e0b, e0c, e0d. You have the option of bundling 2 or more of these to create an etherchannel to your switch. This becomes beneficial if you are considering running iscsi, nfs or cifs as the traffic can be load balanced across the bundled ports. I will choose no because I do not need it for the test scenario.
Next what needs to be done is to define IP addresses of networks connected. We can type in the addresses of the bridged interfaces from the VMware Virtual Machine. We can decide to use only one NIC, but I will configure all four of them.

3. You now have the option to continue setting up via the web interface or through the cli. We will continue through the Command Line interface.

4. Please enter the name or ip address of the default gateway. This is useful for routing and updating the FAS software.

5. Please enter the name or ip address for aadministrative host. The administration host is given root access to the storage system’s /etc files for system administration. To allow /etc root access to all NFS clients enter RETURN below. I will choose the Enter solution, because I do not need this much security in this testing scenario.

6. Please enter timezone (GMT is the default, please refer to the setup.pdf documentation in the Resource area of this site).

7. Where is the filer located ? (This is SNMP location information). You can leave it blank for starting setup.

8. What language will be used for multiprotocol files ? (en for english otherwise refer to the setup.pdf documentation in the Resource area of this site). I chose English.

9. Enter the root directory for HTTP files (Files that are served through HTTP or HTTPS)

10. Do you want to run DNS resolver ? (Basically do you want to storage system to resolve DNS, select yes).


11. Do you want to run NIS client ? If you have a Network Information Server you can choose yes. Otherwise, like I did choose no.

12. Do you want to configure the Shelf Alternate Control Path Management interface for SAS shelves ? In this test scenario we will choose NO.

13. Setting the administrative (root) password for your filer ? (Enter the password and re-enter to confirm) and reboot. In the real world scenario always use the Strong password.

14. If you are configuring the controllers for an active/active pair, repeat the same steps for the other controller. This can be done if one wants to virtualize more Netapp storage device to create a cluster mode. This I will not do , because this is an initial setup of the storage system.

15. Once the filer has rebooted you can access the web admin page type at https://<ip address>/na_admin

And finally we get the WEB http admin page where we can go on to configure some advanced features that I will talk about later. 

So more to come about Netapp , which is by the way now bought by IBM, so it is even getting better support.

Feel free to comment.

Linux Run Levels

Linux run levels details

After the Linux kernel has booted, the init program reads the /etc/inittab file to determine the behavior for each runlevel. Unless the user specifies another value as a kernel boot parameter, the system will attempt to enter (start) the default runlevel.

Here is an example of stanard run Levels under Centos Linux.

RL           Mode                               Action

0              Halt                                  Shuts down system

1              Single-User Mode            Does not configure network interfaces, start daemons,no root logins

2              Multi-User Mode               Does not configure network interfaces or start daemons.

3              Multi-User Mode 

                with  Networking               Starts the system normally.

4              Undefined                          Not used/User-definable

5              X11                                    As runlevel 3 + display manager(X)

6              Reboot                              Reboots the system

Most Linux servers lack a graphical user interface and therefore start in runlevel 3. Servers with a GUI and desktop Unix systems start runlevel 5. When a server is issued a reboot command, it enters runlevel 6.

To see what level is currently using your Distro, you can use the who -r command.

Linux also uses the init scripts to initialize proper service to the user. Init (short for initialization) is the program on Unix and Unix-like systems that spawns all other processes. It runs as a daemon and typically has PID 1.

The /etc/inittab file is used to set the default run level for the system. This is the runlevel that a system will start up on upon reboot. The applications that are started by init are located in the /etc/rc.d folder. Within this directory there is a separate folder for each run level, eg rc0.d, rc1.d, and so on.

The chkconfig tool is used in Red Hat based systems (like CentOS) to control what services are started at which runlevels. Running the command chkconfig –list will display a list of services whether they are enabled or disabled for each runlevel.

On the next graphic we can list the current scripts that have been configured to run at certain levels, or not to run on certain run levels in a Centos enviroment.

Single User mode is a mode that a multi-user system (like a Linux server) can be booted into the operating system as a superuser. Booting a system into this mode does not start networking, but can be used to make changes to any configuration files on the server. One of the most common usages for single-user mode is to change the root password for a server on which the current password is unknown.

Runlevels are an important part of the core of the Linux operating system. While not something the average administrator will work with on a daily basis, understanding runlevels gives the administrator another layer of control and flexibility over the servers they manage.

As we have seen here, the traditional method of booting a Linux system is based on the UNIX System V init process. It involves loading an initial RAM disk (initrd) and then passing control to a program called init, a program that is usually installed as part of the sysvinit package. The init program is the first process in the system and has PID (Process ID) 1. It runs a series of scripts in a predefined order to bring up the system. If something that is expected is not available, the init process typically waits until it is. While this worked adequately for systems where everything is known and connected when the system starts, modern systems with hot-pluggable devices, network file systems, and even network interfaces that may not be available at start time present new challenges

Red Hat Linux hardware discovery tools

RHEL hardware discovery tools

During the Linux kernel loading it discovers the and scans the drivers for a particular Virtual Machine it runs on. After the init procedure linux kernel loads the drivers to support the detected hardware. Examining kernel boot messages is a good way to determine the hardware your are renting for performance issues and simply to know on what "rig" you are working on. 

There are some simple tools I am used to play with to check the current hardware for issues. First one I would like to introduce is the Hardware Abstraction Layer database checker - lshal.

The system output tells us the Bios version of the VM or a physical machine, and serial numbers attached to the same. As we can see this linux kernel is run on a vSphere ESXi virtual machine emulating the Phoenix Technologies bios, which is typical for VMware.

If one wants to get the information about the virtual CPUs or the actual physical ones on their VPS system, this information can be extracted from the /proc folder under the root of the file system.

 From the output of this hardware tool we can see that we are using Genuine Intel two Xeon CPUs. The clock, cache, fpu and family are also displayed so we can get a clear picture of what performance we can expect from this VPS system.

The linux console system can use either the Standard Vga driver, or a video chipset specific modular frame buffer driver. The vga driver is always present in the kernel and will bind automatically to the console if no other is active. To display which driver is used on this particular VPS we can concatenate and display this information from the vtcon0 folder.

[root@cent-01 /]# cat /sys/class/vtconsole/vtcon0/name
(S) VGA+
[root@cent-01 /]#

This particular VPS system is using the Standard VGA kernel driver, so we can determine the no other is loaded into the frame.

Thanks for reading. 

Feel free to comment !

Linux Firewall

I P T A B L E S with S S H

There are lots of other things you can do to help secure your web server’s ssh port, but one of the most powerful and flexible is to bring iptables into the mix. Iptables is an applicaiton which comes preinstalled on most modern GNU/Linux distros and which provides instructions to the Linux kernel firewall. It is not a firewall in and of itself; rather, it provides a (relatively) easy way to view and modify the way the system’s built-in firewall tracks, filters, and transforms the network packets it receives.

In this particular use case, we care about iptables’s ability to perform actions on incoming ssh packets, based on parameters we define. Specifically, we’re going to use it to track all incoming ssh requests, and then block any host that tries to connect too many times. This is a simpler and more robust approach than the one DenyHosts takes, and the advantages are that it is self-maintaining and not dependent on log file parsing to work.

To list the IPTABLES default output in Linux distro we can see several chains.

$ sudo iptables --list

Chain INPUT (policy ACCEPT)

target     prot opt source               destination

Chain FORWARD (policy ACCEPT)

target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)

target     prot opt source               destination

In the example above, there are only the three default iptables chains defined, and no specific rules other than the default ACCEPT policy, meaning that if a packet matches none of the chain’s defined rules, it is accepted and allowed past the firewall. Since we haven’t set up any rules, right now iptables is doing nothing and letting all packets through.

If you were already using your web server’s firewall as its actual perimeter defense, you would likely want the chains’ policies to be default deny instead of accept; however, if you were already using the firewall like that it’s very likely you wouldn’t be reading this article because you’d already know what you’re doing.

Our goal here is to make iptables watch ssh traffic, which we’ll be receiving on TCP port 22, and if there are too many connection attempts within a certain period of time—I’m going to use one minute in this example, though you can use whatever interval makes you happy—then we want to log the host that’s trying to connect and then drop all of its packets. As soon as sixty seconds have elapsed between connection attempts, iptables will forget the remote host and it will be allowed to try to connect again.

To accomplish this, we need to add three rules to the INPUT chain, and we also need to create a new chain to handle the logging and dropping and then add a couple of rules to it as well. Additionally, we need a method of making the rules and chains persistent between reboots

To create a INPUT chain rule we can use a simple syntax.

$ sudo iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --rsource

The syntax is a little archaic, but the line tells iptables that you want to append a rule onto the existing INPUT chain. The -p tcp argument indicates that this rule will apply only to TCP packets. Most of the rest of the arguments rely on the -m option, which stands for match and tells iptables that the rule applies to packets which match the specific attributes we’re looking for. Here, the rule will be applied to packets that signal the start of new connections headed for TCP port 22. If a packet matches those attributes, iptables will note the remote host’s address in a temporary list.

Iptables is now able to watch incoming ssh connections and drop packets from hosts which try to connect too often in too short a period of time.

Simple and powerfull scripting Firewall to be used with other security features Linux Distros offer.

Feel free to comment.

Security-Enhanced Linux

SELinux

Security-Enhanced Linux (SELinux) is a mandatory access control (MAC) security mechanism implemented in the kernel. SELinux was first introduced in CentOS 4 and significantly enhanced in CentOS 5 and 6. These enhancements mean that content varies as to how to approach SELinux over time to solve problems. 

Access can be constrained on such variables as which users and applications can access which resources. These resources may take the form of files. Standard Linux access controls, such as file modes (-rwxr-xr-x) are modifiable by the user and the applications which the user runs. Conversely, SELinux access controls are determined by a policy loaded on the system which may not be changed by careless users or misbehaving applications. SELinux also adds finer granularity to access controls. Instead of only being able to specify who can read, write or execute a file, for example, SELinux lets you specify who can unlink, append only, move a file and so on. SELinux allows you to specify access to many resources other than files as well, such as network resources and interprocess communication (IPC).

SELinux follows the model of least-privilege more closely. By default under a strict enforcing setting, everything is denied and then a series of exceptions policies are written that give each element of the system (a service, program or user) only the access required to function. If a service, program or user subsequently tries to access or modify a file or resource not necessary for it to function, then access is denied and the action is can be logged.

SELinux has three basic modes of operation, of which Enforcing is set as the installation default mode. There is, however, an additional qualifier of targeted or mls which control how pervasive SELinux rules are applied, with targeted being the less stringent level.

Enforcing:   The default mode which will enable and enforce the SELinux security policy on the system,   

                  denying access and logging actions

Permissive: In Permissive mode, SELinux is enabled but will not enforce the security policy, only warn and   

                   log actions. Permissive mode is useful for troubleshooting SELinux issues
Disabled:    SELinux is turned off

The SELinux mode can be viewed and changed by using the SELinux Management GUI tool available on the Administration menu or from the command line by running 'system-config-selinux' (the SELinux Management GUI tool is part of the policycoreutils-gui package and is not installed by default).

SELinux can potentially control which activities a system allows each user, process and daemon, with very precise specifications.

However, it is mostly used to confine daemons like database engines or web servers that have more clearly-defined data access and activity rights. This limits potential harm from a confined daemon that becomes compromised. Ordinary user-processes often run in the unconfined domain, not restricted by SELinux but still restricted by the classic Linux access rights.

More on the NSA web site.