Problem

The MySQL Enterprise Audit plugin stops logging to the audit log file /var/log/mysql/audit.log when the MySQL service starts. The following errors may be seen in the MySQL error log file /var/log/mysql/error.log:

Solution

When the audit log plugin opens its log file, it checks whether the XML declaration and opening root element tag need to be written and writes them if so. When the audit log plugin terminates, it writes a closing tag to the file.

If the log file exists at open time, the plugin checks whether the file ends with an tag and truncates it if so before writing any elements. If the log file already exists but does not end with or the tag cannot be truncated, the plugin considers the file malformed and fails to initialize. This can occur if the server crashes or is killed with the audit log plugin running. No logging occurs until the problem is rectified.

To deal with this problem, you must either remove or rename the malformed log file:

Solution

I resolved this problem by changing the Provider setting for this connection from “Apache Directory LDAP Client API” to “JNDI (Java Naming and Directory Interface)”. However, I am not entirely certain as to why this resolves the problem.

My System Configuration

Client OS: Linux Mint 16 Petra x86 64-bit

Apache Directory Studio Version: 2.0.0.v20130628

OpenJDK Runtime Environment 1.7.0_25

LDAP Server: OpenLDAP 2.4.21

LDAP Server OS: Ubuntu Lucid 10.04 LTS x86 64-bit

References

The default firewall configuration tool for Ubuntu is UFW (uncomplicated firewall). It was developed to ease iptables firewall configuration. By default UFW is disabled, and there are no packet filter rules in the Linux kernel:

When you turn UFW on, it uses a default set of rules that should be fine for the average home user. In short, all incoming connections will be denied, thus protecting the system from intruders. To turn UFW on:

# ufw enable
Firewall is active and enabled on system startup

Once enabled, you are done! All future incoming connections will be denied. This configuration will be reloaded at boot.

You can easily view the status of ufw:

# ufw status
Status: active

If you are interested in seeing what UFW did, then run the following command to output the current UFW rules that are applied to your iptables. While it looks like UFW has done a lot, most of this is benign. UFW basically sets up a framework in order for it to easily add additional rules in the future, as well as faciliting logging.

This is the rule in the INPUT chain above that drops incoming connections:

DROP all -- 0.0.0.0/0 0.0.0.0/0

You may want to install gufw. It is a graphical user interface for UFW that provides an easy and intuitive way to manage your Linux firewall. It supports common tasks such as allowing or blocking ports. There is a status switch that can be turned on and off, which basically performs the commands “ufw enable” and “ufw disable“.

GRUB 2

Configure GRUB 2 /etc/default/grub:

# How long to time out showing blank screen. Commenting this out or setting no value
# after the = sign means the menu will be displayed for the number of seconds
# designated by GRUB_TIMEOUT.
#GRUB_HIDDEN_TIMEOUT=

GRUB

Have GRUB display the menu interface. GRUB will still automatically boot the default entry, unless interrupted.
Modify the GRUB configuration file /boot/grub/grub.conf. Comment out the line that contains “hiddenmenu”.

After each execution of aide, the mtime and ctime on these directories are changed. Hence, aide detects and reports these changes.

This is due to prelinking. If you disable prelinking, then this problem will go away. To disable prelinking, modify the configuration file /etc/sysconfig/prelink. Change “PRELINKING=yes” to “PRELINKING=no“. Then manually run /etc/cron.daily/prelink as root. After updating the aide database, subsequent aide checks will not have this problem.

Download and Install

At the time of this writing, only an old version of libpam-google-authenticator is available in the EPEL package repository. Hence, we are going to compile it from source. First, install prerequisites:

# yum install make gcc pam-devel

TOTP (timebased one-time-password) security tokens are time sensitive. Hence, make sure that your system has ntpd running, and is configured to start the service at boot:

Set Up Google Authenticator

Before configuring SSH, first set up Google Authenticator. Run “google-authenticator” as the user you wish to log in with via SSH. You will be prompted with a few questions.

Do you want me to update your "~/.google_authenticator" file (y/n) y
https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/user@server%3Fsecret%3DABCD12E3FGHIJKLMN
Your new secret key is: ABCD12E3FGHIJKLMN
Your verification code is 98765432
Your emergency scratch codes are:
01234567
89012345
67890123
45678901
23456789
Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) y
By default, tokens are good for 30 seconds and in order to compensate for
possible time-skew between the client and the server, we allow an extra
token before and after the current time. If you experience problems with poor
time synchronization, you can increase the window from its default
size of 1:30min to about 4min. Do you want to do so (y/n) y
If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting (y/n) y

These settings are stored in the user’s ~/.google_authenticator file.

Copy and paste the URL into your browser and scan the QR code that is displayed with the app Google Authenticator on your mobile device. If you can’t scan the QR code, then you can enter the information manually with the given secret key and verification code. A new verification code should be displayed every 30 seconds.

Emergency one-time use verification codes are also given for you to write down in a secure place in case you were to not have your mobile device with you.

Configure PAM

Have PAM require Google Authenticator for SSH authentication. Modify /etc/pam.d/sshd and add the line “auth required pam_google_authenticator.so” at the top.

#%PAM-1.0
auth required pam_google_authenticator.so
auth required pam_sepermit.so
auth include password-auth
account required pam_nologin.so
account include password-auth
password include password-auth
# pam_selinux.so close should be the first session rule
session required pam_selinux.so close
session required pam_loginuid.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session required pam_selinux.so open env_params
session optional pam_keyinit.so force revoke
session include password-auth

This will require all users to use Google Authenticator for SSH authentication. To only require those users with Google Authenticator configured for their account (the ~/.google_authenticator file exists), then instead enter “auth required pam_google_authenticator.so nullok“.

The order in which you place items in this file matters. Given this configuration, you will first be prompted for your Google Authenticator verification code, then for your system account password when you SSH into the system.

Configure the SSH Service

When you SSH into the system as a user configured for Google Authenticator, you will have to enter the verification code that is displayed in you Google Authenticator app, and then by your system password at the next prompt:

login as: root
Verification code: 01234567
Password: *******
#

If you have any problems, look in the /var/log/secure system log file.

If you have SELinux enabled, you may not be able to login, and get this error in /var/log/secure:

Modify /etc/sysconfig/iptables to the following in order to allow a particular IP to initiate 5 new SSH connections within a window of 60s. If additional new SSH connections are opened for that IP, then all packets from that IP will be dropped, and the incident will be logged to /var/log/messages. After 60s that IP will be able to open 5 new SSH connections, and so on. Please note that when I say that a new SSH connection is made that I do not mean to imply the SSH authentication was successful. Just that the two hosts initiated a new TCP/IP connection over port 22.