Basic NetSec Analysis Tools in Linux Operating Systems

In a previous article, I wrote about expanding usage of Wireshark on Linux operating systems and that got me thinking about command line utilities for network and system security. I thought about couple of simple tools that I’ve used in various capacities – tcpdump, iptables and syslog.

tcpdump

Like Wireshark, tcpdump is a packet analyzer for network traffic. While most people might utilize telnet and ping to test network connectivity in separate instances, tcpdump will provide a full print out of each packet as it moves between source and destination. tcpdump does require some actual network traffic in order to properly diagnose an issue. What makes tcpdump great, if packet print outs weren’t what you needed already, is that can be modified with various flags looking to look for specific traffic – source, destinations, ports – helping to diagnose network issues.

Where I think Wireshark is better than tcpdump is in the use of a GUI (tcpdump is CLI only) and that tcpdump relies on current traffic; Wireshark can examine previous packet capture (PCAP) files. However, to me, tcpdump’s greatest feature is being baked into most Linux distributions, which allows, with appropriate root or sudo permissions, to be able to logon to a Linux system and begin using tcpdump to analyze traffic as quickly as it is initially detected.

When I was configuring IDS/IPS systems, I would often have to investigate traffic that would be suspicious in nature but not tripping signatures. Opening two terminal windows, I could use tcpdump to examine the live traffic and simple whois commands to get name resolutions for the IP addresses in question. While I examined the traffic, I could see which ports were being addressed and whether handshakes were completing. Often times I was working with smaller clients who were not expecting much non-ARIN traffic. From there, I could make recommendations on what to do with the traffic, as in if it appeared malicious and needed additional blocking rules.

Outside of a strict security analysis perspective, I also started using tcpdump for general network troubleshooting. If I cannot see a completion of a handshake, I have all of the data right in front of me to determine where in the network stack things are timing out and communication is breaking down. Both of these applications have saved me a lot of time, so I would recommend being familiar with this command for any Linux administrator, whether they are directly in the security realm or not.

iptables

iptables is host-based firewall software. It can give its host machine an extra layer of protection with behavior similar to that hardware-based firewall sitting further up the diagram towards the edge/public Internet connections. While the syntax is a little muddy first learning it, it is repetitive, so programming the access control lists (ACLs) becomes easier. As I noted earlier, doing IDS/IPS configurations, we would also utilize iptables to do some local firewalling for clients that wished to have troublesome IP addresses blocked and did not have an additional firewall in those zones. Like hardware based firewalls, there are three different verdicts in iptables to levy against traffic – accept, drop and reject. So, IPs that were triggering multiple rules against the IDS/IPS engine, we could then restrict all traffic from that IP address making use of iptables if determined acceptable to block that traffic.

Familiarity with iptables is also something I use as a reference point when I come across candidates who have ‘firewall’ on their resumes. I find that it leaves us able to discuss principles of how firewalls work, what ideal access lists would look like in various situations, while also entirely avoiding the traps of expecting near-exact syntax, particularly when the potential candidate might have experience with one popular vendor but the company uses a different one. This includes iptables syntax because I have found that unless you’re looking for a firewall administrator for specific systems, it’s more important to get a candidate that understands how firewalling works and what the difference between available verdicts (accept, drop, reject) is ideal.

iptables appears that it may be on its way out; substituted for nftables in future Linux kernel releases. nftables cites its goal as being a replacement for not only iptables but ip6tables, arptables and ebtables features. I’ve personally not done much with it; however, I’ve installed it on one of my systems and am going to start playing around with it soon.

syslog

syslog is the operation within Linux that takes system messages and writes them to a specific log file, usually defined as /var/log/messages or /var/log/syslog. The draw back to this is that only running syslog and having logs written to the local machine only introduces a potential single point of failure (SPOF) that can really muck up an incident response (IR) investigation. Fortunately, with a bit of modification to syslog.conf, you can mitigate this risk by having syslogd write logs to localhost and then copy them to a remote log server, in addition to expanding the defined types of events that are written to the logs.

syslog.conf is key to the kingdom when it comes to crafting a syslog file that is useful not just for systems administration teams but also preparing for potential incidents when they arise. The first determination to make is the level at which you want to alert on certain events. Using similar levels as described here, anything considered ‘Warning’ and above should be written to the syslog files to best monitor and maintain system stability and be able to search for anomalies due to an intrusion, privilege escalation or other incidents (potential or actual). After setting the level of messaging, the next item to make sure that is included in the configuration file is to have the logs written to a remote syslog server, including the localhost name as a source for easy parsing, as well as to localhost. Additionally, it’s important to include a section regarding log rotation – either by size, age or some other component to have older logs archived, zipped, and a new log created in order to maximize the space available on disk in the log server. Finally, the remote syslog server ideally exist within a different zone, such as a DMZ, with routing restricted to just syslog and associated traffic approved via firewall or other access controls. Once syslog is running, you can incorporate and tweak other local logs, like iptables, and have them write to syslog as well, giving you another resource for writing those logs to remote servers and increasing the reliability for being able to perform incident response tasks. There is an extended syslog package called syslog-ng that provides additional logging options to enhance your syslog experience.

Unlike tcpdump or iptables, there isn’t much more to syslog, other than getting it up, running and reporting. It’s use is almost betrayed by its simplicity. In larger environments, other packages might be utilized for more distributed reporting and lessen overhead of additional files for mandatory inclusion in provisioning whether does manually or by an automation system like puppet or chef. I’d posit that a base syslog config that enhances reporting and assures better reliability is worth having that config included with the provisioning.

There we have it – 3 tools that can be used for network and systems security that are native to the Linux kernel and can be used in the enterprise regardless of the distribution deployed to production.