Study of a ransomware: how does it work ?

Hi all!
In this article we would like to explain what is a Ransomware and how they infect systems.
We hope you will enjoy reading the post. If you have any question or comments, feel free to write and we will try to reply as soon as possible!
Let's start by defining what is a Ransomware.

Introduction

A ransomware as defined by Wikipedia is "a type of malicious software that threatens to publish the victim's data or perpetually block access to it unless a ransom is paid."

A ransomware is technically made of a malware which encrypt the data; the malware can be delivered to the system in many different ways (for example through a Trojan).
If the malware is well written there is really low chance to be able to decrypt the data without having the encryption key.
The ransom is usally paid through digital currencies such as bitcoin. In this way it is almost impossible to trace who is going to receive the transaction.

Infamous Ransomwares

To start with a bit of story, you may have read about CryptoLocker and CryptoWall. The first was a Ransomware which happeared at the end of 2013 and made companies pay a total of about 3 Milion $ before it was stopped (May 2014).
CryptoWall is a Trojan ransomware which infected systems during 2014. In the same year the owners of infected systems payd an estimated amount of about $18m to get the decryption keys.

How it works

Like the TCP handshake, the ransomware operate in 3 steps:

1. The attacker generate a key pair (asymmetric key) and place the public key in the malware. The malware is deployed using different "media" such as trojan, email spam, infected websites...
2. On the victim system, the malware generate a random symmetric key and encrypts victim's data with it. The symmetric key is then encrypted using the public key. Only the private key which was generated in the key pair (step 1) is capable of decrypting the symmetric key!! At the end of process 2, the victim will have selected data encrypted with the random symmetric key and the same key encrypted with the asymmetric key (step 1): this is call hybrid encryption. The symmetric key and the original "not encrypted" data are deleted (with "proper" processes). The victim is informed of the attack with a message of some form, which provide the cyphertext (encrypted using the public key of the key pair) and information about how to pay the ransom.
3. The criminal receive the ransom (normally through digital currencies) and the cyphertext. The cyphertext is decrypted using the attacker private key (of the original key pair). The decrypted cyphertext is the "symmetrical key" created at point 2. The attacker send the symmetric key to the victim which can decrypt the data.

It is interesting to know that in literature you will find "3 steps of a ransomware attack", "5 phases of a cyber attack", "6 Phases of a Ransomware Attack"... whatever the number, the above is a good short explanation of how the attack happens.

This is an example of a message which the malware will display to the victim (from the infamous Wanna Cry ransomware):

As you can see in the picture, the victim is intimidated to pay before the time runs out, otherwise the attacker will delete the his private key!

The malware can be design to target an OS or to be specific against a particular product or solution such as the NAS produced by Synology (August 2014) or a ransomware built to target Linux-based web server (January 2015).

Within Windows, most of modern ransomware are taking advantage of PowerShell for their attacks. Clearly this show that PowerShell is somehow not a secure environment compare to Bash (one point for Linux!).

Apart from the malware itself, there are 2 major factors that helps the ransomware threat to grow: the development of BitCoin and of the DarkNet. The first allow to deliver the ransom with an almost impossible to trace transaction. The DarkNet through Tor services allows ransomware to communicate with their command centre. With the two it is almost impossible to trace the origin of the attack.

Reverse Engineering Malware

While the best protection from a ransomware attack is maintaining a backup of your valuable information (data), researchers are fighting a war to develop defences against the attack and to analyse the malware to find way to stop it and to eventually decrypt the victim's files.
We are not going to duplicate the effort of experts and write a tutorial about this difficult discipline which involves several competences. If you are interested in how researchers do reverse engineering against a malware I would suggest you to follow this link. It is from Lenny Zeltser's website. He is a guru in cyber security!

Conclusion

We hope you enjoyed reading this post and we welcome your comments. Share the post if you liked it and follow us!

How to become an hacker !

It is interesting how many times since I started this blog I came into "Cyber security" forum where the predominant questions were:

1.  How do I become a hacker
2. Which computer languages do I need to learn?
3. Which are the steps to become a Security Expert

In this post, I am going to try to answers to these questions. I will open other questions, which I will answer in my following posts.

Let me know your opinion.

Operating Systems

For sure the starting point, if you are green on IT is knowing how a PC works, how it does boot, the BIOS/UEFI, the boot sectors and the different type of partitions and bootloaders.

You should not focus on a specific OS, perhaps at this stage. There are loads of websites that provide free training and free PDF.

Windows 7 & Windows 10

In my opinion, the best way to learn an OS is by installing it on your PC. If you are still "green" than you should start with a "desktop" OS such as Windows 7 or Windows 10.

It is possible to get trial licenses directly from Microsoft. Just create an account, go into the download area and search for trial licenses. The best way is to create an acocunt under "TechNet":

Microsoft Technet

Then you can click on "Downloads", select the OS you wish to try and click on Evaluation. You need to further register but at the end you can download a fully functional ISO which will allow you to install the product and use it without limitation for 90 days... and 90 days are enough to follow a basic/intermediate training (2 weeks) and then do some more advanced "stuff"!!

I am not a Micorsoft "guy" but I can tell you that Technet website is good, with a lot of information.

Now that you have the ISO, you need to find a good training website. For Windows 10 I would suggest to have a look at this tutorial:

How to use windows 10

Linux

That's my area! Learning Linux is not difficult, especially if you don't have any IT knowledge at all! If otherwise you are a GUI-guy then you should have more problem; but when you will discover the power of Bash ... nothing will stop you anymore.

So, you want to learn Linux; that's come free, forever! Just download a distribution (collection of the OS kernel and free softwares) and install it on your computer.

Now you should be good enough to do an installation within a VM (Virtual Machine). In this way you will be able to mess-up your system as much as you want and restart from a working snapshot.

I am not going to explain you how to create and work with a VM (it is out of the scope of this article), but you can have a look at this link:

How to install Linux on your Windows using Virtual Box

Which distribution to use... this is an easy question!! Easy because all the Linux distros are based upon the same Kernel (Linux kernel) and a similar set of tools (utilities). Hence if you want to learn the command line (learn the hard way), any distros is good for you.

You do not need any fancy GUI interface; most of the servers does not use a Graphical User Interface at all.

Perhaps, one of the most used server distribution is RedHat Enterprise Linux (RHEL) so similar distributions maybe the right starting point: CentOS, Scientific Linux, Fedora.

Personally, I use CentOS 7 on my Laptop and on several VM which I use to make tests.

You may find a good training (basic training) at this link:

Introduction to linux

The Linux Foundation sposnsors it (with a brief video introduction by Linus Torvalds). I followed that training years ago as a refresh of my knowledge, just before starting a position as Tech Support, which required the use of Linux CLI commands. I highly suggest you to follow the training, complete the proposed exercises, and after that search for "The Linux Bible" book. It is a good intermediate level training manual which you can use to increase your knowledge quite a bit.

Networking

If you completed the above steps (which requires you quite some time if you are studying after working hours), you should already have learnt a basic knowledge of Networking. That's not enough if you want to follow the road to Cyber Security Success!!

I followed a 1-year training course in Milan, Italy (eForHum) and got Cisco CCNA certification. That is just an example of training that you need to follow to have a basic knowledge about ISO Layers, IPv4, IPv6, switching and routing protocols and finally Cisco CLI commands.

It has been useful in all my following working experiences, especially now working within a Telco company.

Another good training to follow is the one that brings you to get CompTIA Network+. You may find a good training course if you join Cybrary.it

Computer Languages

Knowing computer languages is possibly the hardest step to achieve in the "growing as an hacker" learning curve.

If you studied Linux, you should have come into Bash and you possibly had some scripting experiences with it. Anyhow, I would suggest you to learn it really well together with the regular expressions (which are used by tools such as grep, awk and sed).

Another language you should be able at least to "read" is Python. If you are going to do reverse engineering of malware, possibly you need to have a background in C/C++ as well.

Any Linux distro provide free environment and IDE to practice these languages. Again the best way to start is by following a basic/intermediate training with loads of Labs ... practice practice practice !!
As suggested by +Mike Barton a good understanding of the Assembly language is quote "very important and not only for reverse engineering but for very tight code".
Perhaps writing good code is something missing in this days!

Continuous Learning

To complete the post, I would like to suggest the beginner (and the expert as well) to keep studying! Learn how the "black hat" are doing their dirty activities by reading forums.

A good way to be always updated is by creating a Google Alerts, which is a Google tool to be able to have Google posting you with a periodicity you may specify, articles related to a selected topic.

The Security world is made of several "chapters" such as Physical Security, Network Security, System Security...

Every Security Expert should have a basic knowledge of all the topics and be expert on a few ! So you should study the training material related to some entry level Security certification such as CompTIA Security+ or Certified Ethical Hacker.

Conclusion

Continuous studying and practice practice practice!!

Don't do dummy things such as trying the available tools without authorization against Networks and Systems you don't own!!

Enjoy every moment of the study, share your knowledge and be always positive.

How to improve your experience with sudo in Linux: tips and tricks

Introduction

If you want to increase the security on your Linux server it is recommended to properly configure sudo !

As per "wikipedia":
sudo (/ˈsuːduː/ or /ˈsuːdoʊ/) is a program for Unix-like computer operating systems that allows users to run programs with the security privileges of another user, by default the superuser. It originally stood for "superuser do" as the older versions of sudo were designed to run commands only as the superuser.

sudo as the advantage to allow you to run a single command with specific privileges compared to su which allows you to "switch" to another user and run all the commands in a shell as the "new user" (su means switch user).

Perhaps with sudo, you can allow a user to run administrative commands without providing the root password. User will require to type their own password every time he/she needs to run a specific command (to be precise you can configure sudo so that it maintain the authorization for a certain amount of time).

An interesting security note can be found in the manual:

Please note that sudo will normally only log the command it explicitly runs. If a user runs a command such as sudo su or sudo sh, subsequent commands run from that shell are not subject to sudo's security policy. The same is true for commands that offer shell escapes (including most editors). If I/O logging is enabled, subsequent commands will have their input and/or output logged, but there will not be traditional logs for those commands. Because of this, care must be taken when giving users access to commands via sudo to verify that the command does not inadvertently give the user an effective root shell. For more information, please see the PREVENTING SHELL ESCAPES section in sudoers(5).

The sudo command is highly flexible and access can be restricted as tight as a single command or script, or access can be given to fully assume the root user's role, and therefore assume other user's role if desired.

Configuration

sudo is configured through the file /etc/sudoers. To edit the file you should use the "visudo" command as it will lock the file and avoid other users to modify it simultaneously.

A simple way to configure sudo is to allow a user to perform any operation as root.  This essentially gives the user root permission without the need for them to know the root password. This basically is using sudo like su ... which is not what we want !!

If you really want to do so ... on CentOS 7.2 you just need to add your user to the group "wheel" as the file /etc/sudoers contains the following:

%wheel   ALL=(ALL)       ALL

Which means ....
the users part of the group "wheels" can execute from ALL terminals (1st ALL), acting as ALL (any) users (2nd ALL), and run ALL (any) command (3rd ALL).

So if you need more granularity ... such as allow a specific user (user1) to run a specific command (/usr/local/bin/command1) from any terminal:

user1     ALL=    /usr/local/bin/command1

You can create an alias for the group of commands you want the user to be able to run:

Cmd_Alias   CMD-LIST = /usr/local/bin/bin/command1, /usr/local/bin/bin/command2, /usr/local/bin/bin/command3

And apply to user1 in this way:

user1    ALL=    CMD-LIST

For more information about how to customize sudoers ... have a look at the manual page !

The user environment problem

When you run sudo, your user environment variable are not used by default... you need to use the option -i to export your environment variables:

sudo -i -u user1 /command

Sudo with I/O redirection

When you want a command to redirect its output to a file ... the redirection may not work if you are trying to write in a location for which you don't have permissions !

These are 2 valid workarounds:

• run sudo to call a shell and use the shell option -c to run the desired command.

           sudo sh -c 'find / -name sudoers 2> /dev/null'

• create a bash script and use sudo to run the script

          #!/bin/sh

          find / -name sudoers 2> /dev/null

  

          sudo script_name.sh

Gving your users more time ...

Within the file /etc/sudoers you may find a line that start with:

Defaults     env_reset

Without any further option you allow the system to "retain" the authorization for 15 minutes. If you want to reduce/increase this time, force the user to type the password every time or allow the user to type the password just once:

Set the authorization time to 30 minutes:
Defaults        env_reset,timestamp_timeout=30

Force the user to type the password every time:
Defaults        env_reset,timestamp_timeout=0

Allow the user to type the password just once (not recommended):
Defaults        env_reset,timestamp_timeout=-1

If you just used the sudo command and you are moving out of your desk ... I would suggest to tell sudo to forget your password:

sudo -k

On the same subject:

sudo privilege escalation

sudo: Privilege escalation - CVE-2017-1000367

Description

There is a security vulnerability which affect the Linux sudo packages.

As mentioned in the CVE-2017-1000367: "the way sudo parsed tty information from the process status file in the proc filesystem. A local user with privileges to execute commands via sudo could use this flaw to escalate their privileges to root."
The flaw has been discovered by Qualys Security.

Diagnose

Red Hat provide a script to check if your "sudo" is affected by the vulnerability.

Fix

You should updated sudo packages to the latest version provided by your distribution repository ASAP. The bug is fixed in sudo 1.8.20p2

How to apply and maintain integrity on your Linux box in 3 steps

Introduction to Integrity management

The CIA triad is the security standard every CISO (Chief Information Security Officer) should know and adopt: Confidentiality, Integrity, availability.

In this article we will discuss about the Integrity concept and how to apply it to a Linux server; we will refer to CentOS 7 being a server platform similar to Red Hat 7.

The information an organization hold should be reliable. It should not change and if a change has happened we should be able to detect it. Integrity management means taking care of detecting and managing changes.

We need to prevent unauthorized changes such as: adding new users, deleting or changing logs (to erase your footprint).

To protect files from being manipulated, deleted or modified, there are several security layers you need to consider:

• File permission
• Network controls (Intrusion detection and prevention such as firewalls)
• Authentication

File permissions is handle mainly by ACL: Access Control List (wrxwrxwrx) while the best way to protect integrity of a Linux OS is to use MAC (Mandatory Access Control) which is obtained through SELinux. Even in this scenario, some remote and several local attacks can be done!

You can also manage special file attribute such as the “immutable” feature which make a file impossible to be manipulated (even by root); you can also set an attribute to a file so that you can only add information to it but you cannot modify the existing data (Append only). This is particularly good when it comes to system, audit or application logs.

To check the current attributes of a file:

# lsattr name-of-the-file

To make a file immutable

# chattr +i name-of-the-file

To remove the immutable attribute:

# chattr –i  name-of-the-file

To add an extra layer of security you can mount your filesystem “read-only”. If you do things right you can make life difficult to an attacker who has not gain root access yet.

Android has the OS binaries stored in a partition which is mounted read-only and can only be modified while in recovery mode; this an extreme solution as it does not allow you to do system updated without rebooting the device.

As things will happen (they will … I mean it) and you cannot prevent all the possible scenario within a limited budget, you need to be able to detect changes: Host-based Intrusion Detection System (H-IDS).

The simplest way (but slowest…) is to make a backup of your baseline system and periodically compare your current system/files with the backup (using diff and rsync). While doing a backup is always to be considered part of good security practice, using hash functions allow you to make a baseline of the hash of the files and then compare the current hash with the baseline.

It is almost impossible for an attacker to break it. Currently we use SHA-2 or SHA-3 hashing families. Comparing 2 hashes is a lot quicker than comparing 2 files. Anyhow there are several negative aspects that you need to take into account:

• If something has changed within a file you won’t know what has changed (Lack of Change Detail): perhaps an attacker can modify a configuration file, compromise a file which is not monitored by the HIDS and then restore the original file before a check of the integrity will happen so nobody will ever notice the attack (Static Anomaly Detection)
• If you change a file attribute the hash will not change (to be verified)
• Signing your hashes can be compromised (stripwire is an evasion tool built to specifically create files which can evade Tripwire detection)
• Restricted Operating Environment: “Checking the integrity of a program binary on disk … does not ensure that the corresponding in memory image of the program has not been modified (Garfinkel & Rosenblum, 2003)

Three applications are mainly used by system administrators to look after integrity and they basically use the concept of having a good baseline stored in a database:

• Another File Integrity Checker (AFICK): (Author: Eric Gerbier – Current version 3.5.2 – 2016-08-05 - http://afick.sourceforge.net/ ) Does not require any mail server so you don’t have to twick the installation; but it may use available mail client to send emails in case of alerts. It is a Perl based application hence slowest compared to the other rivals (which are binaries).
  It is the best in terms of CPU resources usage during the system scan and re-indexing.
• Tripwire: it is possibly the oldest solution (the idea date back in 1994 by Gene Kim and Eugene Spafford). It is the most aggressive in terms of CPU usage.
• AIDE (Advanced Intrusion Detection Environment)

We are going to provide you wit a step by step procedure to install, configure and use AFICK (reviewed version 3.5.2).

Step 1: Installing AFICK 3.5.2

We searched for the package in several repository to be able to install on CentOS 7 box using yum but it seems like it is not available, so the installation may be a little tricky. 

First you need to check if your system already have all the required dependencies (using yum command):

• perl
• perl-Digest-MD5
• perl-Tk
• perl-Digest-SHA1

Then you need to download the rpm package from the sourceforge website:

# wget https://sourceforge.net/projects/afick/files/afick/3.5.2/afick-3.5.2-1.noarch.rpm/download

Then you can proceed with the installation … you will get several errors (the installer is really not so user friendly).

# rpm -Uvh package-name.rpm

I would suggest you to forward the output to a file and then review it to eventually fix any problem.

Step 2: Configuration

In your /etc folder you should now have a file “afick.conf”. Below you can see my file (which is the default one for the current version). As you can see the file has a lot of comments which explain the meaning of each parameter. For further help you can consult the documentation

[start the conf file]

# afick config sample file

# $Id$

# see afick.conf documentation for more informations

####################

# directives section

####################

# binary values can be : yes/1/true or no/0/false

# database : name with full path to database file

database:=/var/lib/afick/afick

# history : full path to history file

history := /var/lib/afick/history

# archive : full path to directory for archived results

archive := /var/lib/afick/archive

# report_url : where to send the result : stdout/stderr/null

report_url := stdout

# report_syslog : send output to syslog ?

report_syslog := no

# verbose : (obsolete) boolean value for debugging messages

# use debug parameter below

verbose := no

# debug : set a level of debugging messages, from 0 (none) to 4 (full)

debug := 0

# warn_dead_symlinks : boolean : if set, warn about dead symlinks

warn_dead_symlinks := no

# follow_symlinks : boolean : if set, do checksum on target file (else on target file name)

follow_symlinks := no

# allow_overload : boolean : if set, allow to overload rules (the last rule wins), else put a warning

allow_overload := yes

# report_context : boolean : if set, display all changed attributes, not just those selected by rules

report_context := no

# report_full_newdel : boolean : if set, report all changes, if not set, report only a summary on top directories

report_full_newdel := no

# report_summary : boolean ; if set, report the summary section

report_summary := yes

# warn_missing_file  : boolean : is set, warn about selected files (in this config), which does not exist

warn_missing_file := no

# running_files : boolean : if set, warn about files changed during a program run

running_files := yes

# timing : boolean : if set, print timing statistics about the job

timing := yes

# ignore_case : boolean : if set, ignore case on file name

ignore_case := no

# max_checksum_size : numeric : only compute checksum on first max_checksum_size bytes ( 0 means unlimited)

max_checksum_size := 10000000

# allow_relativepath : boolean : if set, afick files, config and databases are stored as relative path

allow_relativepath := 0

# only_suffix : list of suffix to scan (and just this ones) : is empty (disabled) by default

# not very usefull on unix, but is ok on windows

# this will speed up the scan, but with a lesser security

# only_suffix :=

# the 3 next directives : exclude_suffix exclude_prefix exclude_re

# can be written on several lines

# exclude_suffix : list of suffixes to ignore

# text files

exclude_suffix := log LOG html htm HTM txt TXT xml

# help files

exclude_suffix := hlp pod chm

# old files

exclude_suffix := tmp old bak

# fonts

exclude_suffix := fon ttf TTF

# images

exclude_suffix := bmp BMP jpg JPG gif png ico

# audio

exclude_suffix := wav WAV mp3 avi

# exclude_prefix : list of prefixes to ignore

#exclude_prefix :=

# exclude_re : a file pattern (using regex syntax) to ignore (apply on full path)

# one pattern by line

#exclude_re :=

#################

# macros section

#################

# used by cron job (afick_cron)

# define the mail adress to send cron job result

@@define MAILTO root@localhost

# truncate the result sended by mail to the number of lines (avoid too long mails)

@@define LINES 1000

# REPORT = 1 to enable mail reports, =0 to disable report

@@define REPORT 1

# VERBOSE = 1 to have one mail by run, =0 to have a mail only if changes are detected

@@define VERBOSE 0

# define the nice value : from 0 to 19 (priority of the job)

@@define NICE 18

# = 1 to allow cron job, = 0 to suppress cron job

@@define BATCH 1

# (optionnal, for unix) specify a file system to mount before the scan

# it must be defined in /etc/fstab

#@@define MOUNT /mnt/dist

# if set to 0, keep all archives, else define the number of days to keep

# with the syntaxe nS , n for a number, S for the scale

# (d for day, w for week, m for month, y for year)

# ex : for 5 months : 5m

@@define ARCHIVE_RETENTION 0

# send nagios messages by NSCA (= 1 to allow, = 0 to block)

@@define NAGIOS 0

# address of the nagios server to send messages to

@@define NAGIOS_SERVER my.nagios.server.org

# NSCA configuration file

# @@define NAGIOS_CONFIG /etc/send_nsca.cfg

# name used for nagios passive check on the nagios server side

@@define NAGIOS_CHECK_NAME Another File Integrity Checker

# number c of the changes that are considered critical => nagios state CRITICAL

# (0 changes => nagios state OK; 0> and <c changes => nagios state WARNING)

@@define NAGIOS_CRITICAL_CHANGES 2

# path to nsca binary

# @@define NAGIOS_NSCA /usr/sbin/send_nsca

###############

# alias section

###############

# action : a list of item to check :

# md5 : md5 checksum

# sha1 : sha-1 checksum

# sha256 : sha-256 checksum

# sha512 : sha-512 checksum

# d : device

# i : inode

# p : permissions

# n : number of links

# u : user

# g : group

# s : size

# b : number of blocks

# m : mtime

# c : ctime

# a : atime

#all:        p+d+i+n+u+g+s+b+m+c+md5

#R:      p+d+i+n+u+g+s+m+c+md5

#L:      p+d+i+n+u+g

#P:         p+n+u+g+s+md5

#E:      ''

# action alias may be configured with

# your_alias = another_alias|item[+item][-item]

# all is a pre-defined alias for all items except "a"

DIR = p+i+n+u+g

ETC = p+d+u+g+s+md5

Logs = p+n+u+g

MyRule = p+d+n+u+g+s+b+md5

##############

# file section

##############

# 3 syntaxe are available :

# file action

#     to scan a file/directory with "action" parameters

# ! file

#     to remove file from scan

# = directory action

#             to scan the directory but not sub-directories

# file with blank character have to be quoted

#

# action is the list of attribute used to detect a change

= /  DIR

/bin        MyRule

/boot    MyRule

# ! /boot/map

# ! /boot/System.map

/dev p+n

# ! /dev/.udev/db

# ! /dev/.udev/failed

# ! /dev/.udev/names

# ! /dev/.udev/watch

! /dev/bsg

! /dev/bus

! /dev/pts

! /dev/shm

# to avoid problems with pending usb

# = /dev/scsi p+n

/etc        ETC

/etc/mtab ETC - md5 - s

/etc/adjtime ETC - md5

/etc/aliases.db ETC - md5

# /etc/mail/statistics ETC - md5

/etc/motd ETC

# /etc/ntp/drift ETC - md5

# /etc/urpmi/urpmi.cfg Logs

# /etc/urpmi/proxy.cfg Logs

# /etc/prelink.cache ETC - md5 - s

! /etc/cups

# ! /etc/map

# ! /etc/postfix/prng_exch

# ! /etc/samba/secrets.tdb

# ! /etc/webmin/sysstats/modules/

# ! /etc/webmin/package-updates/

# ! /etc/webmin/system-status/

/lib         MyRule

/lib64     MyRule

/lib/modules MyRule

# /lib/dev-state MyRule -u

/root MyRule

# ! /root/.viminfo

! /root/.bash_history

# ! /root/.mc

# ! /root/tmp

/sbin      MyRule

/usr/bin               MyRule

/usr/sbin             MyRule

/usr/lib MyRule

/usr/lib64            MyRule

/usr/local/bin    MyRule

/usr/local/sbin  MyRule

/usr/local/lib      MyRule

# /var/ftp MyRule

/var/log Logs

# ! /var/log/journal

= /var/log/afick Logs

# ! /var/log/ksymoops

# /var/www MyRule

# ! /var/www/html/snortsnarf

############################################

# to allow easier upgrade, my advice is too separate

# the default configuration file (above) from your

# local configuration (below).

# default configuration will be upgraded

# local configuration will be kept

########## put your local config below ####################

[end of conf file]

 Step 3: Usage

After the installation and configuration has completed you need to create the baseline (the database of hashes which will be used as “good” when comparing with the running system):

# afick –i

The database itself has a hash (MD5) so you can check manually if somebody hacked into the database by comparing the new hash with the one which I “painted in blue”.

So now that we have our baseline database of hashes there is only one operation required to keep your system under control: run the afick.pl command after any system update or any time you change a configuration file; you should run a compare before applying any changes and then an update after the change has been done.

Update command:

# afick.pl –u

Compare command:

# afick.pl –k

Now you need to take a look to the /etc/cron.daily/afick_cron file (a Bash script). In the distro I am using currently (CentOS 7) you need to check the /etc/anacrontab to see if you have an entry such as the following:

This show that all the scripts within the /etc/cron.daily folder will be executed daily starting at 3am with a delay of 5 minutes between a job and the following. If for some reasons the job (script) is not executed then anacron will try again! To know if anacron is working check the file /var/spool/anacron/cron.daily this should contain the current date … if not verify the logs and troubleshoot cron (that is not the topic of this article !). On CentOS 7 (and Red Hat 7) anacron is executed by crond through a script within cron.hourly. For more information check the related documentation.

Conclusion

For an absolute secure usage of afick:

• The database should be stored on a read-only media
• The afick command should be run from another “clean operating system” (in example from a bootable media): this is not an option in production environment but it is suggested in the afick.sourcforge.net website and we are reporting here for completeness.

We hope you found this article useful and that it will help in your daily effort to keep servers secure. Feel free to comment and share.

Author:

Francesco Campanini

Reference

A full comparison of the 3 HIDS application can be found in the following link:

https://www.sans.org/reading-room/whitepapers/detection/ids-file-integrity-checking-35327

How to secure your CentOS box: hardening your Linux Box in 3 steps

Since I moved to CentOS 7 to be better prepared for my daily business activities (I work on a cluster with hundreds of Red Hat boxes).

I use my laptop with CentOS 7 in several locations: at home within my “secure” wireless umbrella, in the office using company wireless network and sometimes using public open WiFi … which is really not a safe option !

This article want to be a step by step guide into making your Linux box more secure !


As CentOS 7 is similar to Red Hat (derived from) I used several Red Hat advice about securing your server and I applied it to my box. My main reference is “A Guide to Secure Red Hat Enterprise Linux 7” which is free and available to download from Red Hat website (check the reference at the bottom of this page).

1) What to look for !

Unused ports and unused services

You need to check which are the open ports (listening services) on your system and if the related services are not in use (or you don't need it) ... just stop the service and disable it.

To find which ports are in use [a: socket in use, t: tcp, u: udp, n: print numbers for ports/IP]
# netstat -atun 

You may add the option "l" if you want to list the listening sockets. If a socket is listening it does not mean that the related service is available from the outside as you have a perimeter protection thanks to the OS firewall ... 

To stop and then disable a service:
# systemctl stop service-name
# systemctl disable service-name

Unpatched services

Always keep track of security patches for the services/software which are facing the network or used by services facing the network. In example you may have a webserver which make use of phpMailer. phpMailer is not a service but it may have vulnerabilities (perhaps at the time of writing - Jan 2017 - it has just been discovered a big one !!). You need to keep it patched as an attacker may be able to get root of your system by exploiting phpMailer.

Unchanged default password (SQL server)

Many forget to change the default password of services such as SQL ... that's a bad idea !! Check all the package you installed and verify if they are using a default password. If this is the case just use the provided tools to change the password and use the below consideration to select an appropriate password.

Inherently Insecure Services (Telnet, FTP)

Try to avoid using inherently insecure services such as Telnet and FTP. These services transmit data in clear (without encryption) and the authentication is in clear as well (an hacker can get your password by sniffing your network traffic).

Bad password

The OS use Secure Hash Algorithm 512 (SHA 512) to hash the password which are not contain in the /etc/passwd file but in a shadow file ( /etc/shadow ). It is not a good idea to alter this setting. While the passwd file can be read by most of the users, the shadow file can be accessed only by root.

If you are not using CentOS 7 or you just want to be 100% sure that the hashing algorithm is SHA-512, just type the below command:
# authconfig --test | grep hashing
password hashing algorithm is sha512

It is highly important, if not the most important thing at all, to use strong password. The topic about “what is the best password” require an entire new chapter and we will write about it later on! Anyhow remember the following good sense recommendation:

1. Use more than 12 characters ... perhaps it is important to use a "full dictionary" using letters (uppercase and lowercase), numbers and special character. Currently computer are fast enough to be able to discover a 12 symbols password (even a totally random one) in a really short time.
2. Never use a dictionary word, inverted word, only numbers or a word in a foreign language (there are tools to hack password which use dictionary containing words in multiple languages).
3. Never write down your password (use a password keeper tool which encrypt the password).
4. Never use multiple times the same password
5. Periodically change the password
6. Configure your system to lock for an increasing amount of time if the user fail to login after a specified number of attempts.
    

2) How to start in the right way !

Start with BIOS password protection …. If an attacker can control your BIOS he can get control of the boot order and chose to boot from USB or DVD and then mount your disk and get access to your data and hashed password. You should also use password to prevent system for booting (I am talking about your workstation or laptop not about a production server which you wish to be back online after a reboot without an engineer interaction to allow it to boot).

Leave your laptop or computer locked in a cabinet or rack as ... even if it has a BIOS password, an attacker can open the chassis, remove the CMOS battery and reset the BIOS (or find another way to reset it to default).

If you leave your computer unattended, even in your office with trusted people around, remember to lock the keyboard (lock the screen).

So you protected your BIOS ... but after POST, the boot-loader start GRUB ... and it is not password protected ... so your malicious friend (the black hacker) interrupt the boot process and modify the boot to go in single-mode ... he just rooted your workstation ! That's it !! So ... why not to password protect GRUB ?!?
For the same reason you may require to use a password for single-mode.

I would suggest to read this article about BIOS/GRUB and single-mode password protection: Securing Your Network [CentOS org]

Installation recommendation

Partition your system with at least these partitions:

1. /boot
2. /home/
3. /tmp
4. /

By partitioning the system you can fine tune the permission. You should check each entry within fstab (/etc/fstab) and customized using the following options when needed/possible:
nodev: "Interpret/do not interpret block special devices on the filesystem" [fstab - Wikipedia].
noexec: "exec lets you execute binaries that are on that partition, whereas noexec does not let you do that. noexec might be useful for a partition that contains no binaries, like /var, or contains binaries you do not want to execute on your system, or that cannot even be executed on your system, as might be the case of a Windows partition" [fstab - Wikipedia].
nosuid: "Permit/Block the operation of suid, and sgid bits" [fstab - Wikipedia].

Do a minimal installation. Just install the bare minimum packages as each package may have bugs and vulnerabilities (they really have !) and … why to install packages which you don’t need !

To know which packages you have installed:
# yum list installed

Check which service are active on your system:
# systemctl list-units | grep service

Encrypt your home partition. While it is not a good idea to encrypt all the file systems, it is normally recommended to protect your data with encryption. This allow to maintain Confidentiality.

Whenever the system is up and running, perform the network configuration to allow your workstation/laptop to connect to Internet then update your packages:
# yum update

Enable your firewall: normally it is enable by default by why not to check for it ! CentOS use Firewalld utility set.
# systemctl status firewalld
# systemctl start firewalld
# systemctl enable firewalld

If you need to check which is the current configuration of the firewall you can run the following iptables command:
# iptables --list


User rights

As you should normally work as "standard user" while only running specific commands as root, you should not be able to remote into a system as root (via ssh) and you should be able to only login to the local console with root privileges.
The key file for the root login is /etc/securetty. This configuration file list the virtual console (tty1 to tty6) which the root user can log in into. PAM is the service which "use" the /etc/securetty file. When the user "root" attempt a to login on a virtual console such as tty1, the program "login" check using PAM if "tty1" is in the /etc/securetty file; if so the user root can login. PAM menage several other authentication mechanism (both for local and remote authentication).
The single user mode login does not use PAM (the application for login is called sulogin which does not use PAM for authentication).

3) Keep your system secure

You may force yum to only search for security update:
# yum check-update --security

As the above command run in a non interactive way, you can use the exit code to automate your system update.

The possible exit codes are:
0: for no available update
100: for available update (it does not tell you how many …)
-1: if there was an error along the check
Before installing any update it is always good to read the “errata” and to know which is the best procedure to stop the running package and replace/update it with the new package.

Reference

https://wiki.centos.org/HowTos/OS_Protection

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/pdf/Security_Guide/Red_Hat_Enterprise_Linux-7-Security_Guide-en-US.pdf