Single Packet Authorization
Single Packet Authorization provides similar security benefits to port knocking in terms of protecting services with a packet filter that is configured in a default-drop stance. Anyone scanning for a target service that is protected in this way will be unable to detect such a service is listening, and this makes even the exploitation of zero-day vulnerabilities much more difficult. SPA offers elegant solutions to many limitations in port knocking implementations. These allow SPA to solve the replay problem, achieve a data transmission rate that makes the use of asymmetric encryption possible, thwart simple spoofing attacks and remain under the radar of intrusion detection systems that are monitoring networks for port scans.
See next month's LJ for Part II to this article, which will show exactly how to use SPA.
Krzywinski, M. 2003. “Port Knocking: Network Authentication Across Closed Ports”. SysAdmin Magazine 12: 12–17.
ElGamal Encryption: en.wikipedia.org/wiki/ElGamal_encryption
There is only one other SPA implementation that I am aware of at the time of this writing, available at www.unspecific.com/spa.
Another implementation called Tumbler (tumbler.sourceforge.net) employs a single packet, but it uses a hashed payload instead of an encrypted payload, and this results in a significantly different architecture.
fwknop documentation and man pages: www.cipherdyne.org/fwknop/docs
Michael Rash holds a Masters' Degree in applied mathematics with a concentration in computer security from the University of Maryland. Michael is the founder of cipherdyne.org, a Web site dedicated to open-source security software for Linux systems, and he works as Security Architect on the Dragon Intrusion Detection System for Enterasys Networks. He is the author of the upcoming book Linux Firewalls: Attack Detection and Response, published by No Starch Press.
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
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- 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