xrayspx fails to explain his statement of why a consumer should not use NMAP to do a quick security assessment of a site he is considering trusting with his credit card data. He also puts quite a few words in my mouth.
I said nowhere in my article that "IIS admins all suck" nor any comments on their ability. However, with minor hardening and good practices, a Linux web server mostly is at risk for compromise due only to a vulnerability discovered every year or more. From reports I've seen, an IIS server is at risk from a new remote compromise almost weekly. This represents a ratio of roughly 52 to 1 in risk.
I made no claims about the Operations staff at eBay, Barnes&Noble, etc. It does appear, however, that B&N uses special content-based filtering in front of their IIS server. The NMAP scan will show such special filtering by its inability to determine the operating system. No doubt they also have people on the ready 24x7 to instantly apply new patches.
I also never said "Buy Linux servers, they're going to be 'secure". I do believe "Start with Linux, then harden it as per 'Real World Linux Security, Second Edition', subscribe to bug tracking lists, patch quickly, and you will be much more secure, spend far less effort, and spend less money than dealing with Microsoft". UNIX, Macs, and other platforms also have a good history of security if hardened.
I also have hired several "in print" Linux mags,
a UNIX org and Slashdot to provide publicity.
Seriously, I have no business, financial, or other connection to Help Net Security. They had the idea for the book giveaway and contacted Prentice Hall, my publisher, to request the copies. If you write a book they consider worthy, I'm sure that they will talk about it and invite you to write articles. Zorz is not a pseudonym for Toxen. My only web sites are
My reference was SuSE 8.0, which was the most recent this summer when my book was written. Even something as simple as restarting IP Tables rules is done wrong in SuSE.
SuSE first flushes existing rules and then adds new rules. Thus, for a short time there are no rules but the default for each chain is ACCEPT. They are saved only because networking has not yet been turned on. I suspect that this is more of an accident than intent because the correct solution is to first set the defaults to DROP, then add rules, then change the defaults to ACCEPT if that is your desire.
A honeypot is not the best way to test the security of a prototype installation either.
The time spent with the honeypot would be better spent selecting a secure platform to develop on, designing rules for writing secure code, and doing code audits and security audits, etc.
If the honeypot is not breached is the system secure? Of course not. You have learned nothing. If you instead did that code audit and security audit then you would have more confidence that it was secure than when you started.
I stand by my claim that for most people, the time spent on a honeypot does not have technical value.
Almost every issue discussed in the book can affect the newest Linux versions. Most of the problems of BSD that I discuss are in the category of "Those who fail to learn from history are doomed to repeat it".
Most of my original code on the CD was written for the book. While some of it, such as my substantially enhanced versions of Logcheck and Arpwatch were written for clients, these are of general interest and I have sent my enhancements back to the authors for including in their next versions if they desire. The use of each of my programs is discussed in detail in the book. Logcheck and Arpwatch each get about 5 pages under the obscure titles of "Using Logcheck to Check Log Files You Never Check" and "Using Arpwatch..."
RWLS 2/e covers many aspects of IP Tables that Ziegler's book does not. This includes how to safely debug a firewall remotely (Zieger says not to bother), a detailed comparison of Tables to Chains for those considering switching, and tips and techniques for working with IP Tables or Chains.
RWLS's CD contains a complete IP Tables-based firewall rules script that does not need configuration, not even specifying one's external IP address because it figures it out automatically. Ziegler does not provide a CD.
This sounds like the same guy that posted a recommendation on Amazon's RWLS 2/e web page, preferring HLE to it. His recommendation (and thus his evaluation of RWLS 2/e) was posted before RWLS 2/e started shipping and thus he could not have read it before evaluating it.
Regarding "ages old" stories in RWLS 2/e, my discussion of Microsoft's Korean version of.Net having shipped with Nimda was based on a June 2002 report. I then explain nine lessons that can be learned to avoid repeating Microsoft's mistake. For those who actually have read the book, this case study begins on page 387.
That claim, originated by the Aberdeen Group,
simply is incorrect. They noted that there were more vulnerabilities posted for Linux than for Windows and drew the conclusion that Linux was less secure than Windows. I've read followups that also said that if a vulnerability occurred in 3 Linux distributions that Aberdeen counted it as 3 vulnerabilities.
However, Aberdeen's analysis is flawed because it failed to weight each according to its severity (whether it offers a remote root or remote non-root vulnerability, what percentage of the installed base is vulnerable, etc.)
The reality is that many Windows vulnerabilities are the equivalent of a Linux "remote root" vulnerability and affect either every Windows system running IE or every Windows system that runs IIS. Most Linux vulnerabilities are not remotely exploitable and most of those that are affect only a small percentage of systems.
Using a valid analysis, a Linux system deployed for the same purpose as a Windows system (e.g., as a desktop system, web server, file server, mail server, or whatever) is far less likely to be violated, in my opinion.
I called it Real World Linux Security
because my intent was to provide practical
solutions, based on my experience running critical
production systems.
Thus, I give advice on how to recover a compromised system quickly. Other books say "re-install from scratch" or "recover from backup". If one has production data on it, these suggestions from (from other Linux security books) would cause loss of that data. My techniques will
save the data.
One Linux security book says not to remotely manage Linux firewalls because of the risk of locking oneself out or briefly opening up insecure access. I explain how to remotely manage Linux firewalls without the risk of locking oneself out or having even a nanosecond of insecurity. My techniques have worked well for my managing clients' firewalls around the world for three years.
I start with quick fixes for common problems that everyone can benefit from, especially those new to Linux security. Then I get into increased security in different areas, such as desktop systems, mail servers, web servers, etc.
Regarding my Linux qualifications, I have
about 8 years of Linux, I've been working in
Linux almost exclusively for the past 6 years.
I post on the Atlanta Linux Enthusiasts group (www.ale.org) list a lot, have given four talks
to this group and others and help found ALE group.
There are a number of easy hacks to the Linux
kernel to increase security:
1. Add a sys call to disable insmod to prevent
crackers from inserting Trojans and Root Kit
obscuring modules.
2. Disable processes from listening on high
ports (above 1023, except possibly socks, NFS, or X if you're crazy to allow these on a server).
It would be trivial to add this to the kernel.
3. Disable other than low numbered processes from
listening on ports, if all of your servers start
at boot time and don't need restarting.
4. Prevent creation of symlinks in dirs (such as/tmp) with the sticky bit on unless they point
to files owned by the creator. This reduces
popular symlink attacks. It might be possible to
block all symlinks here with most servers' mix
of processes.
5. Disable fchdir() and mknod() to prevent root's
common way to break out of a chroot() jail.
(Disabling/proc,/dev/mem and/dev/kmem, etc.
also will be needed but those aren't kernel mods.)
Keeping up-to-date w.r.t. security patches, running different servers on different systems to limit damage from an intrusion,
using a good Adaptive Firewall and IDS, etc.
will go a long way to conventional security as
will using the LIDS, WireX's SubDomain, or
NSA-enhanced kernels.
Those worrying about a NSA-planted bug in their
kernel need only put a non-NSA Linux based
Firewall in front to detect unexpected packets.
Slashdot Mirror
I said nowhere in my article that "IIS admins all suck" nor any comments on their ability. However, with minor hardening and good practices, a Linux web server mostly is at risk for compromise due only to a vulnerability discovered every year or more. From reports I've seen, an IIS server is at risk from a new remote compromise almost weekly. This represents a ratio of roughly 52 to 1 in risk.
I made no claims about the Operations staff at eBay, Barnes&Noble, etc. It does appear, however, that B&N uses special content-based filtering in front of their IIS server. The NMAP scan will show such special filtering by its inability to determine the operating system. No doubt they also have people on the ready 24x7 to instantly apply new patches.
I also never said "Buy Linux servers, they're going to be 'secure". I do believe "Start with Linux, then harden it as per 'Real World Linux Security, Second Edition', subscribe to bug tracking lists, patch quickly, and you will be much more secure, spend far less effort, and spend less money than dealing with Microsoft". UNIX, Macs, and other platforms also have a good history of security if hardened.
Seriously, I have no business, financial, or other connection to Help Net Security. They had the idea for the book giveaway and contacted Prentice Hall, my publisher, to request the copies. If you write a book they consider worthy, I'm sure that they will talk about it and invite you to write articles. Zorz is not a pseudonym for Toxen. My only web sites are
http://www.realworldlinuxsecurity.com
and
http://www.verysecurelinux.com
SuSE first flushes existing rules and then adds new rules. Thus, for a short time there are no rules but the default for each chain is ACCEPT. They are saved only because networking has not yet been turned on. I suspect that this is more of an accident than intent because the correct solution is to first set the defaults to DROP, then add rules, then change the defaults to ACCEPT if that is your desire.
There are other weaknesses in the current SuSE.
If the honeypot is not breached is the system secure? Of course not. You have learned nothing. If you instead did that code audit and security audit then you would have more confidence that it was secure than when you started.
I stand by my claim that for most people, the time spent on a honeypot does not have technical value.
Almost every issue discussed in the book can affect the newest Linux versions. Most of the problems of BSD that I discuss are in the category of "Those who fail to learn from history are doomed to repeat it".
Most of my original code on the CD was written for the book. While some of it, such as my substantially enhanced versions of Logcheck and Arpwatch were written for clients, these are of general interest and I have sent my enhancements back to the authors for including in their next versions if they desire. The use of each of my programs is discussed in detail in the book. Logcheck and Arpwatch each get about 5 pages under the obscure titles of "Using Logcheck to Check Log Files You Never Check" and "Using Arpwatch..."
RWLS 2/e covers many aspects of IP Tables that Ziegler's book does not. This includes how to safely debug a firewall remotely (Zieger says not to bother), a detailed comparison of Tables to Chains for those considering switching, and tips and techniques for working with IP Tables or Chains.
RWLS's CD contains a complete IP Tables-based firewall rules script that does not need configuration, not even specifying one's external IP address because it figures it out automatically. Ziegler does not provide a CD.
Regarding "ages old" stories in RWLS 2/e, my discussion of Microsoft's Korean version of .Net having shipped with Nimda was based on a June 2002 report. I then explain nine lessons that can be learned to avoid repeating Microsoft's mistake. For those who actually have read the book, this case study begins on page 387.
However, Aberdeen's analysis is flawed because it failed to weight each according to its severity (whether it offers a remote root or remote non-root vulnerability, what percentage of the installed base is vulnerable, etc.)
The reality is that many Windows vulnerabilities are the equivalent of a Linux "remote root" vulnerability and affect either every Windows system running IE or every Windows system that runs IIS. Most Linux vulnerabilities are not remotely exploitable and most of those that are affect only a small percentage of systems.
Using a valid analysis, a Linux system deployed for the same purpose as a Windows system (e.g., as a desktop system, web server, file server, mail server, or whatever) is far less likely to be violated, in my opinion.
Thus, I give advice on how to recover a compromised system quickly. Other books say "re-install from scratch" or "recover from backup". If one has production data on it, these suggestions from (from other Linux security books) would cause loss of that data. My techniques will save the data.
One Linux security book says not to remotely manage Linux firewalls because of the risk of locking oneself out or briefly opening up insecure access. I explain how to remotely manage Linux firewalls without the risk of locking oneself out or having even a nanosecond of insecurity. My techniques have worked well for my managing clients' firewalls around the world for three years.
I start with quick fixes for common problems that everyone can benefit from, especially those new to Linux security. Then I get into increased security in different areas, such as desktop systems, mail servers, web servers, etc.
Eric Raymond wrote the Foreword.
1. Add a sys call to disable insmod to prevent crackers from inserting Trojans and Root Kit obscuring modules.
2. Disable processes from listening on high ports (above 1023, except possibly socks, NFS, or X if you're crazy to allow these on a server). It would be trivial to add this to the kernel.
3. Disable other than low numbered processes from listening on ports, if all of your servers start at boot time and don't need restarting.
4. Prevent creation of symlinks in dirs (such as /tmp) with the sticky bit on unless they point
to files owned by the creator. This reduces
popular symlink attacks. It might be possible to
block all symlinks here with most servers' mix
of processes.
5. Disable fchdir() and mknod() to prevent root's common way to break out of a chroot() jail. (Disabling /proc, /dev/mem and /dev/kmem, etc.
also will be needed but those aren't kernel mods.)
Keeping up-to-date w.r.t. security patches, running different servers on different systems to limit damage from an intrusion, using a good Adaptive Firewall and IDS, etc. will go a long way to conventional security as will using the LIDS, WireX's SubDomain, or NSA-enhanced kernels.
Those worrying about a NSA-planted bug in their kernel need only put a non-NSA Linux based Firewall in front to detect unexpected packets.
These and other ideas are from my book.