Adsense Leaderboard Ad

4.12.2016

How to Log IPTables - Send messages to rsyslog or journalctl

Question sent in by Khristian from Philadelphia:

Q: I have been trying to log some traffic from iptables and have had little success.  I have found multiple tutorials online explaining how to get traffic from iptables into syslog, but none have worked out for me.  I specifically want to log dropped packets to a separate file.

A: This is fairly straight forward, let's give this a quick look using rsyslog, then we will touch on journald.

First, if you read my basics of iptables article you know there are three basic actions that can be taken on traffic that meet your defined rules (ACCEPT, DROP, REJECT).  There is another built in action called LOG.  This basically tells iptables to send this traffic to rsyslog, which is the default logging daemon in most modern Linux distros.

First, lets APPEND a rule to the INPUT chain. This will have to go before any catch all DROP statement since iptables reads rules in order from top down.

iptables -A INPUT -j LOG --log-level info  --log-prefix "IPTABLES-DROP: "
Now that we have a rule in place to send traffic to rsyslog, we have to tell rsyslog where to send them.  The log prefix (IPTABLES-DROP: ) makes it easy to tell rsyslog which lines we want sent to it's own file.

In the default rsyslog configuration file (/etc/rsyslog.conf) there is a rules section that starts with the following line:

#### RULES ####
We will add our configuration right after that line.  So let's add:

:msg, startwith, "IPTABLES"                                     /var/log/iptables
&~

The first line tells rsyslog to find any messages starting with "IPTABLES" and send them to /var/log/iptables.  The second line "&~" tells rsyslog to discard those messages.  If we do not add the second line, rsyslog will log those messages to both /var/log/iptables as we want, but it will also add them to /var/log/messages.

I hope that helps with rsyslog, but for those using journald, it is even easier since there is no configuration file to edit.  So if you are using journald and would like to log iptables messages, you can use the same rule in iptables:

iptables -A INPUT -j LOG --log-level info  --log-prefix "IPTABLES-DROP: "

The messages will be logged to the journald as kernel messages, so all you have to do is query journald for kernel messages like so:


journalctl -k

Or you can follow (tail) the kernel messages like:

jounralctl -k -f

Good luck!


4.01.2016

Start Specifc Services First in RedHat 7/CentOS 7 - SystemD - Set Service Start Order

Question sent in by: Gaurav P

Q: I was wondering if there is a way that I can specify one service to always start before the other service? For eg. I have enabled both mongodb and celiometer service to start at boot time, but I want to ensure that every time the mongodb service starts before the celiometer. 

A: You can configure dependencies for certain services. For example you can make celiometer dependent on mongodb, this way celiometer will not start before mengodb.

NOTE: I am not familiar with celiometer, so for this example we will use mongodb and apache (httpd).

This should work in any version of Linux running Systemd, including but not limited to Redhat 7, CentOS 7, Fedora 20 or higher, Ubuntu, etc...


So let's say you want mongodb to start first before httpd.  You can simply edit the /usr/lib/systemd/system/httpd.service file and look for the following line:


After=network.target remote-fs.target nss-lookup.target

This line tells httpd to start AFTER network remote-fs and nss-lookup targets.

Simply add you mongod.service like so:

After=network.target remote-fs.target nss-lookup.target mongod.service

This will ensure mongodb is started before httpd.

There are other options as well, for example:

Wants=mongod.service
(This will activate mongodb when httpd is started, but will not cause httpd to fail if mongodb fails to start)

Requires=mongod.service
(This will activate mongodb when httpd is started, but will cause httpd to fail if mongodb fails to start)

BindsTo=mongod.service
(This will stop mongodb when httpd is stopped)


There is a lot of information available on the interwebs to guide you through systemd, including the very well documented man pages.  

1.16.2016

How To Stop Your SSH Session From Disconnecting

Question sent in by: Augustino from Tallahassee. 

Q: When I connect to one of my servers via SSH, after about 10 minutes of inactivity my connection is closed.  How do I stop this from happening.

A: You can configured your SSH client to send a small packet called no-op (no operation). The no-op is basically tells the other system "Nothing to do" but in communicating with the system tells SSH that your alive on the other side, thus not closing the TCP connection and logging you out.

To configure this for your current username only, add the following line to "/home/user/.ssh/config" or "~/.ssh/config" (the tilde "~" is just an alias for your home directory):

Host *
 ServerAliveInterval 60

NOTE: Make sure to indent the second line.

The "Host *" line basically tells the SSH client to apply the settings to ANY host.  Will the number after "ServerAliveInterval" is the amount of seconds to wait to send a no-op.

If you would like to apply this to one host only, you can. You can also adjust the interval seconds to meet your needs.

Host putorius.net
 ServerAliveInterval 300

Now you have to read (or source) the file like so:

source ~/.ssh/config
That configured your SSH client to send a no-op every 60 seconds. This will ONLY effect the one user with this in his/her home directory.

To apply this setting globally (or to ALL users) you can add (or change) the line in /etc/ssh/ssh_config:

ServerAliveInterval 60
NOTE: Make sure you add it to the SSH CLIENT configuration "ssh_config" and not the SSH SERVER configuration "sshd_config".

Let me add, SSH sessions are usually logged out after a certain amount of time for security reasons.  It is a best practice to close idle sessions to avoid unattended access to a system. Many companies have policies that govern the way a system is configured.  Circumventing these policies could be ground for disciplinary actions.