How To Install a Secure BSD System - Part 1|
I once wrote up an article on installing and securing the FreeBSD operating system. However, in that article I was unable to go in-depth into the various ways I might have configured certain parts of the operating system without compromising security to the website. So this is my gift to the community that has greatly supported me throughout the past years. And I hope that you find it somewhat educational or stimulating. You do not need to be running a FreeBSD operating system to follow this document. I recommend all users of all distributions read this article just for something to learn. If you like this document please comment on it or drop by IrC and say thanks (which is in no way required by me). A lot of hard work goes into these articles and I enjoy hearing people’s feedback. I’m just trying to be a good guy. I highly suggest reading though this article a couple times before attempting this on your own servers and if any damage or data loss occurs I am not responsible. You have been warned.
Why write this document?
Our exploration into setting up this server started with a simple question from our friends. That question always tends to be “How do I set this up”? Well, in this article, we are going to cover many areas of the operating system, perhaps a little bit too much. The overall goal here is to help you setup a secure server with Mail services configured for multiple domains, and various other services that a typical user needs. Basically, I’m writing up this article to keep the flow of information going after all the months of research I had to do. I’m taking my best articles from my site and putting them into one massive document.
Why choose FreeBSD?
FreeBSD is, in my opinion, a truly great operating system, unlike its rival Microsoft (in which 2 images mocking their policies and practices can be seen below). It is a fairly secure and easy to manage operating system, though not as secure as OpenBSD. And the best part is, things are easily installed and kept up to date, unlike your Linux systems out there. Don’t get me wrong, Linux is great and all, but about 75% of the packages I install are custom based and, well, RedHat sucks when it comes to that.
What’s so bad about the Linux updating system?
Well, you need to keep in mind that the BSD distros are mostly source-based, from the packages you install to updating the operating system. And when you're dealing with source-based you can completely configure the application to do what you want and not what the person who made the package intended. So when you’re using services such as up2date, you're using pre-packaged binaries that just don’t suit my needs.
So what’s up with the picture?
Normally I’m against animated gif images, but this best describes Linux to me. While the *BSD distributions strive to keep things working together, Linux seems to following the path of knocking each other down to be the one on top.
As for Microsoft, well, I hope these explain my thoughts.
Here we see Mr. Billy demonstrating corporate security policies
Here we see Mr. Bill and how he demonstrates corporate policy.
Now, after seeing those can you think of any other reason why you should not switch away from your crappy windows server? After all, once you start getting the feel and hang of Unix, your motto should quickly become “Your windows server is my playbox”.
FreeBSD is an industry standard
FreeBSD currently powers a large portion of the Internet. Over 30% of ISPs and web hosting companies have chosen FreeBSD because of its excellent performance and reliability. In addition, some of the busiest and most successful Internet sites in the world use FreeBSD.
The success of these sites proves that FreeBSD is one of the most powerful and scalable operating systems available. You can take advantage of that same power and scalability.
You're probably sitting there going "well, at least Microsoft has good-hearted values". Well that’s wrong!! Here’s an exclusive shot I made of our leading humanitarian Bill Gates.
So, if nothing else, you should have learned what a monopolizing and cheating corporation Microsoft is and that should drive you even more to switch over to FreeBSD or some other non-monopolizing company’s operating system. If not for yourself, then how about an operating system with the power and flexibility that you deserve? So now that fun time is over let's start with this article.
What’s covered in this document?
- Good background knowledge of the FreeBSD operating system
- A lot of free time and lots of patience
- And a good amount of some beer never hurts
- Compatible system for the FreeBSD Operating system
- ISO Images of the latest version of FreeBSD
- Internet Access
- Base OS Installation
- First time configurations (Basic System security Part 1)
- Updating your server
- Basic System Security Part 2
- Unix File Permissions
- Installing and configuring Mail services
- Firewall configurations
- Closing Remarks
Base OS Installation
Please note that our first goal here is to secure your box. Then we'll add service by service, securing them as we go along. Normally speaking, from experience, if you skip steps as you go along or rush installation of your services, you often forget and leave things unattended that should be set up. And often in that case you tend to forget about them.
Installing FreeBSD from CD
Ensure that the network cable is not plugged in; network access is not needed at this stage. Power on with the FreeBSD CD in the CD-ROM drive.
- Select “Standard” from the main menu.
- Select the size for the partition. For the database host, all of the drive space on the drive array will be used (press Z to toggle to size, it makes it easier to see the actual size). Press A to use the whole disk and then press S to make this a bootable partition. Then Q when finished.
- Choose your boot manager. Since FreeBSD is the only OS on the machine, we will be using standard. Failure to do so may render the computer unbootable after the installation.
- Use auto assign for the disk space. The program will automatically assign most of the space to /usr. Since the database will physically reside at /var/db, most of the disk space will be assigned to that file system. Move cursor to the /usr and delete the partition. Create /usr again with 4G, which is more than sufficient for most purposes, and assign all other space to /var/db, which is the database. /usr will be used to install most of the binaries and programs that do not come with FreeBSD and should have a sufficient amount of storage. The /var/db file system will host the MySQL database, so most drive spaces are assigned to it. When this is done, press Q. You might want to think real hard on how you want your partitions set up though.. it's also recommended to make a separate /usr/home partition as well as a separate /chroot partition. You can also press 1 or 2 to toggle between UFS1 and UFS2 types.
- When prompted for distribution sets, select Minimal config (move cursor to minimal and press space) and then select “Custom”. Most of the other components are not useful for database host and installing them will only increase the size of the OS and increase the burden to maintain them. At the “Custom” menu, select “man”. This is manual for all binaries, and a very important component for all administrators.
- When asked for configuration for Ethernet adapter, answer YES and select the “xl0” network card (which is the 3Com network card) or whatever your particular network card is.
- When prompted for IPv6 configuration, answer NO. There's no reason to use IPv6 yet.
- When prompted for DHCP configuration, answer NO.
- Then the IPv4 configuration screen will come up, this database host will have a temporary internal IP address for installation (it will be connected to a specially
firewalled network segment for installation).
- When prompted for whether to bring up the network interface now, answer NO. (The network cable is not even in place, there is no point of bringing up the interface).
- When prompted for this host being a gateway, answer NO (There is no need for packet forwarding on this machine).
- Then the prompt for configuring inetd and simple Internet services will come up, answer YES.
- When asked whether to enable inetd, answer NO. There is no service on the database server host that will run with inetd.
- When asked whether this host is an anonymous FTP server, NFS server and NFS client, answer NO. These are all very high-risk server software and are not needed for the database server operation.
- At the prompt for choosing security profile, answer YES. This will allow a choice of security profile which can make the OS much more secure. Choose "Extreme" in selection for security profile. The extreme security profile defaults to not start with sshd and sendmail (unlike in medium) and it also sets the kernel securelevel to 2, which requires single-user mode for a lot of system modification (will slow down and/or deter hacking attempts).
- When prompted for time zone, select YES and choose your correct time zone.
- Answer NO to Linux Compatibility.
- When prompted for packages installation, answer NO. The packages in the CD may not be up to date and may require immediate update. Software installation will be done at a later stage.
- Answer YES to adding user to system, and then add a normal user to the system. When prompted for root password, enter a strong password.
- When offered to view the options again, answer YES and review all options before exiting the installation and rebooting.
First Time Configuration (Basic System Security Part 1)
Now that we have covered Installing FreeBSD, let's go a little into the initial first things to do and some basic securing of your new operating system. As usual, this is a DO AT YOUR OWN RISK. We take no responsibility in anything that may happen.
Once you first boot into FreeBSD, go ahead and login as the root User. Now let's find out what ports are presently open on your system and close the unneeded ones. You can find this out by issuing the socket status command.
($:~)=> sockstat –4
You should see a list of all the current daemons that are in effect and which ports they’re running from.
Let's start off by working with sendmail. You should notice both ports 25 and 587 belong to sendmail. First of all, we can completely close port 587, and I have no idea to this day why that is open by default. We can close this by going in and editing the /etc/mail/sendmail.cf file
($:~)=> vi /etc/mail/sendmail.cf
(Depending on your experience, if you don't like vi you can use ee or something different)
now search for a line that states:
O DaemonPortOptions=Port=587, Name=MSA, M=E
Once you find that line, put a comment in front of it. Then save and close. Now execute:
($:~)=> killall -HUP sendmail
The -HUP won't stop sendmail, but will tell it to read the changes you made to /etc/mail/sendmail.cf. Repeat sockstat -4 and it should no longer show port 587.
What about port 25? You may or may not need to leave this port open, depending upon which program you use to send and read your e-mail. If you're running FreeBSD 4.6-RELEASE or higher, put this line in /etc/rc.conf:
This will tell sendmail to only listen on the localhost, which will allow any mail client to be able to send e-mail. If you know that your mail client has its own built-in SMTP agent or you're feeling adventurous, you can try this line instead:
Which will close port 25 completely. To see if you've broken the ability to send e-mail, make sure you've closed all of your terminals and saved all of your work. Then, as the superuser:
($:~)=> shutdown now
Press enter when prompted, then type exit. Once you've logged back in, see if you can send a test message to your e-mail account. If you can't, go back to the word "NO" and repeat the above to re-open port 25 for the localhost.. This is all I’m going to go into on sendmail. I would suggest reading more on configuring sendmail at a later time.
If port 111 (portmap) shows up in your "sockstat" output, remove it by adding the following lines to /etc/rc.conf (or, if a line already exists in that file, change the YES to a NO):
Portmap is only needed if you are running NFS, which you won't be on a stand-alone FreeBSD server. It also has a long history of security issues; so if you don't absolutely need it, disable it.
syslog (port 514) will probably also show in your output. You don't want to disable syslog completely, as you do want to receive logging messages. However, you don't need to have this port open to do so. In your /etc/rc.conf file, make sure syslog is enabled and add a second line with some options:
Those two ss’es (make sure you have two, not just one) in the flags will disable logging from remote hosts and close that port, but still allow your localhost to keep its logging capabilities. After doing this, do another shutdown now command, then once in singleuser mode, press control+D to return to regular mode.. Issue the sockstat command again and the syslog port should now be closed.
Next, make sure inetd_enable is not set to YES in /etc/rc.conf. If inetd is showing up in your sockstat output, something has been uncommented out in /etc/inetd.conf. If you don't need it, put a # back in front of that line, and do a killall inetd.
If you get your address from your ISP's DHCP server, keep dhclient (port 68) open, or you won't be able to renew your IP address.
Some other things to possibly add in your rc.conf are:
If you didn't, it is a good option to include, as it logs all attempts to closed ports. This can get to be annoying after awhile though.
An interesting option is:
This will enable system accounting. If you're new to system accounting, read man sa and man lastcomm to decide whether this option would be useful to you or not.
Finally, this is a good option to include:
as it will clear /tmp at startup, which is always a good thing.
Let's leave /etc/rc.conf and see what else we can do to tighten up your system. I like to change the default algorithm used when encrypting a user's password to the Blowfish algorithm, as it provides the highest security at the greatest speed.
To implement Blowfish hashes, edit /etc/login.conf and change the passwd_format line so that it looks like this:
Also, add the following to set the password defaults. These changes will accomplish the following: force the password change interval to 90 days; Warn the users to use mixed case passwords; The next change will set the minimum password length to 10 characters; And the final field will log the user out after an idle time of 30 minutes.
Save your change, and then rebuild the login database with this command:
($:~)=> cap_mkdb /etc/login.conf
You'll then have to change all of your user's passwords so they will get a new Blowfish hash. You can do this by typing:
($:~)=> passwd username
As the superuser, whatever username you use will be the user whose password will be updated. Repeat for all of your users, including the root account.
Once you're finished, double-check that it worked and you didn't forget any users:
($:~)=> more /etc/master.passwd
All of the passwords for your users should begin with $2.
Finally, configure the adduser utility to use Blowfish whenever you create a new user by editing /etc/auth.conf. Change the crypt_default line so that it looks like this:
You've probably noticed when you log in to your FreeBSD system that your login prompt reminds you that you are running FreeBSD. And that after you log in, you receive the FreeBSD copyright information, which is followed by the version of FreeBSD and the name of your kernel, and finally, a useful (but rather boring) motd which again reminds you that you are running FreeBSD. You probably already know what version of FreeBSD you are running and might not want to share that information with the rest of the world. And the motd is a good place to remind the rest of the world that they shouldn't be messing with your system anyways.
You can edit /etc/motd to say whatever suits your purposes, be it anything from your favorite sci-fi excerpt to all the nasty things that will happen to someone if they continue to try to log in to your system. Below is a good example of a common motd.
* * * * * * * * * * * * * * W A R N I N G * * * * * * * * * * * * * * *
If you want to remove the copyright info:
THIS SYSTEM IS RESTRICTED TO AUTHORIZED USERS FOR AUTHORIZED USE ONLY.
UNAUTHORIZED ACCESS IS STRICTLY PROHIBITED AND MAY BE PUNISHABLE UNDER
THE COMPUTER FRAUD AND ABUSE ACT OF 1986 OR OTHER APPLICABLE LAWS.
IF NOT AUTHORIZED TO ACCESS THIS SYSTEM, DISCONNECT NOW. BY CONTINUING,
YOU CONSENT TO YOUR KEYSTROKES AND DATA CONTENT BEING MONITORED. ALL
PERSONS ARE HEREBY NOTIFIED THAT THE USE OF THIS SYSTEM CONSTITUTES
CONSENT TO MONITORING AND AUDITING. THE ADMINISTRATORS ALSO RESERVE THE
RIGHT TO CANCEL OR LOCK YOUR ACCOUNT AT ANY GIVEN TIME. ALL TERMS
DESCRIBED ABOVE ARE SUBJECT TO CHANGE WITHOUT ANY GIVEN NOTICE. IF YOU
DO NOT AGREE TO THESE TERMS LOGOUT NOW!
* * * * * * * * * * * * * W A R N I N G * * * * * * * * * * * * * * *
($:~)=> touch /etc/COPYRIGHT
To change the text that appears at the login prompt, edit /etc/gettytab. Find the line in the default: section that starts with
Carefully, change the text between r : to whatever text you wish to appear. Double-check that you have the right amount of s and s and save your change. For example, my login prompt looks like this:
I'm a node in cyberspace. Who the hell are you?
You can test your changes by going to another terminal and logging in.
Finally, even though you've edited your motd to remove your version and kernel information, by default FreeBSD will still re-add it to /etc/motd every time you log in. To prevent this behavior, add the following line to /etc/rc.conf:
This change requires a reboot, so make sure you've first tested your previous changes and have saved all of your work on any other terminals.
No one (including you) should ever log in to your system using the root account. To prevent this from happening, edit /etc/ttys. Once you get past a page's worth of comments, you'll notice a section that goes from ttyv0 to ttyv8. Change the word "secure" on each of those lines to "insecure". This is a file you don't want a typo in, so double-check your changes carefully. Test your change by trying to log in as root on one of your terminals. You should receive a "Login incorrect" message.
Personally, I tend to use all nine terminals on my desktop. If you don't, you can also change the word "on" to "off" on some of the ttys in /etc/ttys. Remember to leave at least one terminal "on," or else you won't be able to log in, which will severely hamper the usefulness of your system. You'll also note that ttyv8 is "off" by default, which means you have to manually start an X Window session. If you'd like X to start automatically at bootup, change that "off" to "on."
Another good thing to do inside your ttys file the top part says:
console none unknown off secure
I like to completely change all the secure portions from this file to insecure. So what’s that do? Basically, every time you launch into single user mode you have complete root access without a password. By removing secure you’re going to force people to enter in your root password upon entering single user mode or be given the option to return back to multi-user mode. It should look like:
console none unknown off insecure
Changing all the tty lines will make sure that the root user cannot login to the console by himself. A normal user must login and use either su or sudo to gain root access.
Now that the basics are completed let's get into some fun stuff shall we?
The first thing to do is to elevate the normal user’s group, making the normal user able to become root user later.
($:~)=> vi /etc/group
and edit the first line (after the # comments) which starts with wheel,
wheel:*:0:root becomes wheel:*:0:root,soupx
Where "soupx" is the normal user that was created at installation time.
As a normal user, FreeBSD will only allow minimal privileges. No changes to the system configuration files are allowed. For the purpose of securing the system, configuration would have to be changed. Unix systems have a superuser account for the purpose of system configuration and maintenance. The name of this account is “root” - it is the God-mode account, and a root user can do anything to the system. Given this amount of privileges, it is considered to be dangerous to login using this account for day to day operation because the consequence of a simple mistake is just too great, therefore, it is much safer to operate or “use” the system with a normal user account and only become the “root” user as need arises. To allow this to happen the user must be a member of wheel group (group 0), which is where user “soupx” was assigned above.
Similarly, when an attacker performs reconnaissance on a system, the knowledge of which OS platform is running would be of great value. Sometimes, an attacker would send out of spec packets to a host and by the information returned, they would be able to determine the type of OS running (this usually teams up with port scan to produce more information). To avoid unnecessary information leaking to the attacker:
Tip: This option would break RFC compliance. Do not use this on a web server.
This should be added to rc.conf, and will effectively tell the system to ignore all the TCP packets with SYN and FIN flag set. Notice that the kernel has to be set with “TCP_DROP_SYNFIN” to activate this option (see below – kernel section). ICMP specification allows a type of packets for the router to tell a sending host the most optimized route to another host, that routing is done statically and there is only one router out to other parts of the network. This type of packets should not exist under normal conditions. If these packets are on the network, it should either be a network component error (maybe misconfiguration) or a local LAN attack. The danger of these packets lies in the redirection, if traffic were redirected to a hostile local LAN host, that host would be able to eavesdrop on all traffic to and from the server. To disable the effect of such packets and to log them, add:
In the rc.conf file.
In rc.conf configuration, “log_in_vain” option was selected to log all abnormal connections. This is only a logging feature and does not eliminate the threat of information leaked. Normally, when a host sends a SYN packet indicating the intention to establish a connection, the receiving host would either send a SYN+ACK packet back to continue the connection or send an RST packet to notify that the port is not listening. By monitoring whether SYN+ACK or RST packet is in the reply, the attacker would be able to map out the opened ports on a host. On the other hand, if the target host does not send back anything, the sending host would wait till timeout before trying another port that would slow down the scanning process. FreeBSD has an option to disable sending back the RST packet for unopened ports. Edit the sysctl.conf by typing:
($:~)=> vi /etc/sysctl.conf
This file should only contain comments. After the comments, add the following lines:
Tips: This is not a replacement for a firewall (packet filter). It should be used in conjunction with a packet filter and possibly be a failsafe mechanism for the firewall. With a proper firewall configured, any log produced by log_in_vain should be a warning that the firewall is failing or misconfigured.
While you’re in the sysctl.conf add in this:
Please note if you're running versions earlier than 5.2 the name changed. The old name is:
That will make it so users will only be able to display the processes that are owned by that user. But root will still be able to display all processes. (This option first appeared in FreeBSD 4.7)
Updating Your Server
Before we get into too much else, let's first make sure we have the most current sources and binaries on our system. We will do this through cvsup. To build a secure server, it is essential that the computer is free from known vulnerability. After securing the base OS, the database server should be updated to ensure it is free from known vulnerability. One of the biggest strengths of FreeBSD is the ability to update the whole OS from source code; this makes updating the OS an easy task. It can save FreeBSD administrator a lot of time tracking down bug fixes and patches.
There are a couple ways to get cvsup installed. And there are also 2 cvsup's, depending which one you want. You have cvsup (this one has a GUI for xwindows) or you have cvsup-without-GUI (this is for a system w/out xwindows) but for this article, I’m going to use the no-GUI one.
One way you can install cvsup is with the packaging system. We will go into detail about the packaging system and ports tree at a later time.
($:~)=> pkg_add -r cvsup-without-gui
If the package system is not your cup of tea you can also use the ports tree. If you’ve never used the ports tree before, this is what makes FreeBSD such a great operating system. So if you installed the ports collection you can:
($:~)=> cd /usr/ports/net/cvsup-without-gui ; make install clean
However, if you followed my instructions earlier, you did not install the ports collection because we want to use fresh ports. So now we go onto method 3 of how to install this.
Welcome back to the installer app. Normally I try to stay away from automated things like this to do my bidding. But I’m not fully going to go into the packaging system yet.
Now pop your FreeBSD cd1 into the cd-rom drive and select your cd-rom from the menu
- Choose the 4th Option labeled Configure
- Choose the 2nd Option labeled Packages
- Choose the 1st Option labeled CD-ROM
Scroll down to net and select cvsup. Once you're done installing cvsup you can continue to update your sources. You can also install from the FreeBSD ftp server instead of using the old outdated binaries from the cd-rom.
Create configuration file for CVSup
CVSup can update all the source code provided by FreeBSD or just download and update ones that the user specifies. All of these are controlled by a configuration file provided at run time. I'm not going to go in-depth on cvsup - if you want more information about it I suggest you read the handbook.
Create a file in your /root directory called cvs-supfile. This file will contain the information required for updating your system.
($:~)=> vi /root/cvs-supfile
Put this in it:
Please remember to find your fastest cvsup server and change the release tags to the appropriate values. Now save and exit. Congratulations ! You have a cvs-supfile. Now run this as root:
*default delete use-rel-suffix
($:~)=> /usr/local/bin/cvsup /root/cvs-supfile
Building Your World
The source tree and ports tree will be synchronized with the FreeBSD distribution server.
So once your sources finished updating, let's go ahead and compile and install them.
($:~)=> cd /usr/src
The buildworld is going to take a long time. This is where the requirement of beer comes into play because unless you want to sit there and watch a bunch of code fly across your screen, a good alternative is to invite some friends over and play some good drinking games. Once buildworld completes, let's go ahead and setup a kernel. But keep in mind over time I have come up with a rule that if you're seeing double you probably should not be operating your server.
($:~)=> make buildworld
($:~)=> cd /usr/src/sys/i386/conf
Before editing your kernel I would suggest you read up about it, in the FreeBSD Handbook there are lots of options you should probably do inside your kernel, but I’m only going to suggest a couple to begin with.. You might also want to comment out the devices you don’t have or need.
($:~)=> cp GENERIC KERNNAME (kernname is whatever you wish to call your kernel)
($:~)=> vi KERNNAME
If you add in the console settings above you should add the following into your /etc/rc.conf
#Misc Console Settings
Exchange "swiss-8x8" with whichever font you prefer. You will find all available fonts under the /usr/share/syscons/fonts/ directory.
allscreens_flags="VGA_90x60 red black"
Back inside the kernel, we should also choose the type of firewall we would like to make our server use.
These options will enable the IPF Firewall.
Where as these options will enable the IPFW firewall. If you plan on using OpenBSD’s PF firewall, go ahead and add these in.
device bpf #DEFAULT
And if using PF add these into your rc.conf file
After doing your buildworld later on, be sure to install /usr/ports/security/pf. PF is the way to go, in my opinion. For more information about PF and ALTQ, Solarflux has setup some nice information on this over at: http://solarflux.org/pf. I recommend visiting it and take the time to learn how to use it.
Another fun and interesting kernel option to add in is: (NOTE: the option below is for the 4x branch. It’s standard in 5x)
pseudo-device snp 4
The 5x branch does not need this. But it must be specified in the 4x Branches. Also, if you're running the 4x branch, you need to create some devices by hand. And snp would be one of them.
($:~)=> cd /dev
So what does this allow me to do?
($:~)=> ./MAKEDEV snp0
($:~)=> ./MAKEDEV snp1
($:~)=> ./MAKEDEV snp2
($:~)=> ./MAKEDEV snp3
That’s a good question. The watch command works in conjunction with the pseudo-device snp. Basically, it will allow you the root user to snoop tty’s on your server, and even interact with users or take over their shells. The 4 means that you can snoop on 4 different tty’s at any given time. You can change this to whatever value you would like, just remember to make the devices for them. Read man watch for more information about this.
You can check your LINT file for other options you wish to have. If there is no LINT file present, just issue the command make LINT, and it will create one for you. However, on the 5x branch you might get more of an understanding if you read the NOTES instead of LINT, since when you create a LINT it basically copies the NOTES file and strips the comments.
After you edit your kernel head on over to /usr/src.
($:~)=> cd /usr/src
Hopefully everything will go well there. The kernel is ready to be installed at this point. You can ultimately issue the command:
($:~)=> make buildkernel KERNCONF=KERNELNAME
($:~)=> echo “KERNELNAME” >> /etc/make.conf
This will make it so that each time you build a new kernel, you no longer have to specify the name for it as well as installing the kernel.
($:~)=> make installkernel KERNCONF=MYKERNEL
This will install the kernel.
To activate the kernel, a reboot is necessary. As root user, type the command
The system will reboot at this stage. When the reboot is finished, the system is running on the new kernel. You can issue a uname –a command to verify that you're operating on a new kernel.
Now to install compiled binaries. The source tree was compiled earlier. Now that the kernel is compiled and installed, it is ready for the binaries to be installed. For this to happen, the system has to be in single user mode,
($:~)=> shutdown now
After the system gets into single user mode,
($:~)=> cd /usr/src
This will install all the updated binaries compiled from source downloaded by CVSup, and the system is then ready to be rebooted.
($:~)=> make installworld
You might want to look around at various file permissions once you're finished. One thing I’ve experienced is that /tmp likes to change permissions on you. So remember to look at that. Another example is the master.passwd file. You should chmod it to 600 - nobody but root needs to see that file. We will go into these files and permissions later though.
Now that you know how cvsup works it’s handy to set up a cron job to do this nightly. Anyhow, this should get you on your feet.
($:~)=> vi /etc/crontab
And add the following in there:
0 3 * * * root /usr/local/bin/cvsup /usr/local/etc/ports-supfile 1>/dev/null 2>&1
So, what’s all this mean? Crontabs are pretty simple but commonly overlooked by system administrators. An easy breakdown of it is:
MIN HOUR DAY MONTH WDAY WHO CMD
So we're saying at 3am every day we are going to issue the following command as our root user. When updating your operating system it’s also strongly recommended to read the /usr/src/UPDATING file for any changes that might have occurred.
Basic System Security Fundamentals Part 2
Change permission of root directory. There should not be any normal user other than system administrators logging onto the system, but just in case this happens, the root directory should be properly protected. To avoid unnecessary monitoring by other users on the system.
($:~)=> chmod 700 /root
You might also want to look at the permissions in the users home directories. I would recommend changing them to 700 also.
Change permission of suid and sgid binaries. Suid binaries allows a user to execute the program as a different user (usually root). Sgid works in similar fashion and allows the user to become another group. Some of the suid binaries are badly implemented and easily exploited; they could easily lead to a local user compromising the machine through these suid and sgid binaries. The best practice is to use suid and sgid binaries only if necessary and disallow the use of the unnecessary ones. To find all suid binaries on a machine:
($:~)=> find / -perm –4000
To find all sgid binaries on a machine:
($:~)=> find / -perm –2000
Some binaries are almost for sure never to be touched. For those binaries, permission 000 should be given, this will disallow any read, write and execute from any user. For the binaries that are only useful to root, permission 500 should be given and should be owned by root, it would only allow root to execute and read them. Later in this document we will go over how permissions are defined.
Now I’m going to help you out a little bit here and show you an excellent application for managing suid and sgid binaries.
($:~)=> cd /usr/local/src ; fetch http://www.watson.org/fbsd-hardening/suidcontrol-0.1.tgz
Please take the time to read the README file and learn how to use this great application. A good example of a hardened system policy file can be viewed over here: http://www.watson.org/fbsd-hardening/lockdown.pol
($:~)=> tar –xzvf suidcontrol-0.1.tgz
($:~)=> cd suidcontrol ; make
Some local directories should never encounter certain types of files, such as suid. Such types of files running on directory such as /tmp is certainly abnormal and should be stopped. Fortunately, FreeBSD allows mount options that will limit the type of operation on a mount point. Even though no user should be allowed to log into database host system to execute anything or run any files, a precaution measure is always helpful. To set the allowed operation on a mount point:
($:~)=> vi /etc/fstab
If you’re using prior to FreeBSD 5, you might also want to consider disabling automount of the Procfs. I would suggest you read up on it to see if it's right for you.
For /tmp’s option, change to rw,nosuid,nodev
For /usr’s option, change to nodev,rw
For /var’s option, change to nodev,nosuid,noexec,rw
For /home option, change to nodev,nosuid,noexec,rw
The “nodev” option disallows files to be a device, avoid unnecessary access to hardware devices. The “nosuid” option disallows files on the specified file system to run as suid binaries. The “noexec” option disallows execution of any files on the specified file system. By limiting the capabilities of files in different file system, normal user’s ability on the system is reduced. Even if an attacker gained access as a normal user on the system, it would be harder to exploit local vulnerabilities. Please keep in mind with the above configurations that when you update your system in the future you’re going to have to limit these restrictions to be able to perform a buildworld with out errors. That is the key reason to drop down into single user mode while doing such tasks.
Now, if you didn’t notice yet, your system has 2 temporary placement directories. You have /var/tmp and /tmp. So ideally we don't really need both of these, but certain services use /var/tmp for writing stuff to. So we're going to delete the /var/tmp directory and create a symbolic link to /tmp
($:~)=> cd /var && mv ./tmp/* /tmp/ && rm –rf tmp && ln –s /tmp tmp
Another good security-related aspect of FreeBSD permissions is the chflags command. We will talk about this in the next section when we go over permissions. But there are certain files across your system that should never be touched. So we're going to add a little bit of flavor to these files.
($:~)=> chflags schg /bin/*
On some of these files you will get an error message saying that the operation could not be permitted. That’s fine, just ignore them.
($:~)=> chflags schg /sbin/*
($:~)=> chflags schg /usr/sbin/*
Moving on, we need to change some permissions in /var/log. The permissions set by default tend to be a bit too liberal for my taste.
Remove any logs you don't use (refer to /etc/syslog.conf to see what you actually use) and chmod the files 600 (except the file wtmp which may be sane to chmod 640 so at least the wheel user may be able to use the 'last' command).
($:~)=> cd /var/log
Finally, create an empty file called /etc/ipf.rules and an empty file called /etc/ipnat.rules so IP Filter and IPnat sees the configuration files you specified in /etc/rc.conf.
($:~)=> chmod 600 *
($:~)=> chmod 640 wtmp
($:~)=> touch /etc/ipf.rules
Across our system there are various files that no normal user should be able to view or access. This is where the default permissions, in my opinion, are wrong. So let's quickly change some of these.
($:~)=> touch /etc/ipnat.rules
($:~)=> chmod 600 /etc/ip*.rules
($:~)=> chmod 600 /etc/crontab
These are just a couple prime examples. There are many more files that you should change permissions to. Something to keep in mind though is that each time you perform an install world some of the permissions change back to their original default values.
($:~)=> chmod 700 /root
($:~)=> chmod 700 /home/*
($:~)=> chmod 650 /etc/rc.*
($:~)=> chmod 600 /etc/master.passwd
Now onto SSH. OpenSSH is a remote login program that will enable a person to log into your box from anywhere. But like everything it needs some tweaking. So let's go ahead and edit it’s configuration file.
($:~)=> vi /etc/ssh/sshd_config
The key lines to change or add are the following:
Notice that we're only going to allow users login that are in the ssh group. let's go ahead and create one.
($:~)=> echo “ssh:*:666:soupx” >> /etc/group
Please remember to change "soupx" to your NORMAL user name. If you decide not to, can you at least e-mail me my password?
A good measure to take now is to backup various system directories. We're going to take /etc for an example. It’s a good idea to keep an active backup on your system for quick measures of restoring a file that might accidentally be borked.
($:~)=> tar –cvvpzf /root/etc.tar.gz /etc
For an extra layer of protection let's encrypt that file:
($:~)=> chmod 600 /root/etc.tar.gz
($:~)=> openssl enc –blowfish –in /root/etc.tar.gz –out /root/etc.tgz.bf
To unencrypt the file you would issue:
($:~)=> openssl enc –d –blowfish < /root/etc.tgz.bf | tar –xzf –
Once encrypted, remove the etc.tar.gz file.
Onto further tweaking. Let's go back and edit the rc.conf file again.
Do not turn on RFC1323 extensions:
Disable probing of idle TCP connections to verify the peer is up and reachable:
Do not respond to broadcast ping packets:
ICMP error response bandwith limiting. Helps protect against DoS attacks:
And now jump back into the /etc/sysctl.conf file.
To verify that an incoming packet arrives on an interface that has an address matching the packet's destination address:
Increase TCP Window size for increase in network performance:
Change the ELF Branding fallback:
Block SYN Cookies and other ICMP Stuff:
This article has been split into three parts due to the massive load times that were required when it was all one huge article. Follow the links below to veiw the rest of the article.
Part 1 | Part 2 | Part 3
Copyright © by LWD All Rights Reserved.
Published on: 2004-03-08 (92881 reads)[ Go Back ]