soup4you2
August 20th, 2003, 17:17
Introduction
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 various ways I might have configured certain parts of the operating system with out compromising security to the website. So this is my gift to the community that has greatly supported me though out the past years. And I hope that you enjoy reading this if not 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. I enjoy hearing people’s feedback or drop by IrC and say thanks. A lot of hard work goes into these articles. In which is in no way required by me. 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 in the operating system. Perhaps a little bit too much. The overall goal here is hopefully I can help somebody out from all the months of researching that I had to do. The goal of this document is to hopefully help you setup a secure server with Mail services configured for multiple domains. And various other services that a typical user uses. Basically I’m writing up this article to keep the flow of information going. I’m taking my best articles from my site and putting them into 1 massive document.
Why choose FreeBSD?
FreeBSD Is in my opinion a truly great operating system. Unlike its rivals Microsoft. (In which 2 images demonstrating their policy and practices can be seen below.) Is a fairly secure (not as secure as OpenBSD) and easy to manage operating system. 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 put in mind that the BSD distro's are mostly source based. From the packages you install to updating the operating system. And when your 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 your using pre-packaged binaries that just don’t suite my needs.
http://bsdhound.dnsalias.net:81/~soup4you2/doc/ATT06831.gif
So what’s up with the picture?
Well 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.
http://bsdhound.dnsalias.net:81/~soup4you2/doc/2.jpg
Here we see Mr. Billy Demonstrating Corporate Security Policy's
http://bsdhound.dnsalias.net:81/~soup4you2/doc/1.jpg
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. Now you can take advantage of this same power and scalability.
Now your 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 good leading humanitarian Bill Gates.
http://bsdhound.dnsalias.net:81/~soup4you2/doc/3.jpg
So if nothing else you should have learned what a monopolizing and cheating corporation Microsoft is and 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 a Operating system with the power and flexibility that you deserve. So now that fun time is over lets start with this article.
Requirements
* Good background knowledge of the FreeBSD operating system
* A lot of free time, with 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
What’s covered in this document?
* 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 you add service by service securing them as you go along. Normally speaking from experience if you skip steps as you go along or rush installing your services you often forget and leave things unattended that should be setup. 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 FreeBSD CD in the CD-ROM drive.
- Select “Standard” from the main menu.
- Select the size for the partition, for the database host, all off 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 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 setup 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, 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 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 default to not start with sshd and sendmail (unlike in medium) and it also set 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 the correct time zone.
- Answer NO to Linux Compatibility.
- When prompted for packages installation, answer NO. The packages in the CD may not be most 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 reboot.
First time configuration (Basic System Security Part 1)
Now that we have covered Installing FreeBSD Lets 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 your first boot into FreeBSD go ahead and login as the root User. Now lets find out what all ports are presently open on your system and close the unneeded ones. You can find this out by issuing the socket status command
[code:1:09a0c3835f]($:~)=> sockstat –4[/code:1:09a0c3835f]
You should see a list of all the current daemons that are in effect and what port they’re running off of.
Lets start off by working with sendmail. You should notice both ports 25 and 587 belong to sendmail. Well fist of all we can completely close port 587 and i have no idea to this day why that is open. We can do this by going in and editing the /etc/mail/sendmail.cf file
[code:1:09a0c3835f]($:~)=> vi /etc/mail/sendmail.cf[/code:1:09a0c3835f]
(Depending on your experience if you don't like vi you can use ee or something different)
now search for a line that states:
[code:1:09a0c3835f]O DaemonPortOptions=Port=587, Name=MSA, M=E[/code:1:09a0c3835f]
Once you find the line put a comment in front of it. Then save and close. Now execute:
[code:1:09a0c3835f]($:~)=> killall -HUP sendmail[/code:1:09a0c3835f]
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 email. If you're running FreeBSD 4.6-RELEASE or higher, put this line in /etc/rc.conf:
[code:1:09a0c3835f]sendmail_enable="NO"[/code:1:09a0c3835f]
This will tell sendmail to only listen on the localhost, which will allow any mail client to be able to send email. 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:
[code:1:09a0c3835f]sendmail_enable="NONE"[/code:1:09a0c3835f]
Which will close port 25 completely. To see if you've broken the ability to send email, make sure you've closed all of your terminals and saved all of your work. Then, as the superuser:
[code:1:09a0c3835f]($:~)=> shutdown now[/code:1:09a0c3835f]
Press enter when prompted, then type exit. Once you've logged back in, see if you can send a test message to your email 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 up 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):
[code:1:09a0c3835f]nfs_server_enable="NO"
nfs_client_enable="NO"
portmap_enable="NO"[/code:1:09a0c3835f]
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:
[code:1:09a0c3835f]syslogd_enable="YES"
syslogd_flags="-ss"[/code:1:09a0c3835f]
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:
[code:1:09a0c3835f]log_in_vain="YES"[/code:1:09a0c3835f]
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:
[code:1:09a0c3835f]accounting_enable="YES"[/code:1:09a0c3835f]
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:
[code:1:09a0c3835f]clear_tmp_enable="YES"[/code:1:09a0c3835f]
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:
[code:1:09a0c3835f]:passwd_format=blf:[/code:1:09a0c3835f]
Also add the following to set the password defaults. These changes will do 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.
[code:1:09a0c3835f]:passwordtime=90d:\
:mixpasswordcase=true:\
:minpasswordlen=10:\
:idletime=30:\[/code:1:09a0c3835f]
Save your change, and then rebuild the login database with this command:
[code:1:09a0c3835f]($:~)=> cap_mkdb /etc/login.conf[/code:1:09a0c3835f]
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:
[code:1:09a0c3835f]($:~)=> passwd username[/code:1:09a0c3835f]
As the superuser. Whatever username you use, that 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:
[code:1:09a0c3835f]($:~)=> more /etc/master.passwd[/code:1:09a0c3835f]
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:
[code:1:09a0c3835f]crypt_default=blf[/code:1:09a0c3835f]
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.
[code:1:09a0c3835f]
* * * * * * * * * * * * * * W A R N I N G * * * * * * * * * * * * * * *
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 * * * * * * * * * * * * * * *
[/code:1:09a0c3835f]
Next, to remove the copyright info:
[code:1:09a0c3835f]($:~)=> touch /etc/COPYRIGHT[/code:1:09a0c3835f]
Then to change the text that appears at the login prompt, edit /etc/gettytab. Find the line in the default: section that starts with
[code:1:09a0c3835f]:cb:ce:ck:lc[/code:1:09a0c3835f]
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?
login:
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:
[code:1:09a0c3835f]update_motd="NO"[/code:1:09a0c3835f]
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:
[code:1:09a0c3835f]console none unknown off secure[/code:1:09a0c3835f]
I like to completely remove the secure portion from this line. So what’s that do? Well 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.
Now that the basics are completed lets 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.
[code:1:09a0c3835f]($:~)=> vi /etc/group[/code:1:09a0c3835f]
and edit the first line (after the # comments) which starts with wheel,
[code:1:09a0c3835f]wheel:*:0:root becomes wheel:*:0:root,soupx[/code:1:09a0c3835f]
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, it 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.
[code:1:09a0c3835f]tcp_drop_synfin=”YES”[/code:1:09a0c3835f]
Tip: This option would break RFC compliance. Do not use this on a web server.
This should be added to rc.conf, this 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, 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 condition. If these packets are on the network, it should either be a network component error (maybe mis-configuration) 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 packet and to log them, add
[code:1:09a0c3835f]icmp_drop_redirect=”YES”
icmp_log_redirect=”YES”[/code:1:09a0c3835f]
In the rc.conf file.
In rc.conf configuration, “log_in_vain” option was selected to log all the abnormal connection. 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
[code:1:09a0c3835f]($:~)=> vi /etc/sysctl.conf[/code:1:09a0c3835f]
This file should only contain comments. After the comments, add the following lines
[code:1:09a0c3835f]net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1[/code:1:09a0c3835f]
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:
[code:1:09a0c3835f]security.bsd.see_other_uids=0[/code:1:09a0c3835f]
Please note if your running earlier than 5.2 the name changed. The old name is:
[code:1:09a0c3835f]kern.ps_shoallprocs=0[/code:1:09a0c3835f]
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
Now before we get into too much else lets 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 the securing the base OS, the database server should get 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.
Now there's a couple ways to get cvsup installed. And there's 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 later at a later time.
[code:1:09a0c3835f]($:~)=> pkg_add -r cvsup-without-gui[/code:1:09a0c3835f]
Now 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
[code:1:09a0c3835f]($:~)=> cd /usr/ports/net/cvsup-without-gui ; make install clean[/code:1:09a0c3835f]
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.
[code:1:09a0c3835f]($:~)=> /stand/sysinstall[/code:1:09a0c3835f]
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.
* Choose the 4th Option labeled Configure
* Choose the 2nd Option labeled Packages
* Choose the 1st Option labeled CD-ROM
Now pop in your FreeBSD cd1 in the cd-rom and select your cd-rom from the menu
Scroll on down to net and select cvsup, once your done installing cvsup we can continue to update our 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 our system.
[code:1:09a0c3835f]($:~)=> vi /root/cvs-supfile[/code:1:09a0c3835f]
Put this in it.
[code:1:09a0c3835f]
*default host=cvsup11.FreeBSD.org
*default base=/usr
*default prefix=/usr
*default release=cvs
*default delete use-rel-suffix
*default compress
src-all tag=RELENG_5_2
ports-all tag=.
[/code:1:09a0c3835f]
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.
[code:1:09a0c3835f]($:~)=> /usr/local/bin/cvsup /root/cvs-supfile[/code:1:09a0c3835f]
Building Your World
The source tree and ports tree will be synchronized with the FreeBSD distribution server.
So once your sources finished updating. Lets go ahead and compile and install them.
[code:1:09a0c3835f]($:~)=> cd /usr/src
($:~)=> make buildworld[/code:1:09a0c3835f]
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 lets go ahead and setup a kernel. But keep in mind over time I have come up with a rule that if your seeing double you probably should not be operating your server.
[code:1:09a0c3835f]($:~)=> cd /usr/src/sys/i386/conf
($:~)=> cp GENERIC KERNNAME (kernname is whatever you wish to call your kernel)
($:~)=> vi KERNNAME[/code:1:09a0c3835f]
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.
[code:1:09a0c3835f]options TCP_DROP_SYNFIN
options SC_DISABLE_DDBKEY
options SC_DISABLE_REBOOT
options CPU_ENABLE_SSE
options CPU_ATHLON_SSE_HACK
options IPSEC
options IPSTEALTH
options TCP_DROP_SYNFIN[/code:1:09a0c3835f]
Now we should also choose the type of firewall we would like to make our server use.
[code:1:09a0c3835f]options IPFILTER
options IPFILTER_LOG
options IPFILTER_DEFAULT_BLOCK[/code:1:09a0c3835f]
These options will enable the Packet Filtering Firewall (PF).
[code:1:09a0c3835f]options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_DEFAULT_TO_ACCEPT[/code:1:09a0c3835f]
Where as these options will enable the IPFW firewall (IP Firewall).
Another fun and interesting kernel option to add in is: (NOTE: this option below is for the 4x branch. It’s standard in 5x)
[code:1:09a0c3835f]pseudo-device snp 4[/code:1:09a0c3835f]
Now The 5x branch does not need this. But it must be specified in the 4x Branches. Also if your running the 4x branch some devices you need to create by hand. And snp would be one of them.
[code:1:09a0c3835f]($:~)=> cd /dev
($:~)=> ./MAKEDEV snp0
($:~)=> ./MAKEDEV snp1
($:~)=> ./MAKEDEV snp2
($:~)=> ./MAKEDEV snp3[/code:1:09a0c3835f]
So what does this allow me to do?
Well 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. 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 a 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.
[code:1:09a0c3835f]($:~)=> cd /usr/src
($:~)=> make buildkernel KERNCONF=KERNELNAME[/code:1:09a0c3835f]
Hopefully everything will go well there. The kernel is ready to be installed at this point. You can ultimately issue the command:
[code:1:09a0c3835f]($:~)=> echo “KERNELNAME” >> /etc/make.conf[/code:1:09a0c3835f]
This will make it so each time you build a new kernel you no longer have to specify the name for it as well as installing the kernel.
[code:1:09a0c3835f]($:~)=> make installkernel KERNCONF=MYKERNEL[/code:1:09a0c3835f]
This will install the kernel.
To activate the kernel, a reboot is necessary. As root user, type the command
[code:1:09a0c3835f]($:~)=> reboot[/code:1:09a0c3835f]
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 your 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,
[code:1:09a0c3835f]($:~)=> shutdown now[/code:1:09a0c3835f]
After the system gets into single user mode,
[code:1:09a0c3835f]($:~)=> cd /usr/src
($:~)=> make installworld[/code:1:09a0c3835f]
This will install all the updated binaries compiled from source downloaded by CVSup,
and the system is then ready to be rebooted.
[code:1:09a0c3835f]($:~)=> reboot[/code:1:09a0c3835f]
You might want to look around at various file permissions once your done. 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 in a bit though.
Now that you know how cvsup works it’s handy to setup a cron job to do this nightly. Anyhow this should get you on your feet.
[code:1:09a0c3835f]($:~)=> vi /etc/crontab[/code:1:09a0c3835f]
And add the following in there:
[code:1:09a0c3835f]0 3 * * * root /usr/local/bin/cvsup /usr/local/etc/ports-supfile 1>/dev/null 2>&1[/code:1:09a0c3835f]
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 were 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.
[code:1:09a0c3835f]($:~)=> chmod 700 /root[/code:1:09a0c3835f]
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 are easily exploited; they could easily lead to 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,
[code:1:09a0c3835f]($:~)=> find / -perm –4000[/code:1:09a0c3835f]
To find all sgid binaries on a machine,
[code:1:09a0c3835f]($:~)=> find / -perm –2000[/code:1:09a0c3835f]
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.
[code:1:09a0c3835f]($:~)=> cd /usr/local/src ; fetch http://www.watson.org/fbsd-hardening/suidcontrol-0.1.tgz
($:~)=> tar –xzvf suidcontrol-0.1.tgz
($:~)=> cd suidcontrol ; make[/code:1:09a0c3835f]
Now 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
Mounted drives.
Some local directory should never encounter certain type of files, such as suid. Such type 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,
[code:1:09a0c3835f]($:~)=> vi /etc/fstab
For /tmp’s option, change to rw,nosuid,noexec,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[/code:1:09a0c3835f]
Now 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.
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 done really need both these but certain services use /var/tmp for writing stuff to. So were going to delete the /var/tmp directory and create a symbolic link to /tmp
[code:1:09a0c3835f]($:~)=> cd /var && mv ./tmp/* /tmp/ && rm –rf tmp && ln –s /tmp tmp[/code:1:09a0c3835f]
Now other good security related aspects 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 were going to add a little bit of flavor to these files.
[code:1:09a0c3835f]($:~)=> chflags schg /bin/*
($:~)=> chflags schg /sbin/*
($:~)=> chflags schg /usr/sbin/*[/code:1:09a0c3835f]
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.
To prevent anyone from tampering with your kernel, set the schg flags on the kernel too: (Please remember doing this for when you update your kernel later on in life)
[code:1:09a0c3835f]($:~)=> chflags schg /kernel[/code:1:09a0c3835f]
The file /boot.config can be used to change kernel used at system bootup. To prevent this, do the following:
[code:1:09a0c3835f]($:~)=> touch /boot.config
($:~)=> chflags schg /boot.config[/code:1:09a0c3835f]
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).
[code:1:09a0c3835f]($:~)=> cd /var/log
($:~)=> chmod 600 *
($:~)=> chmod 640 wtmp[/code:1:09a0c3835f]
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.
[code:1:09a0c3835f]($:~)=> touch /etc/ipf.rules
($:~)=> touch /etc/ipnat.rules
($:~)=> chmod 600 /etc/ip*.rules[/code:1:09a0c3835f]
Across our system there are various files that no normal user should be able to view or access. Where the default permissions in my opinion are wrong. So lets quickly change some of these.
[code:1:09a0c3835f]($:~)=> chmod 600 /etc/crontab
($:~)=> chmod 700 /root
($:~)=> chmod 700 /home/*
($:~)=> chmod 650 /etc/rc.*
($:~)=> chmod 600 /etc/master.passwd[/code:1:09a0c3835f]
These are just a couple prime examples. Where there are many more files that you should change permissions to. Something to keep in mind though is each time you perform an install world some of the permissions change back to their original default values.
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 lets go ahead and edit it’s configuration file.
[code:1:09a0c3835f]($:~)=> vi /etc/ssh/sshd_config[/code:1:09a0c3835f]
The key lines to change or add are the following:
[code:1:09a0c3835f]Port 22
Protocol 2
PermitRootLogin no
X11Forwarding no
PrintMotd yes
PrintLastLog yes
KeepAlive yes
PermitEmptyPasswords no
PasswordAuthentication yes
ReverseMappingCheck no
GatewayPorts no
AllowTcpForwarding yes
AllowGroups ssh
Banner /etc/issue
MaxStartups 10[/code:1:09a0c3835f]
Now you notice that were only going to allow users login that are in the ssh group. Lets go ahead and create one.
[code:1:09a0c3835f]($:~)=> echo “ssh:*:666:soupx” >> /etc/group[/code:1:09a0c3835f]
Please remember to change soupx to your NORMAL user name. If you decide not to can you at least email me my password.
Now a good measure to take is to backup various system directories. Were 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.
[code:1:09a0c3835f]($:~)=> tar –cvvpzf /root/etc.tar.gz /etc
($:~)=> chmod 600 /root/etc.tar.gz[/code:1:09a0c3835f]
Now for an extra layer of protection lets encrypt that file.
[code:1:09a0c3835f]($:~)=> openssl enc –blowfish –in /root/etc.tar.gz –out /root/etc.tgz.bf[/code:1:09a0c3835f]
To unencrypt the file you would issue:
[code:1:09a0c3835f]($:~)=> openssl enc –d –blowfish < /root/etc.tgz.bf | tar –xzf –[/code:1:09a0c3835f]
Once encrypted go ahead and remove the etc.tar.gz file.
Onto further tweaking. Lets go back and edit the rc.conf file again.
Do not turn on RFC1323 extensions
[code:1:09a0c3835f]tcp_extensions="NO"[/code:1:09a0c3835f]
Disable probing of idle TCP connections to verify the peer is up and reachable
[code:1:09a0c3835f]tcp_keepalive="YES"[/code:1:09a0c3835f]
Do not respond to broadcast ping packets
[code:1:09a0c3835f]icmp_bmcastecho="NO"[/code:1:09a0c3835f]
ICMP error response bandwith limiting. Helps protect against DoS attacks.
[code:1:09a0c3835f]icmp_bandlim="YES"[/code:1:09a0c3835f]
And now jump back into the /etc/sysctl.conf file.
To defend against sequence number attacks based on rfc1948 by randomize initial sequence number
[code:1:09a0c3835f]net.inet.tcp.strict_rfc1948=1[/code:1:09a0c3835f]
To verify that an incoming packet arrives on an interface that has an address matching the packet's destination address
[code:1:09a0c3835f]net.inet.ip.check_interface=1[/code:1:09a0c3835f]
Increase TCP Window size for increase in network performance
[code:1:09a0c3835f]net.inet.tcp.recvspace=65535
net.inet.tcp.sendspace=65535[/code:1:09a0c3835f]
Change the ELF Branding fallback
[code:1:09a0c3835f]kern.fallback_elf_brand=3[/code:1:09a0c3835f]
Block SYN Cookies and other ICMP Stuff
[code:1:09a0c3835f]net.inet.tcp.syncookies=0
net.inet.icmp.bmcastecho=0
net.inet.icmp.maskrepl=0
net.inet.icmp.icmplim=200[/code:1:09a0c3835f]
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 various ways I might have configured certain parts of the operating system with out compromising security to the website. So this is my gift to the community that has greatly supported me though out the past years. And I hope that you enjoy reading this if not 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. I enjoy hearing people’s feedback or drop by IrC and say thanks. A lot of hard work goes into these articles. In which is in no way required by me. 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 in the operating system. Perhaps a little bit too much. The overall goal here is hopefully I can help somebody out from all the months of researching that I had to do. The goal of this document is to hopefully help you setup a secure server with Mail services configured for multiple domains. And various other services that a typical user uses. Basically I’m writing up this article to keep the flow of information going. I’m taking my best articles from my site and putting them into 1 massive document.
Why choose FreeBSD?
FreeBSD Is in my opinion a truly great operating system. Unlike its rivals Microsoft. (In which 2 images demonstrating their policy and practices can be seen below.) Is a fairly secure (not as secure as OpenBSD) and easy to manage operating system. 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 put in mind that the BSD distro's are mostly source based. From the packages you install to updating the operating system. And when your 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 your using pre-packaged binaries that just don’t suite my needs.
http://bsdhound.dnsalias.net:81/~soup4you2/doc/ATT06831.gif
So what’s up with the picture?
Well 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.
http://bsdhound.dnsalias.net:81/~soup4you2/doc/2.jpg
Here we see Mr. Billy Demonstrating Corporate Security Policy's
http://bsdhound.dnsalias.net:81/~soup4you2/doc/1.jpg
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. Now you can take advantage of this same power and scalability.
Now your 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 good leading humanitarian Bill Gates.
http://bsdhound.dnsalias.net:81/~soup4you2/doc/3.jpg
So if nothing else you should have learned what a monopolizing and cheating corporation Microsoft is and 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 a Operating system with the power and flexibility that you deserve. So now that fun time is over lets start with this article.
Requirements
* Good background knowledge of the FreeBSD operating system
* A lot of free time, with 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
What’s covered in this document?
* 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 you add service by service securing them as you go along. Normally speaking from experience if you skip steps as you go along or rush installing your services you often forget and leave things unattended that should be setup. 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 FreeBSD CD in the CD-ROM drive.
- Select “Standard” from the main menu.
- Select the size for the partition, for the database host, all off 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 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 setup 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, 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 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 default to not start with sshd and sendmail (unlike in medium) and it also set 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 the correct time zone.
- Answer NO to Linux Compatibility.
- When prompted for packages installation, answer NO. The packages in the CD may not be most 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 reboot.
First time configuration (Basic System Security Part 1)
Now that we have covered Installing FreeBSD Lets 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 your first boot into FreeBSD go ahead and login as the root User. Now lets find out what all ports are presently open on your system and close the unneeded ones. You can find this out by issuing the socket status command
[code:1:09a0c3835f]($:~)=> sockstat –4[/code:1:09a0c3835f]
You should see a list of all the current daemons that are in effect and what port they’re running off of.
Lets start off by working with sendmail. You should notice both ports 25 and 587 belong to sendmail. Well fist of all we can completely close port 587 and i have no idea to this day why that is open. We can do this by going in and editing the /etc/mail/sendmail.cf file
[code:1:09a0c3835f]($:~)=> vi /etc/mail/sendmail.cf[/code:1:09a0c3835f]
(Depending on your experience if you don't like vi you can use ee or something different)
now search for a line that states:
[code:1:09a0c3835f]O DaemonPortOptions=Port=587, Name=MSA, M=E[/code:1:09a0c3835f]
Once you find the line put a comment in front of it. Then save and close. Now execute:
[code:1:09a0c3835f]($:~)=> killall -HUP sendmail[/code:1:09a0c3835f]
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 email. If you're running FreeBSD 4.6-RELEASE or higher, put this line in /etc/rc.conf:
[code:1:09a0c3835f]sendmail_enable="NO"[/code:1:09a0c3835f]
This will tell sendmail to only listen on the localhost, which will allow any mail client to be able to send email. 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:
[code:1:09a0c3835f]sendmail_enable="NONE"[/code:1:09a0c3835f]
Which will close port 25 completely. To see if you've broken the ability to send email, make sure you've closed all of your terminals and saved all of your work. Then, as the superuser:
[code:1:09a0c3835f]($:~)=> shutdown now[/code:1:09a0c3835f]
Press enter when prompted, then type exit. Once you've logged back in, see if you can send a test message to your email 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 up 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):
[code:1:09a0c3835f]nfs_server_enable="NO"
nfs_client_enable="NO"
portmap_enable="NO"[/code:1:09a0c3835f]
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:
[code:1:09a0c3835f]syslogd_enable="YES"
syslogd_flags="-ss"[/code:1:09a0c3835f]
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:
[code:1:09a0c3835f]log_in_vain="YES"[/code:1:09a0c3835f]
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:
[code:1:09a0c3835f]accounting_enable="YES"[/code:1:09a0c3835f]
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:
[code:1:09a0c3835f]clear_tmp_enable="YES"[/code:1:09a0c3835f]
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:
[code:1:09a0c3835f]:passwd_format=blf:[/code:1:09a0c3835f]
Also add the following to set the password defaults. These changes will do 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.
[code:1:09a0c3835f]:passwordtime=90d:\
:mixpasswordcase=true:\
:minpasswordlen=10:\
:idletime=30:\[/code:1:09a0c3835f]
Save your change, and then rebuild the login database with this command:
[code:1:09a0c3835f]($:~)=> cap_mkdb /etc/login.conf[/code:1:09a0c3835f]
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:
[code:1:09a0c3835f]($:~)=> passwd username[/code:1:09a0c3835f]
As the superuser. Whatever username you use, that 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:
[code:1:09a0c3835f]($:~)=> more /etc/master.passwd[/code:1:09a0c3835f]
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:
[code:1:09a0c3835f]crypt_default=blf[/code:1:09a0c3835f]
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.
[code:1:09a0c3835f]
* * * * * * * * * * * * * * W A R N I N G * * * * * * * * * * * * * * *
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 * * * * * * * * * * * * * * *
[/code:1:09a0c3835f]
Next, to remove the copyright info:
[code:1:09a0c3835f]($:~)=> touch /etc/COPYRIGHT[/code:1:09a0c3835f]
Then to change the text that appears at the login prompt, edit /etc/gettytab. Find the line in the default: section that starts with
[code:1:09a0c3835f]:cb:ce:ck:lc[/code:1:09a0c3835f]
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?
login:
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:
[code:1:09a0c3835f]update_motd="NO"[/code:1:09a0c3835f]
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:
[code:1:09a0c3835f]console none unknown off secure[/code:1:09a0c3835f]
I like to completely remove the secure portion from this line. So what’s that do? Well 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.
Now that the basics are completed lets 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.
[code:1:09a0c3835f]($:~)=> vi /etc/group[/code:1:09a0c3835f]
and edit the first line (after the # comments) which starts with wheel,
[code:1:09a0c3835f]wheel:*:0:root becomes wheel:*:0:root,soupx[/code:1:09a0c3835f]
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, it 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.
[code:1:09a0c3835f]tcp_drop_synfin=”YES”[/code:1:09a0c3835f]
Tip: This option would break RFC compliance. Do not use this on a web server.
This should be added to rc.conf, this 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, 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 condition. If these packets are on the network, it should either be a network component error (maybe mis-configuration) 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 packet and to log them, add
[code:1:09a0c3835f]icmp_drop_redirect=”YES”
icmp_log_redirect=”YES”[/code:1:09a0c3835f]
In the rc.conf file.
In rc.conf configuration, “log_in_vain” option was selected to log all the abnormal connection. 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
[code:1:09a0c3835f]($:~)=> vi /etc/sysctl.conf[/code:1:09a0c3835f]
This file should only contain comments. After the comments, add the following lines
[code:1:09a0c3835f]net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1[/code:1:09a0c3835f]
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:
[code:1:09a0c3835f]security.bsd.see_other_uids=0[/code:1:09a0c3835f]
Please note if your running earlier than 5.2 the name changed. The old name is:
[code:1:09a0c3835f]kern.ps_shoallprocs=0[/code:1:09a0c3835f]
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
Now before we get into too much else lets 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 the securing the base OS, the database server should get 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.
Now there's a couple ways to get cvsup installed. And there's 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 later at a later time.
[code:1:09a0c3835f]($:~)=> pkg_add -r cvsup-without-gui[/code:1:09a0c3835f]
Now 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
[code:1:09a0c3835f]($:~)=> cd /usr/ports/net/cvsup-without-gui ; make install clean[/code:1:09a0c3835f]
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.
[code:1:09a0c3835f]($:~)=> /stand/sysinstall[/code:1:09a0c3835f]
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.
* Choose the 4th Option labeled Configure
* Choose the 2nd Option labeled Packages
* Choose the 1st Option labeled CD-ROM
Now pop in your FreeBSD cd1 in the cd-rom and select your cd-rom from the menu
Scroll on down to net and select cvsup, once your done installing cvsup we can continue to update our 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 our system.
[code:1:09a0c3835f]($:~)=> vi /root/cvs-supfile[/code:1:09a0c3835f]
Put this in it.
[code:1:09a0c3835f]
*default host=cvsup11.FreeBSD.org
*default base=/usr
*default prefix=/usr
*default release=cvs
*default delete use-rel-suffix
*default compress
src-all tag=RELENG_5_2
ports-all tag=.
[/code:1:09a0c3835f]
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.
[code:1:09a0c3835f]($:~)=> /usr/local/bin/cvsup /root/cvs-supfile[/code:1:09a0c3835f]
Building Your World
The source tree and ports tree will be synchronized with the FreeBSD distribution server.
So once your sources finished updating. Lets go ahead and compile and install them.
[code:1:09a0c3835f]($:~)=> cd /usr/src
($:~)=> make buildworld[/code:1:09a0c3835f]
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 lets go ahead and setup a kernel. But keep in mind over time I have come up with a rule that if your seeing double you probably should not be operating your server.
[code:1:09a0c3835f]($:~)=> cd /usr/src/sys/i386/conf
($:~)=> cp GENERIC KERNNAME (kernname is whatever you wish to call your kernel)
($:~)=> vi KERNNAME[/code:1:09a0c3835f]
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.
[code:1:09a0c3835f]options TCP_DROP_SYNFIN
options SC_DISABLE_DDBKEY
options SC_DISABLE_REBOOT
options CPU_ENABLE_SSE
options CPU_ATHLON_SSE_HACK
options IPSEC
options IPSTEALTH
options TCP_DROP_SYNFIN[/code:1:09a0c3835f]
Now we should also choose the type of firewall we would like to make our server use.
[code:1:09a0c3835f]options IPFILTER
options IPFILTER_LOG
options IPFILTER_DEFAULT_BLOCK[/code:1:09a0c3835f]
These options will enable the Packet Filtering Firewall (PF).
[code:1:09a0c3835f]options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_DEFAULT_TO_ACCEPT[/code:1:09a0c3835f]
Where as these options will enable the IPFW firewall (IP Firewall).
Another fun and interesting kernel option to add in is: (NOTE: this option below is for the 4x branch. It’s standard in 5x)
[code:1:09a0c3835f]pseudo-device snp 4[/code:1:09a0c3835f]
Now The 5x branch does not need this. But it must be specified in the 4x Branches. Also if your running the 4x branch some devices you need to create by hand. And snp would be one of them.
[code:1:09a0c3835f]($:~)=> cd /dev
($:~)=> ./MAKEDEV snp0
($:~)=> ./MAKEDEV snp1
($:~)=> ./MAKEDEV snp2
($:~)=> ./MAKEDEV snp3[/code:1:09a0c3835f]
So what does this allow me to do?
Well 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. 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 a 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.
[code:1:09a0c3835f]($:~)=> cd /usr/src
($:~)=> make buildkernel KERNCONF=KERNELNAME[/code:1:09a0c3835f]
Hopefully everything will go well there. The kernel is ready to be installed at this point. You can ultimately issue the command:
[code:1:09a0c3835f]($:~)=> echo “KERNELNAME” >> /etc/make.conf[/code:1:09a0c3835f]
This will make it so each time you build a new kernel you no longer have to specify the name for it as well as installing the kernel.
[code:1:09a0c3835f]($:~)=> make installkernel KERNCONF=MYKERNEL[/code:1:09a0c3835f]
This will install the kernel.
To activate the kernel, a reboot is necessary. As root user, type the command
[code:1:09a0c3835f]($:~)=> reboot[/code:1:09a0c3835f]
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 your 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,
[code:1:09a0c3835f]($:~)=> shutdown now[/code:1:09a0c3835f]
After the system gets into single user mode,
[code:1:09a0c3835f]($:~)=> cd /usr/src
($:~)=> make installworld[/code:1:09a0c3835f]
This will install all the updated binaries compiled from source downloaded by CVSup,
and the system is then ready to be rebooted.
[code:1:09a0c3835f]($:~)=> reboot[/code:1:09a0c3835f]
You might want to look around at various file permissions once your done. 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 in a bit though.
Now that you know how cvsup works it’s handy to setup a cron job to do this nightly. Anyhow this should get you on your feet.
[code:1:09a0c3835f]($:~)=> vi /etc/crontab[/code:1:09a0c3835f]
And add the following in there:
[code:1:09a0c3835f]0 3 * * * root /usr/local/bin/cvsup /usr/local/etc/ports-supfile 1>/dev/null 2>&1[/code:1:09a0c3835f]
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 were 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.
[code:1:09a0c3835f]($:~)=> chmod 700 /root[/code:1:09a0c3835f]
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 are easily exploited; they could easily lead to 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,
[code:1:09a0c3835f]($:~)=> find / -perm –4000[/code:1:09a0c3835f]
To find all sgid binaries on a machine,
[code:1:09a0c3835f]($:~)=> find / -perm –2000[/code:1:09a0c3835f]
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.
[code:1:09a0c3835f]($:~)=> cd /usr/local/src ; fetch http://www.watson.org/fbsd-hardening/suidcontrol-0.1.tgz
($:~)=> tar –xzvf suidcontrol-0.1.tgz
($:~)=> cd suidcontrol ; make[/code:1:09a0c3835f]
Now 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
Mounted drives.
Some local directory should never encounter certain type of files, such as suid. Such type 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,
[code:1:09a0c3835f]($:~)=> vi /etc/fstab
For /tmp’s option, change to rw,nosuid,noexec,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[/code:1:09a0c3835f]
Now 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.
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 done really need both these but certain services use /var/tmp for writing stuff to. So were going to delete the /var/tmp directory and create a symbolic link to /tmp
[code:1:09a0c3835f]($:~)=> cd /var && mv ./tmp/* /tmp/ && rm –rf tmp && ln –s /tmp tmp[/code:1:09a0c3835f]
Now other good security related aspects 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 were going to add a little bit of flavor to these files.
[code:1:09a0c3835f]($:~)=> chflags schg /bin/*
($:~)=> chflags schg /sbin/*
($:~)=> chflags schg /usr/sbin/*[/code:1:09a0c3835f]
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.
To prevent anyone from tampering with your kernel, set the schg flags on the kernel too: (Please remember doing this for when you update your kernel later on in life)
[code:1:09a0c3835f]($:~)=> chflags schg /kernel[/code:1:09a0c3835f]
The file /boot.config can be used to change kernel used at system bootup. To prevent this, do the following:
[code:1:09a0c3835f]($:~)=> touch /boot.config
($:~)=> chflags schg /boot.config[/code:1:09a0c3835f]
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).
[code:1:09a0c3835f]($:~)=> cd /var/log
($:~)=> chmod 600 *
($:~)=> chmod 640 wtmp[/code:1:09a0c3835f]
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.
[code:1:09a0c3835f]($:~)=> touch /etc/ipf.rules
($:~)=> touch /etc/ipnat.rules
($:~)=> chmod 600 /etc/ip*.rules[/code:1:09a0c3835f]
Across our system there are various files that no normal user should be able to view or access. Where the default permissions in my opinion are wrong. So lets quickly change some of these.
[code:1:09a0c3835f]($:~)=> chmod 600 /etc/crontab
($:~)=> chmod 700 /root
($:~)=> chmod 700 /home/*
($:~)=> chmod 650 /etc/rc.*
($:~)=> chmod 600 /etc/master.passwd[/code:1:09a0c3835f]
These are just a couple prime examples. Where there are many more files that you should change permissions to. Something to keep in mind though is each time you perform an install world some of the permissions change back to their original default values.
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 lets go ahead and edit it’s configuration file.
[code:1:09a0c3835f]($:~)=> vi /etc/ssh/sshd_config[/code:1:09a0c3835f]
The key lines to change or add are the following:
[code:1:09a0c3835f]Port 22
Protocol 2
PermitRootLogin no
X11Forwarding no
PrintMotd yes
PrintLastLog yes
KeepAlive yes
PermitEmptyPasswords no
PasswordAuthentication yes
ReverseMappingCheck no
GatewayPorts no
AllowTcpForwarding yes
AllowGroups ssh
Banner /etc/issue
MaxStartups 10[/code:1:09a0c3835f]
Now you notice that were only going to allow users login that are in the ssh group. Lets go ahead and create one.
[code:1:09a0c3835f]($:~)=> echo “ssh:*:666:soupx” >> /etc/group[/code:1:09a0c3835f]
Please remember to change soupx to your NORMAL user name. If you decide not to can you at least email me my password.
Now a good measure to take is to backup various system directories. Were 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.
[code:1:09a0c3835f]($:~)=> tar –cvvpzf /root/etc.tar.gz /etc
($:~)=> chmod 600 /root/etc.tar.gz[/code:1:09a0c3835f]
Now for an extra layer of protection lets encrypt that file.
[code:1:09a0c3835f]($:~)=> openssl enc –blowfish –in /root/etc.tar.gz –out /root/etc.tgz.bf[/code:1:09a0c3835f]
To unencrypt the file you would issue:
[code:1:09a0c3835f]($:~)=> openssl enc –d –blowfish < /root/etc.tgz.bf | tar –xzf –[/code:1:09a0c3835f]
Once encrypted go ahead and remove the etc.tar.gz file.
Onto further tweaking. Lets go back and edit the rc.conf file again.
Do not turn on RFC1323 extensions
[code:1:09a0c3835f]tcp_extensions="NO"[/code:1:09a0c3835f]
Disable probing of idle TCP connections to verify the peer is up and reachable
[code:1:09a0c3835f]tcp_keepalive="YES"[/code:1:09a0c3835f]
Do not respond to broadcast ping packets
[code:1:09a0c3835f]icmp_bmcastecho="NO"[/code:1:09a0c3835f]
ICMP error response bandwith limiting. Helps protect against DoS attacks.
[code:1:09a0c3835f]icmp_bandlim="YES"[/code:1:09a0c3835f]
And now jump back into the /etc/sysctl.conf file.
To defend against sequence number attacks based on rfc1948 by randomize initial sequence number
[code:1:09a0c3835f]net.inet.tcp.strict_rfc1948=1[/code:1:09a0c3835f]
To verify that an incoming packet arrives on an interface that has an address matching the packet's destination address
[code:1:09a0c3835f]net.inet.ip.check_interface=1[/code:1:09a0c3835f]
Increase TCP Window size for increase in network performance
[code:1:09a0c3835f]net.inet.tcp.recvspace=65535
net.inet.tcp.sendspace=65535[/code:1:09a0c3835f]
Change the ELF Branding fallback
[code:1:09a0c3835f]kern.fallback_elf_brand=3[/code:1:09a0c3835f]
Block SYN Cookies and other ICMP Stuff
[code:1:09a0c3835f]net.inet.tcp.syncookies=0
net.inet.icmp.bmcastecho=0
net.inet.icmp.maskrepl=0
net.inet.icmp.icmplim=200[/code:1:09a0c3835f]