Unfortunately, keeping up with system security can be tedious. Administrators must stay aware of updates to software as well as the latest system compromise techniques. Due to this difficult task, system security is often not maintained and is lacking in many areas. This is illustrated by the increased number of reports that entail system compromise. This dilemma changed for me when I discovered the freeware tools offered by Psionic Software, Inc. called PortSentry and Logcheck. Within minutes, these tools can be installed and configured to improve system security dramatically.
Once a host is targeted by an attacker, a port scan is almost always performed. The port scan is done to expose all services available on the target host and to provide a starting point for break-in attempts. PortSentry detects such scans by monitoring the unused ports on the host. Upon a connection attempt to one of the unused ports, PortSentry is alerted and has the ability to issue a number of commands in response to the scan. The commands issued are configured by the administrator within a configuration file. Although any command may be used, the most helpful is one in which the IP address of the attacker's host is essentially “black holed” by issuing a routing command that denies all traffic from that address. The violation and corresponding action taken by PortSentry are recorded in the system log. Using another Psionic utility, Logcheck, these security alerts are e-mailed to an administrator at designated intervals. Thus, the host is now capable not only of retaliating against a potential break-in attempt automatically, but also of notifying the administrator of the occurrence.
Installation and configuration of these freeware utilities is simple and straightforward. They compile on most operating systems, including Linux, Solaris and FreeBSD. The system used for the following install is an x86-based web server using Red Hat Linux 7.0. The tools can be downloaded from Psionic's web site (www.psionic.com/tools/).
The latest version of the tarballs as of this writing are Logcheck 1.1.1 and PortSentry 1.0. First, we will install and configure PortSentry. Untar the archive and enter the PortSentry-version directory. Read the README.install file for all configuration options available, if desired. Type make <<I>systype> (where systype is one of: linux, bsd, solaris, hpux, hpux-gcc, freebsd, openbsd, netbsd, bsdi, aix, osf or generic). Then use make install (installation directory can be changed by editing the Makefile).
Next, we will install Logcheck. First, untar the archive and enter the Logcheck-version directory. Then read the INSTALL file for all configuration options available, if desired. Type make <<I>systype> (where systype is one of: linux, bsdos, freebsd, sun, generic, hpux or digital). Lastly, type make install (installation directory can be changed by editing the Makefile).
We will now edit /usr/local/psionic/portsentry/portsentry.conf file to enable route drop. Find and uncomment the KILL_ROUTE option that corresponds to your operating system. For our example, we will use the ipchains utility found in the Linux kernel version 2.102+:
KILL_ROUTE="/sbin/ipchains -I input -s $TARGET$ -j DENY -l
This will drop all packets originating from an attacker's IP address and log future connection attempts. Individual ports must now be specified for monitoring within the configuration file. Commonly used ports are already given and can simply be uncommented, depending upon how secure the system needs to be:
TCP_PORTS="1,11,15,79,111,119,143,540,635,1080,1524,2000,5742,6667, 12345,12346,20034,31337,32771,32772,32773,32774,40421,49724, 54320"UDP_PORTS="1,7,9,69,161,162,513,635,640,641,700,32770,32771, 32772,32773,32774,31337,54321"
On our example Linux system, however, we will be using PortSentry's advanced stealth scan detection mode, which will automatically monitor ports not being used below 1024 by default. This value can also be altered, but alteration is not recommended. When using this advanced mode, ports can also be manually excluded:
# Default TCP ident and NetBIOS serviceADVANCED_EXCLUDE_TCP="113,139"# Default UDP route (RIP), NetBIOS, bootp broadcasts.ADVANCED_EXCLUDE_UDP="520,138,137,67"
Once all services for our host have been started, PortSentry can now be enabled. First, we start up the TCP port monitor (leaving out the -atcp switch for non-Linux systems):
Tailing our system log will give the following output:
Dec 1 14:23:20 hostname portsentry:adminalert: Advanced Stealth scan detection modeactivated. Ignored TCP port: 80Dec 4 14:23:20 hostname portsentry:adminalert: PortSentry is now active and listening.
A list of ignored TCP ports will be displayed, followed by confirmation of PortSentry's activation. Then, if desired, we start up the UDP port monitor (again, leaving out the -audp switch for non-Linux systems):
Tailing our system log once more will give the following output:
Dec 1 14:23:20 hostname portsentry:adminalert: Advanced Stealth scan detection modeactivated. Ignored UDP port: 137Dec 4 14:23:20 hostname portsentry:adminalert: PortSentry is now active and listening.
A list of ignored UDP ports will be displayed, followed by confirmation of PortSentry's activation. The command(s) can be placed within a startup script but should always be initialized after all other services are active. In this example we will include the above command line into /etc/rc.d/rc.local. All actions taken by PortSentry will be recorded in the system log.
With PortSentry now running, we will configure Logcheck to e-mail an administrator of any suspicious network activity experienced by the host. Edit /usr/local/etc/logcheck.sh to include the e-mail address of the administrator:
Finally, place the Logcheck command into a cron script to parse the system log at an interval best suited for your operations. We will set our interval for this example at one hour. Open the crontab for editing by typing crontab -e, and place the following line into the crontab:
0 * * * * /usr/local/etc/logcheck.sh > > /dev/null
The host is now configured to detect and react to intrusion attempts and to notify the administrator of such attempts, all fully automated (see Listing 1).
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server