Hi all.
I added some of the suggestions Paul gave me. I'm still working on some of the password stuff, and I would like to put screenshots in some places, but since I'm new to this whole way of documenting things, I'll have to do a little research on that one.
Anyway, please check out the updates. I've updated the HTML version at http://members.cox.net/tuxxer as well as the XML, which can be found at the link below.
http://members.cox.net/tuxxer/fedora-hardening-guide-whole-en.xml
Please feel free to make comments, constructive criticism, etc. Depending upon the amount of feedback I get, I'll post a final here, then post that to the bug tracker.
Thanks for all of the help and advice!
Oh, I tried to do a 'make pdf', and it failed. It said there was no target, so maybe I grabbed the wrong Makefile when I got started or something. If anyone can point me in the direction to get this target into my Makefile, I'd like to make this as complete as possible.
Thanks.
On Sat, 08 Jan 2005 12:00:35 -0800, "tuxxer" tuxxer@cox.net said:
Please feel free to make comments, constructive criticism, etc. Depending upon the amount of feedback I get, I'll post a final here, then post that to the bug tracker.
I think that it's a really useful document, so please take these as comments rather than criticism. The points below mainly relate to Red Hat or Linux-specific quirks.
General points)
- FWIW, I handled root commands in the Installation Guide by bracketing them with su -c. My worry with "login as root" is that it is ambiguous and a new user may start logging in to X as root. If you move the sections on disabling root logins and sudo to the top you could also promote the use of sudo for admin commands throughout the rest of the document.
- The wheel group used by sudo can also be used in a broader way - if you put "AllowGroups wheel" in sshd_config as well as "PermitRoot no" you implicitly block remote logins from all accounts other than the users you manually added to the wheel group, which mitigates the risks of compromised service accounts (Section 1.6). This isn't specific to wheel, but it just reduces overhead if you reuse the group rather than create a new one.
These definitely aren't official in any way.
- You might also want to mention the role of the built-in firewall - even enabled services like SSH are effectively closed unless the administrator alters the default firewall settings.
- SMTP has a specific security role as messaging service, so I feel that it shouldn't be disabled. Daily LogWatch log analysis, smartd disk monitoring, SELinux context checkers, crond etc. all send mail to the address that root is aliased to in /etc/aliases (or /etc/postfix/aliases). The default configurations of the SMTP services supplied with FC are to reject connections from other hosts, so they cannot be used as relays unless the administrator changes the config. I find LogWatch is incredibly useful as a early warning system on our public-facing Red Hat servers.
Section 1.1)
You might want to consider the role of Installation Types here - the user can pick an Installation Type and then customise the package groups (which ties in with role selection in 1.2). Anaconda essentially mandates certain packages, so you don't really get the flexibility that you mention. Even using the "Minimal" package group will install sendmail, CUPS, SSH and NFS (and mDNS on FC3, I think).
"If you know that the system you are installing will be used as only a webserver, then there shouldn't be any reason to install sendmail"
See above.
Section 1.4)
The automatic update feature of yum could be mentioned here. The incantation would be:
su -c '/sbin/chkconfig --level 345 yum on; /sbin/service yum start'
Section 1.5.1)
<nitpick>You've listed snortd, which doesn't ship with Fedora Core</nitpick>.
In the GUI you have to untick the boxes on service levels 3, 4 and 5 to really enable/disable a service. Certain key services are also active at runlevel 2 - sendmail and SSH.
Section 1.5.2)
I really like the idea of the serviceslist.txt. If you put an example listing in then users will be able to copy and paste, which should give them more confidence to do it.
Section 1.6)
Strictly IMHO, disabling service accounts is often excessive and causes a maintenance problem. They can't login locally, and you can easily block remote logins (see above).
Section 3)
I like this section (that's all).
Section 4.2)
"Then, either reboot your system, or issue the command pkill -1 sshd. The pkill command will force sshd to re-read it's configuration file. This will force users to login as a normal user account and then su to root, or utilize sudo."
Are you doing this to ensure that active SSH sessions are terminated ? If so, it's probably worth noting. The non-disruptive way to apply a config. change in Red Hat/Fedora is:
su -c '/sbin/service sshd reload' --
Stuart Ellis s.ellis@fastmail.co.uk
On Sun, 2005-01-09 at 14:48 +0000, Stuart Ellis wrote:
On Sat, 08 Jan 2005 12:00:35 -0800, "tuxxer" tuxxer@cox.net said:
Please feel free to make comments, constructive criticism, etc. Depending upon the amount of feedback I get, I'll post a final here, then post that to the bug tracker.
I think that it's a really useful document, so please take these as comments rather than criticism. The points below mainly relate to Red Hat or Linux-specific quirks.
I think that's what we're shooting for since it's meant to be FC specific. ;-) I'll let you know when the "all-encompassing-linux" security book comes out....maybe I'll give you an acknowledgment. ;-)
General points)
- FWIW, I handled root commands in the Installation Guide by bracketing
them with su -c. My worry with "login as root" is that it is ambiguous and a new user may start logging in to X as root. If you move the sections on disabling root logins and sudo to the top you could also promote the use of sudo for admin commands throughout the rest of the document.
- The wheel group used by sudo can also be used in a broader way - if
you put "AllowGroups wheel" in sshd_config as well as "PermitRoot no" you implicitly block remote logins from all accounts other than the users you manually added to the wheel group, which mitigates the risks of compromised service accounts (Section 1.6). This isn't specific to wheel, but it just reduces overhead if you reuse the group rather than create a new one.
These definitely aren't official in any way.
- You might also want to mention the role of the built-in firewall -
even enabled services like SSH are effectively closed unless the administrator alters the default firewall settings.
I use Firestarter, so this I need to do some playing around with this before I can speak intelligently about it.
- SMTP has a specific security role as messaging service, so I feel that
it shouldn't be disabled. Daily LogWatch log analysis, smartd disk monitoring, SELinux context checkers, crond etc. all send mail to the address that root is aliased to in /etc/aliases (or /etc/postfix/aliases). The default configurations of the SMTP services supplied with FC are to reject connections from other hosts, so they cannot be used as relays unless the administrator changes the config. I find LogWatch is incredibly useful as a early warning system on our public-facing Red Hat servers.
Makes sense.
Section 1.1)
You might want to consider the role of Installation Types here - the user can pick an Installation Type and then customise the package groups (which ties in with role selection in 1.2). Anaconda essentially mandates certain packages, so you don't really get the flexibility that you mention. Even using the "Minimal" package group will install sendmail, CUPS, SSH and NFS (and mDNS on FC3, I think).
"If you know that the system you are installing will be used as only a webserver, then there shouldn't be any reason to install sendmail"
See above.
Mentioned. Could probably do more here, so I will look into adding more detail. I think I really need to do some experimentation, but don't have the facilities at the moment.
Section 1.4)
The automatic update feature of yum could be mentioned here. The incantation would be:
su -c '/sbin/chkconfig --level 345 yum on; /sbin/service yum start'
Done.
Section 1.5.1)
<nitpick>You've listed snortd, which doesn't ship with Fedora Core</nitpick>.
I'm running snortd, so it showed up in the list when I ran the command. ;-)
In the GUI you have to untick the boxes on service levels 3, 4 and 5 to really enable/disable a service. Certain key services are also active at runlevel 2 - sendmail and SSH.
Got it.
Section 1.5.2)
I really like the idea of the serviceslist.txt. If you put an example listing in then users will be able to copy and paste, which should give them more confidence to do it.
Done.
Section 1.6)
Strictly IMHO, disabling service accounts is often excessive and causes a maintenance problem. They can't login locally, and you can easily block remote logins (see above).
Rahul mentioned something along these lines. Does anyone know for sure if you remove a certain service that the user for that service is removed as well? I don't remember for sure, but I believe that the user remains.
Section 3)
I like this section (that's all).
Thanks. Nice to get a little kudos in the middle. It's the "spoonful of sugar that makes the medicine go down". ;-)
Section 4.2)
"Then, either reboot your system, or issue the command pkill -1 sshd. The pkill command will force sshd to re-read it's configuration file. This will force users to login as a normal user account and then su to root, or utilize sudo."
Are you doing this to ensure that active SSH sessions are terminated ? If so, it's probably worth noting. The non-disruptive way to apply a config. change in Red Hat/Fedora is:
su -c '/sbin/service sshd reload'
This would be from my Solaris background. As you know, there are 6 different ways to do just about anything, and some of them tend to be more graceful than others. :) However, I think that it might be valuable to kill existing connections (assuming that you have multiple users, which I think I touched on this in the scope and intended audience). If you have someone "unwanted" logged on while you're making changes, booting them might be handy. Admittedly, it's unlikely, however, possible. I think I'll mention both, with a caveat.
--
Stuart Ellis s.ellis@fastmail.co.uk
Stuart,
As usual, your comments are insightful, intelligent, experienced, and greatly appreciated. The "general points" are valid, but may require some "re-engineering" of the doc in its entirety, so I'll save that for another time when I have a little more time to dedicate to it. I've commented where I was able to make "quick changes". And again, your insights are greatly appreciated.
All, the updates made from Stuart's comments have been posted, if you would like to check out the revisions.
Thanks. -Charlie
On Tue, 11 Jan 2005 00:04:34 -0800, "tuxxer" tuxxer@cox.net said:
- You might also want to mention the role of the built-in firewall -
even enabled services like SSH are effectively closed unless the administrator alters the default firewall settings.
I use Firestarter, so this I need to do some playing around with this before I can speak intelligently about it.
It's extremely basic, which is good for simple configurations. I don't know what RH would recommend for routers and more complex setups - I use shorewall. The only quirks with the built-in firewall config that I can think of are a) it automatically allows inbound traffic for mDNS and UDP 631 (CUPS browsing ?), b) The manual install process doesn't expose all of the functionality - trusted interfaces and allowing arbitrary port numbers become post-installation tasks.
You might want to consider the role of Installation Types here - the user can pick an Installation Type and then customise the package groups (which ties in with role selection in 1.2). Anaconda essentially mandates certain packages, so you don't really get the flexibility that you mention. Even using the "Minimal" package group will install sendmail, CUPS, SSH and NFS (and mDNS on FC3, I think).
Mentioned. Could probably do more here, so I will look into adding more detail. I think I really need to do some experimentation, but don't have the facilities at the moment.
FWIW, the relevent sections of the draft Installation Guide are complete. If you can't find relevent information there then feel free to ask. I've installed FC rather a lot already... and have more or less beaten VMWare into submission, so testing configurations is now a bit less onerous too.
Strictly IMHO, disabling service accounts is often excessive and causes a maintenance problem. They can't login locally, and you can easily block remote logins (see above).
Rahul mentioned something along these lines. Does anyone know for sure if you remove a certain service that the user for that service is removed as well? I don't remember for sure, but I believe that the user remains.
I believe so too, but haven't checked. Removal definitely leaves the configuration files behind.
Section 4.2)
"Then, either reboot your system, or issue the command pkill -1 sshd. The pkill command will force sshd to re-read it's configuration file. This will force users to login as a normal user account and then su to root, or utilize sudo."
However, I think that it might be valuable to kill existing connections (assuming that you have multiple users, which I think I touched on this in the scope and intended audience). If you have someone "unwanted" logged on while you're making changes, booting them might be handy. Admittedly, it's unlikely, however, possible. I think I'll mention both, with a caveat.
It might be worth putting something as a general point at the start of the document - warning the reader to try not to allow network connections whilst carrying out lockdown, and advising that config changes will not affect existing connections.
The "general points" are valid, but may require some "re-engineering" of the doc in its entirety, so I'll save that for another time when I have a little more time to dedicate to it. I've commented where I was able to make "quick changes".
OK. I'll bear that in mind when I look at it again. Thanks for being a good sport about us bystanders picking holes in your doc.
--
Stuart Ellis s.ellis@fastmail.co.uk
On Tue, 2005-01-11 at 00:04 -0800, tuxxer wrote:
Section 1.5.1)
<nitpick>You've listed snortd, which doesn't ship with Fedora Core</nitpick>.
I'm running snortd, so it showed up in the list when I ran the command. ;-)
If you're writing official documentation, it's probably a good idea for you to have a "stock" system to do fact-checking. Like you, I have a lot of things on my system that don't come with Fedora Core. I do testing for documentation either in a VMWare guest that has the stock distribution installed, or on a separate box.
Strictly IMHO, disabling service accounts is often excessive and causes a maintenance problem. They can't login locally, and you can easily block remote logins (see above).
Rahul mentioned something along these lines. Does anyone know for sure if you remove a certain service that the user for that service is removed as well? I don't remember for sure, but I believe that the user remains.
It differs from package to package. It also depends on what you mean when you say "remove a certain service." Are you talking about doing "chkconfig --del"? If so, then definitely not. But if you're talking about "rpm -e", then the answer is "sometimes." For instance,
rpm -q --scripts bind rpm -q --scripts nfs-utils
shows that bind nicely removes named when it is uninstalled, and nfs- utils does the same with its associated users. However,
rpm -q --scripts httpd
shows that httpd is not as good at cleaning up after itself. There may be a reason for this. For instance, if a system administrator is running a web server, but has the "userdel" command aliased under the root account to automatically use the "-r" option, and did "rpm -e httpd", then he would run the risk of deleting the entire /var/www, which is user apache's home directory. That's just idle speculation on my part; I have no idea whether there's a real rationale hidden in there or not.
docs@lists.stg.fedoraproject.org
-
Paul W. Frields -
Stuart Ellis -
tuxxer