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).
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- RSS Feeds
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- Dynamic DNS—an Object Lesson in Problem Solving
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"
- Tech Tip: Really Simple HTTP Server with Python
- Roll your own dynamic dns
3 hours 50 min ago
- Please correct the URL for Salt Stack's web site
7 hours 2 min ago
- Android is Linux -- why no better inter-operation
9 hours 17 min ago
- Connecting Android device to desktop Linux via USB
9 hours 45 min ago
- Find new cell phone and tablet pc
10 hours 43 min ago
12 hours 12 min ago
- Automatically updating Guest Additions
13 hours 21 min ago
- I like your topic on android
14 hours 7 min ago
- This is the easiest tutorial
20 hours 43 min ago
- Ahh, the Koolaid.
1 day 2 hours ago
Free Webinar: Hadoop
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?