Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
May the source be with you, but remember the KISS principle ;-)
Bigger doesn't imply better. Bigger often is a sign of obesity, of lost control, of overcomplexity, of cancerous cells

Linux Server Security


Potemkin Villages of Computer Security

Recommended Books

Recommended Links

Softpanorama Laws of Computer Security

Red Hat security

 Suse Security

Log rotation in RHEL/Centos/Oracle linux Linux root password recovery Mounting partitions with chroot in rescue mode Working with ISO Images in Linux Reverting permissions in etc to redhat defaults    
Top Vulnerabilities In Linux Environment Linux Hardening Seccheck Access Control Protective partitioning chkperm Warning banners
Intrusion Detection TCP Wrappers PAM Unix Access Control Lists (ACL) wheel group Apparmor Integrity Checkers
Cloud providers as intelligence collection hubs Is Google evil ? Google Embedded Tracking and Hidden Redirects in Search Results Privacy is Dead – Get Over It Facebook = Spyware Cyberstalking Big Uncle is Watching You

Linux root password recovery


Virtualization SecurId Sysadmin Horror Stories



Never underestimate the power of human stupidity


Computer Security is an anthropomorphic deity of a new messianic high demand cult. It is synonym of goodness, happiness and light; a mystic force which provides a beautiful eternal harmony of all things computable. The main recruitment base of the cult are system administrators.

A secure server is a cosmic harbinger of charismatic power; an exorcistic poltergeist that preserves mental health, cures headache, allergy, alcoholism, depression, and deters aging. It is a nirvana for both young and old system administrators; an enviable paragon of all imaginable idealistic virtues; an apocalyptic voice that answers the question: "What is truth?".

Finally, a secure computer network is the bright hope of all mankind, a glimpse of things to come with the help of Homeland Security, and an inscrutable enigma that may well decide whether this nation, or any other nation, conceived in Liberty, can endure. In the USA this notion plays a role similar to the second coming of Christ in some high demand cults.

Linux server security is environment and threat specific topic. There is little value in discussing "generic" security issues, because generic security issues are actually architectural decisions and as such, paradoxically,  lies mostly outside of security.  Also steady stream of serious bugs that is typical for Linux (with Shellshock as the most recent example) makes achieving high security a really challenging task. Existence of NSA and their genuine interest in exploits make this task probably impossible ;-).  So security is never general, but always "security from whom". We have disctiguish here three levels:

 And it is one level to security your system from non-state supported hackers and the other from NSA. Big difference as in the second case encryption and high level of isolation and compartmentalization of network should be enforced and maintained on all level as access to systems can be assumed is achieved by NSA without much effort.

Also in all cases security via obscurity works wonders. And  custom compiled version of Open Solaris working on non Intel CPU is a better deal then thorously secured Linux.

Unless you take such really draconian (and, as such, probably self-defeating) measures level of security can be assumed only against "non state supprted hackers and disgruntled employees". . Taking into account a well know observation "Never underestimate the power of human stupidity" this looks like "task impossible". So generally we can speak only about degrees of insecurity. And please note that any additional degree of security inflicts cost on the user community (and by extension on sysadmin).  there is no free lunch.

At the same time there are many common aspects in security infrastructure of Suse and Red Hat related to popular protocols. Daemon weaknesses are among top Linux vulnerabilities. Even supposedly intended to enhance security protocols, such as ssh, regularly became target of nasty attacks and serve as a back door into the systems.

While Rhel and Suse has different primary security mechanisms (SELinux vs. AppArmor) in Suse 11 Suse surrender to the RHEL market share and adopted Red Hat SELinux model in addition to its native AppArmor. Also some daemons in those two distributions are difference ad as such have different security problems (ftpd, syslogd, etc)

Among elements of security infrastructure that are sufficiently close.

  1. firewall (IPTables)

  2. ACL

  3. PAM

  4. TCP wrappers

    The TCP Wrappers package (tcp_wrappers) is installed by default and provides host-based access control to network services. The most important component within the package is the /usr/lib/libwrap.a library. In general terms, a TCP-wrapped service is one that has been compiled against the libwrap.a library.

    When a connection attempt is made to a TCP-wrapped service, the service first references the host's access files (/etc/hosts.allow and /etc/hosts.deny) to determine whether or not the client is allowed to connect. In most cases, it then uses the syslog daemon (syslogd) to write the name of the requesting client and the requested service to /var/log/secure or /var/log/messages.

    If a client is allowed to connect, TCP Wrappers release control of the connection to the requested service and take no further part in the communication between the client and the server.

    In addition to access control and logging, TCP Wrappers can execute commands to interact with the client before denying or releasing control of the connection to the requested network service.

    Because TCP Wrappers are a valuable addition to any server administrator's arsenal of security tools, most network services within Red Hat Enterprise Linux are linked to the libwrap.a library. Some such applications include /usr/sbin/sshd, /usr/sbin/sendmail, and /usr/sbin/xinetd.

Among elements of security infrastructure that are different

  1. Syslog daemon
  2. Ftp daemon (pure-ftpd vs vsftpd)

One of the simplest and most efficient way to make typical server more secure is to run it firewall enabled. This is actually a default mode for both SLES and RHEL. But this measure does complicates troubleshooting.

RHEL training courses they teach how to overcome obstacles related to the presence of firewall and how to troubleshoot related issues. SLES training does not touch this issues yet. 

Top Visited
Past week
Past month


Old News ;-)

[Jan 04, 2019] Linux Servers Most Affected by IPMI Enabled JungleSec Ransomware by Christine Hall

Jan 02, 2019 |

Linux servers top the list of victims to a ransomware attack that seems to take advantage of poorly configured IPMI devices.

SysAdmins, who probably already have much on their plates at the end of the holiday season, have another rather urgent task at hand if they administer servers equipped with Intelligent Platform Management Interface (IPMI) cards. It seems that since November, black hat hackers have been using the cards to gain access in order to install JungleSec ransomware that encrypts data and demands a 0.3 bitcoin payment (about $1,100 at the current rate) for the unlock key.

For the uninitiated, IPMI is a management interface that's either built into server motherboards or on add-on cards that provides management and monitoring capabilities that are independent of the system's CPU, firmware, and operating system. With it, admins can remotely manage a server to do things like power it up and down, monitor system information, access KVMs, and more. While this is useful for managing off-premises servers in colocation data centers and the like, it also offers an opening for attackers if it's not properly locked.

Related: Start a Security To-Do List

There's been a lot of uneven reporting on this since BleepingComputer broke the story on Dec. 26, with many sites indicating that the hack only affects Linux servers. While it's true that the majority of servers affected have been running Linux, Windows as well as Mac servers have also fallen victim. At this point it's not clear whether Linux servers appear to be most affected simply because of Linux's dominance in the server market or because attackers are finding the attack easier to successfully manage when targeting Linux machines.

There have also been reports that the exploit only takes advantage of systems using default IPMI passwords, but BleepingComputer reported it had found at least one victim that had disabled the IPMI Admin user and was still hacked by an attacker that evidently gained access by taking advantage of a vulnerability that was most likely the result of IPMI not being configured properly.

Related: Recent Security Breaches, IoT Vulnerabilities Make Top Stories of 2018

Indeed, it appears at this point that poor configuration is how attackers are gaining entry.

The good news is that securing against such attacks should be rather straightforward, starting with making sure the IPMI password isn't the default. In addition, access control lists (ACLs) should be configured to specify the IP addresses that have access the IPMI interface, and to also configure IPMI to only listen on internal IP addresses, which would limit access to admins inside the organization's system.

For Linux servers, it might be a good idea to password protect the GRUB bootloader. After gaining access to Linux servers, attackers have been rebooting into single user mode to gain root access before downloading the malicious payload. At the very least, password protecting GRUB would make reboots difficult.

[Oct 15, 2018] Check man chroot. The authors of chroot say it's useless for security

Notable quotes:
"... Noexec is basically a suggestion, not an enforcement mechanism . Just run ld /path/to/executable. ld is the loader/lilinker for elf binaries. Without ld ,you can't run bash, or ls. With ld, noexec is ignored. ..."
Oct 15, 2018 |

raymorris ( 2726007 ) , Saturday August 29, 2015 @07:53PM ( #50418235 ) Journal

read the man page ( Score: 5 , Informative)

> In short: I think chroot is plenty good for security

Check man chroot. The authors of chroot say it's useless for security. Perhaps you think you know more than they do ,and more than security professionals like myself do. Let's find out.

> you get a shell in one of my chroot's used for security, then.....
ur uid and gid are not going to be 0. Good luck telling the kernel to try and get you out.
There aren't going to be any /dev, /proc, or other special filesystems

Gonna be kind of tthough to have a ahell without a tty, aka /dev/*tty*

So yeah, you need /dev. Can't launch a process, including /bin/ls, without /proc, so you're going to need proc. Have a look in /proc/1. You'll see a very interesting symlink there.

> mounted noexec

Noexec is basically a suggestion, not an enforcement mechanism . Just run ld /path/to/executable. ld is the loader/lilinker for elf binaries. Without ld ,you can't run bash, or ls. With ld, noexec is ignored.

My company does IT security for banks. Meaning we show the banks how they can be hacked. When I say chroot is not a security control, I'm not guessing.

[Sep 23, 2017] CentOS 7 Server Hardening Guide Linux Security Networking

Highly recommended!
Notable quotes:
"... As a rule of thumb, malicious applications usually write to /tmp and then attempt to run whatever was written. A way to prevent this is to mount /tmp on a separate partition with the options noexec , nodev and nosuid enabled. ..."
Sep 23, 2017 |

Remove packages which you don't require on a server, e.g. firmware of sound cards, firmware of WinTV, wireless drivers etc.

# yum remove alsa-* ivtv-* iwl*firmware ic94xx-firmware
2. System Settings – File Permissions and Masks 2.1 Restrict Partition Mount Options

Partitions should have hardened mount options:

  1. /boot – rw,nodev,noexec,nosuid
  2. /home – rw,nodev,nosuid
  3. /tmp – rw,nodev,noexec,nosuid
  4. /var – rw,nosuid
  5. /var/log – rw,nodev,noexec,nosuid
  6. /var/log/audit – rw,nodev,noexec,nosuid
  7. /var/www – rw,nodev,nosuid

As a rule of thumb, malicious applications usually write to /tmp and then attempt to run whatever was written. A way to prevent this is to mount /tmp on a separate partition with the options noexec , nodev and nosuid enabled.

This will deny binary execution from /tmp , disable any binary to be suid root, and disable any block devices from being created.

The storage location /var/tmp should be bind mounted to /tmp , as having multiple locations for temporary storage is not required:

/tmp /var/tmp none rw,nodev,noexec,nosuid,bind 0 0

The same applies to shared memory /dev/shm :

tmpfs /dev/shm tmpfs rw,nodev,noexec,nosuid 0 0

The proc pseudo-filesystem /proc should be mounted with hidepid . When setting hidepid to 2, directories entries in /proc will hidden.

proc /proc proc rw,hidepid=2 0 0

Harden removeable media mounts by adding nodev noexec and nosuid , e.g.:

/dev/cdrom /mnt/cdrom iso9660 ro,noexec,nosuid,nodev,noauto 0 0
2.2 Restrict Dynamic Mounting and Unmounting of Filesystems

Add the following to /etc/modprobe.d/hardening.conf to disable uncommon filesystems:

install cramfs /bin/true

install freevxfs /bin/true

install jffs2 /bin/true

install hfs /bin/true

install hfsplus /bin/true

install squashfs /bin/true

install udf /bin/true

Depending on a setup (if you don't run clusters, NFS, CIFS etc), you may consider disabling the following too:

install fat /bin/true

install vfat /bin/true

install cifs /bin/true

install nfs /bin/true

install nfsv3 /bin/true

install nfsv4 /bin/true

install gfs2 /bin/true

It is wise to leave ext4, xfs and btrfs enabled at all times.

2.3 Prevent Users Mounting USB Storage

Add the following to /etc/modprobe.d/hardening.conf to disable modprobe loading of USB and FireWire storage drivers:

blacklist usb-storage

blacklist firewire-core

install usb-storage /bin/true

Disable USB authorisation. Create a file /opt/ with the following content:


echo 0 > /sys/bus/usb/devices/usb1/authorized

echo 0 > /sys/bus/usb/devices/usb1/authorized_default

If more than one USB device is available, then add them all. Create a service file /etc/systemd/system/usb-auth.service with the following content:


Description=Disable USB auth




ExecStart=/bin/bash /opt/


Set permissions, enable and start the service:

# chmod 0700 /opt/

# systemctl enable usb-auth.service

# systemctl start usb-auth.service

If required, disable kernel support for USB via bootloader configuration. To do so, append nousb to the kernel line GRUB_CMDLINE_LINUX in /etc/default/grub and generate the Grub2 configuration file:

# grub2-mkconfig -o /boot/grub2/grub.cfg

Note that disabling all kernel support for USB will likely cause problems for systems with USB-based keyboards etc.

2.4 Restrict Programs from Dangerous Execution Patterns

Configure /etc/sysctl.conf with the following:

# Disable core dumps

fs.suid_dumpable = 0

# Disable System Request debugging functionality

kernel.sysrq = 0

# Restrict access to kernel logs

kernel.dmesg_restrict = 1

# Enable ExecShield protection

kernel.exec-shield = 1

# Randomise memory space

kernel.randomize_va_space = 2

# Hide kernel pointers

kernel.kptr_restrict = 2

Load sysctl settings:

# sysctp -p
2.5 Set UMASK 027

The following files require umask hardening: /etc/bashrc , /etc/csh.cshrc , /etc/init.d/functions and /etc/profile .

Sed one-liner:

# sed -i -e 's/umask 022/umask 027/g' -e 's/umask 002/umask 027/g' /etc/bashrc

# sed -i -e 's/umask 022/umask 027/g' -e 's/umask 002/umask 027/g' /etc/csh.cshrc

# sed -i -e 's/umask 022/umask 027/g' -e 's/umask 002/umask 027/g' /etc/profile

# sed -i -e 's/umask 022/umask 027/g' -e 's/umask 002/umask 027/g' /etc/init.d/functions
2.6 Disable Core Dumps

Open /etc/security/limits.conf and set the following:

*  hard  core  0
2.7 Set Security Limits to Prevent DoS

Add the following to /etc/security/limits.conf to enforce sensible security limits:

# 4096 is a good starting point

*      soft   nofile    4096

*      hard   nofile    65536

*      soft   nproc     4096

*      hard   nproc     4096

*      soft   locks     4096

*      hard   locks     4096

*      soft   stack     10240

*      hard   stack     32768

*      soft   memlock   64

*      hard   memlock   64

*      hard   maxlogins 10

# Soft limit 32GB, hard 64GB

*      soft   fsize     33554432

*      hard   fsize     67108864

# Limits for root

root   soft   nofile    4096

root   hard   nofile    65536

root   soft   nproc     4096

root   hard   nproc     4096

root   soft   stack     10240

root   hard   stack     32768

root   soft   fsize     33554432
2.8 Verify Permissions of Files

Ensure that all files are owned by a user:

# find / -ignore_readdir_race -nouser -print -exec chown root {} \;

Ensure that all files are owned by a group:

# find / -ignore_readdir_race -nogroup -print -exec chgrp root {} \;

Automate the process by creating a cron file /etc/cron.daily/unowned_files with the following content:


find / -ignore_readdir_race -nouser -print -exec chown root {} \;

find / -ignore_readdir_race -nogroup -print -exec chgrp root {} \;

Set ownership and permissions:

# chown root:root /etc/cron.daily/unowned_files

# chmod 0700 /etc/cron.daily/unowned_files
2.9 Monitor SUID/GUID Files

Search for setuid/setgid files and identify if all are required:

# find / -xdev -type f -perm -4000 -o -perm -2000
3. System Settings – Firewall and Network Configuration 3.1 Firewall

Setting the default firewalld zone to drop makes any packets which are not explicitly permitted to be rejected.

# sed -i "s/DefaultZone=.*/DefaultZone=drop/g" /etc/firewalld/firewalld.conf

Unless firewalld is required, mask it and replace with iptables:

# systemctl stop firewalld.service

# systemctl mask firewalld.service

# systemctl daemon-reload

# yum install iptables-services

# systemctl enable iptables.service ip6tables.service

Add the following to /etc/sysconfig/iptables to allow only minimal outgoing traffic (DNS, NTP, HTTP/S and SMTPS):








-A INPUT -i lo -m comment --comment local -j ACCEPT

-A INPUT -d ! -i lo -j REJECT --reject-with icmp-port-unreachable

-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

-A INPUT -p tcp -m tcp -m conntrack --ctstate NEW --dport 22 -s -j ACCEPT

-A INPUT -p tcp -m tcp -m conntrack --ctstate NEW --dport 22 -s -j ACCEPT

-A INPUT -p tcp -m tcp -m conntrack --ctstate NEW --dport 22 -s -j ACCEPT

-A INPUT -p tcp -m tcp -m conntrack --ctstate NEW --dport 22 -j ACCEPT


-A OUTPUT -d -o lo -m comment --comment local -j ACCEPT

-A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

-A OUTPUT -p icmp -m icmp --icmp-type any -j ACCEPT

-A OUTPUT -p udp -m udp -m conntrack --ctstate NEW --dport 53 -j ACCEPT

-A OUTPUT -p tcp -m tcp -m conntrack --ctstate NEW --dport 53 -j ACCEPT

-A OUTPUT -p udp -m udp -m conntrack --ctstate NEW --dport 123 -j ACCEPT

-A OUTPUT -p tcp -m tcp -m conntrack --ctstate NEW --dport 80 -j ACCEPT

-A OUTPUT -p tcp -m tcp -m conntrack --ctstate NEW --dport 443 -j ACCEPT

-A OUTPUT -p tcp -m tcp -m conntrack --ctstate NEW --dport 587 -j ACCEPT

-A OUTPUT -j LOG --log-prefix "iptables_output "

-A OUTPUT -j REJECT --reject-with icmp-port-unreachable


Note that the rule allowing all incoming SSH traffic should be removed restricting access to an IP whitelist only, or hiding SSH behind a VPN.

Add the following to /etc/sysconfig/ip6tables to deny all IPv6:









Apply configurations:

# iptables-restore < /etc/sysconfig/iptables

# ip6tables-restore < /etc/sysconfig/ip6tables
3.2 TCP Wrappers

Open /etc/hosts.allow and allow localhost traffic and SSH:


sshd: ALL

The file /etc/hosts.deny should be configured to deny all by default:

3.3 Kernel Parameters Which Affect Networking

Open /etc/sysctl.conf and add the following:

# Disable packet forwarding

net.ipv4.ip_forward = 0

# Disable redirects, not a router

net.ipv4.conf.all.accept_redirects = 0

net.ipv4.conf.default.accept_redirects = 0

net.ipv4.conf.all.send_redirects = 0

net.ipv4.conf.default.send_redirects = 0

net.ipv4.conf.all.secure_redirects = 0

net.ipv4.conf.default.secure_redirects = 0

net.ipv6.conf.all.accept_redirects = 0

net.ipv6.conf.default.accept_redirects = 0

# Disable source routing

net.ipv4.conf.all.accept_source_route = 0

net.ipv4.conf.default.accept_source_route = 0

net.ipv6.conf.all.accept_source_route = 0

# Enable source validation by reversed path

net.ipv4.conf.all.rp_filter = 1

net.ipv4.conf.default.rp_filter = 1

# Log packets with impossible addresses to kernel log

net.ipv4.conf.all.log_martians = 1

net.ipv4.conf.default.log_martians = 1

# Disable ICMP broadcasts

net.ipv4.icmp_echo_ignore_broadcasts = 1

# Ignore bogus ICMP errors

net.ipv4.icmp_ignore_bogus_error_responses = 1

# Against SYN flood attacks

net.ipv4.tcp_syncookies = 1

# Turning off timestamps could improve security but degrade performance.

# TCP timestamps are used to improve performance as well as protect against

# late packets messing up your data flow. A side effect of this feature is 

# that the uptime of the host can sometimes be computed.

# If you disable TCP timestamps, you should expect worse performance 

# and less reliable connections.

net.ipv4.tcp_timestamps = 1

# Disable IPv6 unless required

net.ipv6.conf.lo.disable_ipv6 = 1

net.ipv6.conf.all.disable_ipv6 = 1

net.ipv6.conf.default.disable_ipv6 = 1

# Do not accept router advertisements

net.ipv6.conf.all.accept_ra = 0

net.ipv6.conf.default.accept_ra = 0
3.4 Kernel Modules Which Affect Networking

Open /etc/modprobe.d/hardening.conf and disable Bluetooth kernel modules:

install bnep /bin/true

install bluetooth /bin/true

install btusb /bin/true

install net-pf-31 /bin/true

Also disable AppleTalk:

install appletalk /bin/true

Unless required, disable support for IPv6:

options ipv6 disable=1

Disable (uncommon) protocols:

install dccp /bin/true

install sctp /bin/true

install rds /bin/true

install tipc /bin/true

Since we're looking at server security, wireless shouldn't be an issue, therefore we can disable all the wireless drivers.

# for i in $(find /lib/modules/$(uname -r)/kernel/drivers/net/wireless -name "*.ko" -type f);do \

  echo blacklist "$i" >>/etc/modprobe.d/hardening-wireless.conf;done
3.5 Disable Radios

Disable radios (wifi and wwan):

# nmcli radio all off
3.6 Disable Zeroconf Networking

Open /etc/sysconfig/network and add the following:

3.7 Disable Interface Usage of IPv6

Open /etc/sysconfig/network and add the following:


3.8 Network Sniffer

The server should not be acting as a network sniffer and capturing packages. Run the following to determine if any interface is running in promiscuous mode:

# ip link | grep PROMISC
3.9 Secure VPN Connection

Install the libreswan package if implementation of IPsec and IKE is required.

# yum install libreswan
3.10 Disable DHCP Client

Manual assignment of IP addresses provides a greater degree of management.

For each network interface that is available on the server, open a corresponding file /etc/sysconfig/network-scripts/ifcfg- interface and configure the following parameters:




4. System Settings – SELinux

Ensure that SELinux is not disabled in /etc/default/grub , and verify that the state is enforcing:

# sestatus
5. System Settings – Account and Access Control 5.1 Delete Unused Accounts and Groups

Remove any account which is not required, e.g.:

# userdel -r adm

# userdel -r ftp

# userdel -r games

# userdel -r lp

Remove any group which is not required, e.g.:

# groupdel games
5.2 Disable Direct root Login
# echo > /etc/securetty
5.3 Enable Secure (high quality) Password Policy

Note that running authconfig will overwrite the PAM configuration files destroying any manually made changes. Make sure that you have a backup

Secure password policy rules are outlined below.

  1. Minimum length of a password – 16.
  2. Minimum number of character classes in a password – 4.
  3. Maximum number of same consecutive characters in a password – 2.
  4. Maximum number of consecutive characters of same class in a password – 2.
  5. Require at least one lowercase and one uppercase characters in a password.
  6. Require at least one digit in a password.
  7. Require at least one other character in a password.

The following command will enable SHA512 as well as set the above password requirements:

# authconfig --passalgo=sha512 \

 --passminlen=16 \

 --passminclass=4 \

 --passmaxrepeat=2 \

 --passmaxclassrepeat=2 \

 --enablereqlower \

 --enablerequpper \

 --enablereqdigit \

 --enablereqother \


Open /etc/security/pwquality.conf and add the following:

difok = 8

gecoscheck = 1

These will ensure that 8 characters in the new password must not be present in the old password, and will check for the words from the passwd entry GECOS string of the user.

5.4 Prevent Log In to Accounts With Empty Password

Remove any instances of nullok from /etc/pam.d/system-auth and /etc/pam.d/password-auth to prevent logins with empty passwords.

Sed one-liner:

# sed -i 's/\<nullok\>//g' /etc/pam.d/system-auth /etc/pam.d/password-auth
5.5 Set Account Expiration Following Inactivity

Disable accounts as soon as the password has expired.

Open /etc/default/useradd and set the following:


Sed one-liner:

# sed -i 's/^INACTIVE.*/INACTIVE=0/' /etc/default/useradd
5.6 Secure Pasword Policy

Open /etc/login.defs and set the following:





Sed one-liner:

# sed -i -e 's/^PASS_MAX_DAYS.*/PASS_MAX_DAYS 60/' \

  -e 's/^PASS_MIN_DAYS.*/PASS_MIN_DAYS 1/' \

  -e 's/^PASS_MIN_LEN.*/PASS_MIN_LEN 14/' \

  -e 's/^PASS_WARN_AGE.*/PASS_WARN_AGE 14/' /etc/login.defs
5.7 Log Failed Login Attemps

Open /etc/login.defs and enable logging:


Also add a delay in seconds before being allowed another attempt after a login failure:

5.8 Ensure Home Directories are Created for New Users

Open /etc/login.defs and configure:

5.9 Verify All Account Password Hashes are Shadowed

The command below should return "x":

# cut -d: -f2 /etc/passwd|uniq
5.10 Set Deny and Lockout Time for Failed Password Attempts

Add the following line immediately before the statement in the AUTH section of /etc/pam.d/system-auth and /etc/pam.d/password-auth :

auth required preauth silent deny=3 unlock_time=900 fail_interval=900

Add the following line immediately after the statement in the AUTH section of /etc/pam.d/system-auth and /etc/pam.d/password-auth :

auth [default=die] authfail deny=3 unlock_time=900 fail_interval=900

Add the following line immediately before the statement in the ACCOUNT section of /etc/pam.d/system-auth and /etc/pam.d/password-auth :

account required

The content of the file /etc/pam.d/system-auth can be seen below.


auth        required

auth        required preauth silent deny=3 unlock_time=900 fail_interval=900

auth        sufficient  try_first_pass

auth        [default=die] authfail deny=3 unlock_time=900 fail_interval=900

auth        requisite uid >= 1000 quiet_success

auth        required

account     required

account     required

account     sufficient

account     sufficient uid < 1000 quiet

account     required

password    requisite try_first_pass local_users_only retry=3 authtok_type=

password    sufficient sha512 shadow  try_first_pass use_authtok remember=5

password    required

session     optional revoke

session     required

-session    optional

session     [success=1 default=ignore] service in crond quiet use_uid

session     required

Also, do not allow users to reuse recent passwords by adding the remember option.

Make /etc/pam.d/system-auth and /etc/pam.d/password-auth configurations immutable so that they don't get overwritten when authconfig is run:

# chattr +i /etc/pam.d/system-auth /etc/pam.d/password-auth

Accounts will get locked after 3 failed login attemtps:

login[]: pam_faillock(login:auth): Consecutive login failures for user tomas account temporarily locked

Use the following to clear user's fail count:

# faillock --user tomas --reset
5.11 Set Boot Loader Password

Prevent users from entering the grub command line and edit menu entries:

# grub2-setpassword

# grub2-mkconfig -o /boot/grub2/grub.cfg

This will create the file /boot/grub2/user.cfg if one is not already present, which will contain the hashed Grub2 bootloader password.

Verify permissions of /boot/grub2/grub.cfg :

# chmod 0600 /boot/grub2/grub.cfg
5.12 Password-protect Single User Mode

CentOS 7 single user mode is password protected by the root password by default as part of the design of Grub2 and systemd.

5.13 Ensure Users Re-Authenticate for Privilege Escalation

The NOPASSWD tag allows a user to execute commands using sudo without having to provide a password. While this may sometimes be useful it is also dangerious.

Ensure that the NOPASSWD tag does not exist in /etc/sudoers configuration file or /etc/sudoers.d/ .

5.14 Multiple Console Screens and Console Locking

Install the screen package to be able to emulate multiple console windows:

# yum install screen

Install the vlock package to enable console screen locking:

# yum install vlock
5.15 Disable Ctrl-Alt-Del Reboot Activation

Prevent a locally logged-in console user from rebooting the system when Ctrl-Alt-Del is pressed:

# systemctl mask
5.16 Warning Banners for System Access

Add the following line to the files /etc/issue and /etc/ :

Unauthorised access prohibited. Logs are recorded and monitored.
5.17 Set Interactive Session Timeout

Open /etc/profile and set:

readonly TMOUT=900
5.18 Two Factor Authentication

The recent version of OpenSSH server allows to chain several authentication methods, meaning that all of them have to be satisfied in order for a user to log in successfully.

Adding the following line to /etc/ssh/sshd_config would require a user to authenticate with a key first, and then also provide a password.

AuthenticationMethods publickey,password

This is by definition a two factor authentication: the key file is something that a user has, and the account password is something that a user knows.

Alternatively, two factor authentication for SSH can be set up by using Google Authenticator.

5.19 Configure History File Size

Open /etc/profile and set the number of commands to remember in the command history to 5000:


Sed one-liner:

# sed -i 's/HISTSIZE=.*/HISTSIZE=5000/g' /etc/profile
6. System Settings – System Accounting with auditd 6.1 Auditd Configuration

Open /etc/audit/auditd.conf and configure the following:

local_events = yes

write_logs = yes

log_file = /var/log/audit/audit.log

max_log_file = 25

num_logs = 10

max_log_file_action = rotate

space_left = 30

space_left_action = email

admin_space_left = 10

admin_space_left_action = email

disk_full_action = suspend

disk_error_action = suspend

action_mail_acct =

flush = data

The above auditd configuration should never use more than 250MB of disk space (10x25MB=250MB) on /var/log/audit .

Set admin_space_left_action=single if you want to cause the system to switch to single user mode for corrective action rather than send an email.

Automatically rotating logs ( max_log_file_action=rotate ) minimises the chances of the system unexpectedly running out of disk space by being filled up with log data.

We need to ensure that audit event data is fully synchronised ( flush=data ) with the log files on the disk .

6.2 Auditd Rules

System audit rules must have mode 0640 or less permissive and owned by the root user:

# chown root:root /etc/audit/rules.d/audit.rules

# chmod 0600 /etc/audit/rules.d/audit.rules

Open /etc/audit/rules.d/audit.rules and add the following:

# Delete all currently loaded rules


# Set kernel buffer size

-b 8192

# Set the action that is performed when a critical error is detected.

# Failure modes: 0=silent 1=printk 2=panic

-f 1

# Record attempts to alter the localtime file

-w /etc/localtime -p wa -k audit_time_rules

# Record events that modify user/group information

-w /etc/group -p wa -k audit_rules_usergroup_modification

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

-w /etc/gshadow -p wa -k audit_rules_usergroup_modification

-w /etc/shadow -p wa -k audit_rules_usergroup_modification

-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

# Record events that modify the system's network environment

-w /etc/ -p wa -k audit_rules_networkconfig_modification

-w /etc/issue -p wa -k audit_rules_networkconfig_modification

-w /etc/hosts -p wa -k audit_rules_networkconfig_modification

-w /etc/sysconfig/network -p wa -k audit_rules_networkconfig_modification

-a always,exit -F arch=b32 -S sethostname -S setdomainname -k audit_rules_networkconfig_modification

-a always,exit -F arch=b64 -S sethostname -S setdomainname -k audit_rules_networkconfig_modification

# Record events that modify the system's mandatory access controls

-w /etc/selinux/ -p wa -k MAC-policy

# Record attempts to alter logon and logout events

-w /var/log/tallylog -p wa -k logins

-w /var/log/lastlog -p wa -k logins

-w /var/run/faillock/ -p wa -k logins

# Record attempts to alter process and session initiation information

-w /var/log/btmp -p wa -k session

-w /var/log/wtmp -p wa -k session

-w /var/run/utmp -p wa -k session

# Ensure auditd collects information on kernel module loading and unloading

-w /usr/sbin/insmod -p x -k modules

-w /usr/sbin/modprobe -p x -k modules

-w /usr/sbin/rmmod -p x -k modules

-a always,exit -F arch=b64 -S init_module -S delete_module -k modules

# Ensure auditd collects system administrator actions

-w /etc/sudoers -p wa -k actions

# Record attempts to alter time through adjtimex

-a always,exit -F arch=b32 -S adjtimex -S settimeofday -S stime -k audit_time_rules

# Record attempts to alter time through settimeofday

-a always,exit -F arch=b64 -S adjtimex -S settimeofday -k audit_time_rules

# Record attempts to alter time through clock_settime

-a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -k time-change

# Record attempts to alter time through clock_settime

-a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -k time-change

# Record events that modify the system's discretionary access controls

-a always,exit -F arch=b32 -S chmod -S fchmod -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod

-a always,exit -F arch=b32 -S chown -S fchown -S fchownat -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod

-a always,exit -F arch=b64 -S chmod -S fchmod -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod

-a always,exit -F arch=b64 -S chown -S fchown -S fchownat -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod

-a always,exit -F arch=b32 -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod

-a always,exit -F arch=b64 -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod

# Ensure auditd collects unauthorised access attempts to files (unsuccessful)

-a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k access

-a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k access

-a always,exit -F arch=b64 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k access

-a always,exit -F arch=b64 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k access

# Ensure auditd collects information on exporting to media (successful)

-a always,exit -F arch=b32 -S mount -F auid>=1000 -F auid!=4294967295 -k export

-a always,exit -F arch=b64 -S mount -F auid>=1000 -F auid!=4294967295 -k export

# Ensure auditd collects file deletion events by user

-a always,exit -F arch=b32 -S rmdir -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -F auid!=4294967295 -k delete

-a always,exit -F arch=b64 -S rmdir -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -F auid!=4294967295 -k delete

# Ensure auditd collects information on the use of privileged commands

-a always,exit -F path=/usr/bin/chage -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged

-a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=4294967295 -F key=privileged-priv_change

-a always,exit -F path=/usr/bin/chfn -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged

-a always,exit -F path=/usr/bin/chsh -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged

-a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged

-a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged

-a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged

-a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged

-a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged

-a always,exit -F path=/usr/bin/pkexec -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged

-a always,exit -F path=/usr/bin/screen -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged

-a always,exit -F path=/usr/bin/ssh-agent -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged

-a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged

-a always,exit -F path=/usr/bin/sudoedit -F perm=x -F auid>=1000 -F auid!=4294967295 -F key=privileged

-a always,exit -F path=/usr/bin/su -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged

-a always,exit -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged

-a always,exit -F path=/usr/bin/wall -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged

-a always,exit -F path=/usr/bin/write -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged

-a always,exit -F path=/usr/lib64/dbus-1/dbus-daemon-launch-helper -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged

-a always,exit -F path=/usr/libexec/openssh/ssh-keysign -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged

-a always,exit -F path=/usr/libexec/utempter/utempter -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged

-a always,exit -F path=/usr/lib/polkit-1/polkit-agent-helper-1 -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged

-a always,exit -F path=/usr/sbin/netreport -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged

-a always,exit -F path=/usr/sbin/pam_timestamp_check -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged

-a always,exit -F path=/usr/sbin/postdrop -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged

-a always,exit -F path=/usr/sbin/postqueue -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged

-a always,exit -F path=/usr/sbin/restorecon -F perm=x -F auid>=1000 -F auid!=4294967295 -F key=privileged-priv_change

-a always,exit -F path=/usr/sbin/semanage -F perm=x -F auid>=1000 -F auid!=4294967295 -F key=privileged-priv_change

-a always,exit -F path=/usr/sbin/setsebool -F perm=x -F auid>=1000 -F auid!=4294967295 -F key=privileged-priv_change

-a always,exit -F path=/usr/sbin/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged

-a always,exit -F path=/usr/sbin/userhelper -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged

-a always,exit -F path=/usr/sbin/usernetctl -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged

# Make the auditd configuration immutable.

# The configuration can only be changed by rebooting the machine.

-e 2

The auditd service does not include the ability to send audit records to a centralised server for management directly.

It does, however, include a plug-in for audit event multiplexor to pass audit records to the local syslog server.

To do so, open the file /etc/audisp/plugins.d/syslog.conf and set:

active = yes

Enable and start the service:

# systemctl enable auditd.service

# systemctl start auditd.service
6.3. Enable Kernel Auditing

Open /etc/default/grub and append the following parameter to the kernel boot line GRUB_CMDLINE_LINUX:


Update Grub2 configuration to reflect changes:

# grub2-mkconfig -o /boot/grub2/grub.cfg
7. System Settings – Software Integrity Checking 7.1 Advanced Intrusion Detection Environment (AIDE)

Install AIDE:

# yum install aide

Build AIDE database:

# /usr/sbin/aide --init

By default, the database will be written to the file /var/lib/aide/ .

# cp /var/lib/aide/ /var/lib/aide/aide.db.gz

Storing the database and the configuration file /etc/aide.conf (or SHA2 hashes of the files) in a secure location provides additional assurance about their integrity.

Check AIDE database:

# /usr/sbin/aide --check

By default, AIDE does not install itself for periodic execution. Configure periodic execution of AIDE by adding to cron:

# echo "30 4 * * * root /usr/sbin/aide --check|mail -s 'AIDE'" >> /etc/crontab

Periodically running AIDE is necessary in order to reveal system changes.

7.2 Tripwire

Open Source Tripwire is an alternative to AIDE. It is recommended to use one or another, but not both.

Install Tripwire from the EPEL repository:

# yum install epel-release

# yum install tripwire

# /usr/sbin/tripwire-setup-keyfiles

The Tripwire configuration file is /etc/tripwire/twcfg.txt and the policy file is /etc/tripwire/twpol.txt . These can be edited and configured to match the system Tripwire is installed on, see this blog post for more details.

Initialise the database to implement the policy:

# tripwire --init

Check for policy violations:

# tripwire --check

Tripwire adds itself to /etc/cron.daily/ for daily execution therefore no extra configuration is required.

7.3 Prelink

Prelinking is done by the prelink package, which is not installed by default.

# yum install prelink

To disable prelinking, open the file /etc/sysconfig/prelink and set the following:


Sed one-liner:

# sed -i 's/PRELINKING.*/PRELINKING=no/g' /etc/sysconfig/prelink

Disable existing prelinking on all system files:

# prelink -ua
8. System Settings – Logging and Message Forwarding 8.1 Configure Persistent Journald Storage

By default, journal stores log files only in memory or a small ring-buffer in the directory /run/log/journal . This is sufficient to show recent log history with journalctl, but logs aren't saved permanently. Enabling persistent journal storage ensures that comprehensive data is available after system reboot.

Open the file /etc/systemd/journald.conf and put the following:



# How much disk space the journal may use up at most


# How much disk space systemd-journald shall leave free for other uses


# How large individual journal files may grow at most


Restart the service:

# systemctl restart systemd-journald
8.2 Configure Message Forwarding to Remote Server

Depending on your setup, open /etc/rsyslog.conf and add the following to forward messages to a some remote server:


Here *.* stands for facility.severity . Note that a single @ sends logs over UDP, where a double @ sends logs using TCP.

8.3 Logwatch

Logwatch is a customisable log-monitoring system.

# yum install logwatch

Logwatch adds itself to /etc/cron.daily/ for daily execution therefore no configuration is mandatory.

9. System Settings – Security Software 9.1 Malware Scanners

Install Rkhunter and ClamAV:

# yum install epel-release

# yum install rkhunter clamav clamav-update

# rkhunter --update

# rkhunter --propupd

# freshclam -v

Rkhunter adds itself to /etc/cron.daily/ for daily execution therefore no configuration is required. ClamAV scans should be tailored to individual needs.

9.2 Arpwatch

Arpwatch is a tool used to monitor ARP activity of a local network (ARP spoofing detection), therefore it is unlikely one will use it in the cloud, however, it is still worth mentioning that the tools exist.

Be aware of the configuration file /etc/sysconfig/arpwatch which you use to set the email address where to send the reports.

9.3 Commercial AV

Consider installing a commercial AV product that provides real-time on-access scanning capabilities.

9.4 Grsecurity

Grsecurity is an extensive security enhancement to the Linux kernel. Although it isn't free nowadays, the software is still worth mentioning.

The company behind Grsecurity stopped publicly distributing stable patches back in 2015, with an exception of the test series continuing to be available to the public in order to avoid impact to the Gentoo Hardened and Arch Linux communities.

Two years later, the company decided to cease free distribution of the test patches as well, therefore as of 2017, Grsecurity software is available to paying customers only.

10. System Settings – OS Update Installation

Install the package yum-utils for better consistency checking of the package database.

# yum install yum-utils

Configure automatic package updates via yum-cron.

# yum install yum-cron

Add the following to /etc/yum/yum-cron.conf to get notified via email when new updates are available:

update_cmd = default

update_messages = yes

download_updates = no	

apply_updates = no

emit_via = email	

email_from =

email_to =

email_host = localhost

Add the following to /etc/yum/yum-cron-hourly.conf to check for security-related updates every hour and automatically download and install them:

update_cmd = security

update_messages = yes

download_updates = yes

apply_updates = yes

emit_via = stdio

Enable and start the service:

# systemctl enable yum-cron.service

# systemctl start yum-cron.service
11. System Settings – Process Accounting

The package psacct contain utilities for monitoring process activities:

  1. ac – displays statistics about how long users have been logged on.
  2. lastcomm – displays information about previously executed commands.
  3. accton – turns process accounting on or off.
  4. sa – summarises information about previously executed commands.

Install and enable the service:

# yum install psacct

# systemctl enable psacct.service

# systemctl start psacct.service
1. Services – SSH Server

Create a group for SSH access as well as some regular user account who will be a member of the group:

# groupadd ssh-users

# useradd -m -s /bin/bash -G ssh-users tomas

Generate SSH keys for the user:

# su - tomas

$ mkdir --mode=0700 ~/.ssh

$ ssh-keygen -b 4096 -t rsa -C "tomas" -f ~/.ssh/id_rsa

Generate SSH host keys:

# ssh-keygen -b 4096 -t rsa -N "" -f /etc/ssh/ssh_host_rsa_key

# ssh-keygen -b 1024 -t dsa -N "" -f /etc/ssh/ssh_host_dsa_key

# ssh-keygen -b 521 -t ecdsa -N "" -f /etc/ssh/ssh_host_ecdsa_key

# ssh-keygen -t ed25519 -N "" -f /etc/ssh/ssh_host_ed25519_key

For RSA keys, 2048 bits is considered sufficient. DSA keys must be exactly 1024 bits as specified by FIPS 186-2.

For ECDSA keys, the -b flag determines the key length by selecting from one of three elliptic curve sizes: 256, 384 or 521 bits. ED25519 keys have a fixed length and the -b flag is ignored.

The host can be impersonated if an unauthorised user obtains the private SSH host key file, therefore ensure that permissions of /etc/ssh/*_key are properly set:

# chmod 0600 /etc/ssh/*_key

Configure /etc/ssh/sshd_config with the following:

# SSH port

Port 22

# Listen on IPv4 only


# Protocol version 1 has been exposed

Protocol 2

# Limit the ciphers to those which are FIPS-approved, the AES and 3DES ciphers

# Counter (CTR) mode is preferred over cipher-block chaining (CBC) mode

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc

# Use FIPS-approved MACs

MACs hmac-sha2-512,hmac-sha2-256,hmac-sha1

# INFO is a basic logging level that will capture user login/logout activity

# DEBUG logging level is not recommended for production servers

LogLevel INFO

# Disconnect if no successful login is made in 60 seconds

LoginGraceTime 60

# Do not permit root logins via SSH

PermitRootLogin no

# Check file modes and ownership of the user's files before login

StrictModes yes

# Close TCP socket after 2 invalid login attempts

MaxAuthTries 2

# The maximum number of sessions per network connection

MaxSessions 2

# User/group permissions


AllowGroups ssh-users

DenyUsers root

DenyGroups root

# Password and public key authentications

PasswordAuthentication no

PermitEmptyPasswords no

PubkeyAuthentication yes

AuthorizedKeysFile  .ssh/authorized_keys

# Disable unused authentications mechanisms

RSAAuthentication no # DEPRECATED

RhostsRSAAuthentication no # DEPRECATED

ChallengeResponseAuthentication no

KerberosAuthentication no

GSSAPIAuthentication no

HostbasedAuthentication no

IgnoreUserKnownHosts yes

# Disable insecure access via rhosts files

IgnoreRhosts yes

AllowAgentForwarding no

AllowTcpForwarding no

# Disable X Forwarding

X11Forwarding no

# Disable message of the day but print last log

PrintMotd no

PrintLastLog yes

# Show banner

Banner /etc/issue

# Do not send TCP keepalive messages

TCPKeepAlive no

# Default for new installations

UsePrivilegeSeparation sandbox

# Prevent users from potentially bypassing some access restrictions

PermitUserEnvironment no

# Disable compression

Compression no

# Disconnect the client if no activity has been detected for 900 seconds

ClientAliveInterval 900

ClientAliveCountMax 0

# Do not look up the remote hostname

UseDNS no

UsePAM yes

In case you want to change the default SSH port to something else, you will need to tell SELinux about it.

# yum install policycoreutils-python

For example, to allow SSH server to listen on TCP 2222, do the following:

# semanage port -a -t ssh_port_t 2222 -p tcp

Ensure that the firewall allows incoming traffic on the new SSH port and restart the sshd service.

2. Service – Network Time Protocol

CentOS 7 should come with Chrony, make sure that the service is enabled:

# systemctl enable chronyd.service
3. Services – Mail Server 3.1 Postfix

Postfix should be installed and enabled already. In case it isn't, the do the following:

# yum install postfix

# systemctl enable postfix.service

Open /etc/postfix/ and configure the following to act as a null client:

smtpd_banner = $myhostname ESMTP

inet_interfaces = loopback-only

inet_protocols = ipv4

mydestination =

local_transport = error: local delivery disabled

unknown_local_recipient_reject_code = 550

mynetworks =

relayhost = []:587

Optionally (depending on your setup), you can configure Postfix to use authentication:

# yum install cyrus-sasl-plain

Open /etc/postfix/ and add the following:

smtp_sasl_auth_enable = yes

smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd

smtp_sasl_security_options = noanonymous

smtp_tls_CApath = /etc/ssl/certs

smtp_use_tls = yes

Open /etc/postfix/sasl_passwd and put authentication credentials in a format of:


Set permissions and create a database file:

# chmod 0600 /etc/postfix/sasl_passwd

# postmap /etc/postfix/sasl_passwd

Restart the service and ensure that firewall allows outgoing traffic to the SMTP relay server.

3.2 Mail Distribution to Active Mail Accounts

Configure the file /etc/aliases to have a forward rule for the root user.

4. Services – Remove Obsolete Services

None of these should be installed on CentOS 7 minimal:

# yum erase xinetd telnet-server rsh-server \

  telnet rsh ypbind ypserv tfsp-server bind \

  vsfptd dovercot squid net-snmpd talk-erver talk

Check all enabled services:

# systemctl list-unit-files --type=service|grep enabled

Disable kernel dump service:

# systemctl disable kdump.service

# systemctl mask kdump.service

Disable everything that is not required, e.g.:

# systemctl disable tuned.service
5. Services – Restrict at and cron to Authorised Users

If the file cron.allow exists, then only users listed in the file are allowed to use cron, and the cron.deny file is ignored.

# echo root > /etc/cron.allow

# echo root > /etc/at.allow

# rm -f /etc/at.deny /etc/cron.deny

Note that the root user can always use cron, regardless of the usernames listed in the access control files.

6. Services – Disable X Windows Startup

This can be achieved by setting a default target:

# systemctl set-default
7. Services – Fail2ban

Install Fail2ban from the EPEL repository:

# yum install epel-release

# yum install fail2ban

If using iptables rather than firewalld, open the file /etc/fail2ban/jail.d/00-firewalld.conf and comment out the following line:

#banaction = firewallcmd-ipset

Fail2Ban uses /etc/fail2ban/jail.conf . Configuration snippet for SSH is provided below:


port    = ssh

enabled = true

ignoreip =

bantime  = 600

maxretry = 5

If you run SSH on a non-default port, you can change the port value to any positive integer and then enable the jail.

# systemctl enable fail2ban.service
# systemctl start fail2ban.service
8. Services – Sysstat to Collect Performance Activity

Sysstat may provide useful insight into system usage and performance, however, unless used, the service should be disabled, or not installed at all.

# yum install sysstat
# systemctl enable sysstat.service
# systemctl start sysstat.service

[Jun 09, 2017] Sneaky hackers use Intel management tools to bypass Windows firewall

Notable quotes:
"... the group's malware requires AMT to be enabled and serial-over-LAN turned on before it can work. ..."
"... Using the AMT serial port, for example, is detectable. ..."
"... Do people really admin a machine through AMT through an external firewall? ..."
"... Businesses demanded this technology and, of course, Intel beats the drum for it as well. While I understand their *original* concerns I would never, ever connect it to the outside LAN. A real admin, in jeans and a tee, is a much better solution. ..."
Jun 09, 2017 |
When you're a bad guy breaking into a network, the first problem you need to solve is, of course, getting into the remote system and running your malware on it. But once you're there, the next challenge is usually to make sure that your activity is as hard to detect as possible. Microsoft has detailed a neat technique used by a group in Southeast Asia that abuses legitimate management tools to evade firewalls and other endpoint-based network monitoring.

The group, which Microsoft has named PLATINUM, has developed a system for sending files -- such as new payloads to run and new versions of their malware-to compromised machines. PLATINUM's technique leverages Intel's Active Management Technology (AMT) to do an end-run around the built-in Windows firewall. The AMT firmware runs at a low level, below the operating system, and it has access to not just the processor, but also the network interface.

The AMT needs this low-level access for some of the legitimate things it's used for. It can, for example, power cycle systems, and it can serve as an IP-based KVM (keyboard/video/mouse) solution, enabling a remote user to send mouse and keyboard input to a machine and see what's on its display. This, in turn, can be used for tasks such as remotely installing operating systems on bare machines. To do this, AMT not only needs to access the network interface, it also needs to simulate hardware, such as the mouse and keyboard, to provide input to the operating system.

But this low-level operation is what makes AMT attractive for hackers: the network traffic that AMT uses is handled entirely within AMT itself. That traffic never gets passed up to the operating system's own IP stack and, as such, is invisible to the operating system's own firewall or other network monitoring software. The PLATINUM software uses another piece of virtual hardware-an AMT-provided virtual serial port-to provide a link between the network itself and the malware application running on the infected PC.

Communication between machines uses serial-over-LAN traffic, which is handled by AMT in firmware. The malware connects to the virtual AMT serial port to send and receive data. Meanwhile, the operating system and its firewall are none the wiser. In this way, PLATINUM's malware can move files between machines on the network while being largely undetectable to those machines.

PLATINUM uses AMT's serial-over-LAN (SOL) to bypass the operating system's network stack and firewall.

Enlarge / PLATINUM uses AMT's serial-over-LAN (SOL) to bypass the operating system's network stack and firewall. Microsoft

AMT has been under scrutiny recently after the discovery of a long-standing remote authentication flaw that enabled attackers to use AMT features without needing to know the AMT password. This in turn could be used to enable features such as the remote KVM to control systems and run code on them.

However, that's not what PLATINUM is doing: the group's malware requires AMT to be enabled and serial-over-LAN turned on before it can work. This isn't exploiting any flaw in AMT; the malware just uses the AMT as it's designed in order to do something undesirable.

Both the PLATINUM malware and the AMT security flaw require AMT to be enabled in the first place; if it's not turned on at all, there's no remote access. Microsoft's write-up of the malware expressed uncertainty about this part; it's possible that the PLATINUM malware itself enabled AMT-if the malware has Administrator privileges, it can enable many AMT features from within Windows-or that AMT was already enabled and the malware managed to steal the credentials.

While this novel use of AMT is useful for transferring files while evading firewalls, it's not undetectable. Using the AMT serial port, for example, is detectable. Microsoft says that its own Windows Defender Advanced Threat Protection can even distinguish between legitimate uses of serial-over-LAN and illegitimate ones. But it's nonetheless a neat way of bypassing one of the more common protective measures that we depend on to detect and prevent unwanted network activity. potato44819 , Ars Legatus Legionis Jun 8, 2017 8:59 PM Popular

"Microsoft says that its own Windows Defender Advanced Threat Protection can even distinguish between legitimate uses of serial-over-LAN and illegitimate ones. But it's nonetheless a neat way of bypassing one of the more common protective measures that we depend on to detect and prevent unwanted network activity."

It's worth noting that this is NOT Windows Defender.

Windows Defender Advanced Threat Protection is an enterprise product.

aexcorp , Ars Scholae Palatinae Jun 8, 2017 9:04 PM Popular
This is pretty fascinating and clever TBH. AMT might be convenient for sysadmin, but it's proved to be a massive PITA from the security perspective. Intel needs to really reconsider its approach or drop it altogether.

"it's possible that the PLATINUM malware itself enabled AMT-if the malware has Administrator privileges, it can enable many AMT features from within Windows"

I've only had 1 machine that had AMT (a Thinkpad T500 that somehow still runs like a charm despite hitting the 10yrs mark this summer), and AMT was toggled directly via the BIOS (this is all pre-UEFI.) Would Admin privileges be able to overwrite a BIOS setting? Would it matter if it was handled via UEFI instead? 1810 posts | registered 8/28/2012

bothered , Ars Scholae Palatinae Jun 8, 2017 9:16 PM
Always on and undetectable. What more can you ask for? I have to imagine that and IDS system at the egress point would help here. 716 posts | registered 11/14/2012
faz , Ars Praefectus Jun 8, 2017 9:18 PM
Using SOL and AMT to bypass the OS sounds like it would work over SOL and IPMI as well.

I only have one server that supports AMT, I just double-checked that the webui for AMT does not allow you to enable/disable SOL. It does not, at least on my version. But my IPMI servers do allow someone to enable SOL from the web interface.

xxx, Jun 8, 2017 9:24 PM
But do we know of an exploit over AMT? I wouldn't think any router firewall would allow packets bound for an AMT to go through. Is this just a mechanism to move within a LAN once an exploit has a beachhead? That is not a small thing, but it would give us a way to gauge the severity of the threat.

Do people really admin a machine through AMT through an external firewall? 178 posts | registered 2/25/2016

zogus , Ars Tribunus Militum Jun 8, 2017 9:26 PM
fake-name wrote:

Hi there! I do hardware engineering, and I wish more computers had serial ports. Just because you don't use them doesn't mean their disappearance is "fortunate".

Just out of curiosity, what do you use on the PC end when you still do require traditional serial communication? USB-to-RS232 adapter? 1646 posts | registered 11/17/2006

bthylafh , Ars Tribunus Angusticlavius Jun 8, 2017 9:34 PM Popular
zogus wrote:
Just out of curiosity, what do you use on the PC end when you still do require traditional serial communication? USB-to-RS232 adapter?
tomca13 , Wise, Aged Ars Veteran Jun 8, 2017 9:53 PM
This PLATINUM group must be pissed about the INTEL-SA-00075 vulnerability being headline news. All those perfectly vulnerable systems having AMT disabled and limiting their hack. 175 posts | registered 8/9/2002
Darkness1231 , Ars Tribunus Militum et Subscriptor Jun 8, 2017 10:41 PM
Causality wrote:
Intel AMT is a fucking disaster from a security standpoint. It is utterly dependent on security through obscurity with its "secret" coding, and anybody should know that security through obscurity is no security at all.
Businesses demanded this technology and, of course, Intel beats the drum for it as well. While I understand their *original* concerns I would never, ever connect it to the outside LAN. A real admin, in jeans and a tee, is a much better solution.

Hopefully, either Intel will start looking into improving this and/or MSFT will make enough noise that businesses might learn to do their update, provisioning in a more secure manner.

Nah, that ain't happening. Who am I kidding? 1644 posts | registered 3/31/2012

Darkness1231 , Ars Tribunus Militum et Subscriptor Jun 8, 2017 10:45 PM
meta.x.gdb wrote:
But do we know of an exploit over AMT? I wouldn't think any router firewall would allow packets bound for an AMT to go through. Is this just a mechanism to move within a LAN once an exploit has a beachhead? That is not a small thing, but it would give us a way to gauge the severity of the threat. Do people really admin a machine through AMT through an external firewall?
The interconnect is via W*. We ran this dog into the ground last month. Other OSs (all as far as I know (okay, !MSDOS)) keep them separate. Lan0 and lan1 as it were. However it is possible to access the supposedly closed off Lan0/AMT via W*. Which is probably why this was caught in the first place.

Note that MSFT has stepped up to the plate here. This is much better than their traditional silence until forced solution. Which is just the same security through plugging your fingers in your ears that Intel is supporting. 1644 posts | registered 3/31/2012

rasheverak , Wise, Aged Ars Veteran Jun 8, 2017 11:05 PM
Hardly surprising: ... armful.pdf

This is why I adamantly refuse to use any processor with Intel management features on any of my personal systems. 160 posts | registered 3/6/2014

michaelar , Smack-Fu Master, in training Jun 8, 2017 11:12 PM
Brilliant. Also, manifestly evil.

Is there a word for that? Perhaps "bastardly"?

JDinKC , Smack-Fu Master, in training Jun 8, 2017 11:23 PM
meta.x.gdb wrote:
But do we know of an exploit over AMT? I wouldn't think any router firewall would allow packets bound for an AMT to go through. Is this just a mechanism to move within a LAN once an exploit has a beachhead? That is not a small thing, but it would give us a way to gauge the severity of the threat. Do people really admin a machine through AMT through an external firewall?
The catch would be any machine that leaves your network with AMT enabled. Say perhaps an AMT managed laptop plugged into a hotel wired network. While still a smaller attack surface, any cabled network an AMT computer is plugged into, and not managed by you, would be a source of concern. 55 posts | registered 11/19/2012
Anonymouspock , Wise, Aged Ars Veteran Jun 8, 2017 11:42 PM
Serial ports are great. They're so easy to drive that they work really early in the boot process. You can fix issues with machines that are otherwise impossible to debug.
sphigel , Ars Centurion Jun 9, 2017 12:57 AM
aexcorp wrote:
This is pretty fascinating and clever TBH. AMT might be convenient for sysadmin, but it's proved to be a massive PITA from the security perspective. Intel needs to really reconsider its approach or drop it altogether.

"it's possible that the PLATINUM malware itself enabled AMT-if the malware has Administrator privileges, it can enable many AMT features from within Windows"

I've only had 1 machine that had AMT (a Thinkpad T500 that somehow still runs like a charm despite hitting the 10yrs mark this summer), and AMT was toggled directly via the BIOS (this is all pre-UEFI.) Would Admin privileges be able to overwrite a BIOS setting? Would it matter if it was handled via UEFI instead?

I'm not even sure it's THAT convenient for sys admins. I'm one of a couple hundred sys admins at a large organization and none that I've talked with actually use Intel's AMT feature. We have an enterprise KVM (raritan) that we use to access servers pre OS boot up and if we have a desktop that we can't remote into after sending a WoL packet then it's time to just hunt down the desktop physically. If you're just pushing out a new image to a desktop you can do that remotely via SCCM with no local KVM access necessary. I'm sure there's some sys admins that make use of AMT but I wouldn't be surprised if the numbers were quite small. 273 posts | registered 5/5/2010
gigaplex , Ars Scholae Palatinae Jun 9, 2017 3:53 AM
zogus wrote:
fake-name wrote:
blockquote Quote: blockquote

Hi there! I do hardware engineering, and I wish more computers had serial ports. Just because you don't use them doesn't mean their disappearance is "fortunate".

Just out of curiosity, what do you use on the PC end when you still do require traditional serial communication? USB-to-RS232 adapter?
We just got some new Dell workstations at work recently. They have serial ports. We avoid the consumer machines. 728 posts | registered 9/23/2011

GekkePrutser , Ars Centurion Jun 9, 2017 4:18 AM
Physical serial ports (the blue ones) are fortunately a relic of a lost era and are nowadays quite rare to find on PCs.
Not that fortunately.. Serial ports are still very useful for management tasks. It's simple and it works when everything else fails. The low speeds impose little restrictions on cables.

Sure, they don't have much security but that is partly mitigated by them usually only using a few metres cable length. So they'd be covered under the same physical security as the server itself. Making this into a LAN protocol without any additional security, that's where the problem was introduced. Wherever long-distance lines were involved (modems) the security was added at the application level.

[Jun 01, 2017] CVE-2017-1000367 Bug in sudos get_process_ttyname. Most linux distributions are affected

Jun 01, 2017 |

There is a serious vulnerability in sudo command that grants root access to anyone with a shell account. It works on SELinux enabled systems such as CentOS/RHEL and others too. A local user with privileges to execute commands via sudo could use this flaw to escalate their privileges to root. Patch your system as soon as possible.

It was discovered that Sudo did not properly parse the contents of /proc/[pid]/stat when attempting to determine its controlling tty. A local attacker in some configurations could possibly use this to overwrite any file on the filesystem, bypassing intended permissions or gain root shell.

... ... ...

A list of affected Linux distro
  1. Red Hat Enterprise Linux 6 (sudo)
  2. Red Hat Enterprise Linux 7 (sudo)
  3. Red Hat Enterprise Linux Server (v. 5 ELS) (sudo)
  4. Oracle Enterprise Linux 6
  5. Oracle Enterprise Linux 7
  6. Oracle Enterprise Linux Server 5
  7. CentOS Linux 6 (sudo)
  8. CentOS Linux 7 (sudo)
  9. Debian wheezy
  10. Debian jessie
  11. Debian stretch
  12. Debian sid
  13. Ubuntu 17.04
  14. Ubuntu 16.10
  15. Ubuntu 16.04 LTS
  16. Ubuntu 14.04 LTS
  17. SUSE Linux Enterprise Software Development Kit 12-SP2
  18. SUSE Linux Enterprise Server for Raspberry Pi 12-SP2
  19. SUSE Linux Enterprise Server 12-SP2
  20. SUSE Linux Enterprise Desktop 12-SP2
  21. OpenSuse, Slackware, and Gentoo Linux

[May 19, 2017] Google Found Over 1,000 Bugs In 47 Open Source Projects

May 14, 2017 |
( 43

Posted by EditorDavid on Saturday May 13, 2017 @11:34AM

Orome1 writes: In the last five months, Google's OSS-Fuzz program has unearthed over 1,000 bugs in 47 open source software projects ...

So far, OSS-Fuzz has found a total of 264 potential security vulnerabilities: 7 in Wireshark, 33 in LibreOffice, 8 in SQLite 3, 17 in FFmpeg -- and the list goes on...

Google launched the program in December and wants more open source projects to participate, so they're offering cash rewards for including "fuzz" targets for testing in their software.

"Eligible projects will receive $1,000 for initial integration, and up to $20,000 for ideal integration" -- or twice that amount, if the proceeds are donated to a charity.

[Jan 26, 2017] Penguins force-fed root Cruel security flaw found in systemd v228
Some Linux distros will need to be updated following the discovery of an easily exploitable flaw in a core system management component.

The CVE-2016-10156 security hole in systemd v228 opens the door to privilege escalation attacks, creating a means for hackers to root systems locally if not across the internet. The vulnerability is fixed in systemd v229.

Essentially, it is possible to create world-readable, world-writeable setuid executable files that are root owned by setting all the mode bits in a call to touch(). The systemd changelog for the fix reads:

basic: fix touch() creating files with 07777 mode

mode_t is unsigned, so MODE_INVALID < 0 can never be true.

This fixes a possible [denial of service] where any user could fill /run by writing to a world-writable /run/systemd/show-status.

However, as pointed out by security researcher Sebastian Krahmer, the flaw is worse than a denial-of-service vulnerability – it can be exploited by a malicious program or logged-in user to gain administrator access: "Mode 07777 also contains the suid bit, so files created by touch() are world writable suids, root owned."

The security bug was quietly fixed in January 2016 back when it was thought to pose only a system-crashing risk. Now the programming blunder has been upgraded this week following a reevaluation of its severity. The bug now weighs in at a CVSS score of 7.2, towards the top end of the 1-10 scale.

It's a local root exploit, so it requires access to the system in question to exploit, but it pretty much boils down to "create a powerful file in a certain way, and gain root on the server." It's trivial to pull off.

"Newer" versions of systemd deployed by Fedora or Ubuntu have been secured, but Debian systems are still running an older version and therefore need updating.

systemd is a suite for building blocks for Linux systems that provides system and service management technology. Security specialists view it with suspicion and complaints about function creep are not uncommon. ฎ

[Feb 11, 2015] GHOST: glibc vulnerability (CVE-2015-0235)

First of all this is kind of system error that is not easy to exploit. You need to locate the vulnerable functions in core image and be able to overwrite them via call (length of which any reasonable programmer will check). So whether this vulnerability is exploitable or not for applications that we are running is an open question.

In any case most installed systems are theoretically vilnerable. Practically too if they are running applications that do not check length for such system calls.

Only recently patched systems with glibc-2.11.3-17.74.13.x86_64 and above are not vulnerable.

[Oct 03, 2014] Everything you need to know about the Shellshock Bash bug

September 25, 2014 |
Remember Heartbleed? If you believe the hype today, Shellshock is in that league and with an equally awesome name albeit bereft of a cool logo (someone in the marketing department of these vulns needs to get on that). But in all seriousness, it does have the potential to be a biggie and as I did with Heartbleed, I wanted to put together something definitive both for me to get to grips with the situation and for others to dissect the hype from the true underlying risk.

To set the scene, let me share some content from Robert Graham's blog post who has been doing some excellent analysis on this. Imagine an HTTP request like this:

target =
port = 80
banners = true
http-user-agent = shellshock-scan (
http-header = Cookie:() { :; }; ping -c 3
http-header = Host:() { :; }; ping -c 3
http-header = Referer:() { :; }; ping -c 3

Which, when issued against a range of vulnerable IP addresses, results in this:

[Oct 03, 2014] Shellshock (software bug)

Analysis of the source code history of Bash shows that the vulnerabilities had existed undiscovered since approximately version 1.13 in 1992.[4] The maintainers of the Bash source code have difficulty pinpointing the time of introduction due to the lack of comprehensive changelogs.[1]

In Unix-based operating systems, and in other operating systems that Bash supports, each running program has its own list of name/value pairs called environment variables. When one program starts another program, it provides an initial list of environment variables for the new program.[14] Separately from these, Bash also maintains an internal list of functions, which are named scripts that can be executed from within the program.[15] Since Bash operates both as a command interpreter and as a command, it is possible to execute Bash from within itself. When this happens, the original instance can export environment variables and function definitions into the new instance.[16] Function definitions are exported by encoding them within the environment variable list as variables whose values begin with parentheses ("()") followed by a function definition. The new instance of Bash, upon starting, scans its environment variable list for values in this format and converts them back into internal functions. It performs this conversion by creating a fragment of code from the value and executing it, thereby creating the function "on-the-fly", but affected versions do not verify that the fragment is a valid function definition.[17] Therefore, given the opportunity to execute Bash with a chosen value in its environment variable list, an attacker can execute arbitrary commands or exploit other bugs that may exist in Bash's command interpreter.

The name "shellshock" is attributed[by whom?][not in citation given] to Andreas Lindh from a tweet on 24 September 2014.[18][non-primary source needed]

On October 1st, Zalewski released details of the final bugs, and confirmed that Florian's patch does indeed prevent them. Zalewski says fixed

CGI-based web server attack

When a web server uses the Common Gateway Interface (CGI) to handle a document request, it passes various details of the request to a handler program in the environment variable list. For example, the variable HTTP_USER_AGENT has a value that, in normal usage, identifies the program sending the request. If the request handler is a Bash script, or if it executes one for example using the system(3) call, Bash will receive the environment variables passed by the server and will process them as described above. This provides a means for an attacker to trigger the Shellshock vulnerability with a specially crafted server request.[4] The security documentation for the widely used Apache web server states: "CGI scripts can ... be extremely dangerous if they are not carefully checked."[20] and other methods of handling web server requests are often used. There are a number of online services which attempt to test the vulnerability against web servers exposed to the Internet.[citation needed]

SSH server example

OpenSSH has a "ForceCommand" feature, where a fixed command is executed when the user logs in, instead of just running an unrestricted command shell. The fixed command is executed even if the user specified that another command should be run; in that case the original command is put into the environment variable "SSH_ORIGINAL_COMMAND". When the forced command is run in a Bash shell (if the user's shell is set to Bash), the Bash shell will parse the SSH_ORIGINAL_COMMAND environment variable on start-up, and run the commands embedded in it. The user has used their restricted shell access to gain unrestricted shell access, using the Shellshock bug.[21]

DHCP example

Some DHCP clients can also pass commands to Bash; a vulnerable system could be attacked when connecting to an open Wi-Fi network. A DHCP client typically requests and gets an IP address from a DHCP server, but it can also be provided a series of additional options. A malicious DHCP server could provide, in one of these options, a string crafted to execute code on a vulnerable workstation or laptop.[9]

Note of offline system vulnerability

The bug can potentially affect machines that are not directly connected to the Internet when performing offline processing, which involves the use of Bash.[citation needed]

Initial report (CVE-2014-6271)

This original form of the vulnerability involves a specially crafted environment variable containing an exported function definition, followed by arbitrary commands. Bash incorrectly executes the trailing commands when it imports the function.[22] The vulnerability can be tested with the following command:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

In systems affected by the vulnerability, the above commands will display the word "vulnerable" as a result of Bash executing the command "echo vulnerable", which was embedded into the specially crafted environment variable named "x".[23][24]

There was an initial report of the bug made to the maintainers of Bash (Report# CVE-2014-6271). The bug was corrected with a patch to the program. However, after the release of the patch there were subsequent reports of different, yet related vulnerabilities. On 26 September 2014, two open-source contributors, David A. Wheeler and Norihiro Tanaka, noted that there were additional issues, even after patching systems using the most recently available patches. In an email addressed to the oss-sec list and the bash bug list, Wheeler wrote: "This patch just continues the 'whack-a-mole' job of fixing parsing errors that began with the first patch. Bash's parser is certain [to] have many many many other vulnerabilities".[25]
On 27 September 2014, Michal Zalewski announced his discovery of several other Bash vulnerabilities,[26] one based upon the fact that Bash is typically compiled without address space layout randomization.[27] Zalewski also strongly encouraged all concerned to immediately apply a patch made available by Florian Weimer.[26][27]


CVE-2014-6277 relates to the parsing of function definitions in environment variables by Bash. It was discovered by Michał Zalewski.[26][27][28][29]

This causes a segfault.

() { x() { _; }; x() { _; } <<a; }


CVE-2014-6278 relates to the parsing of function definitions in environment variables by Bash. It was discovered by Michał Zalewski.[30][29]

() { _; } >_[$($())] { echo hi mom; id; }


On the same day the bug was published, Tavis Ormandy discovered a related bug which was assigned the CVE identifier CVE-2014-7169.[21] Official and distributed patches for this began releasing on 26 September 2014.[citation needed] Demonstrated in the following code:

env X='() { (a)=>\' sh -c "echo date"; cat echo

which would trigger a bug in Bash to execute the command "date" unintentionally. This would become CVE-2014-7169.[21]

Testing example

Here is an example of a system that has a patch for CVE-2014-6271 but not CVE-2014-7169:

$ X='() { (a)=>\' bash -c "echo date"
bash: X: line 1: syntax error near unexpected token `='
bash: X: line 1: `'
bash: error importing function definition for `X'
$ cat echo
Fri Sep 26 01:37:16 UTC 2014

The patched system displays the same error, notifying the user that CVE-2014-6271 has been prevented. However, the attack causes the writing of a file named 'echo', into the working directory, containing the result of the 'date' call. The existence of this issue resulted in the creation of CVE-2014-7169 and the release patches for several systems.

A system patched for both CVE-2014-6271 and CVE-2014-7169 will simply echo the word "date" and the file "echo" will not be created.

$ X='() { (a)=>\' bash -c "echo date"
$ cat echo
cat: echo: No such file or directory


CVE-2014-7186 relates to an out-of-bounds memory access error in the Bash parser code.[31] While working on patching Shellshock, Red Hat researcher Florian Weimer found this bug.[23]

Testing example

Here is an example of the vulnerability, which leverages the use of multiple "<<EOF" declarations:

bash -c 'true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF' ||
echo "CVE-2014-7186 vulnerable, redir_stack"
A vulnerable system will echo the text "CVE-2014-7186 vulnerable, redir_stack".


CVE-2014-7187 relates to an off-by-one error, allowing out-of-bounds memory access, in the Bash parser code.[32] While working on patching Shellshock, Red Hat researcher Florian Weimer found this bug.[23]

Testing example

Here is an example of the vulnerability, which leverages the use of multiple "done" declarations:

(for x in {1..200} ; do echo "for x$x in ; do :"; done; for x in {1..200} ; do echo done ; done) | bash ||
echo "CVE-2014-7187 vulnerable, word_lineno"
A vulnerable system will echo the text "CVE-2014-7187 vulnerable, word_lineno".

Frequently Asked Questions about the Shellshock Bash flaws

Sep 26, 2014 |

Why are there four CVE assignments?

The original flaw in Bash was assigned CVE-2014-6271. Shortly after that issue went public a researcher found a similar flaw that wasn't blocked by the first fix and this was assigned CVE-2014-7169. Later, Red Hat Product Security researcher Florian Weimer found additional problems and they were assigned CVE-2014-7186 and CVE-2014-7187. It's possible that other issues will be found in the future and assigned a CVE designator even if they are blocked by the existing patches.

... ... ...

Why is Red Hat using a different patch then others?

Our patch addresses the CVE-2014-7169 issue in a much better way than the upstream patch, we wanted to make sure the issue was properly dealt with.
I have deployed web application filters to block CVE-2014-6271. Are these filters also effective against the subsequent flaws?

If configured properly and applied to all relevant places, the "() {" signature will work against these additional flaws.

Does SELinux help protect against this flaw?

SELinux can help reduce the impact of some of the exploits for this issue. SELinux guru Dan Walsh has written about this in depth in his blog.

Are you aware of any new ways to exploit this issue?

Within a few hours of the first issue being public (CVE-2014-6271), various exploits were seen live, they attacked the services we identified at risk in our first post:

We did not see any exploits which were targeted at servers which had the first issue fixed, but were affected by the second issue. We are currently not aware of any exploits which target bash packages which have both CVE patches applied.

Why wasn't this flaw noticed sooner?

The flaws in Bash were in a quite obscure feature that was rarely used; it is not surprising that this code had not been given much attention. When the first flaw was discovered it was reported responsibly to vendors who worked over a period of under 2 weeks to address the issue.

This entry was posted in Vulnerabilities and tagged bash, CVE-2014-6271, CVE-2014-6277, CVE-2014-6278, CVE-2014-7169, CVE-2014-7186, CVE-2014-7187, shellshocked by Huzaifa Sidhpurwala. Bookmark the permalink.

Update 2014-09-25 16:00 UTC

Red Hat is aware that the patch for CVE-2014-6271 is incomplete. An attacker can provide specially-crafted environment variables containing arbitrary commands that will be executed on vulnerable systems under certain conditions. The new issue has been assigned CVE-2014-7169.

We are working on patches in conjunction with the upstream developers as a critical priority. For details on a workaround, please see the knowledgebase article.

Red Hat advises customers to upgrade to the version of Bash which contains the fix for CVE-2014-6271 and not wait for the patch which fixes CVE-2014-7169. CVE-2014-7169 is a less severe issue and patches for it are being worked on.

Bash or the Bourne again shell, is a UNIX like shell, which is perhaps one of the most installed utilities on any Linux system. From its creation in 1980, Bash has evolved from a simple terminal based command interpreter to many other fancy uses.

In Linux, environment variables provide a way to influence the behavior of software on the system. They typically consists of a name which has a value assigned to it. The same is true of the Bash shell. It is common for a lot of programs to run Bash shell in the background. It is often used to provide a shell to a remote user (via ssh, telnet, for example), provide a parser for CGI scripts (Apache, etc) or even provide limited command execution support (git, etc)

Coming back to the topic, the vulnerability arises from the fact that you can create environment variables with specially-crafted values before calling the Bash shell. These variables can contain code, which gets executed as soon as the shell is invoked. The name of these crafted variables does not matter, only their contents. As a result, this vulnerability is exposed in many contexts, for example:

Like "real" programming languages, Bash has functions, though in a somewhat limited implementation, and it is possible to put these Bash functions into environment variables. This flaw is triggered when extra code is added to the end of these function definitions (inside the enivronment variable). Something like:

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
 this is a test

The patch used to fix this flaw, ensures that no code is allowed after the end of a Bash function. So if you run the above example with the patched version of Bash, you should get an output similar to:

 $ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
 bash: warning: x: ignoring function definition attempt
 bash: error importing function definition for `x'
 this is a test

We believe this should not affect any backward compatibility. This would, of course, affect any scripts which try to use environment variables created in the way as described above, but doing so should be considered a bad programming practice.

Red Hat has issued security advisories that fixes this issue for Red Hat Enterprise Linux. Fedora has also shipped packages that fixes this issue.

We have additional information regarding specific Red Hat products affected by this issue that can be found at

Information on CentOS can be found at

[Sep 29, 2014] Shellshock: How to protect your Unix, Linux and Mac servers By Steven J. Vaughan-Nichols

Fortunately, all the major Linux vendors quickly issued patches, including Debian, Ubuntu, Suse and Red Hat.

The only thing you have to fear with Shellshock, the Unix/Linux Bash security hole, is fear itself. Yes, Shellshock can serve as a highway for worms and malware to hit your Unix, Linux, and Mac servers, but you can defend against it.

The real and present danger is for servers. According to the National Institute of Standards (NIST), Shellshock scores a perfect 10 for potential impact and exploitability. Red Hat reports that the most common attack vectors are:

So much for Red Hat's thoughts. Of these, the Web servers and SSH are the ones that worry me the most. The DHCP client is also troublesome, especially if, as it the case with small businesses, your external router doubles as your Internet gateway and DHCP server.

Of these, Web server attacks seem to be the most common by far. As Florian Weimer, a Red Hat security engineer, wrote: "HTTP requests to CGI scripts have been identified as the major attack vector." Attacks are being made against systems running both Linux and Mac OS X.

Jaime Blasco, labs director at AlienVault, a security management services company, ran a honeypot looking for attackers and found "several machines trying to exploit the Bash vulnerability. The majority of them are only probing to check if systems are vulnerable. On the other hand, we found two worms that are actively exploiting the vulnerability and installing a piece of malware on the system."

Other security researchers have found that the malware is the usual sort. They typically try to plant distributed denial of service (DDoS) IRC bots and attempt to guess system logins and passwords using a list of poor passwords such as 'root', 'admin', 'user', 'login', and '123456.'

So, how do you know if your servers can be attacked? First, you need to check to see if you're running a vulnerable version of Bash. To do that, run the following command from a Bash shell:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

If you get the result:

vulnerable this is a test

Bad news, your version of Bash can be hacked. If you see:

bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x' this is a test

You're good. Well, to be more exact, you're as protected as you can be at the moment.

Updated information on the bash fixes.
Sep 26, 2014 |

We have fixed the critical issue CVE-2014-6271 ( with updates for all supported and LTSS code streams.

SLES 10 SP3 LTSS, SP4 LTSS, SLES 11 SP1 LTSS, SLES 11 SP2 LTSS, SLES 11 SP3, openSUSE 12.3, 13.1.

The issue CVE-2014-7169 ( is less severe (no trivial code execution) but will also receive fixes for above. As more patches are under discussions around the bash parser, we will wait some days to collect them to avoid a third bash update.

Why I Hate Linux CSO Blogs

I also hate Linux. Maybe it's not Linux in particular, maybe I hate all computer systems when it really comes down to it. But this is my list of reasons why:

Unix Skills are Special Skills

Sounds like a marketing brochure for the competition, doesn't it? Fact of the matter is that right now, I spend entirely too much of my time doing personnel management. If I can put out a requisition to hire somebody and have them working for me in 3 weeks, then it makes my job that much easier.

This has always been a double-edged sword. Linux expects that you know what you are doing, even if it's a dumb thing to do--it's non-judgemental. Non-Unix systems expect that you will do dumb things and refuses to do them. I still don't know which one of these is better.

All-Or-Nothing Admin Privileges

You're either root or you're not. Sudo and selinux aside, this is the basic model that we've always had, installed by default. Anything else is like middleware--yeah, you can connect the dots, but how much time and effort is it going to take?

Project Viability

There are tons of applications out there in the Linux world. Some are very, very good and very, very viable. The Linux kernel, apache, and a couple databases come to mind. That's easy to point to. But then there is this seedy underworld of code. This is software is pure junk. If I'm not initiated into Freshmeat-foo (ranking, version, vitality, and popularity), then I can't tell the difference between these two poles of the spectrum. This means that I cannot assess what my level of risk is (both security and project-wise) when I choose a particular piece of software-was it developed professionally with QA standards and security code review or by a 14-year-old in his parents' basement?

Speed of Development

As an operations guy, I like slow and steady, as long as vulnerabilities get patched. With the speed of development that most viable open-source projects have, it is hard to keep up with all the different places that you can get vulnerability notices from. Usually you get these filtered through the distribution, but then again, you have the same ad-hoc processes. Like "Black Tuesday" or not, it does make sense in a twisted sort of operational mindset.

Who Is Responsible for Linux Security?

As a business, I put a security contact at each level of the "solution stack". I have a counterpart to the CSO, the business owners, the governance framework, the architecture group, the network engineers, the server engineers, and the application engineers. What is the corresponding structure in the Linux world? Most major distributions have a security team, but when it comes to the applications themselves, it's hit and miss.

I run fedora and on *many* message boards I see the first trouble shooting idea is to turn off SELinux. What most people forget is that you can set SELinux to be permissive, so it is still turned on, and it lets you know when applications would be doing something that would be prevented. I think changing to permissive mode SELinux is more useful than turning it off as it lets you know what applications are misbehaving. I think part of this problem is that previously there has been no easy way to look as SELinux messages and manage the policies.

The main disadvantage of AppArmor is that it relies on file paths, not the inodes. All you need to do is be able to create a hard link in the right directory to get around it.


Permissive mode is only useful for policy development.

I wholeheartedly agree.
Step 1: Install RHEL, disable SELinux
Step 2: Install and configure your stack (apache, jboss, tomcat, mysql, whatever)
Step 3: Enable permissive mode, light up the stack, watch logs
Step 4: Tweak the rules, repeat step 3 until the logs are clean.
Step 5: Enable Enforcing Mode

You can now rest a little bit easier knowing that you have SELinux enabled. The only drawback is that you sometimes have to repeat the process as new versions of your stack are released (mysql, jboss). It's basically a monthly process.

[Oct 31, 2009] 20 Linux Server Hardening Security Tips

Nothing special but still not completely useless... Demonstrates average level of misunderstanding of security

Securing your Linux server is important to protect your data, intellectual property, and time, from the hands of crackers (hackers). The system administrator is responsible for security Linux box. In this first part of a Linux server security series, I will provide 20 hardening tips for default installation of Linux system. Project details for Lynis


Security and system auditing tool

Project information
Lynis is an auditing tool for Unix (specialists). It scans the system configuration and creates an overview of system information and security issues usable by professional auditors.

This software has not the intention to be an all round solution for creating a "safe system", but to assist in automated audits. The software can be used in addition to other software, like security scanners, system benchmarking and finetuning tools.

Intended audience: security specialists, system auditors, system/network managers

Current state:
Stable releases are available, development is still in progress.

Changelog - Present in tarball
FAQ - Present in tarball
Logging support - Builtin
Report creation - Builtin
Man page - Present in tarball
Readme - Present in tarball

System requirements:
- Compatible operating system (see 'Supported operating systems')
- Default shell
Supported operating systems
Tested on:
- CentOS 5
- Debian 4.0
- Fedora Core 4
- FreeBSD 6.2
- Mac OS X 10.4
- OpenBSD 4.2
- OpenSuSE

Currently unsupported:
- All others (though some will work)

(did it work on your operating system? Let me know!)

Chapter 8. Basic Security

SLES Security Guide (1993)

Linux system auditing by example by Emily Ratliff

A case study in scripting for system audit compliance
30 Apr 2007
Think you have a secure Linuxฎ system? Following best practices during installation and setup is a must, but if you haven't set up regular system auditing, you're missing half the picture. This article discusses some existing tools and offers a couple of sample scripts to automate the process in a real-world environment.

Many articles and books have been written on how to install a secure Linux system. But once the system has been installed to meet security requirements, only half the battle is won. The second half involves ensuring that the system continues to meet its security requirements throughout its lifetime (and that you can prove it). This means that periodic system auditing is required to make sure that nothing goes wrong.

System audit requirements

The security requirements that you verify during routine system auditing should be the same requirements and security principles that guide the system installation. The three-part developerWorks series "Securing Linux" gives you an introduction on how to install a reasonably secure Linux system. Regular system auditing will also help refine the security policy used for new machine installations as it helps close the feedback loop on what subsystems are actually in use.

The first tools for meeting these requirements are system auditing and host-based intrusion detection. This article focuses on system auditing. Host-based intrusion detection systems such as tripwire, AIDE, and Samhain detect when changes have been made to the file system and are therefore critical tools for ensuring that the system retains its known state. The Linux Gazette has an interesting article, "Constructive Paranoia," on using these tools (see Resources section below for a link).

This article focuses specifically on the practical aspects of periodic system auditing based on real-world requirements from a system administrator of a subnet in a large academic network. The lessons learned by this administrator apply to everyone from business intranets to home users who want to prevent their home machine from becoming a zombie in the bot army. The administrator's system is required to undergo periodic, random system audits, during which routine audit activities (such as showing that the audit and system logs are regularly reviewed, and checking for user accounts that have lapsed), In addition, the administrator also has to address the following:

What are all those suid files for?

Identifying the suid and sgid files on your system - and disabling the unnecessary ones - is one of the fundamental rules of installing a secure system. This task is so common that the man page for find lists the parameters for this in its examples. Listing 1 is a script that executes the typical find command and also helps answer the question of what the suid file does and what package it belongs to, in order to help the administrator to identify it, and decide if it should stay on the system or be removed. (You can download the code for Listings 1, 3, and 4 from the zip file in the section later in this article.)

Listing 1. Abbreviated sample output on suid/sgid files
[root@localhost hpc]# ./ /
04755 root /usr/X11R6/bin/cardinfo
       cardinfo - PCMCIA card monitor and control utility for X

04755 root /usr/bin/opiepasswd
       opiepasswd -  Change or set a user's password for the
       OPIE authentication system.

04755 root /usr/bin/opiesu
       opiesu  -  Replacement  su(1)  program that uses OPIE challenges

04755 root /usr/bin/sudo
       sudo - execute a command as another user

Which file systems contain world writable directories?

As an administrator, you might be interested in world writable directories to meet the requirement that all user-writable file systems be mounted with the nosuid attribute. User-writable directories include users' home directories as well as any world writable directories. This requirement is in place to prevent users from creating suid executables that another user or administrator might inadvertently execute. However, if a legitimate suid executable is on the same file system as a world writable directory and is thus mounted nosuid, the suid bits are ignored and the executable will not operate correctly. You might consider implementing this restriction on your multi-user systems as well.

The script in Listing 1 also tests each regular file system for world writable directories and reports whether the file system contains a world writable directory at the end of the output. For each suid/sgid file, it also reports whether the file is on a filesystem that contains world writable directories.

Abbreviated example output on world writable directories:
/ Contains both suid/sgid files and world writable directories.

What network ports does the system use and for what purpose?

There are several ways to detect which ports are in use on your system. Nmap, netstat, and lsof are the most helpful tools.

Kurt Seifried maintains a listing of 8,457 commonly used ports. (A link to his ports list is in the Resources below.) You can use this data to help explain what the port is being used for and what the impact would be of firewalling it off. He includes information about ports that are commonly used for trojans and root kits; for example, 31337 is commonly used by Back Orifice and 12345, 12346, and 20034 are used by netbus.

Listing 2 contains a script that uses lsof and netstat to show the system's current port usage in an easily readable format.

Listing 2. Sample output from
[root@localhost hpc]# ./
  please wait...
PORT              SERVICE         LINK
22                sshd
25                sendmail
123               ntpd
631               cupsd
46336 <-> 22      ssh             **

In Listing 2, the low-number ports (<1024) indicate daemons running on the system that accept incoming communication unless firewalled off. The high-number port 46336 shows an outgoing ssh connection and the port (22) that it is connected to on the other end. This means that blocking outbound communication on ephemeral ports will break commonly used client programs such as ssh. See Kurt's ports list in Resources for more details on the effects of firewalling the higher-number ports.

These scripts and tools show port usage at a point in time. The audit subsystem can be used to find out which ports have been used (for the duration of the audit log files) even if they are not currently in use. Adding the following audit rule to /etc/audit.rules will log calls to bind.

-a entry,always -S socketcall -F a0=2

The parameter -a entry,always indicates that the rule should always be invoked at the beginning of the system call execution. The -S socketcall indicates that this audit rule is for the socketcall syscall. The socketcall syscall is multiplexed on the i386 architecture, so the -F a0=2 is required to limit the audit records generated to bind only.

Other architectures handle the bind system call differently, so these commands and scripts will have to be altered slightly to handle architectures other than i386. Audit events are recorded as multiple audit records that are correlated by a shared serial number. ausearch will correlate the related records using the serial number and present them as a group. The -i flag requests that numeric values, indicating, for example, that saddr (IP address) and uid (user name) be translated to human readable text when possible.

Listing 3. Abbreviated output from ausearch
# ausearch -i -sc socketcall
Abbreviated example output
type=SOCKETCALL msg=audit(11/20/2006 11:28:43.844:10) : nargs=3 a0=0
a1=b8004004 a2=10
type=SOCKADDR msg=audit(11/20/2006 11:28:43.844:10) : saddr=inet
host: serv:631
type=SYSCALL msg=audit(11/20/2006 11:28:43.844:10) : arch=i386
syscall=socketcall(bind) success=yes exit=0 a0=2 a1=bfffaca0 a2=b8000664
a3=1 items=0 pid=3340 auid=unknown(4294967295) uid=root gid=root euid=root
suid=root fsuid=root egid=root sgid=root fsgid=root comm=cupsd
type=SOCKETCALL msg=audit(11/20/2006 16:40:46.169:16) : nargs=3 a0=6
a1=b8056720 a2=10
type=SOCKADDR msg=audit(11/20/2006 16:40:46.169:16) : saddr=inet
host: serv:123
type=SYSCALL msg=audit(11/20/2006 16:40:46.169:16) : arch=i386
syscall=socketcall(bind) success=yes exit=0 a0=2 a1=bffff9a0 a2=b80004a8
a3=6 items=0 pid=3523 auid=unknown(4294967295) uid=root gid=root euid=root
suid=root fsuid=root egid=root sgid=root fsgid=root comm=ntpd

This output shows that each call to bind generated three audit records. The first record type is the SOCKETCALL record, which shows the number and value of the arguments passed to bind on entry. The second record type is the SOCKADDR record, which shows the host by IP address and the port used. The third record type is the SYSCALL record, which shows whether the call to bind was successful, the arguments upon exit, gives the process ID, file executed, and shows the effective and real user and group information of the process that made the call. For our purposes, we are interested mostly in the serv: part of the SOCKADDR record, which documents the port used and the exe= field of the SYSCALL record, which documents the program that made the call to bind.

Listing 4 contains a simple script using sed and awk to compress the output of ausearch down to only the non-duplicated (time omitted) executable and port number fields.

Listing 4. Sample output from
[root@localhost hpc]# ./
22      /usr/sbin/sshd
123     /usr/sbin/ntpd
123     /usr/sbin/ntpdate
631     /usr/sbin/cupsd

This article introduced some tools and techniques that can help you maintain your system's adherence to its security policy. It also gave you some simple scripts to help parse system data into an easily readable format that can help you prove the security status of the system quickly and easily to anyone less familiar with the tools and system. I hope that you can use these simple tools and techniques to create your own scripts to periodically test the security stance of your systems.


Many thanks to Kylene Hall, Dustin Kirkland, Flavio Ivan da Silva, Rodrigo Rubira Branco, and Flavio C. Buccianti for their code, suggestions, and hard work on this article.

[Jan 06, 2004] Managing Linux Security Effectively in 2004 By Benjamin D. Thomas

This article examines the process of proper Linux security management in 2004. First, a system should be hardened and patched. Next, a security routine should be established to ensure that all new vulnerabilities are addressed. Linux security should be treated as an evolving process.


As Linux continues to gain popularity in the business world, security issues are something that cannot be ignored. In 2003, several well known Linux distributors had servers compromised. In one particular case, the vulnerability was well known in advance, but most vendors took entirely too much time to release an update. Similarly, most security problems that users face are known well in advance. As with any system, security on Linux is a process. It requires full commitment and due diligence. The secret is determining your own vulnerabilities and fixing them before anything catastrophic happens.

Although Linux security is entirely in the hands of system administrators, several improvements have been made at the kernel level. With the release of kernel version 2.6, users will now be able to take advantage of the Linux Security Module allowing greater levels of security customization, modularization, and ease of management. Another thing that has changed in the past several years is that today more of us are reliant on automated software update services. Rather than download and install patches manually, it is now easier to subscribe to a trusted source and let the system manage itself. As long as the integrity of the trusted source remains strong, automated management works flawlessly. As soon as something questionable happens, it is necessary to re-evaluate.

Solve the Problem

Addressing Linux security is like solving any problem. It must be approached with a purpose and plan. If you have been using Linux and neglecting security, it is now time to face it head on. Although the task may seems daunting in the beginning, it will soon be apparent that securing a Linux system is actually very strait forward.

In general security can be summed up into several steps. First, live by the minimum necessary rule. For example, turn off all unnecessary services, remove all programs that are not being used, and only give access when it is absolutely critical to a particular job function. Taking this simplistic approach will not only increase security, but over time will make life easier. It will eventually mean less stale-accounts to remove, less software to patch, and greater system performance.

Next, keep a software inventory of all versions used. Use this information to conduct the research necessary to ensure that all have been patched appropriately. Doing this, will greatly reduce the risk of being compromised by a known vulnerability. As simple as it may sound, doing this will make the system no longer an easy target, therefore be much less likely compromised. Unless the attacker is highly motivated highly sophisticated a hardened system will not be appealing.

Because most organizations have tens to hundreds of systems to manage, living by the minimum necessary rule, and establishing a security patch baseline is not always easy. The only way to approach Linux security is by developing a detailed plan. If server roles can be modularized, it may be much easier to determine what software is actually necessary for operation. Similarly, if multiple Web servers are on the network, they should all have the same basic set of software which again makes management easier. Planning for security, rather than trying to bolt it on after implementation is the key to success.

Setup a Routine

After a security plan is established and well underway, it also necessary to have a security routine. Security patches are released daily and your organization must have a way to deal with these. Hardening a system will only ensure a high level of security a single point in time. As time moves forward and vulnerabilities are discovered and exploits are made public, the system will become more vulnerable each day. To address this, it is necessary to monitor mailing lists, subscribe to our newsletter Linux Advisory Watch, or subscribe to an automated patch management system. When evaluating Linux distributions, it is important to take into account the frequency, timeliness, and reliability of security updates. Unfortunately, some distributions have been known to only release updates every several months in inconsistent intervals. Others are very good and release patches very soon after the vulnerability is known.

Some may wish to apply security updates daily, but it is probably more reasonable to apply them weekly. Of course, exceptions should be made for very critical updates. If production servers are going to be updated, it is advisable to first try them out in a testing environment. This is to minimize any damage that a flawed patch may cause. Also, do not forget to check the MD5 checksums of all downloaded patches. This can be done easily using the command-line tool 'md5sum.' To ensure overall system integrity, it is beneficial to a tool such as tripwire.

Being the new year, it is now the best time to establish a routine. Excuses can always be made, but now is the best time to start. Determine what is necessary to keep your systems operating securely, and pick a day each week to devote to this. Time should be spent applying security patches, reviewing logs, reviewing active user accounts, and looking for anomalies. Devoting just a little time specifically security each week can make a huge difference. It is always better to address problems before they crop up.

Concluding Remarks

Security requires both dedication and commitment. 2004 can be a good year if you expect security problems and then develop specific plans to address each of them. After the basics have been addressed, now is the time to establish a routine that will ensure security is addressed on a reoccurring basis rather than waiting for problems to surface. To maintain proper Linux security, it must be a regular part of an organization's operational maintenance. Being the beginning of a new year, it is now the perfect time to establish routines that will promote greater security. Linux is a wonderful operating system and holds a huge amount of potential. Security should not be major concern as long as it is handled properly.

Benjamin Thomas is a long time contributor to and EnGarde Secure Linux.

Linux Today - Linux Vs. Windows CeBIT Panelists Weigh The OS

Linux Vs. Windows: CeBIT Panelists Weigh The OS
May 28, 2004, 21 :15 UTC (6 Talkback[s]) (3388 reads)
(Other stories by Jacqueline Emigh)

By Jacqueline Emigh
Linux Today Correspondent

Do Linux security exploits really belong in the same league as Windows security holes? Are OpenOffice and its derivatives actually as good as Microsoft Office? These are just a couple of the questions debated this week by a panel of experts at the CeBIT America show in New York City.

Comparing Linux and Windows security amounts to a "chicken and egg" issue, according to Kathy Ivens, an author and consultant.

Given that Linux is a more secure environment, it's tough to know whether this is because Linux is "inherently more secure," or because Windows is still the more prevalent environment, Ivens said, during a panel moderated by Paul Gillin, VP of Editorial at TechTarget.

Also during the session, Nicholas Petreley, an analyst and consultant at Evans Data, contended that regardless of the numbers of exploits per platform, Windows exploits are often much more severe. Citing materials produced by Microsoft itself, Petreley said that many of the growing population of worms targeting Windows let outside hackers "completely take over" a server.

In contrast, Linux exploits are generally more limited in scope, and more likely to lend themselves to insider attacks, Petreley suggested. One Linux exploit, for instance, permits information in Firebird servers to be overwritten.

Generally speaking, though, Windows is still easier to administer, according to several of the panelists. "That's where Linux is behind, especially in directory services," Petreley observed.

Jon "Maddog" Hall, president and executive director of Linux International, pointed to third-party tools, available from vendors such as IBM and Computer Associates (CA), for managing Linux along with MVS and Unix, for example.

"In enterprise environments, that's what (you're) looking for," said Hall. Yet, he admitted, companies need to pay for such tools.

"(Administrative) controls are a lot better (in Windows)," Ivens asserted, citing printer set-up as one example.

Meanwhile, other panelists pointed to freely available Linux tools such as Samba.

What about Linux on the desktop? OpenOffice and its derivatives lack some of the features of Microsoft Office, according to Mark Minasi, a writer and consultant

Petreley, though, argued that EI (Evermore Integrated) Office, an office suite from Evermore Software, contains a similar feature set to Microsoft Office. Unlike Microsoft Office, however, EI Office doesn't allow anti-aliasing of fonts, he acknowledged, attributing this distinction to a decision by authors of the Java-based program to reduce overhead. EI Office runs on both Linux and Windows.

OpenOffice types of suites also tend to come with fewer fonts, indicated Hall. One rather obvious reason is that some font creators charge for the fonts, according to Hall.

On an overall basis, Linux applications still lack the "fit and finish" of Windows apps, Minasi charged. To gain more traction on the desktop, Linux needs a better GUI, he insisted.

Ivens, however, argued that GUIs aren't necessarily the way to go for all applications. In fact, some database and accounting apps have actually taken performance hits from the advent of the Windows GUI.

"There's no reason to have a GUI to punch in numbers," Ivens said. She harkened back to the days when the MAS 90 accounting system was at its zenith. Back then, MAS 90 was sold in Unix and DOS flavors. "My clients loved it," according to Ivens.

Ivens would also like to see fewer features in today's office suites. Microsoft Office, she quipped, seems to be evolving under an illusion in Redmond that "everyone in the world is collaborating on a single document."

Yet most users take advantage of only a small fraction of Office features, and migration to Microsoft Office 2003 has been particularly slow, Ivens observed.

In terms of third-party desktop applications, Linux is now starting to catch up with Windows, panelists generally concurred. Quicken, for instance, is now available for Linux, said Hall.

Desktop gaming, however, is one area where Linux still lags, according to Petreley. Yet with increasing improvements to game consoles such as Game Cube, more consumers are migrating from Windows-based PC games to consoles.

On the other hand, Windows doesn't necessarily hold much of an edge when it comes to ease of installation, according to the CeBIT panelists. Many users don't know how tricky Windows can be to install, since Windows still comes pre-installed on most PCs, members of the CeBIT audience were told.

Hall said that he'll be more than happy if Linux ultimately captures 30 percent of the desktop space.

"Competition is good," he declared. Hall reasoned that, as a result, no operating system -- not even Linux -- should totally dominate any market.

Linux Today - Builder AU Oracle to Switch Its Programmers to Linux

"Oracle will finish switching its 9,000-person in-house programming staff to Linux by the end of 2004, the database powerhouse said Wednesday.

"In October, the company finished the Linux transition for the 5,000 programmers of its Oracle Applications software. Now the transformation has begun for those who work on the database product, said Wim Coekaerts, director of Linux engineering, in an interview at the CeBit trade show in New York..." - IBM's Linux Push

With the release of Linux version 2.6, Linux scalability has leapt to the point where it will support deployment on 32-way SMP machines. IBM sees this, rightly in my opinion, as an opportunity to sell Linux based solutions into an area of usage from which it had previously been excluded. This means big ERP, CRM and SCM implementations (using SAP, PeopleSoft et al). It also means big database implementations and big app server implementations. This is also an area where the 64-bit implementations of Linux will deliver value.

According to Adam Jollans, who is part of IBM's Linux Marketing Strategy team, the adoption of Linux is happening most quickly in Banking, Government and Retail, followed by sectors that use scientific or engineering applications (automotive, pharmaceuticals, life sciences, education etc.) This is unusual in some respects as the Banking industry is normally an early adopter of technology whereas Government is normally a late adopter, but these two sectors appear to be driving Linux adoption along with Retail.

Government qualifies as a special case, since many governments now see in Linux the possibility of stimulating a local IT software industry and are doing what they can to stimulate the growth of Linux skills. And naturally, IBM is doing what it can to associate itself with many of these initiatives, having set up competence centres in Moscow, Beijing and Romania and offering support for Linux based government initiatives wherever it can.

IBM is also active in stimulating Linux adoption among ISVs and Business Partners, offering incentives to migrate to Linux, which vary from market development funding and marketing assistance to big discounts on IBM Linux-based software. This is not so much a new initiative, as IBM has been enabling the Linux community for many years now, just a more aggressive push than before.

IBM also has many developers working on Linux and other key Open Source projects. Currently the count is at about 500, which if you think about it, represents a large on-going investment. However, there can be little doubt that IBM is getting an adequate return, and in any event it has another axe to grind.

IBM's "On Demand" initiative will be far more likely to deliver results if a single standard operating system emerges in the coming years. As far as I can tell, this looks likely to happen and it will be the horse that IBM is so clearly backing; Linux.

IT-Analysis Linux To Become A De Facto Standard

Linux Today

IBM, Hewlett-Packard and Sun Microsystems, among others, are creating an imperative. Their infrastructure initiatives, entitled respectively; On Demand, Adaptive Enterprise and N1, are all quite similar and aimed at the idea of virtualising the hardware layer. The primary reason for wanting to virtualise hardware is this; in the last five years or so companies have been buying servers in an ad hoc manner, tending to deploy them on a one server per application basis.

Consequently, they assembled server farms which turn out to have an average hardware utilization of about 20 percent. This is, of course, a waste of money and, in the long run, a management headache. However there are other imperatives, particularly the idea of being able to provide infrastructure as a service - dynamically, i.e. you pay for what you use and you get what you need when you need it.

So companies, especially large companies, are very receptive to the idea of corporate computer resource that is both managed and efficient - which is what IBM, HP and Sun are talking about. However, if you talk the talk you are also going to have to walk the walk, and right now, what can be delivered doesn't amount to wall-to-wall virtualisation - or anything like it.

So the question is: How is it ever going to be delivered - given legacy systems, existing server farms and the enormous difficulty involved in relocating applications in a heterogeneous network.

Blade technology, grid computing, automatic provisioning, SANs, NAS and so forth will play a part in this, but for it to work, and work well, it will require a standard OS - and there is only one candidate - Linux.

The easiest way to see the need for a standard OS is to consider why and how TCP/IP became a standard. It didn't happen because it was the best option or because it was purpose designed to run a world-wide network with hundreds of millions of nodes (it wasn't). It happened because it was the only reasonable choice at the time. The same is now true of Linux as regards hardware virtualisation. Irrespective of its other qualities, it is the only one that fits the bill.

It qualifies because it spans so many platforms - from small devices up to IBM's zSeries mainframe. It also qualifies because, like TCP/IP, it doesn't actually belong to anyone. It runs on most chips and is rapidly becoming the developer platform of choice. So the idea is starting to emerge that you virtualise storage by the use of SANs and NAS and you virtualise server hardware by the use of Linux - thus making it feasible to switch applications from one server to another automatically, and quickly. Within this capability you can cater for failover and make highly efficient use of resources.

This doesn't solve all the problems of virtualisation - and there are many, including legacy hardware that will never run Linux and legacy applications that will never run on Linux. But this doesn't actually matter. In the short run they'll get excluded from virtualisation and in the long run, they cease to exist.

The momentum is building and Linux is set to become the standard OS for hardware virtualisation in large networks. Other OSes may eventually have to impersonate the characteristics of Linux or move aside.

[Nov 15, 2002] Study Linux' Security Problems Outstrip Microsoft's

NewsFactor Network

Open source software has surpassed Microsoft software in terms of security problems, according to an Aberdeen Group report.

"Open source software, commonly used in many versions of Linux, Unix, and network routing equipment, is now the major source of elevated security vulnerabilities for IT buyers," the report stated.

The research cited a list of advisories published by the Computer Emergency Response Team (CERT), a federally funded research and development center operated by Carnegie Mellon University.

The CERT report claims that security alerts for open source and Linux software accounted for 16 out of the 29 advisories published during the first 10 months of 2002. During those same 10 months, only seven security problems were documented in Microsoft products.

Trojan Horses and Viruses

Microsoft applications have made significant progress in avoiding virus and Trojan horse problems, according to CERT. The number of such advisories peaked in 2001 at six, but none were posted during the first 10 months of 2002.

Virus and Trojan horse advisories for Unix, Linux and open source software went from one in 2001 to two in the first 10 months of 2002.

To fully understand these figures, it is important to understand CERT's criteria for issuing an advisory, Aberdeen Group research director and report co-author Eric Hemmendinger told NewsFactor.

For example, although several viruses that affect Microsoft products have been reported this year, such threats need to reach a certain severity level before CERT will issue an advisory in response to them, he said.

New Poster Child

"Obviously, the label of poster child for security glitches moved from Microsoft to the shoulders of open source and Linux product suppliers during 2002," the Aberdeen research stated.

Hemmendinger said the greater number of security vulnerabilities in open source was connected to problems with quality assurance testing. "While there are multiple distributors of open source products, there is no single entity responsible for quality assurance or for addressing security issues," he said.

Popular Misconception

Hemmendinger noted that the CERT findings run counter to what he sees as a popular misconception: that Microsoft software suffers the most security problems.

He said that network administrators trying to assess Microsoft versus open source platform strategies "need to set aside everything you've heard over the last year and look at what the numbers actually show. Perception does not match reality."

Rationale for Change

One reason for the decreased number of Microsoft security problems may be "the beginnings of an impact of efforts Microsoft has made to improve coding practices," Hemmendinger said.

He noted that not only has Microsoft made security a major push this year, "but there have been a number of things that have gone on [in Microsoft] over the last couple years reflecting that they know security matters, and that they had to pay attention to it."

Future of Open Source

Hemmendinger predicted even more security advisories will be released for open source products in the future, while the number of Microsoft security vulnerabilities will remain flat or decrease.

"The numbers lag the adoption," he said, explaining that as open source becomes more prevalent, problems -- and scrutiny of weaknesses -- will increase.

Apple Bit, Also

"Apple's products are now just as vulnerable, now that it is fielding an operating system with embedded Internet protocols and Unix utilities," the Aberdeen reported added.

According to the CERT list, security advisories affecting Apple's OS X jumped from two in 2001 to four in the first 10 months of 2002.

Recommended Links

"Practical Linux Security" (developerWorks, Oct 2002) describes secure policies for sensible account management.

"Securing Linux" outlines some security basics. Part 1 defines what it means to be secure, Part 2 lays the groundwork for a secure setup, and Part 3 explains strategies to harden your system to keep it safe from attack.

Constructive Paranoia at the End of 2003 describes lessons learned from the security incidents of November 2003.

Kurt Seifried maintains lists of TCP-IP, UDP-IP, TCP, and UDP ports. He also wrote an introduction to network security.

A Look at Systems-level Auditing under Linux by Timothy R. Chavez (in PDF format).

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

DISA Security Checklists

DISA Security Technical Implementation Guides


[DOC] Auditing Linux (Red Hat)

Securing Debian Manual - After installation

Linux Security Quick Reference Guide This Quick Reference Guide is intended to provide a starting point for improving the security of your system. Contained within include references to security resources around the net, tips on securing your Linux box, and general security information. [PDF] [PS] [A4 PS] [A4 PDF]

Linux Security Administrator's Guide

This is a document that I last made modifications to in 1998, but is still pretty relevant. Topics covered include developing a security policy, network and host security tips, process accounting, physical security, intrusion detection, files and filesystem security, encryption, kernel security, explanation of many types of exploits, links to documents on writing secure code, firewalls, and incident response. I would be very interested in hearing any comments about this document. [HTML] [PS] [DVI] [SGML] [TEXT] Main Documentation Resource Page This section contains documentation on how to improve the security of your Linux box, whitepapers on various security issues, newsletters, a glossary of security terms as well as publications. We've tried our best to accumulate the most relevant and up-to-date list of documentation here.[HTML]

This FAQ is intended to serve as a starting point for those new to the newsgroup, but is also intended to be a survey of Linux security issues and tools. This FAQ is aimed at intermediate to experienced Linux users and is intended to not only answer specific questions, but to also facilitate further learning by providing pointers other useful security resources.

Be sure to read our interview with author Daniel Swan to learn more about this document. [HTML]

Linux Security HOWTO This document is a general overview of security issues that face the administrator of Linux systems. It covers general security philosophy and a number of specific examples of how to better secure your Linux system from intruders. Also included are pointers to security-related material and programs. [HTML]

Linux Security Quick-Start Guide This document, written by Hal Burgiss, is an introductory level document that provides the information necessary for inexperienced Linux users to secure their machine. Well-written and thorough.

Be sure to read our interview with Hal on Linux security and his document. [HTML] [Red Hat Version]

This Cisco whitepaper discusses the TCP/IP architecture and provides a basic reference model that explains TCP/IP terminology and describes the fundamental concepts underlying the TCP/IP protocol suite. Great document. [PDF]

Securing Debian HOWTO This document describes the process of securing and hardening the default Debian installation. In addition this document just gives a overview of what you can do to increase the security of your Debian GNU/Linux installation. Many parts of this HOWTO can be transferred to other distributions. [HTML] [PDF.GZ] [TXT.GZ]

Secure Programming HOWTO This paper provides a set of design and implementation guidelines for writing secure programs for Linux and Unix systems. Such programs include application programs used as viewers of remote data, CGI scripts, network servers, and setuid/setgid programs. Specific guidance for C, C++, Java, Perl, Python, and Ada95 are included. See our interview with David Wheeler on [HTML]

WWW Security FAQ This is the World Wide Web Security Frequently Asked Question list (FAQ). It attempts to answer some of the most frequently asked questions relating to the security implications of running a Web server and using Web browsers. [HTML]

Chroot-BIND HOWTO Describes installing the BIND 9 nameserver to run in a chroot jail and as a non-root user, to provide added security and minimise the potential effects of a security compromise. [HTML]

Encryption HOWTO This document will (eventually, more or less extensively) describe all major development activities around the Linux operating system that provide encryption features to the kernel. [HTML]

Securing-Domain HOWTO Outlines the things you will probably have to do when you want to setup a network of computers under your own domain. Covers configuration of network parameters, network services, and security settings. [HTML]

VPN HOWTO This HOWTO describes how to set up a Virtual Private Network with Linux. [HTML]

VPN Masquerade HOWTO How to configure a Linux firewall to masquerade IPsec-and PPTP-based Virtual Private Network traffic, allowing you to establish a VPN connection without losing the security and flexibility of your Linux firewall's internet connection and allowing you to make available a VPN server that does not have a registered internet IP address. [HTML] >

Securing and Optimizing Linux: Red Hat Edition This book addresses unanswered questions about Linux security and optimization in the marketplace. It is intended for a technical audience and discusses how to install a Red Hat Linux Server with all the necessary security and optimization for a high performance Linux-specific machine. It covers (in detail) several ways to configure security and optimization. [PDF]

alt.2600 Hack FAQ The purpose of this FAQ is to give you a general introduction to the topics covered in alt.2600 and #hack. General information on hacking, telephony, cellular communications, security resources, and a description of what alt.2600 actually is.




Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy


War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes


Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law


Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright ฉ 1996-2018 by Dr. Nikolai Bezroukov. was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting development of this site and speed up access. In case is down you can use the at


The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: January 04, 2019