Linux Security Cookbook
Daniel J. Barrett, Richard E. Silverman, Robert G. Byrnes
Format: PDF / Kindle (mobi) / ePub
Computer security is an ongoing process, a relentless contest between system administrators and intruders. A good administrator needs to stay one step ahead of any adversaries, which often involves a continuing process of education. If you're grounded in the basics of security, however, you won't necessarily want a complete treatise on the subject each time you pick up a book. Sometimes you want to get straight to the point. That's exactly what the new Linux Security Cookbook does. Rather than provide a total security solution for Linux computers, the authors present a series of easy-to-follow recipes—short, focused pieces of code that administrators can use to improve security and perform common tasks securely.
The Linux Security Cookbook includes real solutions to a wide range of targeted problems, such as sending encrypted email within Emacs, restricting access to network services at particular times of day, firewalling a webserver, preventing IP spoofing, setting up key-based SSH authentication, and much more. With over 150 ready-to-use scripts and configuration files, this unique book helps administrators secure their systems without having to look up specific syntax. The book begins with recipes devised to establish a secure system, then moves on to secure day-to-day practices, and concludes with techniques to help your system stay secure.
Some of the "recipes" you'll find in this book are:
• Controlling access to your system from firewalls down to individual services, using iptables, ipchains, xinetd, inetd, and more
• Monitoring your network with tcpdump, dsniff, netstat, and other tools
• Protecting network connections with Secure Shell (SSH) and stunnel
• Safeguarding email sessions with Secure Sockets Layer (SSL)
• Encrypting files and email messages with GnuPG
• Probing your own security with password crackers, nmap, and handy scripts
This cookbook's proven techniques are derived from hard-won experience. Whether you're responsible for security on a home Linux system or for a large corporation, or somewhere in between, you'll find valuable, to-the-point, practical recipes for dealing with everyday security issues. This book is a system saver.
iptables iptables iptables iptables -A -A -A -A INPUT INPUT INPUT INPUT -s IP_address_1 [-p protocol --dport service] -j ACCEPT -s IP_address_2 [-p protocol --dport service] -j ACCEPT -s IP_address_3 [-p protocol --dport service] -j ACCEPT [-p protocol --dport service] -j REJECT -A -A -A -A input input input input -s IP_address_1 [-p protocol --dport service] -j ACCEPT -s IP_address_2 [-p protocol --dport service] -j ACCEPT -s IP_address_3 [-p protocol --dport service] -j ACCEPT [-p
an intruder discovers this fact, and mackie is down, the intruder could spoof mackie’s MAC address and your firewall would be none the wiser. On the other hand, if mackie is up during the spoofing, its kernel will start screaming (via syslog) about duplicate MAC addresses. Note that our recipe permits local connections from your own host; these arrive via the loopback interface. See Also iptables(8), ipchains(8). 2.12 Permitting SSH Access Only Problem You want to permit incoming SSH access but
high-level script that operates on all network interfaces, not just one. It runs ifup or ifdown for each interface as needed, and also handles other details: adding routes, creating a lock file to indicate that networking is enabled, and much more. It even toggles the loopback interface, which might be more than you intended, if you just want to block outside traffic. The scripts ifup, ifdown, and network are pretty short and well worth reading. See Also ifconfig(8). usernetctl(8) describes how
1234 and in another, connect with the client to the test server: myclient$ ssh -v1p 1234 myserver See if any enlightening diagnostic messages pop up on either side—you can increase the verbosity of the logging by repeating the -d and -v switches up to three times. If sshd reports “incorrect net address,” try adding ListenAddress statements to /etc/ssh/ sshd_config, explicitly listing the addresses on which you want the SSH server to listen; this can work around a bug in the handling of
Suppose your system is infiltrated by the infamous Jack the Cracker. Being a conscientious evildoer, he quickly modifies some system files to create back doors and cover his tracks. For instance, he might substitute a hacked version of /bin/login to admit him without a password, and a bogus /bin/ls could skip over and hide traces of his evil deeds. If these changes go unnoticed, your system could remain secretly compromised for a long time. How can this situation be avoided? Break-ins of this