Dec 04 2003, 10:25 (UTC+0) syncro writes: This paper results like many other papers on the Internet. In this article we wish to make a FreeBSD machine configured as well as possible to resist all kinds of threats. It is kind of a compilation of knowledge, which we need. Security is a process not a product; this is why we try in this document to approach a broad panel of subjects and uses. We will be basing this paper on the 4.x-Stable FreeBSD branch. This paper will also be split up into several sections, which will be posted throughout the next couple weeks. I'm also taking into consideration you are very familiar with the FreeBSD operating system.
The topics we will be covering are in today▓s paper are:
1. Intro 1.1. Services 1.2. CVSup 1.3. Updating your system
1. Intro
I'm hoping by now you have successfully installed FreeBSD correctly, and that you have arrived to a stable connection to the Internet. If you have not I suggest doing a search on on how to overcome your obstacles. In this chapter we will concentrate on the basic system configuration of FreeBSD, the first measures in which you will apply from a point of view of safety.
1.1. Services
Inetd service is super a daemon which makes it possible to launch several network services as well as part of their configuration like ftpd, smptd or telnetd. The file of configuration for inetd is preserved in /etc/inetd.conf. Here is an extract:
In general, one places a comment ('#') in front of the line on the services we do not wish to load. If we do not wish to run any of these services inetd may be disabled though your rc.conf. If you wish to disable inetd you also give up the option for TCP Wrappers used by default in FreeBSD. Normally our first step is to determine what services are listening on a port. There's 2 good ways to do this, by using either netstat or the sockstat utility, both part of the base FreeBSD installation.
($:~)=> netstat -a | grep 'listen'
Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp4 0 0 *:ssh *:* LISTEN tcp4 0 0 *:ftp *:* LISTEN tcp4 0 0 *:smtp *:* LISTEN udp4 0 0 *:portmap *:* LISTEN
Or my personal favorite is the sockstat command
($:~)=> sockstat -46
The -46 Tells sockstat to display open sockets on both IPv4 and IPv6 network stacks.
As you see we probably do not want all of these services. But if your machine is going to become a waiter with multiple services, I recommend that you follow our solution. In short, all the network services you wish to use in the future will turn in the shape of a stand alone daemon, by doing it this way it lets the daemons increase safety but also simplifying the configuration and the speed of response of the services by eliminating the inetd service. To make sure that inetd does not launch on the next boot we add 1 simple line to our /etc/rc.conf file.
($:~)=> vi /etc/rc.conf
inetd_enable="NO"
If you wish to use the inetd service you would use a line similar to this:
inetd_enable="YES" inetd_flags="-WW"
With inetd set to YES it will be launched upon every boot up. The options -Ww tells inetd to carry out the capacity of filtering of the internal services and external TCP via TCP Wrappers, which we will not be using in the course of this article. So go ahead and set inetd_enable="NO" and comment out the inetd_flags line. Next we also want to disable the portmapper service. Portmapper is an extremely practical tool within the framework of services such as RPC and NFS. But it also presents a incalculable number of vulnerabilities. So while still inside the rc.conf file we add the following line:
portmap_enable="NO"
Now we should probably kill the current inetd service running. By adding the line to the rc.conf we tell the system that we don▓t want to load it upon startups, but it does not tell it to kill the current running process.
($:~)=> killall inetd
NOTE: It is very important to know that your rc.conf file is used to configure the programs or scripts and starting daemons upon startup of your system.
1.2 CVSup
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.
($:~)=> pkg_add -r cvsup-without-gui
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
($:~)=> cd /usr/ports/net/cvsup-without-gui ; make install clean
So now we go onto method 3 of how to install this.
($:~)=> /stand/sysinstall
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. A configuration file provided at run time controls all of these. 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.
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.
Branch CVS Tags
A revision tag refers to either a particular line of FreeBSD development, or a specific point in time. The first type are called ``branch tags'', the second type are called ``release tags''.
Branch Tags:
RELENG_5_1 - The release branch for FreeBSD-5.1, used only for security advisories and other seriously critical fixes.
Other branch tags would be: RELENG_5_0, RELENG_4, RELENG_4_9, RELENG_4_8, RELENG_4_7, RELENG_4_6, RELENG_4_5, RELENG_4_4, RELENG_4_3, RELENG_3, RELENG_2_2, etc..
Release Tags
These tags correspond to the FreeBSD src/ tree (and ports/, doc/, and www/ trees) at a specific point in time, when a particular version of FreeBSD was released.
RELENG_4_9_0_RELEASE - FreeBSD 4.9
Other release tags would be: RELENG_5_1_0_RELEASE, RELENG_4_8_0_RELEASE, RELENG_5_0_0_RELEASE, RELENG_4_7_0_RELEASE, RELENG_4_6_2_RELEASE,
RELENG_4_6_1_RELEASE, etc.
Refusing Ports and souces and docs.
The refuse file essentially tells CVSup that it should not take every single file from a collection; in other words, it tells
the client to refuse certain files from the server. The refuse file can be found (or, if you do not yet have one, should be placed) in base/sup/. Base is defined in your supfile; by default, base is /usr/local/etc/cvsup, which means that by default the refuse file is /usr/local/etc/cvsup/sup/refuse. So if you used the cvsup above the refuse file should be held in /usr/sup/refuse. The refuse file has a very simple format; it simply contains the names of files or directories that you do not wish to download. For example, if you cannot speak any languages other than English and some German, and you do not feel the need to use the German applications (or applications for any other languages, except for English), you can put the following in your
NO_FORTRAN= true # do not build g77 and related libraries NO_I4B= true # do not build isdn4bsd package NO_IPFILTER= true # do not build IP Filter package NO_KERBEROS= true # do not build and install Kerberos 5 (KTH Heimdal) NO_OBJC= true # do not build Objective C support NO_SENDMAIL= true # do not build sendmail and related programs NOGAMES= true # do not build games (games/ subdir)
COMPAT1X= no COMPAT20= yes COMPAT21= yes COMPAT22= yes COMPAT3X= yes
You may also refer to /etc/default/make.conf for other options you may wish to pass. Now with those variables in place lets test it out and update our sources and ports tree.
($:~)=> cd /usr/src && make update
1.3. Updating your system
We harness ourselves now with the configuration and the compilation of the kernel. For the later configurations and optimal performances, we recommend to you to select the following options in your file of configuration kernel located in the repertory /sys/i386/conf. In order to always be able to retrogress with a functional configuration, we will publish a copy of GENERIC, from which we will compile.
($:~)=> cd /usr/src/sys/i386/conf ($:~)=> cp GENERIC NEWKERN ($:~)=> vi NEWKERN
Here are some good options to add into the kernel we will be building:
pseudo-device snp 4 # high because of Nessus pseudo-device bpf 20 # high because of IPSec pseudo-device gif 10 pseudo-device faith 1 pseudo-device stf 1
In the order listed above we are selecting support for IPv6, IPv6, IPSEC and ESP. Then we activate the support for IPFW (Which you can decide if you wish to use IPFilter or PF instead) with the sending of messages to syslog limited to 30 times for the same event. Forwarding is also activated as well as the hidden forwarding (passing a package without decreasing it's TTL), just like the diver sockets making it possible to modify the transit of a package in the kernel. And finally support of dummynet, the basic traffic shaper of the system. we activate then accept the filters which accelerates the process of admission of certain types of connections (like HTTP) by placing them directly in the kernel.
After that, we activate the troop of nodes of the NetGraph subsystem which allows complex handling the network level using nodes inheriting the characteristics of their type (hooks possible, treatment of the traffic to each hook, interpretation of the messages of control...) which can be chained through hooks to constitute a continuation of edges: a graph. More information and descriptions of the nodes in the manpage netgraph(4).
We connect with some safety measures network, initially, like the rejection of certain forged packages (SYN/FIN) allowing the OS recognition, the limitation, via sysctl, of emission of packages ICMP in order not to be used as reflector at the time of a Back, and the random generation of IP ID to reduce the scanning appropriateness▓s. Then physical safety with the deactivation of the sequences keyboard of debugging and restarting, as well as the deactivation of the back scrolling for the virtual terminals. Lastly, safety system with the deactivation of the LKM; and even of the KLD if you apply the patch according to .http://people.freebsd.org/~cjc/kld_stable.patch.
Following the activation of the disc quotas, code of Linux compatibility via the emulation of certain system calls and the debugger kernel DDB. We check also the activation of SoftUpdates, method of writing and asynchronous reading solving the problems involved in the metadata and to their loss. The approach of Linux is the journalizing (concept inherited the data base), which consists in writing the updates of metadata with their dependences in a part distinct from the filing system: the newspaper. When the metadata is ready, they are actually written. The filing system of FreeBSD named UFS uses an approach different (inspired by CVS) in which the operations from writing or reading are placed in a queue divided into a buffer of waiting and a buffer of checking of the dependences. If a block belongs to a loop of dependences, it is rejected into the buffer of waiting. This approach will allow moreover in the future of the restarting following a crash with an fsck functioning in background task. Always on the level system, you will appreciate the device polling allowing improving the performances kernel by limiting the interruptions and thus the context switch and the call to a manager of interruption.
NOTE: finally that the numbers maximum of users is placed at 0 so that it is calculated at the time of the boot according to the physical memory available. These variables as well as the number of clusters of the filing system are used to calculate the allowance of unquestionable resources memory. The frequency of clock is then placed at 1000 Hz to increase the accuracy of the device polling (and also to limit the burst if you use ALTQ). Come finally the pseudo-devices snoop and bpf for the respective monitoring from the tty and the Ethernet screens, and GIF, faith and stf for the tunneling v6/v4.
Certain options will be already present; we do nothing but check them. You can also safely to put in comment the support procfs and NFS, which can create possible vulnerabilities in the system. To examine the whole of the kernel options available, refer to file LINT in same the directory as GENERIC.
By the sequence of following orders, we build successively kernel NEWKERN then install we it and finally let us protect by using the flags immutables while cleaning the system from the files generated by the install.
($:~)=> cd /usr/obj ; chflags -R noschg * ; rm -rf * ($:~)=> cd /usr/src ($:~)=> make cleandir ; make cleandir ($:~)=> make buildworld ($:~)=> make buildkernel KERNCONF=NEWKERN ($:~)=> make installkernel KERNCONF=NEWKERN ($:~)=> make installworld
We apply a script mergemaster, very practical since it carries out a comparison between the old files of configuration and those by defect of the installation. All that in order to update the configuration of the new system and to avoid us starting again a tiresome work.
