Configuring AIX Audit Subsystems to enhance security

With the dynamic nature of business today and its growing dependence on information technology, it is becoming important day by day to improve security measures to guarantee confidentiality, integrity and authenticity of data. This has introduced needs of more and more security tools and their implementation in corporate environments so that proper security can be ensured.

AIX, like all other industry leading operating systems has a built-in feature of Auditing. This Auditing subsystem is part of base operating system and provides system administrators the features to record information pertinent to system security. This information is essential for the system administrators to prevent potential violations of the system security policy.
Any occurrence on the AIX servers relevant to system security is considered an auditable event. The set of auditable events on the system defines which occurrences can actually be audited and the granularity of the auditing provided.
Hence we can say that main concept of auditing is to detect any occurrence of auditable event record information pertaining to the set of auditable events, and process this information to examine audit trails and generate periodic reports.

An auditing subsystem should also provide feature to monitor the audit trail in real time for generating alerts to immediate security threats. AIX audit subsystem is no exception. It is capable of recording audit events for long term analysis by system administrators and security administrators as well as it can also provide real time auditing.

In this article, I will explore AIX auditing subsystem in detail, covering its different configuration aspects. I will also take my readers to basic configuration steps, so that they can configure this freely available feature of AIX 5L for auditing different system events happening on their AIX servers.

1.AIX Auditing Subsystem Components & Structure


As I described earlier that an audit is an examination of a group, individual account or activity and the auditing Subsystems provides a means of tracing and recording what is happing on your system.

This Subsystem also provides the means of security related information and to alert System and security administrators about potential and actual violations of the system security policy. For example a system administrator would like to be identified either immediately or at day end that some internal or external intruder has tried to change some critical files on your system ( like database log files or system critical log files like smit.log file or root user shell history file etc). Here comes the AIX auditing to help administrators.

Let’s start with components description for AIX auditing. Main component is auditing configuration file ( /etc/security/audit/config ).Whenever you start the auditing daemon on AIX , this configuration file is read. This file contains information, such as
• Mode
Mode represents the data collection method, as used by auditing daemon .There are two different modes of AIX auditing , which are discussed in detail in next section of this article. These modes are
– Bin Mode
– Stream Mode
• Events
Events are systems defined activity. Here are two examples
– USER_SU give you information about whether a user tries to su another user; this event is associated with General class, by default.
– CRON_Start event gives you information whether a cron job has started or not.

• Customized Events( if any):
The Systems Administrator can also define his own Customized Events relating to system kernel activity and also to the critical users activates. For example, in this article I have defined some customized events related to smit activities as performed by root user.
I named it as “smitlogs_WRITE”. This event will give you information about whether any user and even the root user ties to edit the smit.log file or update this file using smitty tool.

• Classes
Classes define group of events. A system administrator can group logically similar events in a class. For example both USER_SU & Password_Change events are related to “general” class of events. Class names are arbitrary and you can use any class name for certain group of events.
• Objects
Auditing objects means system configuration files as well as kernel related objects present in ODM (for example /etc/sendmail.cf and /etc/objrepos/SRCsubsys, both are example of audit objects). Read, write & execution activities related to these audit objects can easily be audited through AIX auditing.
• Users:
It is the responsibility of system administrator to identify the users who are to be audited for specific group of events (or so called classes). You can audit one or more class per user. For instance /etc/security/audit/config file may contain the following stanza.
user:
jack= general,cron,tcpip.


2.0 Data collection Modes

One of the most important configuration aspects of AIX auditing is the data collection mode in which it is operating. This data collection mode, basically describes the way in which data is collected by AIX auditing subsystems for analysis by system and security administrators.

There are two basic types of data collection by AIX auditing. One is named as binary mode and other is known as stream mode.

2.1 Binary Mode Configuration


While AIX auditing daemon operates in binary mode, audit events are recorded in two BIN files alternatively. This recording in binary files is temporary and finally data is appended into one single trail file. It must be noted down as the data format is binary so operating system commands like vi, pg or more can not be used to read the data directly from these files. Instead “auditcat“command is used to read the data from these files.

In essence, binary mode is used in scenarios, where long term audit data recording and analysis is required (for example by IT auditors or by IT security teams).



A schematic data flow in binary mode configuration of AIX audit subsystem is shown as below:


The alternating BIN mechanism (/auditfs/bin1 and /auditfs/bin2) is used to ensure that the audit susbsystem always has something to write to while the audit records are processed. When the audit subsystem switches to the other bin, it empties the first bin content to the /auditfs/trail file.
When time comes to switch the bin again, the first bin will be available. This mechanism ensures the decoupling of the storage and analysis of the data from the data generation.
Typically, the auditcat program is used to read the data from the bin that the kernel is not writing to at the moment. To make sure that the system never runs out of space for the audit trail (the output of the auditcat program), the freespace parameter can be specified in the /etc/security/audit/config file.

Let’s start with basic configuration steps for AIX auditing in binary mode. Configuration files of AIX auditing subsystem are located in /etc/security/audit directory. Main configuration file is “config”, which controls auditing subsystem basic behavior.

For enabling of binary mode, you just have to put “binmode = on” in config file.

It is important to note down that either of modes can be “ON” or both of them. It means that there is also a possibility of having both binary as well as stream modes “active” at same time.

It is always a good idea to create a separate filesystem for holding bin files as well as trail. It will eliminate any chance of filling up / filesystem or any other filesystem (as size of these files is usually large due to enormous number of records coming all together).

I therefore created a filesystem /auditfs and then configured auditing subsystem configuration file as shown below:

/home/root> more /etc/security/audit/config
------------------------------------------------------------------------------------------------------------
start:
binmode = on
streammode=off
bin:
trail = /auditfs/trail
bin1 = /auditfs/bin1
bin2 = /auditfs/bin2
binsize = 10240
cmds = /etc/security/audit/bincmds
freespace = 65536
stream:
cmds = /etc/security/audit/streamcmds
classes:

general =USER_SU,PASSWORD_Change

objects=S_ENVIRON_WRITE,S_GROUP_WRITE,S_LIMITS_WRITE,S_LOGIN_WRITE,S_PASSWD_READ,S_PASSWD_WRITE,S_USER_WRITE,AUD_CONFIG_WRITE
users:
root = general

-------------------------------------------------------------------------------------------------

As shown in this relatively simple configuration of auditing daemon, it is obvious that bin1 and bin2 parameter describes location of binary files while trail parameter specifies location of audit trail record.
The other two important parameters are binsize and cmd;”binsize” parameter specifies size of temporary files in bytes, before switching to the other binary temporary file while “cmd” specifies location of backend command for the BIN mode of AIX auditing subsystem. It is very important to note down that this backend program ( bincmds) is nothing more than usage of auditcat command as follows

/usr/sbin/auditcat -p -o $trail $bin


Events to be audited can be grouped in “classes” stanza of config file. As shown above, class named as “general” comprises of events related to user security (like switch user and password change) and then root user is configured to be audited against this class of events. It should be noted down that you can create classes of you own choice with arbitrary names and then use these classes to group predefined events as well as customized events.

Another important stanza of this configuration file is “objects”. In AIX auditing environment, auditing objects means system configuration files as well as kennel related objects present in ODM (for instance /etc/sendmail.cf & /etc/objrepos/SRCsubsys are both example of audit objects). Read, write & Execution of a file kernel object can be audited through audit objects. You can either specify objects in config file under the stanza of “objects” for relatively simpler configurations but for more complex auditing configurations you can specify all objects of your need in “object” file also, which is present in /etc/security/audit directory.






2.2 Stream Mode Configuration




The stream mode writes the audit records in a circular buffer in memory. The root user or audit group member user can continuously view the records from stream.out file by using vi, more or pg commands.



Structurally, STREAM mode writes the audit records to a circular buffer that can be read
by a /dev/audit device file, as shown in Figure 2-3 on page 10. When the kernel reaches the end of the buffer, it simply wraps to the beginning.
In stream mode, auditstream command is used to read the /dev/audit audit device file. On the other hand, the auditselect command can be used to select only those events in which system administrators are interested. This objective can be achieved by –c flag of auditselect command.

It is obvious Stream mode of AIX auditing is more likely to be used in those environments where system and security administrators are interested in monitoring real time data from audit events and generating some kinds of traps for more crucial security related events.

In the STREAM mode, the kernel writes records into a circular buffer. When the kernel reaches the end of the buffer, it simply wraps to the beginning. Processes read the information through a pseudo-device called /dev/audit. When a process opens this device, a channel is created for that process. Optionally, the events to be read on the channel can be specified as a list of audit classes. See the following figure for an illustration of audit STREAM mode:



As it is obvious, stream mode provides system and security administrators to have a real monitoring on audit events. This mode is therefore useful for the environments where auditors want to have continuous monitoring so that in case of any potential security breach or intruder attack, system and security administrators get notified immediately. Another use is to create a trail that is written immediately, preventing any possible tampering with the audit trail, as is possible if the trail is stored on some writable media.


Yet another method to use the STREAM mode is to write the audit stream into a program that stores the audit information on a remote system, which allows central near-time processing, while at the same time protecting the audit information from tampering at the originating host.


Basic stream mode configuration can be achieved by modifying /etc/security/config file as shown below.




/home/root> more /etc/security/audit/config
-----------------------------------------------------------------------------------------------------------
start:
binmode = off
streammode=on
bin:
trail = /auditfs/trail
bin1 = /auditfs/bin1
bin2 = /auditfs/bin2
binsize = 10240
cmds = /etc/security/audit/bincmds
freespace = 65536
stream:
cmds = /etc/security/audit/streamcmds
classes:
genuser=USER_SU,PASSWORD_Change

objects=S_ENVIRON_WRITE,S_GROUP_WRITE,S_LIMITS_WRITE,S_LOGIN_WRITE,S_PASSWD_READ,S_PASSWD_WRITE,S_USER_WRITE,AUD_CONFIG_WR
users:
root = general

-------------------------------------------------------------------------------------------------



As shown above, there are hardly any significant changes to configure stream mode as compared to what we did to configure binary mode, except we “on” stream mode and switch “off” binary mode.

It is important that streamcmd is nothing but a combination of auditstream and auditpr command:
/home/root> more /etc/security/audit/streamcmds

The output would be as follows:

/usr/sbin/auditstream | auditpr > /audit/stream.out &


As a result , whenever you start stream mode of AIX audit subsystem , by default you will start getting audit records in stream.out file. You can use either vi or cat or tail command to view real time audit records generated by auditing subsystem.









# tail -f /audit/stream.out

event login status time command
--------------- -------- -------- --------- ---------
S_NOTAUTH_READ root OK Thu May 24 14:07:05 2007 cat
S_NOTAUTH_READ root OK Thu May 24 14:07:05 2007 cat
FILE_Unlink root OK Thu May 24 14:07:09 2007 vi
S_NOTAUTH_READ root OK Thu May 24 14:07:09 2007 vi
S_NOTAUTH_READ root OK Thu May 24 14:07:09 2007 vi
S_NOTAUTH_READ root OK Thu May 24 14:07:09 2007 vi





3.0 Customized auditing output presentations



One of the most important aspect of AIX auditing subsystem is that juts like all other auditing subsystems of various other operating system like windows, Linux or Sun Solaris , it generates lot of audit records. As a result , output data coming from auditing is huge.

Best approach to overcome this problem is to properly configure auditing subsystem so that not all events and users should be audited. Instead it is always a good idea to identify critical system files, events and commands to be monitored and restrict this monitoring to few users only.

Finally, you can also restrict output audit records to certain specific auditable events. For example , in above scenerio where I configured auditing for “smit_READ” and “smit_WRITE”, there are other corresponding audit events appear in audit log like “FILE_Unlink”. There is provision of offloading these undesirable events so that information gathered through AIX auditing subsystem will be more specific.
There are several commands present, a combination of which can be used for this objective. Main command is “auditpr” which is used for formatting and display of audit records.

For example , after you setup binary or stream mode of audit subsystem and start audit subsystem ( using audit start command) you can use following “auditpr” command to display or read all audit records .

/home/root> auditpr -hhelpPRtTc -v | more



In stream mode, you can also use a combination of commands to display only selected events related audit records. There is “auditstream” command which stream out incoming data from audit subsystem. The resulted stream data can be inputted to “auditselect “command to select only specific audit events and discard remaining ones.

For instance, as in above example of auditing “smit_WRITE” event, if system administrators wants to collect related data to this specific event in a file “criticalwrites.out” then following combination of commands can be used as follows:

/home/root> /usr/sbin/auditstream | /usr/sbin/auditselect -e "event == smit_Write" | auditpr -hhelpPRtTc -v >> /home/root/criticalwrites.out

Similarly if system administrator wants to watch this critical event on system console , he can modify the above command as follows

/home/root> /usr/sbin/auditstream | /usr/sbin/auditselect -e "event == smit_Write" | auditpr -hhelpPRtTc -v > /dev/console &


4.0 Critical system events auditing configuration


Now we proceed to some relatively complex audit configuration to monitor some critical activities on AIX servers. We will create some customized audit events for this purpose, with our own defined objects to fulfill our requirements.



Event-A Monitoring changes in a specific file



There are certain important files which are always under root user ownership and system administrator with root password can easily play with these files. Traditionally, system administrator being super user for the UNIX operating system has full privileges so he can execute any commands through command line or through smitty menus and then delete the entries from corresponding log files (root’s shell history file and /smit.log files) This has remain a point of concern for IT auditors so here we proceed to configure auditing against any attempt to modify these critical files.
Let’s start with /smit.log file as an object for AIX 5L auditing. Same configuration steps can be used for monitoring root user shell history file.

First of all, I had to configure /smit.log file as an auditing object to be monitored by AIX auditing subsystem. For this purpose, I added following stanza in /etc/security/audit/objects file:


/smit.log:
r = "smitlogs_READ"
w = "smitlogs_WRITE"



Next, I added following entries in /etc/security/audit/config file as follows

classes:
readwrite = smitlogs_smitlogs_WRITE




It has added an event class of readwrite and finally we have to assign users of our interest (whom we want to audit against read write attempts to smit.log file). This again done in same file (/etc/security/audit/config)





users:
root = general, readwrite
jack = readwrite
thomas = readwrite
john = readwrite



Now in which data collection mode, we want to monitor this specific event, it really depends upon our own choice. Let’s assume, we want to monitor this specific event in stream mode , so we just “off” the binary mode in config file ( as described above) and “On” stream mode , start audit subsystem using “ audit start” command .
Because the data collection is enabled in STREAM mode, data collection can be started by running the following command:
# /usr/sbin/auditstream | auditpr -hhelpPRtTc -v

Optionally , as described in section 3.0 , you can combine auditselect command to select and display only specific events
#/usr/sbin/auditstream | /usr/sbin/auditselect -e "event == smit_Write" | auditpr -hhelpPRtTc -v


Or redirecting it to a file for later review by auditors

# usr/sbin/auditstream | /usr/sbin/auditselect -e "event == smit_Write" | auditpr -hhelpPRtTc –v >> /auditfs/criticalevents.out


The auditing results are written in the /auditfs/criticalevents.out file, which can be monitored in real time to keep track of the read and write operations.
If you use first option, typical output would look like below.

Listing 1. Output file—Data collection in STREAM mode

# tail -f /auditfs/criticalevents.out

event login status time command
--------------- -------- -------- --------- ---------
smit_READ root OK Thu May 24 14:07:05 2007 cat
smit_READ root OK Thu May 24 14:07:05 2007 cat
smit_READ root OK Thu May 24 14:07:09 2007 vi
smit_READ root OK Thu May 24 14:07:09 2007 vi
smit_READ root OK Thu May 24 14:07:09 2007 vi
smit_WRITE root OK Thu May 24 14:07:13 2007 vi
FILE_Unlink root OK Thu May 24 14:07:13 2007 vi
FILE_Unlink root OK Thu May 24 14:07:20 2007 vi


The interpretation of the output file is relatively simple as it shows that first of all root user opened the smit.log file using cat command and then by using vi command until the first write was done by root user on Thursday, May 24th, at 14:07:13, after which several operating systems events instances of “FILE_unlink” which updates file related information like inodes and file sizes accordingly.

If data collection in BIN mode is enabled, you can start the data collection by executing the following command:
# /usr/sbin/auditpr -v < /auditfs/trail > /auditfs/audit.out

This command writes the results of auditing to the /audit.out file, which can be monitored in real time as well. A sample is shown below:


Listing 2. Output file—Data collection in BIN mode

# vi /audit.out
"/audit.out" 30 lines, 2012 characters
event login status time command
-------- -------- ----------- ------------- --------------
smit_READ root OK Thu May 24 15:07:27 2007 cat

smit_READ root OK Thu May 24 15:07:27 2007 cat

FILE_Unlink root OK Thu May 24 15:07:32 2007 vi
filename /var/tmp/Ex21778
smit_WRITE root OK Thu May 24 15:07:37 2007 vi

FILE_Unlink root OK Thu May 24 15:07:37 2007 vi




Event-B Monitoring execution of specific command



Another event which may be of very much interest for security administrators and IT auditors is the event of execution of any specific command on system (like rmdev, cfgmgr or even simple rm command).

If you review /etc/security/audit/events, you can find many commands which generate many system related events. For example, you can find a stanza for rmdev command which generates three events namely “DEV_Stop”, “DEV_Unconfigure” and “DEV_Remove”. It means that when system administrator executes “rmdev” command, it will generate all these events.

Now if you want to audit execution of “rmdev” command by root user , first of all you have to add following entry in objects file

I first of all added following stanza in /etc/security/audit/objects file:


/usr/sbin/rmdev
x = "DEV_Remove"






Next, I added following entries in /etc/security/audit/config file as follows

classes:
commandexec = DEV_Remove



Finally I assigned this class of DEV_Remove to one of my developer user so that whenever he executes rm command on systems, security administrators get notified






users:
root = readwrite, commandexec




You can add some more commands to same class. For example to add “rmlv” command in same class, I have to add another object like follows



/usr/sbin/rmlv:
x = " LVM_DeleteLV "



and then add this auditable action to event class of “commandexec”



classes:
commandexec = DEV_Remove,LVM_DeleteLV

Now as event class of “commandexec” has already been assigned to root user, so you can start auditing of execution of rmlv command by shutting down and then restarting audit daemon.

Finally monitoring of this specific event can be done by

#/home/root>/usr/sbin/auditstream | /usr/sbin/auditselect -e "event==LVM_DeleteLV"| auditpr -hhelpPRtTc -v


Event-C Monitoring users related activities

Su and password change events are very critical events on UNIX operating system , especially with reference to root user. These events are , therefore by default monitored by AIX auditing subsystem.

In my scenario, config file already included these events. The events of “USER_SU” and “PASSWORD_Change” are already member of general class of events and are assigned to root user. So whenever root user switch to any other user , using su command or change his password using passwd command , it is being audited by AIX auditing subsystem.

For auditing any attempt by root user (or any other user) to change characteristics of any other user, i simply added following line in objects file , followed by changes in config file ( both mentioned below)

Added new entry in Objects File
/usr/bin/chuser:
X = “USER_Change“


Added new entry in Config File
general = USER_SU,PASSWORD_Change,DEV_Remove,LVM_DeleteLV,USER_Change






Summary:


Auditing always being a powerful tool for ensuring systems security and integrity, has been point of interest for IT auditors since long time, however its strength can only be realized in real sense when system and IT security administrators use this tool in positive sense to enhance systems security. AIX auditing subsystem is no more exception and it can be used for improving corporate level security , however as it generates lot of logs and therefore may put processing load in production environment , therefore it is required to configure this subsystem properly and for auditing of specific events only.

References: AIX 5.3 Security Guide IBM -SC23-4907-03

AIX 5L Auditing and Accounting IBM Red Book


About Author: Khurram Shiraz is Technical Consultant at GBM, Kuwait. In his ten years of IT experience, he worked mainly with IBM technologies and products especially AIX, HACMP Clustering, Tivoli and IBM SAN/ NAS Storage. He also has worked with IBM Integrated Technology Services group. His area of expertise includes design and implementation of high availability and DR solutions based on pSeries, Linux and windows infrastructure. He can be reached at kshiraz12@hotmail.com

Encrypt your AIX backups with OpenSSL

Have u met any auditor who ask you about security of your backups? For most of system and database administrators it is an annoying question, but still this fact can not be denied that the security of database and system level backups is major responsibility of the administrator who has taken these backups.
Security for our day to day taken system and database level backups can be accomplished in many ways. The first way is off course related to physical security of these backups. For most of the corporate, tape cartridges are still being used as main backup media. These tape cartridges are usually kept under safe and lock fire proof vaults and many organizations even allow access of these tape cartridges by even their own staff employees after certain approvals ( usually on IT manager level ) and they have fully defined procedures and policies for this purpose. Most of organizations also move these cartridges to their DR site and secure this movement with the help of secure transportation service provider companies.
But what if these tape cartridges or other backup media been stolen by some hackers during this movement. There is no doubt, that these backup cartridges contain very useful data and could even lead many financial loses if went into the hands of any criminal minded person. Here comes the role of encryption, which can be added to your backups and therefore protect your organization data against any unethical hacking. Many commercial backup encryption software are now available which can be used on database level; however there is still lack of such software availability for operating system level backups.

In this article, I will cover ways of encrypting (both symmetrical and asymmetrical) operating system level backups on AIX with the help of open source software called Open SSL. I will go through you with the steps with which you can even encrypt your mksysb and other vg and file system level backups.

Types of Encryption

There are two types of encryption methods: symmetric and asymmetric.
1) Symmetric Password Based Encryption - This is the simplest form of encryption. It is a symmetrical encryption method. The same password is used to encrypt and decrypt the data (or the file). This method is useful to encrypt sensitive information for yourself, or for family, or for a few trusted friends or coworkers.
2) Symmetric Secret Key Based Encryption
This is the simplest form of key based encryption. It is a symmetrical encryption method. The same secret key file is used to encrypt and decrypt the data (or the file). This is not a very commonly used technique.
3) Assymetric public/private Key Based Encryption
A public key file is used to encrypt the data. The corresponding private key file is used to decrypt the data. Only you should have access to your private key. You can distribute your public key to anyone who needs to send you data. This is the technique that is most commonly used in corporations
While we use either type of encryption for encrypting data, we have to keep this fact in our mind that asymmetrical encryption is ideal for encryption of small amount of data while symmetrical encryption can be used easily for large amount of data. Hence size of the data to be encrypted plays a vital role in deciding which type of encryption to be used in creating whole solution.

Different Encryption Tools for encrypting backups


There is lots of commercial encryption tools available which can be used for data backup’s encryption. Most of them are integrated with database level backups. For example, many of them encrypt oracle based database backups. However, for encryption of operating system level backups, there are not too much commercial products available.
Most of the corporate which want to encrypt their server’s operating system level backups (especially UNIX based systems) have to rely on open source tools available and then have to develop solution using these tools. OpenSSL and PGP are the two commonly used free tools which are used for this purpose.
While any organization thinks of developing solution for encrypting their day to day backups, they must have to consider two important points.

1. First, that solution should not have performance impact on daily backup operations. It means that encryption of backups should not consume long time as well as it should not be CPU cycles consuming on the server which is executing encryption algorithm.
2. The decryption mechanism should be well tested and documented. This means that when there is a need arises for restoration of data, there should not be any surprises.
Although PGP can be well utilized for developing solution for encrypting backups on AIX with above mentioned requirements, I will concentrate to demonstrate how to develope solution using OpenSSL only in this article.

OpenSSL usage for data & backups encryption

OpenSSL is a library that provides cryptographic functionality to various applications. On major Linux and other BSD Unix variants, OpenSSL is provided under GPL licenses. It also includes a command line utility which can be used for different cryptographic purposes
While using OpenSSL on AIX, you can opt for either using OpenSSL from AIX tool box for Linux (website or CD) or download from Bull website.
I opted for getting it from Bull website and installed its rpm without any problem.
Now the first thing is to get the feeling of how the OpenSSL works.

With OpenSSL encryption of a text file is very simple. You have to be root user and then you have to execute:

/home/root> openssl enc –bf –ofb salt –in sample.txt –out enc.txt

The command will prompt for password before encrypting data present in sample.txt file. This is a typical example of symmetrical encryption.

To decrypt, use the following command

/home/root> openssl enc –d –bf –ofb –salt –in enc.txt –out abc1.txt

Above command will ask for password which was used in encryption before decryption.

Now if you want to encrypt the same data file with asymmetrical encryption, technique will be slightly different. First, you have to generate private key with the following command:
/home/root> openssl genrsa –des3 –out prvkey.pem 4096

Then you have to derive public key from this private key by using following command

/home/root> openssl rsa –in prvkey.pem –pubout –out pubkey.pem

Now to encrypt data present in abc.txt file using this already generated pair of keys, you have to execute

/home/root> openssl rsautl –encrypt –inkey pubkey.pem –pubin –in abc.txt –out encr.txt

And to decrypt,

/home/root> openssl rsautl –decrypt –inkey prvkey.pem –in enc.txt –out abc1.txt

This asymmetrical encryption with help of two keys works well for small inputs of data. However as soon as size of data to be encrypted increases, this technique generally does not work well. Imagine when you have a 30 GB file system and your management wants to take an encrypted backup of this filesystem. Under these circumstances, you can not use this asymmetrical technique of encryption. You however, can combine symmetrical encryption with asymmetrical encryption to design a very good solution for need of encrypting your backups.

For this solution , we will start with creating a small text file called backup_key with some string ( which may include numbers and characters). This string will be our password string. We will encrypt this key file with asymmetrical, two keys based encryption technique:
/home/root> openssl genrsa –des3 –out prvkey.pem 4096
/home/root> openssl rsa –in prvkey.pem –pubout –out pubkey.pem
/home/root> openssl rsautl –encrypt –inkey pubkey.pem –pubin –in backup_key –out backup_keyencr.txt

Now you have an encrypted secret key which has been encrypted with strong asymmetrical encryption technique.

The next step would be using this key to encrypt backed up data (symmetrical encryption).

/home/root> tar –cvf - /home/oradata1! /usr/local/bin/openssl enc –des –cbc –salt –pass file:/home/root/backup_key.txt > /dev/rmt0

And for decrypt this backup data, you have to execute

/home/root> /usr/local/bin/openssl enc –d –des –cbc –salt –pass file:/home/root/backup_key.txt < /dev/rmt0! tar –xvf -

Now this solution can work very easily for any corporate environment. You can send tape cartridge containing encrypted tar backup along with a floppy containing encrypted key (backup_keyencr.txt) to decrypt this encrypted tar backup to your disaster recovery site. However any person at you DR site should already have RSA private key which has been used in encryption of this backup_key file. You, therefore have to send this private key, one time, to the person at DR site so that he can first decrypt backup_key and then use decrypted backup_key to decrypt tar backup. Consequently your backups will be entirely safe during the backup movements from your main site to DR site. Even if your backups go into hand of any criminal persons during this movement, they can not decrypt the key file without private key and hence can not decrypt backup data.


Encrypting your AIX level backups


AIX level operating systems backups like volume group, file system and even mksysb can be encrypted. However , as these backup utilities send backups directly to tape drive or CD devices without buffering so encryption of data being backed up by these utilities has to be done in a different way ( as compared to tar command backups ).

To encrypt volume group level backups, I used tricky solution. I first of all created a special pipe device file which can operate on FIFO basis.

/home/root> mknod /tmp/vgbk p

/home/root> cat /tmp/vgnest ! /usr/local/bin/openssl enc –des –cbc –salt –pass file:/home/bck_key ! /bin/dd of=/dev/rmt0 obs=100b &

/home/root> vgbackup datavg /tmp/vgbk


Similarly you can apply same trick to mksysb backups, which is to create a FIFO special device pipe file and then initiate a process in background which can read this file and then encrypt the incoming data with the help of asymmetrical key. This incoming data is off course fed by mksysb command to pipe device in foreground.

Summary:
Although many techniques can be used to encrypt your AIX level backups, however OpenSSL off course provides a easy and free way of encrypting your operating system level backup. No matter whether you use OpenSSL, PGP or any commercial software to encrypt your backups, always remember to test your restoration scheme and procedure, before time actually comes to do your restoration.


Note: This article was published in AIX Update January 2008 edition.

Enhance your security with secret port knocks

In the field of IT systems security, concept of” port knocking” is relatively new. However with the passage of time, it is getting popular day by day among system and security administrators.

Port knocking is a method of externally opening ports on a firewall by generating a connection attempt on a set of pre-specified closed ports. Once a correct sequence of connection attempts is received, the firewall rules are dynamically modified to allow the host which sent the connection attempts to connect over specified port (s).

The primary purpose of port knocking is to prevent an attacker from scanning a system for potentially exploitable services by doing a port scan. Until the correct knock sequence is used, the protected ports will appear closed– so attackers won’t be able to conduct an attack on those ports.

More specifically, Port knocking works on the concept that users wishing to attach to a network service must initiate a predetermined sequence of port connections or send a unique string of bytes before the remote client can connect to the eventual service.

For example, suppose that a remote client wants to connect to an FTP server. The administrator configures the port-knocking requirements ahead of time, requiring that connecting remote clients first connect to ports 2000, 4000, and 7107 before connecting to the final destination port, 21 on FTP server.

The administrator tells all legitimate clients about the correct” combination” of knocks to port knocking daemon running on FTP server and hence when they want to connect to FTP service, they simply send these knocks to the server and then start using FTP service.

The question arises, what is the basic advantage of the additional step of sending knocks and then connecting to FTP service? The answer is simple: The FTP service is not always running on the server, it will be started only when the correct port knocks are sent to server, and it will shut down once it receives another predefined sequence of port knocks.

The potential backdoor to business-critical services is only to be opened for a short time, when it’s required. Once the service is no longer needed, it is closed again, mitigating the vulnerability to attack.

One of the primary advantages to using port knocking is that it is platform, service, and application agnostic. Any operating system with the correct client and server software can take advantage of port knocking. If you need help finding a tool, you can find a list of port knocking implementations here. The site lists clients and daemons for pretty much any platform you’d care to use.

I selected knockd, which is considered to be one of the most famous and robust implementation of port knocking mechanism for Linux and UNIX. In this article, I will cover setting up port knocking on a Red Hat Enterprise Linux (RHEL) server, using knockd, a popular open source port knocking tool. Most importantly, I will try to extend the idea of port knocking beyond simple firewall modifications to more complex system administration tasks.

Note that knockd is available for other systems as well, so if you’re using Debian, Ubuntu, Mac OS X, or even Windows, you should be able to follow along with most of the advice herein to secure your system with knockd.

Flaws with Port Knocking

Before we begin, I should note that port knocking has some detractors. Some IT security professionals say that a predefined and fixed sequence of knocks is, in and of itself, a security flaw. To overcome this, some port knocker daemons have been modified to generate a random sequence of knocks, which can be used by clients to issue requests.

It’s also important to remember that port knocking is just one component of a successful security strategy. You’ll need to deploy other security mechanisms so that if an attacker is successful in providing the correct sequence, they are still faced with authentication and other barricades before connecting to a service.

Port Knocking: A Basic Overview

To start, let’s take a look at the basic functionality of a port knock server. knockd is a daemon that runs on a server, passively listening to network traffic. You configure knockd with a sequence of ports, the length of time between connection attempts, the type of packet that will be sent, and the command to be run when the correct sequence is given.

Once knockd” sees” a port sequence it has been configured to recognize, it will run the command it’s been configured to run. Note that you can use TCP, UDP, or a combination of both. Usually the action will be an iptables command, but not always.

So, to implement port knocking, we start with the installation of knockd and run it in the background. (Or foreground, if you wish, but we will usually want to run it in the background.)

Securing A MySQL Database Remote Connections with Port Knocks

Now that we know what port knocking is, let’s put it to use. In this scenario, I have a business-critical MySQL-based application running on RHEL. On occasion, I need to allow remote connections from a DBA who is performing basic database maintenance activities.

However, for security reasons, we don’t want to allow remote database connections at all times or from every IP address. Because we wanted tighter control over remote connections, we decided to explore port knocking so that remote connections would be open for a limited time only and from a specific IP address.

Let’s start with the firewall rule, just in case you’re not already a firewall wizard. To append a rule to one of the” chains,” you’ll use the -A option. The -I parameter tells iptables to insert the rule into a specific position in the chain. This is important because you may want specific rules to be processed first. Make sure you give it a rule number.

Now, to secure MySQL connections to my database server (172.16.2.183), I blocked network traffic on server’s MySQL port (default 3306) coming from all addresses. For this purpose, I executed following command:

iptables -A INPUT -p tcp -s 0/0 -d 172.16.2.183 --dport 3306 -j REJECT

You don’t want to be reissuing the command every time you restart the machine, so you’ll want to save the rule permanently, using iptables-save.

Getting and configuring knockd

The next step is to install the knockd server on the system you want to use it on. You can get the RPM from the RHEL network.

After installing knockd it’s time to customize your configuration. The knockd config file is found at /etc/knockd.conf

[options]
 logfile=/var/log/knockd.log
[DB2clientopen]
       sequence    = 7050,8050,9050
       seq_timeout = 10
       tcpflags    = syn
       command     = /sbin/iptables -I INPUT 1 -p tcp -s 192.168.2.201
      --sport 1024:65535 -d 172.16.2.183 --dport 3306 -m state
--state NEW,ESTABLISHED -j ACCEPT
[DB2clientclose]
       sequence    = 9050,8050,7000
       seq_timeout = 10
       tcpflags    = syn
       command     = /sbin/iptables -D INPUT 1

Let’s take a look at the format. The syntax is very simple, you give knockd option / value pairs, separated by =, and port numbers are separated by commas in the order you want the” knocks” to be received. Don’t forget to specify a logfile, you may need to review it later!

It should be obvious from the knockd.conf example that it has two types of actions that can be executed by the daemon, depending on the sequence it receives.

First, if it receives syn packets to port 7050, 8050, and 9050, knockd will insert the first iptables rule as rule number 1 in the INPUT chain. This will open the MySQL database port, so a remote connection can be made from 192.168.2.201– and only that IP address. It’s a good idea to specify the IP address whenever possible, so that if an attacker tries to connect while the port is open, they will still be denied.

On the other hand, if the server receives a knock sequence of 9050, 8050, and 7000, it will delete the rule so that all remote database connections will be closed down again.

I made sure that MySQL would know what address my DBA would be coming from, so I added my PC’s IP address to the server’s /etc/hosts file and created a test database called test1, and created a user called test1 as well with the appropriate grant privileges.

First, fire up the MySQL client with mysql-u root-p test1 and enter the following commands:

mysql> create user test;
mysql> grant all privileges on *.* to 'test@dbawin'
identified by 'polanipass' with grant option;

Next, restart knockd as a daemon.

/usr/sbin/knockd -d

It should be noted that, by default, knockd will start listening on eth0. If you need it to run on a different interface, you can configure it to do so using the -i option. For instance, to start knockd as a daemon on wlan0 you’d use /usr/sbin/knockd-i wlan0. If you’re always going to run knockd on a different interface, you can add this to your knockd.conf:

[options]
interface = wlan0

Knock, Knock, It’s Me!

Now, knockd isn’t very useful without a client, so let’s get a client to talk to knockd. I chose a Windows-based Cygwin client, but you can find a client for just about any client OS at the implementations page mentioned earlier.

To use the Windows client, you open a DOS prompt and run something similar to this command:

C:KNOCKKNOCKWINDOWS>knock.exe 172.16.2.183 9050 8050 7000

Of course, the IP address and ports will vary. Once the” knock” is issued, the knock daemon will execute the iptables command listed under the [DB2clientopen] section of knockd.conf and add the rule in INPUT chain to allow DB2 PC to connect to database running on server.

Now you can connect to your MySQL database with your favorite client and do whatever you need to do. Once you’re finished, it’s time to close the door.

If you send the close knock sequence, in this case a syn packet sent to ports 9050, 8050, and then 7000, the MySQL port will be closed and all connections will be terminated. If you try to reconnect to the server, your MySQL client will time out and you’ll eventually see an access error. This will be the case until you send the proper sequence to re-open the port.

So, now you see how you can use port knocking to increase security for remote MySQL connections. Of course, this is really database (and application) independent, so you can use port knocking to secure any database or application you want to connect to remotely.

If it’s too much hassle to open and close the connection each time you need to connect to the database, it might make more sense to set it up so that the port is open during specific hours. For example, if your database guru works 10 a.m. to 7 p.m., you could set up a script to open the port a bit before 10 a.m., and close the port a bit after 7 p.m.

This is not quite as secure, but it does mean that the port won’t be open 24/7, so it may block some automated and casual (i.e., not targeted) attacks. Also, if the port knocking is coupled with only allowing connections from specific IP addresses or IP address ranges, then you have an additional layer of security.

Performing Other System Administration Tasks with Knocks

But wait, that’s not all! Port knocking can be used to do more than set iptables rules. After configuring knockd to play doorkeeper, I decided to explore the feature and see if I could use it to make my life easier in other ways.

I decided I wanted to be able to restart my system remotely, just by” knocking” in the right sequence. I also configured knockd to kick off my backups to tape, so I don’t even need to log in to start the backup– just send a quick series of packets, and my data is safe another day.

Here’s my /etc/knockd.conf:

[options]
 logfile=/var/log/knockd.log
[systemreboot]
       sequence    = 7050,8050,9050
       seq_timeout = 10
       tcpflags    = syn
       command     = /usr/bin/reboot
[systembackup]
       sequence    = 9050,8050,7000
       seq_timeout = 10
       tcpflags    = syn
       command     =  /usr/bin/tar -cf  /dev/rmt0 /home/root/

You can take this a lot farther, and set it up so that other admins (say, the junior admin who’s reliable but still a bit green) can perform complex actions just by using a knock client, or even just by running a shell script that sends the packets.

Summary

Port knocking is a very useful tool for systems security. It is because of its usefulness and robustness that the number of implementations, and users, are growing rapidly. If you can open a door into a closed black box for to perform some system administration tasks, even without requiring a login to the system, it can be very ideal for many environments.

Finally, it is always a good idea to further secure your systems by changing the knock sequences frequently, or by using random seed generators to create random port knocks.

Note: This article belongs to one of my published work on security. It was published in Linux Magazine , March 2008 print edition.It can still be found on their website at www.linux-mag.com/id/5445

Configuring SSH in Just Five Minutes

Have a problem in setting up SSH on UNIX or Linux systems Or you are tired of reading big manuals for SSH setups... No problem.. I am documenting three simple steps for configuring SSH with RSA authentication... Do it by yourself in 5 minutes
Prerequisite: the remote system needs to have ssh installed and sshd running, with RSA authentication enabled. This is the default configuration, and is typically specified with the option: RSAAuthentication yes in /etc/ssh/sshd_config.

Zeroth step: You will need ssh installed on your computer. Procedures for doing this vary by Linux and/or Unix (or other OS) distribution. Refer to system documentation for details.
1. Create a local RSA key:
$ ssh-keygen
Follow the prompts, this takes a few seconds as your computer gathers entropy from the system.
You will be asked to supply a passphrase, you can elect to choose a null passphrase. I would recommend you *do* supply a passphrase as it provides additional security -- your key is not useful without it. The upside is that you only have to remember this one passphrase for all the systems you access via RSA authentication. You can change the passhrase later with "ssh-keygen -p".
This is typically stored in your home directory under .ssh/identity. After doing this, a directory listing of ~/.ssh should look like:

-rw------- 1 karsten karsten 528 Aug 4 21:37 identity
-rw-r--r-- 1 karsten karsten 332 Aug 4 21:03 identity.pub
-rw-r--r-- 1 karsten karsten 28106 Jul 26 16:52 known_hosts

2. Copy the public key identity.pub to the hosts you wish to access remotely. You can do this by any method you like, one option is to use scp, naming the key to indicate your present host:
$ scp .ssh/identity.pub remote-user@remote.host:local-host.ssh
e.g.: I might name a key for my host "navel" navel.ssh.
3. Connect to the remote host. You don't have RSA authentication enabled yet, so you'll have to use an old method such as walking up to the terminal or supplying a password. Add the new hostkey to the file .ssh/authorized_keys.

$ cat local-host.ssh >> .ssh/authorized_keys
Note the use of two right-angles ">" -- this will add the contents of local-host.ssh to a preexisting file, or create the file if it already exists.
Check the permissions of .ssh/authorized_keys, it must be as below or you won't be able to use RSA authentication:
-rw-r--r-- 1 karsten karsten 334 Aug 4 21:03 authorized_keys
And you're all set!
4. Test the method by logging out of the remote server and trying to connect to it via ssh:
$ ssh remote-user@remote-host
You may be prompted for your RSA key passphrase, but you won't need a remote password to connect to the host. If you are prompted for a password, or your connection is refused, something is wrong, and you'll want to refer to the troubleshooting section below.
You can repeat steps 1 - 3 for each remote host you wish to connect from.
More information:
• man ssh
• man ssh-keygen
• man sshd

Network services minimization on AIX

Minimize network services on AIX Servers

Principles

Network services present a significant risk to security:

• Only enable the strict minimum of services needed. The number system processes listed by "ps –ef" or equivalent should be less than 10.
• Use encrypted tools (like SSH) rather than clear-text network logins (e.g. telnet, 3270, ftp, rlogin, rcmd).
• Keeping up to date with security patches on network daemons is particularly important.
• Daemons should run as non-root users.
• Daemons should "chroot" to a dedicated directory.
• Use encryption where possible to prevent snooping or replay attacks.
• Services must use minimal umask, file permissions etc.
• Strong authentication (with token or lists) should be considered for critical services.
• Applications should package structure

Minimise Inetd network Services

Inetd a process which automatically starts certain daemons such as telnet, ftp, if connections are made.

Inetd services can be enabled or disabled with the command 'chsubserver' on AIX. Likewise after changes to inetd configuration, the daemon needs to be send a hang-up signal - 'refresh -s inetd'. For example:

[server1]# chsubserver -d -v daytime -p udp
[server1]# chsubserver -d -v daytime -p tcp
[server1]# grep daytime /etc/inetd.conf
#daytime stream tcp nowait root internal
#daytime dgram udp wait root internal

It is recommended that ALL services except the following be disabled:

..... TBD list ...

The can be achieved with the following commands:
chsubserver -d -v daytime -p udp
chsubserver -d -v daytime -p tcp
..... TBD list ...

securetcpip ?

Special services which may be needed (discuss what measures to take for each one)

1. ftp

2. telnet

3. other?

4. tftp - for diskless booting : /etc/tftpaccess.ctl

Minimize /etc/rc.tcpip network services

A description of what services are started in /etc/rc.tcpip and how they can be changed with chrctcp.

/usr/sbin/no -o clean_partial_conns=1
/usr/sbin/no -o bcastping=0
/usr/sbin/no -o directed_broadcast=0
/usr/sbin/no -o ipignoreredirects=1
/usr/sbin/no -o ipsendredirects=0
/usr/sbin/no -o ipsrcroutesend=0
/usr/sbin/no -o ipsrcrouterecv=0
/usr/sbin/no -o ipsrcrouteforward=0
/usr/sbin/no -o ip6srcrouteforward=0
/usr/sbin/no -o icmpaddressmask=0
/usr/sbin/no -o nonlocsrcroute=0
/usr/sbin/no -o tcp_pmtu_discover=0
/usr/sbin/no -o udp_pmtu_discover=0
/usr/sbin/no -o ipforwarding=0

Minimize /etc/rc.nfs network services

A description of /etc/rc.nfs

/etc/exports

secure nfs : /usr/secretdata -secure

Minimize inittab services

A description of what services are started in /etc/inittab and how they can be changed with mkitab and rmitab.

Minimize other services

• Restrict AIXwindows/CDE login to console
• The xss command uses the enhanced MIT screen saver extensions.
• xauth, xhost
• Disable anonymous ftp
• Disable anonymous ftp writes
• Disable ftp to system accounts
• Lock down root access

The default configuration allows telnet and rlogin access to the root account. This can be configured in the /etc/security/user file -- set the rlogin option to "false" for all system accounts. System managers should login to their account and then su so we have an audit trail.

• disable SNMP readWrite communities
  The default SNMP configuration includes these "readWrite" communities:

[server1]# grep readWrite /etc/snmpd.conf
# readOnly, writeOnly, readWrite. The default permission is readOnly.
community private 127.0.0.1 255.255.255.255 readWrite
community system 127.0.0.1 255.255.255.255 readWrite 1.17.2

---