Manual ID: rhl-sg(EN)-8.0-HTML-RHI (2002-08-30T11:29-0400) 3. Security Updates/Using the Errata Website: Reccomending /tmp/updates for security updates isn't that great, because /tmp is regularly pruned by tmpwatch (and might delete the rpms, possibly before they are installed). For a permament storage it's a no-go. 5. Server Security/Securing NIS: Section title "Assign Static Ports and Use" (rest missing) 5. Server Security/Securing Apache HTTP Server/Restrict Permissions for Executable Directories chown <directory_name> should be chown root <directory_name> 5. Server Security/Securing FTP/Anonymous Upload: 733 is rwx-wx-wx (correct), the example below is rwxr--r-- (which is 744 and doesn't allow uploads at all) 5. Server Security/Securing Sendmail/Limiting Denial of Service Attack confMIN_FREE_BLOCKS: blacks instead of blocks 5. Server Security/Securing Sendmail/Mail-only Users shell /sbin/nologin is more explicit and obvious than /bin/false, and gives a reasonable error message on login attempts 7. Firewalls/Netfilter iptables Most examples are bogus, INPUT/OUTPUT is not local net/outside world, but to/from this particular computer, packets local net<->outside world go only through FORWARD (iptables is not ipchains) --sport is SOURCE-port, so the examples allow connections FROM port xxx, not TO port xxx Setting ip_forward belongs in /etc/sysctl.conf Maybe it should be emphasized that order of rules is important, just reading the chapter and adding rules in that order would be bad (DROP after ACCEPT) 10. Intrusion Detection/Host-based IDS/RPM as an IDS rpm -Fv /bin/ls check whole package containing /bin/ls, not only /bin/ls Overall, the guide is a bit unbalanced. Chapter 5 is simply great, the rest of Section II is good too (except for the iptables examples), but the rest seems to be targeted at a different audience (managers?).
Thanks for pointing all of this out! I will review these issues and issue the appropriate Errata ASAP. Johnray
I have corrected: 5> Server Security/Securing NIS 5> Server Security/Securing Apache HTTP Server/Restrict Permissions for Executable Directories 5> Server Security/Securing FTP/Anonymous Upload 5> Server Security/Securing Sendmail/Mail-only Users shell /sbin/nologin -> I ignored my own advise from the earlier chapter when I said /bin false... :-( I did not correct: 5> Server Security/Securing Sendmail/Limiting Denial of Service Attack confMIN_FREE_BLOCKS: blacks instead of blocks I can find no evidence to support the use of the term "blacks" here. From all that I have been able to dig up, this directive relates to blocks left on the spool drive, not black lists. Please let me know if I am missing something. The Issues in chapters 7 and 10 will be addressed by John. I will look into the issue for Chapter 3 and tell you the results here. Thank you for all your help! Johnray
I have reviewed the firewall chapter with our technical lead, and we agree that the examples in this chapter are valid for machines which act as a firewall/gateway between the Internet and a local network. INPUT and OUTPUT chains in IPTables are for restricting or allowing connections inside and outside the LAN. FORWARD jumps are used, for example, when administrators want to send all incoming port 80 requests to one machine within the LAN that could be running httpd on port 8080. Your observation about running rpm -Vf on individual files is valid and should have been written more clearly. Thank you for your suggestion.
For the observations you make regarding recommending /tmp/updates in Chapter 3 Security Updates, I do not see the problem with creating a directory in /tmp/ because you should not need the security updates once you have installed them. The fact that tmpwatch gets rid of the updates to save disk space if you forget to delete them is, in my view, an advantage. If there is something I am missing, let me know here. I do appreciate you taking the time to send in this detailed bug. It whas helped tremendously. Johnray
I have posted errata and corrected the source in regards to these errors. Feel free to post to this bug about any of the issues raised here. Thanks again for your help. Johnray
Hello, at least in one case I have been misunderstood: 5. Server Security/Securing Sendmail/Limiting Denial of Service Attack confMIN_FREE_BLOCKS: — The minimum number of free blacks which must be ... ^^^^^^ As for the firewall chapter, the trouble is that packets from *both* the LAN and the "outside" go through INPUT, but *only* if directed at the computer in question. Packets to *both* the LAN and the "outside" to through OUTPUT. (It is quite logical, the kernel can't guess which is LAN and which is "outside), but *only* if originated at the computer in question. Packets which are forwarded between interfaces go *only* through FORWARD. Yet the chapter contains things like: The OUTPUT chain specifies any packets that originate from inside a LAN and travels outside (for example, to a remote website) The LAN (which uses a private class C 192.168.1.0/24 IP range) rejects telnet access from the outside iptables -A INPUT -p tcp --sport telnet -j REJECT (this means: Reject all packets to this computer (regardless of origin), which are *from* port telnet. In effect, this disables connections *from* the computer in question to any telnet service (because the "answers" will be rejected.) The whole chapter seems to be based on these wrong assumptions.
Although it may appear like I was trying to make a political statement through the sendmail security section, it was actually a typo :-/ I have fixed it now, however. Thanks for clarifying that for me. Johnray
Chapter 7 is basically unchanged in 8.0.93 doc set. See the Reference guide explanation of INPUT/OUTPUT/FORWARD in filter table, of just (man iptables).
Hello Miloslav, You are correct. That chapter as well as the Server chapter have not yet changed for the new release. They are due to be finished soon, but I do not think they will make it into a beta release. Johnray
The firewall chapter has been revamped with some clarification/explanation of chain rules and implementation. Some rulesets have been changed based on this bug report and further analysis. The revamped chapter will appear in the upcoming version of the Security Guide. Thank you for your detailed report and further comments on this chapter. It appears that this covers all points for this bug report. Thank you again for your detailed analysis and response.