I always tolerated the barrage of failed login attempts to port 22 from SSH on my Linux desktop at home...until recently. I leave a back door open for myself to access my desktop, where I have more storage than my laptop can provide. Even with password authentication turned off and SSH keys generated, I receive hundreds of login attempts each day to that specific port. If you look in /var/log/secure (the default path of Redhat releases), you will likely see the same results on your own systems.
There are many ways to block these attempts, and author Barry Kline touched upon a few methods in a recent issue of "The Linux Letter." By using those techniques and the efficient DenyHosts project, you too can rest assured that your chances of being hacked via SSH are slim to none.
What Is DenyHosts?
DenyHosts is an open-source project dedicated to helping you block dictionary attacks on your SSH servers. The tool examines invalid login attempts in /var/log/secure with the configuration options you provide and then automatically appends the offending IP addresses to your /etc/hosts.deny file. DenyHosts can be configured to run as a cron job or a daemon. The only requirements are that you have SSH installed with tcp_wrappers (usually the default) and that you have Python-2.3 or greater installed. Detailed requirements and statistics are located on the project's home page.
Getting Started
I'll be using RHEL 4 as the example system with platform-independent RPMs. However, configuration shouldn't drift too far with other system architectures handling RPM packages. Source RPMs as well as zipped files are available if you prefer to build your own. After you've obtained the package you need and installed the RPM, all configuration files will be located in /usr/share/denyhosts/. Enter this from the command line:
[
You're now ready to begin editing the configuration file with your favorite command line editor, such as Vim.
Configuration
Configuration is simple, and the default configuration file is well-documented. Ensure that the SECURE_LOG entry contains the path specific to your OS.
Now, choose the file in which to store the offending IP addresses. If you prefer to use a custom file, see the tutorial in the FAQ section of the Web site.
If configured with the purge option, DenyHosts will purge the entries at a time length you specify. The default is to leave it blank, which means the entries will never be purged.
The service name that you want to be blocked in HOSTS_DENY will obviously be SSH.
The next four options available in the configuration file are up to your personal preference. You may specify the number of times an attempt can be made on invalid user login attempts, valid user login attempts, root login attempts, and user names that are placed in the restricted user name file. The defaults are as follows:
DENY_THRESHHOLD_VALID = 10
DENY_THRESHOLD_ROOT = 1
DENY_THRESHOLD_RESTRICTED = 1
The working directory is simply the path to where you would like DenyHosts to store its data files. The default selection is fine, unless you prefer the files to be stored elsewhere.
You may specify whether or not you want DenyHosts to report suspicious activity. An example of a suspicious login attempt would be if someone attempted to connect from a valid host but failed because of improper credentials.
If host name lookups are turned on, reports that are generated will include not only the offending IP address, but also the host name DNS provides.
To ensure only one instance of DenyHosts is running on your system, supply the path specific to your OS where the lock files are kept.
I won't go into detail about the next section of configuration options because these optional settings are not necessary for a working version of the utility. But I'll briefly explain the first two settings because they're useful for reporting purposes.
If you want to receive email updates for new IP addresses added to the system, fill in the proper email account and SMTP settings according to your network. These settings are located under the ADMIN_EMAIL section. Also, if you are afraid you might get locked out of your own account, ensure the reset feature is turned on. This resets the failed count of a successful login to 0.
Configuring the Daemon
The next section of the configuration file is specific to running the service as a daemon. First, ensure there is a proper path to the log files; then, choose your time and message formatting and also the amount of time you would like DenyHosts to poll /var/log/secure for possible connection attempts.
Once you are through editing the configuration file, be sure to save it. Then, you can finish setting up the daemon. Open up the daemon-control-dist script file for editing and ensure the following three settings are valid for the system you are working on:
DENYHOSTS_LOCK = “/var/lock/subsys/denyhosts”
DENYHOSTS_CFG = “/usr/share/denyhosts/denyhosts.cfg”
The script can now be copied to a name of your choosing, changed to be executable, and placed in the path of where your system can start the process at boot time.
[
[
[
[
You can attempt to log in to your system with incorrect credentials and watch the log files live. After the amount of attempts specified, your IP address will automatically be added to the /etc/hosts.deny file and will be blocked. Most importantly, now /var/log/secure won't be filled up with invalid attempts. Just ensure you already have an SSH session logged in if you are doing this remotely, or attempt your connections from another host.
Staying Secure
As mentioned, this is only one of several ways to handle incoming SSH hack attempts on your machines. If you're concerned about such attempts, applying this utility along with other methods, such as changing port numbers and using iptables, will keep those nasty dictionary attacks to a minimum.
References
Unix Review: Tool of the Month
Max Hetrick is a PC Support Analyst/Specialist who holds a certification as a MCSA. He also has experience with installation and maintenance of Linux operating systems from the PC to server levels. Max can be reached at
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online