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]

soup4you2
August 21st, 2003, 13:36
Unix File Permissions

How to place control over users

One aspect of a Unix system security is putting control on users. There are several different types of controls that can be used, including file permissions, file attributes, file system quotas, and system resource limits.

File Permissions

Unix file permissions are a way to allow a user to restrict access to a file or directory on the file system. For files a user can specify who can read the file who can write to the file and who can execute the file. For directories a user can specify who can read the directory, who can write to the directory and who can execute programs located in the directory.


Files

Lets look at a simple example of a file.

[code:1:ae38ddb6aa]($:~)=> ls -a example.txt
-rw-rw-r-- 1 soup4you2 soup4you2 852B Feb 22 00:26 example.txt[/code:1:ae38ddb6aa]

Here we execute ls -l The ls command lists the contents of the directory, or in the case, only the file example.txt the -l option lists the file in long form, which displays quite a bit of information about the file. The output lists the following info:

[code:1:ae38ddb6aa]-rw-rw-r-- 1 soup4you2 soupx 852B Feb 22 00:26 note.txt[/code:1:ae38ddb6aa]

Here's a breakdown of what’s being displayed here:

[code:1:ae38ddb6aa]-rw-rw-r-- Permissions

1 Number of links

soup4you2 File Owner

soupx Group

852B File size

Feb 22 00:26 Date last modified

example.txt Filename[/code:1:ae38ddb6aa]

Notice that this file has one owner (soup4you2) and belongs to one group (users) the owner and group are important when we discuss file permissions.

The file permissions are as follows:

-rw-rw-r--

The information is divided into four parts

[code:1:ae38ddb6aa]
- rw- rw- r--
File Type, Owner Permissions, Group Permissions, World Permissions
[/code:1:ae38ddb6aa]

The first part of the output is the file type. Common file types are as follows:

[code:1:ae38ddb6aa]
- A Normal File
d A Directory
l A Symbolic link
s A Socket
[/code:1:ae38ddb6aa]

Following the file type are three groups of these characters representing the permissions for the owner group and world. Three characters indicate weather or not permissions is granted to read the file (r), write to the file (w) or execute the file (x). If permissions is granted the letter is present. If permissions is denied the letter is well you guessed it sparky not there and an (-) in it's place. Here's another example

rwxr-x--x

The first three characters are the permissions for the owner. The permissions rwx indicate that the owner can read the file, write to the file and execute the file. The next three characters are the permissions for the group associated with the file. The next three characters are the permissions for the group associated with the file. The permissions r-x indicates that members of the group can read the file and execute the file but cannot write to the file. The last three characters are the permissions for the rest of the world. Cannot read the file and cannot write to the file but can execute the file. Getting this yet. It only gets more fun from here.

Take notice that the three permissions are either granted or denied, either on or off (I’ve got to get specific.. you might be a slobbering drunk who needs all the help they can). Since the permissions can be considered either on or off the permissions can be thought of as collection of 0s or 1s. For instance "rwx" has read, write and execute permissions on. Therefore we can write these permissions as "111" and in octal format the value as 7. Similarly "r-x" has read permissions and execute permissions on and write off. Therefore we can write these permissions as 101 and in octal format the value 5.

If we put this idea in practice for owner/group/world permissions. Then the permissions rwxr-x--x in binary format are 111101001 and if we treat this as a series of three groups of octal numbers the value is 750

Confused yet? Let me try to clarify just a little bit here.

Read Permissions you should give a value of 4
Write Permissions you should give a value of 2
Execute Permissions you should give a value of 1

So if you want read+execute permissions you add 4 + 1 and get 5 you do this for each of the 3 parts user/group/other

U = User G = Group O = Other (not U or G)

Triplet for u: rwx => 4 + 2 + 1 = 7
Triplet for g: r-x => 4 + 0 + 1 = 5
Tripler for o: r-x => 4 + 0 + 1 = 5
Which makes : 755

-U- --G-- --O--
-rwxr-xr-x 1 nick users 382 Jan 19 11:49
-drwxr-xr-x 3 nick users 1024 Jan 19 11:19 lib/
-rwxr-xr-x 1 nick users 1874 Jan 19 10:23 socktest.pl

Everything goes by 4 2 1

Changing File Permissions

The chmod command changes file permissions you would use it like such:

chmod mode file [file ...]

To see how to use chmod lets look at a file laying around.

[code:1:ae38ddb6aa]($:~)=> ls -l a.txt
-rw-rw-r-- 1 soupx users 10 Mar 03 06:50 a.txt[/code:1:ae38ddb6aa]

To change the permissions to an explicit mode use the octal method

[code:1:ae38ddb6aa]($:~)=> chmod 751 a.txt
($:~)=> ls -l a.txt
-rwx--x--x 1 soupx users 10 Mar 03 06:50 a.txt[/code:1:ae38ddb6aa]

Do you see how the permissions 751 translated into rwxr-x-x. And look at this if your feeling saucy enough.

[code:1:ae38ddb6aa]($:~)=> chmod 640 a.txt
($:~)=> ls -l a.txt
-rw-r----- 1 soupx users 10 Mar 03 06:50 a.txt[/code:1:ae38ddb6aa]

Here 640 translates to rw-r----- You can also use the chmod command in symbolic mode as follows. Even though I don’t care too much for this way.

[code:1:ae38ddb6aa]($:~)=> chmod +x a.txt
($:~)=> ls -l a.txt
-rwxr-x--x 1 soupx users 10 Mar 03 06:50 a.txt[/code:1:ae38ddb6aa]

Here chmod is used with +x which means to add executable permissions where the + character is used. It means to add the permissions where as - character means to remove. Here +x means to add executable permissions for the owner group and world. The chmod command can also be used to change permissions for a specific group:

[code:1:ae38ddb6aa]($:~)=> chmod g-r a.txt
($:~)=> ls -l a.txt
-rwx--x--x 1 soupx users 10 Mar 03 06:50 a.txt[/code:1:ae38ddb6aa]

This shows chmod being executed with g-r which means "remove group executable permissions" Are you getting tired of my bad spelling yet or have you drank enough to where you just don’t care anymore?

Sticky Bits

If a user has write permissions to a directory that user can delete files and directories within it, even if those files are not owned by the user and permissions are set sot that the user cannot read or write the file:

[code:1:ae38ddb6aa]($:~)=> ls -ld temp
($:~)=> ls -l a.txt
drwxrwxrwx 1 soupx users 10 Mar 03 06:50 temp[/code:1:ae38ddb6aa]

We see here that the temp directory is owned by soupx yet write able by the world. This is bad because somebody else not in the group or owner can delete the file even though they cannot see it. Well I’m a few beers into this so I’m going to skip right along to our next topic.

Default Permissions and Umask

When a user creates a file or directory that file or directory is given default permissions:

[code:1:ae38ddb6aa]($:~)=> touch a.txt
($:~)=> mkdir testdir
($:~)=> ls -l
total 1
-rw-rw-r-- 1 soupx users 10 Mar 03 06:50 a.txt
drwxrwxr-x 1 soupx users 10 Mar 03 06:50 testdir[/code:1:ae38ddb6aa]

Notice that the default permissions for the user soupx are 644 fir files and 775 for directories. Default file and directory permissions are set accordingly to the value of the users umask value. The umask value is due to mask off bits from the most permissive default values 666 for files and 777 for directories. To display your umask just type in umask

[code:1:ae38ddb6aa]($:~)=> umask
002[/code:1:ae38ddb6aa]

The user soupx has a umask value of 002. A simple way to determine the value of soupx's default permissions when soupx creates a file or directory to simple subtract the value of umask from the system default permission values.

[code:1:ae38ddb6aa]
Files: Directories
666 777
002 002
664 775
[/code:1:ae38ddb6aa]

To change your default permission change your umask value to create the most restrictive permission use a value of 777 which would give out the equivalent of 000 permissions. Of course this is too restrictive since soupx does not have read and write permissions for new files (pretty shitty ehh?) To create files and directories with the most practical restrictive permissions use a umask value of 077 which will grant read/write/execute for the owner but nothing for the group or world. So it would retain file permissions values of 700. If you wish to change your umask value permently add it in your users login profile.

The easiest way to figure out what umask to use is to take the octal number and subtract it from 777. So, if you wanted all new files to be created in your directory as 754 , subtract that from 777, 777-754=023.

A default mode of 755 would be 777-755 = 022. This is the default umask on most systems as far as I know.

File and directory Flags

The chflags utility comes in very handy when dealing with system security. This utility will place various restrictions on a file overtop of their permission values.

Flags are a comma-separated list of keywords that are defined as:

sappnd - set the system append-only flag (superuser only)
This is the system append-only flag. And can only be set and removed by the root user. Files with this flag can be added to but cannot be removed or otherwise edited, a particularly useful feature for log files. Setting sappnd on a .history file can be interesting in the event of a system compromise. A popular script kiddie trick is to remove .hostory or link it to /dev/urandom so that the sysadmin cannot see what was done, but sappnd prevents this tactic from working without changing any file system permissions on the .history file itself. This flag cannot be removed when the system is at securelevel 1 or higher.

schg - set the system immutable flag (superuser only)
The system-level immutable flag can only be set or removed by root. Files with this flag set cannot be changed in any way, not edited, not moved, and not replaced. Basically the kernel will prevent all attempts to touch this file in any way. This flag cannot be removed when the system is running at securelevel 1 or grater.

uappnd - set the user append-only flag (owner or superuser only)
Only the file owner or root can set the user append-only flag. Like the system append-only flag, sappnd, a file with this flag set can be added to but not otherwise edited or removed. This is most useful for logs from personal programs and the like and is primarily a means users can employ to prevent vital files from accidentaly removal. The user or root may perform this flag at any time.

uchg - set the user immutable flag (owner or superuser only)
Only the owner or root can set the users immutable flag. Like the schg flag, the user immutable flag prevents a user from changing the file. Again, root can override this, and the user at any securelevel can remove it

An immutable file may not be changed, moved, or deleted. An append-only file is immutable except that data may be appended to it. Putting the letters ``no'' before a flag name causes the flag to be turned off. For example:

nouchg the immutable bit should be cleared.

The superuser-settable ``sappnd'' and ``schg'' flags can be set at any time, but may only be cleared when the system is running at security level 0 or -1 (insecure or permanently insecure mode, respectively). The securelevel is normally set to 0, for example, when running in single-user mode.

Symbolic links do not have flags, so unless the -H or -L option is set, chflags on a symbolic link always succeeds and has no effect. The -H, -L, and -P options are ignored unless the -R option is specified. In addition, these options override each other and the command's actions are determined by the last one specified.

Only the superuser can change the user flags on block and character de-vices. You can use ls -lo to see the flags of existing files. These are just a couple of the flags available i recommend reading man chflags more a list of possible flags and their meanings.

The information about chflags was taken from the chflags manpage. And other absolute OpenBSD

Installing and configuring Mail services

If you are after one badass secure mail server then this section is for you. Sendmail is installed by default on FreeBSD systems and unless configured properly it is extremely insecure. So what I’m going to attempt here is setting up:

* Postfix With Qmail Maildir support
* Courrier IMAP / POP3 with IMAP and POP though SSL
* Procmail
* Spamassasin
* Amavis Virus scanning
* Virtual domain support

I will go into configuring most of these. But some of these you’re going to have to do a bit of tweaking and playing around.

Installing and Configuring Postfix

Lets start off by installing our new mail server postfix, Use the ports luke.

[code:1:ae38ddb6aa]($:~)=> cd /usr/ports/mail/postfix
($:~)=> make install clean[/code:1:ae38ddb6aa]

Now to avoid any confusion with other applications that use postfix were going to make a quick symbolic link.

[code:1:ae38ddb6aa]($:~)=> ln -s /usr/local/etc/postfix /etc/postfix[/code:1:ae38ddb6aa]

Now lets configure this puppy. Thanks to elmore at screamingelectron.org for providing the configuration we will be using here. Lets start off by going into your postfix directory and editing main.cf with your favorite editor.

[code:1:ae38ddb6aa]($:~)=> vi main.cf[/code:1:ae38ddb6aa]

The first thing you're going to modify is the following line:

[code:1:ae38ddb6aa]"myhostname = your.servername.here"[/code:1:ae38ddb6aa]

This line will set the mail server host name of your box. This cannot be any arbitrary name; it MUST be a fully qualified domain name!!

The next line to modify is:

[code:1:ae38ddb6aa]"mydomain = some.domain.name"[/code:1:ae38ddb6aa]

Again this sets the default domain of the box, this must be a Fully Qualified Domain Name Here!

The next line to look at is the following line:

[code:1:ae38ddb6aa]"myorigin = $mydomain"[/code:1:ae38ddb6aa]

Make sure this variable is set correctly! "$mydomain" is a valid global variable for the file so you should be good with that!

The next line to modify is the following:

[code:1:ae38ddb6aa]"mydestination = $myhostname, localhost.$mydomain $mydomain virtualdomain1 virtual domain2"[/code:1:ae38ddb6aa]

Obviously this example assumes you'll be setting up virtual domains, It also assumes you'll be setting up sendmail style virtual domains, now I know the file says use the virtual file instead I don't do that, I specify here, sendmail style, you may not want to do that that's fine with me just understand in this how-to we'll be setting up sendmail style virtual domains.

Moving On, the next line I modify is the following:

[code:1:ae38ddb6aa]"home_mailbox = Maildir/"[/code:1:ae38ddb6aa]

DO NOT uncomment this line if you do not intend to use imap. If you are using pop or traditional /var/mail spool to deliver mail this is not needed and will undoubtedly mess up your mail delivery. If you are using courier-imap this line needs to be uncommented!

Moving right along the next line I modify is the:

[code:1:ae38ddb6aa]"relay_domains = $mydestination, 127.0.0.1"[/code:1:ae38ddb6aa]

This will only allow messages to be accepted where the final destination domain is on this box. It also allows delivery over the loopback interface!

Now, modify the following:

[code:1:ae38ddb6aa]"mynetworks = xxx.xxx.xxx.xxx/zz, 127.0.0.1"[/code:1:ae38ddb6aa]

This only allows mail to be sent out to the Internet from the specified ips! This can be an entire subnet or just one box you decide.

This brings us to the next lines to modify:

[code:1:ae38ddb6aa]"local_destination_concurrency_limit = 2"
"default_destination_concurrency_limit = 10"[/code:1:ae38ddb6aa]

These lines limit the amount of concurrent connections to a domain. Good to have especially if you have a user that is forwarding mail out of his home via the use of a .forward file.

The next lines I actually insert into the file. They are for the canonical maps, you'll need these if the following is true:

You have virtual domains
You have virtual usernames like full.name@somehost.com mapped back to username@somehost.com
If you’re using one of the above add it in, if not don't worry about it!

[code:1:ae38ddb6aa]"sender_canonical_maps = hash:/etc/postfix/canonical"
"recipient_canonical_maps = hash:/etc/postfix/canonical-receive"[/code:1:ae38ddb6aa]

We'll be going over canonical tables in more depth in a little while. For now what you need to know is that on table modifies the incoming mail and one will modify outgoing mail.

The following lines I also add, you may or may not want to add these, It depends on how true you want to be to to the rfc and how strict you want to be on other hosts trying to send mail to you! These lines will lay down the framework for cutting down on your spam!

[code:1:ae38ddb6aa]smtpd_client_restrictions = reject_rbl_client, check_client_access hash:/etc/postfix/client_access, reject_unauth_pipelining

smtpd_recipient_restrictions = regexp:/etc/postfix/regexp_access, check_recipient_access hash:/etc/postfix/access, permit_mynetworks,reject_unknown_recipient_domain, reject_unknown_hostname, reject_rbl_client, reject_unauth_pipelining, reject

smtpd_sender_restrictions = regexp:/etc/postfix/sender_checks.regexp, check_sender_access hash:/etc/postfix/sender_access, reject_unknown_sender_domain, reject_non_fqdn_sender, reject_rbl_client, reject_unauth_pipelining[/code:1:ae38ddb6aa]

(That should be 3 lines, thought i would mention that so avoid future frustrations)

Ok the first section specifies rejection if a client is not in an access list an access list is a list I use which details the exact usernames on the box. This list is a necessity if you are running virtual domains, if you don't use it userid1@virtualdomain1 can receive an e-mail to userid1@virtualdomain2 and so on and so forth. This is the most efficient way I know to block this! It is also a good practice to do even if you aren't running virtual domains (opinion). It also specifies a lookup to the rbl list! A real time black hole list for open-relay mail servers It also does not allow unauthorized pipelining, not exactly sure why that's needed but it is. If you know, let me know!

The second section does much of the same but is it for outside connections. People trying to send mail in. It specifies a regular expression file which sorts through the headers and look for junk, the access list, it rejects mail from computers that don’t have a fqdn it also reject is it can't get the computer hostname through nslookup, it also rejects via the rbl list and the pipelining again!

Ok the next section is a lot more of the same. Nothing really new to explain here!

The next line I add is my rbl line, defining what list to use. I personally use the ordb list it can be found at http://ordb.org I like it a lot and it's free!

[code:1:ae38ddb6aa]"maps_rbl_domains = relays.ordb.org"[/code:1:ae38ddb6aa]

The next things added are the following body and header checks. They specify lookup files to run against all incoming and outgoing messages!

[code:1:ae38ddb6aa]"header_checks = regexp:/etc/postfix/header_checks"
"body_checks = regexp:/etc/postfix/body_checks"[/code:1:ae38ddb6aa]

The final things I add are a couple of reject codes and a message size limit self-explanatory, here they are!

[code:1:ae38ddb6aa]"unknown_hostname_reject_code = 554"
"unknown_client_reject_code = 450"
"message_size_limit = 5000000"[/code:1:ae38ddb6aa]

Now after the SMTP helo is sent, the client needs to tell Postfix who the e-mail is from (MAIL FROM) and where to sent to (RCPT TO). This communication is supposed to follow RFC-821. Some spam software is not strict about its conformance, we can block spam based on this fact.

[code:1:ae38ddb6aa]strict_rfc821_envelopes = yes[/code:1:ae38ddb6aa]

With this done, we are now through with the main.cf file. Save it and let's move on with our next section configuring the rest of postfix! A keynote here once you finish editing files you need to cap it. Don’t forget to do this whenever you edit your postfix configuration files.

[code:1:ae38ddb6aa]($:~)=> postmap main.cf[/code:1:ae38ddb6aa]

The Access file

This file is the definitive list as that decides who to accept incoming mail from the internet for. If you defined it earlier in the main.cf file it must be defined here. Basic syntax is one user per line followed by an OK so edit /etc/postfix/access now

[code:1:ae38ddb6aa]"userid1@domain1 OK"
"userid2@domain1 OK"
"userid3@domain2 OK"[/code:1:ae38ddb6aa]

etc. etc. Now for a little postfix sorcery, don't specify an account if you don't want them to have the ability to receive internet mail for instance, if you only want the ability for someone to mail local accounts (accounts only contained on your box, leave them out of here) Also, if you are running lots of Virtual domains, you may want to specify system account for each domain, like:

[code:1:ae38ddb6aa]"webmaster@domain1 OK"
"webmaster@domain2 OK"
"postmaster@domain1 OK"
"postmaster@domain2 OK"[/code:1:ae38ddb6aa]

Remember if the specific e-mail you want to receive mail from is not listed in this file it will bounce. Once you've entered in all your info save that file. From here you must make that file into a hashed db, also after any updates you make to this file in the future you must recompile that hashed db to include your new accounts. Do this by typing the following:

[code:1:ae38ddb6aa]($:~)=> postmap access[/code:1:ae38ddb6aa]

Also to avoid any delay you should always reload postfix, don't do that now because we haven’t turned postfix on yet! It can be done like this:

[code:1:ae38ddb6aa]($:~)=> postfix reload[/code:1:ae38ddb6aa]

CANONICAL FILES

The next files we'll look at are, /etc/postfix/canonical and /etc/postfix/canonical-receive. Again, if you're not using canonical tables specified in your main.cf file, you don't need to worry about it here.

canonical

The canonical file as defined in this how-to will remap a users e-mail from the default domain to the appropriate virtual domain, if this is the case you need to specify all users except those in the default domain of the box here! Also if you are mapping a local account to use another name eg. userid1 -> full.name you need to specify that here. Syntax is: userid@domain userid@virtualdomain, or, userid@domain full.name@domain this file handles mail outgoing only! edit /etc/postfix/canonical now

[code:1:ae38ddb6aa]"userid@defaultdomain userid@virtualdomain"
"userid2@defaultdomain userid2@virtualdomain"[/code:1:ae38ddb6aa]

Or

[code:1:ae38ddb6aa]"userid@defaultdomain full.name@defaultdomain"[/code:1:ae38ddb6aa]

canonical-receive

This file is used for incoming mail, it is used to clean up, so that the virtual addresses don't get remapped to the default domain. All users should have an entry here including system accounts unless they are on the default domain of the box alone, and not using virtual usernames. With that let's edit /etc/postfix/canonical-receive now!

[code:1:ae38ddb6aa]"userid1@defaultdomain userid1@defaultdomain"
"userid1@virtualdomain userid1@virtualdomain"
"userid2@virtualdomain userid2@virtualdomain"
"postmast@virtualdomain userid2@virtualdomain"
"webmaster@defaultdomain webmaster@defaultdomain"
"webmastr@virtualdomain userid2@virtualdomain"[/code:1:ae38ddb6aa]

Or for virtual usernames

[code:1:ae38ddb6aa]"full.name@domain userid@domain"[/code:1:ae38ddb6aa]

got it? Good, it's not that difficult now is it. Again once you're done with these files you’ll need to make a hashed db out of them using the postmap command and you'll need to reload postfix. You remember how to do that right? Good! You're on your way.

CLIENT_ACCESS

The next file we'll be looking at is the /etc/postfix client_access file. This file will specify a list of exceptions and specific denials of mail servers. For instance, your friend, god bless him, has a mail server but is pretty clueless when it comes to dns, he hasn't configured his dns to reverse lookup properly. Well you could bypass that here. Also, you have some evil spammer that keeps sending you mail and the rbl list isn't blocking him, you could add a specific block here. Syntax of this file is xxx.xxx.xxx.xxx function where x is an ip address and function is either OK or REJECT!

[code:1:ae38ddb6aa]"xxx.xxx.xxx.xxx OK"
"xxx.xxx.xxx.xxx REJECT"[/code:1:ae38ddb6aa]

after making this file do you know what you need to do? That right you must make a hashed db out of this file as well! Ok that's done let's move on!

SENDER_ACCESS

This file /etc/postfix/sender_access is where you can specify specific e-mail addresses or domain to block. Usually bogus Spam addresses. Syntax is fakeemail@bogusdomain.com function where the function is a reject code.

[code:1:ae38ddb6aa]"fakeemail@fakedomain.com 550 No Spam Accepted"
"fakedomain.com 550 What kind of bogus address is that?"[/code:1:ae38ddb6aa]

etc. etc. This file further solidifies you box and you your place as an anti-spam ninja! -For you McDonald! You'll need to make this file a hashed db as well once you're done with it!

BODY_CHECKS

The next file we'll be looking at is /etc/postfix/body_checks. This file is either a regex file or a pcre file (if you compiled postfix with pcre support) I mainly use this file to block troublesome attachments I have no use for anyways. The following blocks certain types of attachments. Self-explanatory.

[code:1:ae38ddb6aa]"/^(.*)name="(.*). (com|vbs|vbe|js|jse|exe|bat|cmd|vxd|scr|hlp|swf|mp eg|mpg|mov|mp3|avi|pif|mpe|shs|ini)"$/ REJECT"[/code:1:ae38ddb6aa]

This will help out with viruses among other things, you won't have to worry about vbs scripts and that sort of stupid thing from now on. This file just needs to be in place. There is NO need to make it a hashed db. Although after making changes DO reload postfix!

HEADER_CHECKS

The next file we'll take a look at is /etc/postfix/header_checks. This file does exactly as it says. It checks mail headers. Again either regex or pcre. I will give a couple of examples here that I use:

[code:1:ae38ddb6aa]
# This will block 8 non ascii characters in a row, which shouldn't be in the
# header anyway according to the RFC... Japan and Chinese spammers...
"/[^[:print:]]{8}/ REJECT"

# Pegasus uses "Comments: ..." not "Comment: ...". spammers got it wrong.
"/^Comment: Authenticated sender is/ REJECT"
[/code:1:ae38ddb6aa]

These are just a couple examples. My files are actually really large for this. You can spend a lot of time doing this! Try to avoid going crazy, as it can be fairly obsessive! Again no hashed db needed, just reload postfix when you finish altering.

REGEXP_ACCESS

The next file to look at is regexp_access, this file pretty much does some more of the same, kicking spammers where it hurts! Here is an example I have in mine!

[code:1:ae38ddb6aa]"/[%!@].*[%!@]/ 550 Sender specified routing is not supported here."[/code:1:ae38ddb6aa]

There you see not too bad huh. Ok again reload postfix when your done no db needed and lets move on.

ALIASES

Lets edit /etc/aliases

The aliases file is very limited with the configuration we have specified here. It does need some things filled in. Standard system aliases should be placed here, aliases for root, postmaster, abuse, etc. etc. Also if you are running majordomo you'll specify your outgoing secrets here, If you're forwarding mail to another domain, and not using a .forward file in your home, specify that here as well. Other than that you should be good to go. after editing the aliases file you should run the command newaliases to tell the system theres new content in that file.

STARTING UP POSTFIX

Ok now our configuration is complete, let's start up postfix! Run the following

[code:1:ae38ddb6aa]($:~)=> postfix start[/code:1:ae38ddb6aa]

It should start-up error free! Now be sure to send a couple emails to yourself through yahoo or something and watch your maillog to ensure everything goes smoothly. I would actually recommend keeping this setup for a week or 2 before continuing with the rest of this article.

Installing Courier POP and IMAP

[code:1:ae38ddb6aa]($:~)=> cd /usr/ports/mail/courier-imap ; make install clean[/code:1:ae38ddb6aa]

Next we need to generate our imap ssl certs

[code:1:ae38ddb6aa]($:~)=> /usr/local/share/courier-imap/mkimapdcert
($:~)=> cd /usr/local/etc/courier-imap/[/code:1:ae38ddb6aa]

If you notice every configuration file in here is named .dist so lets copy those so our services actually work.

[code:1:ae38ddb6aa]($:~)=> for foo in *.dist; do cp $foo `basename $foo .dist`; done
($:~)=> mv quotawarnmsg.example quotawarning[/code:1:ae38ddb6aa]

Pretty simple on this one.

[code:1:ae38ddb6aa]($:~)=> vi /usr/local/etc/courier-imap/imapd
($:~)=> vi /usr/local/etc/courier-imap/imapd-ssl[/code:1:ae38ddb6aa]

Make any changes that you feel are necessary.

Now here’s a brief introduction to imap and what it can do for you.

Introduction to imap and maildirmake

Imap is a great protocol for handling mail. For the reson that all mail that a user gets is still stored on the mailserver, so in the event that windows crashes (and trust me it will) all your valuable email is still nice and safe. You can also setup user quotas and public shared imap folders. A good example of the need for public shared folders is say that you subscribe to bugtraq mailing lists and the freebsd mailing lists. And you’re not the only geek in the neighborhood who enjoys reading these. Instead of having both accounts get mail from them you can ultimately setup some procmail rules to automatically send those emails to the shared imap folder for anybody to read and enjoy.

For each user we need to create a mailbox. We will make one for the user soupx in this demonstration.

[code:1:ae38ddb6aa]($:~)=> cd /home/soupx
($:~)=> su soupx
($:~)=> maildirmake ./Maildir[/code:1:ae38ddb6aa]

To make things simple I changed users to soupx so that the permissions are correct. If you do this as root the folders will be marked with the ownership of root and the local user “soupx” will not be able to write or read mail from there. So unless you want to change the permissions on the Maildir folders it’s just easier this way.

Now say we wanted to put a quota on soupx’s mail account. As the root user we would run

[code:1:ae38ddb6aa]($:~)=> maildirmake -q 10000000S ./Maildir[/code:1:ae38ddb6aa]

On certain occasions I’ve run into issues where the quota values do not change. So to get around this create a cron job to perform this task for you every 30 minutes or so on the local mailbox’s.

Now lets talk about shared imap folders. First we need to create a collection of shared folders on a separate Maildir. Since were sending our spam over to /var/mail/spam it only seems logical to make a maildir in /var/mail/shared.

[code:1:ae38ddb6aa]($:~)=> maildirmake -S /var/mail/shared[/code:1:ae38ddb6aa]

Now we create our individual folders that we want shared.

[code:1:ae38ddb6aa]($:~)=> maildirmake -s write -f bugtraq /var/mail/shared[/code:1:ae38ddb6aa]

Here we are stating that the “bugtraq” folder is created with read/write permissions to everybody. You can set your permissions however you like. Now you can also use maildirmake to join the folders to peoples mailbox’s but were going to use a different approach. Were going to be defining things in a simple configuration file.

[code:1:ae38ddb6aa]($:~)=> vi /usr/local/etc/courier-imap/maildirshared[/code:1:ae38ddb6aa]

An example is listed below:

[code:1:ae38ddb6aa]
# ===========================================
# Shared IMAP Folders
# ===========================================

Bugtraq /var/mail/Shared/Bugtraq
FreeBSD /var/mail/Shared/FreeBSD
OpenBSD /var/mail/Shared/OpenBSD
NetBSD /var/mail/Shared/NetBSD
[/code:1:ae38ddb6aa]

The first area is the name we wish to display on our shares. Followed by a single space or a tab and then the location of the folder.

Congratulations you should now have POP, IMAP, and IMAP-SSL Working on your new postfix Install... Now onto bigger and better things.

Configuring Procmail

This part is easy. And any dumb ass could probably figure this one out.. But just so I don’t get 500 Emails asking how to do this I’ll go over it anyways..

[code:1:ae38ddb6aa]($:~)=> cd /usr/ports/mail/procmail ; make install clean[/code:1:ae38ddb6aa]

Now lets tell postfix that we now have procmail installed on our system So lets edit the main.cf file again.

[code:1:ae38ddb6aa]($:~)=> vi /etc/postfix/main.cf[/code:1:ae38ddb6aa]

Scroll down to the end of the file and add in:

[code:1:ae38ddb6aa]mailbox_command = /usr/local/bin/procmail -m /usr/local/etc/procmailrc[/code:1:ae38ddb6aa]

Save, Exit, Rehash and reload. Congratulations Procmail is now installed and ready for the next part of our howto

Configuring spamassasin and vipul's razor to postfix

Thanks to strog over at screamingelectron.org for the information on this one.

[code:1:ae38ddb6aa]($:~)=> cd /ports/mail/p5-Mail-SpamAssassin/ ; make install clean[/code:1:ae38ddb6aa]

Now we need to create a procmailrc file

[code:1:ae38ddb6aa]($:~)=> vi /usr/local/etc/procmailrc[/code:1:ae38ddb6aa]

[code:1:ae38ddb6aa]
# tell procmail we use Maildir style
DEFAULT="$HOME/Maildir/"

# specify the location for identified spam
SPAM="/var/mail/spam/new"

# various debugging stuff uncomment if needed
# VERBOSE=no
# LOGFILE=/var/log/procmailrc
# LOGABSTRACT=no

# Allow previously identified spam to be delivered since it
# must have been approved to get back here with the
# X-Spam-Deferred: YES flag set

:0 w
* ^X-Spam-Deferred: YES
$DEFAULT

# SPAM time
# first send to razor

:0 Wc
|/bin/nice usr/bin/razor-check -home=/root -logfile=/var/log/razor-agent.log

# if previous procmail recipe successfully completed then
# message is spam. prepare for quarantine. use formail to
# rip Delivered-To out (else you'll get loop errors) and tag
# with identifying headers

:0 Waf
| formail -I "Delivered-To:" -A "X-Razor2-Warning: SPAM" -A "X-Spam-Deferred: YES"

# drop razor identified spam into $SPAM (see above)

:0:
* ^X-Razor2-Warning: SPAM
$SPAM

# got this far, time to hand it off to spamassassin

:0fw
| /usr/bin/spamc

# Redirect definitive spam add identifying tags and rip
# postfix Delivered-To headers

:0 f
* ^X-Spam-Flag: YES
| formail -I "Delivered-To:" -A "X-Spam-Deferred: YES"

# quarantine it

:0:
* ^X-Spam-Flag: YES
$SPAM
[/code:1:ae38ddb6aa]

A quick note on the X-Spam-Deferred: YES flag. We need to add this as mail gets identified so that if we later determine that we want to actually approve that message on to deliver to the intended recipient we can sneak it back through procmail without getting tossed back into the spam trap.

Ok, almost done! The next thing is to add a means to easily examine the messages in the spam trap. For this we rely on the mighty mutt! We want to add one simple line to Muttrc (usually /usr/local/etc/mutt/Muttrc):

[code:1:ae38ddb6aa]
# Approve message identified as spam and deliver it
macro index A "| /usr/sbin/sendmail"
[/code:1:ae38ddb6aa]

Now we need to create the Maildir for our spam.

[code:1:ae38ddb6aa]($:~)=> maildirmake /var/mail/spam ; chown root:mail /var/mail/spam[/code:1:ae38ddb6aa]

Now we can just use mutt to view /var/mail/spam:

[code:1:ae38ddb6aa]($:~)=> mutt -f /var/mail/spam[/code:1:ae38ddb6aa]

You can now browse through identified and quarantined spam looking for incorrectly identified spam etc. If you find a message you want to approve, from the index screen just hit Shift A. This will prompt you asking if you want to pipe to /usr/sbin/sendmail, hit enter to do it and the message will get delivered, bypassing further spam detection. Don't forget to delete the message!!! You can, if you so desire, tack some additional commands on the macro added to mutt to delete the message after approval.

NOTE: If you use mbox style delivery as opposed to Maildir, simply remove the top line of the procmailrc that tells procmail to deliver Maildir style.

You may want to configure SpamAssassin by editing /usr/local/etc/mail/spamassassin/local.cf. By default, SpamAssassin modifies messages heavily. I recommend the the following options in order to minimally annoy people who don't want to be pestered with this crap:

[code:1:ae38ddb6aa]rewrite_subject 0
report_header 1
defang_mime 0[/code:1:ae38ddb6aa]

Congrats you don’t have spam. Now we take our journey into defeating those pesky viruses that even the best system administrator can get in their email unless precautions are made.

Now lets do some work with Razor.

[code:1:ae38ddb6aa]($:~)=> cd /usr/ports/mail/razor-agents/ ; make install clean
($:~)=> vi /usr/local/etc/razor.conf[/code:1:ae38ddb6aa]

Here’s a good starting configuration to use

[code:1:ae38ddb6aa]
debuglevel = 3
identity = identity
ignorelist = 0
listfile catalogue = servers.catalogue.lst
listfile discovery = servers.discovery.lst
listfile nomination = servers.nomination.lst
logfile = razor-agent.log
logic method = 4
min cf = ac + 10
razorzone = razor2.cloudmark.com
rediscovery wait = 172800
report headers = 1
turn off discovery = 0
use engines = 1,2,3,4
whitelist = razor-whitelist
razorhome = /usr/local/etc/razor
logfile = /var/log/razor-agent.log
[/code:1:ae38ddb6aa]

Configuring Amavis Virus Scanning

This part is extremely easy to setup but can drive the average user nuts trying to get it to work properly. The best software to use in my opinion to do virus scanning is Mcaffe’s Sophis. However this is a commercial product and we are cheap basterds here. So in the ideal of this article were going to use a secondary scanner available in the ports tree called clamscan.

So lets start off by installing amavisd-new

[code:1:ae38ddb6aa]($:~)=> cd /usr/ports/security/amavisd-new ; make install clean[/code:1:ae38ddb6aa]

Now lets move onto configuring it.

[code:1:ae38ddb6aa]($:~)=> vi /usr/local/etc/amavisd.conf[/code:1:ae38ddb6aa]

Make any necessary changes to this configuration file. The file is well documented so I don’t believe I need to go in-depth on what needs done here. Now we need to tell postfix that amavis is here.

[code:1:ae38ddb6aa]($:~)=> vi /etc/postfix/main.cf[/code:1:ae38ddb6aa]

And add in:

[code:1:ae38ddb6aa]content_filter = smtp-amavis:[127.0.0.1]:10024[/code:1:ae38ddb6aa]

Next edit the master.cf

[code:1:ae38ddb6aa]($:~)=> vi /etc/postfix/master.cf[/code:1:ae38ddb6aa]

And add in:

[code:1:ae38ddb6aa]smtp-amavis unix - - y - 2 smtp
-o smtp_data_done_timeout=1200
-o disable_dns_lookups=yes
127.0.0.1:10025 inet n - y - - smtpd
-o content_filter=
-o local_recipient_maps=
-o smtpd_helo_restrictions=
-o smtpd_client_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,rej ect
-o mynetworks=127.0.0.0/8[/code:1:ae38ddb6aa]

Don’t forget to rehash the files and restart postfix.

Next we need our virus scanner

[code:1:ae38ddb6aa]($:~)=> cd /usr/ports/security/clamav ; make install clean[/code:1:ae38ddb6aa]

So where do you go from here? My best suggestions would be to study up on different ways that you can authenticate mail users. Ultimately a good way is to use OpenLDAP to keep a database of users and store mail though there. But that’s beyond the scope of this article but a definite nice way to get things done. By utilizing the OpenLDAP services you cannot only have postfix authenticate though they’re but courier-imap and a vast majority of your services. Along with the ability to use a shared contacts system or whatever you mind can think of.

soup4you2
August 21st, 2003, 13:37
Firewall Configurations

It would take me all month to give you a good overview of how PF or IPFW works. And I pretty much don’t have the time for that these days. So I’m just going to cover final stages of getting PF to work and include a decent sample rule set.

First lets lockdown our kernel I’m assuming there should not be any further changed made to it.

[code:1:db1191b41c]($:~)=> vi /etc/rc.conf[/code:1:db1191b41c]

Here’s the changes were going to be making.

[code:1:db1191b41c]kern_securelevel_enable="YES"
kern_securelevel="1"[/code:1:db1191b41c]

You might want to read up a little bit in the handbook to see which securelevel is right for you.

NOTE: When operating in kernel securelevel the Xwindows system WILL NOT WORK! There I hope I save you some future frustrations.

Now lets enable the PF firewall with use of IPNAT

[code:1:db1191b41c]ipfilter_enable="YES"
ipnat_enable="YES"
ipfilter_rules="/etc/ipf.rules"[/code:1:db1191b41c]

If your using IPFW you would use something like this:

[code:1:db1191b41c]firewall_enable="YES"
firewall_script="/etc/ipfw.rules"
firewall_quiet="NO"
firewall_logging="YES" [/code:1:db1191b41c]

Now here we will activate the Ip monitoring utility.

[code:1:db1191b41c]ipmon_enable="YES"
ipmon_flags="-Dvn /var/log/firewall.log"[/code:1:db1191b41c]

So any denied packets that come in as long as in your rules you state to log will be sent to /var/log/firewall.log This is a good file to keep an eye on. You will be amazed about how much evil things try to make its way into your box.

Sample Firewall Rules

I’m only going to cover PF rule sets here. I also recommend you spend the time to learn IPFW and ultimately OpenBSD’s PF which is just a crazy insane firewall that just dominates. For the demonstration of these rules we will be using sis0 as our network card.

[code:1:db1191b41c]($:~)=> vi /etc/ipf.rules[/code:1:db1191b41c]

[code:1:db1191b41c]
# ============================================
# Here is a basic list of things we need to be able to access
# ============================================

pass out quick on sis0 proto udp from any to any port = 67 keep state
pass out quick on sis0 proto udp from any to any port = 68 keep state

#Allow web browsing
pass out quick on sis0 proto tcp from any to any port = 80 flags S keep frags keep state

#Allow email usage / pop3 / imap / smtp
pass out quick on sis0 proto tcp from any to any port = 110 flags S keep frags keep state
pass out quick on sis0 proto tcp from any to any port = 143 flags S keep frags keep state
pass out quick on sis0 proto tcp from any to any port = 25 flags S keep frags keep state

#Allow outgoing ssh
pass out quick on sis0 proto tcp from any to any port = 22 flags S keep frags keep state

#Allow DNS lookups
pass out quick on sis0 proto udp from any to any port = 53 keep state keep frags

#Allow CVSUP Access
pass out quick on sis0 proto tcp from any to any port = 5999 flags S keep state

#Allow access to Time Server
pass out quick on sis0 proto tcp from any to any port = 37 keep state
pass out quick on sis0 proto tcp from any to any port = 123 keep state

#Allow whois lookups
pass out quick on sis0 proto tcp from any to any port = 43 keep state

#Razor and spamassasin needs
pass out quick on sis0 proto tcp from any to any port = 2703 flags S keep state
pass out quick on sis0 proto tcp from any to 216.52.3.16 port < 3500 flags S keep state
pass out quick on sis0 proto tcp from any to 216.52.13.94 port < 3500 flags S keep state
pass out quick on sis0 proto tcp from any to 216.52.3.10 port < 3500 flags S keep state
pass out quick on sis0 proto tcp from any to 216.52.3.5 port < 3500 flags S keep state
pass out quick on sis0 proto tcp from any to 216.52.13.92 port < 3500 flags S keep state
pass out quick on sis0 proto tcp from any to 216.52.3.6 port < 3500 flags S keep state

#IRC
pass out quick on sis0 proto tcp from any to any port = 6667 keep state
pass out quick on sis0 proto tcp from any to any port = 6668 keep state
pass out quick on sis0 proto tcp from any to any port = 6669 keep state

# Other Random Things.

#IGMP
block out quick on sis0 proto igmp all

#ICMP
block out quick on sis0 proto icmp from any to any keep state

# EGRESS filtering
# Filter outbound packets directed to reserved networks
# Uncomment the first line to allow Multicast traffic.

block out quick on sis0 from !192.168.1.0/24 to any
block out quick on sis0 from any to 0.0.0.0/7
block out quick on sis0 from any to 2.0.0.0/8
block out quick on sis0 from any to 5.0.0.0/8
block out quick on sis0 from any to 10.0.0.0/8
block out quick on sis0 from any to 23.0.0.0/8
block out quick on sis0 from any to 27.0.0.0/8
block out quick on sis0 from any to 31.0.0.0/8
block out quick on sis0 from any to 69.0.0.0/8
block out quick on sis0 from any to 70.0.0.0/7
block out quick on sis0 from any to 72.0.0.0/5
block out quick on sis0 from any to 82.0.0.0/7
block out quick on sis0 from any to 84.0.0.0/6
block out quick on sis0 from any to 88.0.0.0/5
block out quick on sis0 from any to 96.0.0.0/3
block out quick on sis0 from any to 127.0.0.0/8
block out quick on sis0 from any to 128.0.0.0/16
block out quick on sis0 from any to 128.66.0.0/16
block out quick on sis0 from any to 169.254.0.0/16
block out quick on sis0 from any to 172.16.0.0/12
block out quick on sis0 from any to 191.255.0.0/16
block out quick on sis0 from any to 192.0.0.0/19
block out quick on sis0 from any to 192.0.48.0/20
block out quick on sis0 from any to 192.0.64.0/18
block out quick on sis0 from any to 192.0.128.0/17
block out quick on sis0 from any to 192.168.0.0/16
block out quick on sis0 from any to 197.0.0.0/8
block out quick on sis0 from any to 201.0.0.0/8
block out quick on sis0 from any to 204.152.64.0/23
block out quick on sis0 from any to 206.112.0.0/16
block out quick on sis0 from any to 224.0.0.0/3

#All The Rest
block out on sis0 all

# ===========================================
# What ports do i want allowed to be open
# ===========================================

#Allow bootp traffic in from your ISP's DHCP server only.
pass in quick on sis0 proto udp from any to any port = 68 keep state
pass in quick on sis0 proto udp from any to any port = 67 keep state

#Incomming SSH Access

pass in quick on sis0 proto tcp from STATION1 to SERVER port = 22 flags S keep frags keep state
pass in quick on sis0 proto tcp from 166.222.222.0/24 to SERVER port = 22 flags S keep frags keep state
pass in quick on sis0 proto tcp from STATION2 to SERVER port = 22 flags S keep frags keep state
[/code:1:db1191b41c]

Ok let me take a quick break to explain something here. We don’t want any computer on the internet to be able to try and gain SSH access to our box. So we are going to filter who can get in and who cant. So inside your /etc/hosts file you declare a hostname to match an IP address so were saying that on port 22 (SSH) we will only allow hostname STATION1 to connect to SERVER (our box).

[code:1:db1191b41c]
#SMTP/POP/IMAP
pass in quick on sis0 proto tcp from any to any port = 25 keep state
pass in quick on sis0 proto tcp from any to any port = 110 flags S keep frags keep state
pass in quick on sis0 proto tcp from any to any port = 143 keep state

#AMAVISD
block in quick on sis0 proto tcp from any to any port = 10024 keep state

#ICMP
block in quick on sis0 proto icmp from any to any keep state

#IGMP
block in quick on sis0 proto igmp all

#OTHER ODDITIES
block in quick on sis0 all with ipopts
block in quick on sis0 all with frag
block in quick on sis0 all with short
block return-rst in quick on sis0 proto tcp all flags FUP
block return-rst in quick on sis0 proto tcp from any to any
block return-icmp-as-dest(port-unr) in quick on sis0 proto udp from any to any

## Now we are blocking packets that are too short to
## contain a complete header, or with source routing
## options (most-likely setted to bypass our firewall).

block in log quick on sis0 all with opt lsrr
block in log quick on sis0 all with opt ssrr

# Prevent spoof of bogus/non-routable addresses
# May seem like overkill since we already block everything,
# but we really want to make sure these networks never reaches us.

block in quick on sis0 from 0.0.0.0/7 to any
block in quick on sis0 from 2.0.0.0/8 to any
block in quick on sis0 from 5.0.0.0/8 to any
block in quick on sis0 from 10.0.0.0/8 to any
block in quick on sis0 from 23.0.0.0/8 to any
block in quick on sis0 from 27.0.0.0/8 to any
block in quick on sis0 from 31.0.0.0/8 to any
block in quick on sis0 from 69.0.0.0/8 to any
block in quick on sis0 from 70.0.0.0/7 to any
block in quick on sis0 from 72.0.0.0/5 to any
block in quick on sis0 from 82.0.0.0/7 to any
block in quick on sis0 from 84.0.0.0/6 to any
block in quick on sis0 from 88.0.0.0/5 to any
block in quick on sis0 from 96.0.0.0/3 to any
block in quick on sis0 from 127.0.0.0/8 to any
block in quick on sis0 from 128.0.0.0/16 to any
block in quick on sis0 from 128.66.0.0/16 to any
block in quick on sis0 from 169.254.0.0/16 to any
block in quick on sis0 from 172.16.0.0/12 to any
block in quick on sis0 from 191.255.0.0/16 to any
block in quick on sis0 from 192.0.0.0/19 to any
block in quick on sis0 from 192.0.48.0/20 to any
block in quick on sis0 from 192.0.64.0/18 to any
block in quick on sis0 from 192.0.128.0/17 to any
block in quick on sis0 from 192.168.0.0/16 to any
block in quick on sis0 from 197.0.0.0/8 to any
block in quick on sis0 from 201.0.0.0/8 to any
block in quick on sis0 from 204.152.64.0/23 to any
block in quick on sis0 from 224.0.0.0/3 to any

#ALL THE REST
block in log quick on sis0 all

# Loopback Interface
pass in quick on lo0 all
pass out quick on lo0 all
[/code:1:db1191b41c]

Save and exit. With a little bit of modifying you should have a decent set of rules there.

Closing Statements

Originally I planned on making this document a lot more in-depth specifically towards IDS, setting up various other services. Then I got burned out and I just don’t feel like it anymore. This is my finale article from bsdhound and I hope you enjoy it. It’s been a great few years operating that site and as I mentioned above this is my gift back to you all for all the support and help you’ve given me throughout the years. I hope you enjoyed reading this and possibly learned a think or too.

Thanks for your support

Soup4you2

A Updated copy of this howto may be found in PDF format at:
http://bsdhound.com/downloads/Creating_a_Stable_Secure_FreeBSD_Mailserver.pdf

soup4you2
August 21st, 2003, 13:37
Updated w/ more content.. enjoy :D

z0mbix
August 22nd, 2003, 04:01
This is excellent stuff soup4you2. I have to rush off to work now as I should have left 45 mins ago...but i'm gonna read the rest later tonight. :)

v902
August 22nd, 2003, 13:10
DAMN! Nice soup! I should set up a "Securing OpenBSD" tutorial "Once you got case open remove the NIC, ocne you have it firmly in your hand, bring the hammer down hitting right in the middle" :lol:

soup4you2
August 22nd, 2003, 13:24
i think we discussed this before..

removal of the nic will not stop the ninjas and flying squirrels from gaining local access.

v902
August 22nd, 2003, 14:10
http://www.biconet.com/critter/GIFs/squirrel2.jpg

The Ninjas' ph33r the power of root....

soup4you2
August 22nd, 2003, 14:28
So as it may be Ninjas might f33r the power of root, but were talking about UID 0 and not mathematics. And squirrel away can be pretty effective but tell me what do you think is going to happen when you end up with a bunch of squirrels running away in a enclosed space? I foresee one of them spilling my coffee cup that I conviently placed in the cd-rom tray earlier that morning and borking the entire system. I guess the squirrelaway would be an effective form of a DoS attack then. So you plan backfires.


And you might want to look at this.. It requires flash though (http://trimeg.bayair.net/preview.asp?t=When+the+Flying+Squirrels+Come+Back&i=Vlad902)

SolarfluX
August 26th, 2003, 13:12
Soup:
I have to point out that you describe kernel options and files with 'ipfilter', then refer to them as PF. That should be IPF.

Otherwise, good stuff.

The offending bits:

--------------------------

[code:1:5a6150b645]options IPFILTER
options IPFILTER_LOG
options IPFILTER_DEFAULT_BLOCK[/code:1:5a6150b645]

These options will enable the Packet Filtering Firewall (PF).

--------------------------

It would take me all month to give you a good overview of how PF or IPFW works. And I pretty much don’t have the time for that these days. So I’m just going to cover final stages of getting PF to work and include a decent sample rule set.

Now lets enable the PF firewall with use of IPNAT

[code:1:5a6150b645]ipfilter_enable="YES"
ipnat_enable="YES"
ipfilter_rules="/etc/ipf.rules"[/code:1:5a6150b645]

--------------------------

I’m only going to cover PF rule sets here. I also recommend you spend the time to learn IPFW and ultimately OpenBSD’s PF which is just a crazy insane firewall that just dominates.

--------------------------

This will be confusing for those who don't know the difference between IPF and PF, and irritating for those who do!

8)

SolarfluX
August 26th, 2003, 13:37
I recently played with sysctl and all the network settings I could modify, along with grepping the mailing lists for clues on how to get vastly increased network performance and offer a little more protection. There are a couple of other tweaks for increased filesystem performance, but I didn't really look further into that. Here are the results:

[code:1:124d616a65]# /etc/sysctl.conf

kern.ipc.max_datalen=512
kern.ipc.maxsockbuf=2097152
kern.ipc.somaxconn=8192
kern.maxfiles=65536

net.inet.icmp.drop_redirect=1
net.inet.icmp.icmplim=500
net.inet.icmp.log_redirect=1

net.inet.ip.ttl=128

net.inet.raw.maxdgram=57344
net.inet.raw.recvspace=65536

net.inet.tcp.blackhole=1
net.inet.tcp.drop_synfin=1
net.inet.tcp.log_in_vain=1
#net.inet.tcp.recvspace=65536 (default)
net.inet.tcp.sendspace=65536

net.inet.udp.blackhole=1
net.inet.udp.log_in_vain=1
net.inet.udp.maxdgram=57344
net.inet.udp.recvspace=65536

net.local.dgram.maxdgram=57344
net.local.dgram.recvspace=65536

net.local.stream.recvspace=65536
net.local.stream.sendspace=65536[/code:1:124d616a65]

I had Indigo2 try these out and he said they helped make NFS and file transfers absolutely fly. Run some benchmarks before and after enabling these and see how they work for you.

soup4you2
August 26th, 2003, 16:08
Oh dammit........

/me slaps himself...

thanks for pointing that out.. i'll fix it once i update it w/ TLS configuration...

thanks for sharing your performance tweaks... :)

i'll have to play with those...

some other good login.conf settings would be:

[code:1:27b386dff2]
:login-tries=3:\
:passwordtries=0:\
:filesize=512MB:\
:requirehome=true:\
:coredumpsize=0:
[/code:1:27b386dff2]

|MiNi0n|
August 28th, 2003, 22:10
Now we need to create a procmailrc file

:twisted:

Nice procmail recipe soup... whomever crafted that must be simply brilliant! :wink:

soup4you2
August 28th, 2003, 22:15
[quote:bd63c842b0="soup4you2"]Now we need to create a procmailrc file

:twisted:

Nice procmail recipe soup... whomever crafted that must be simply brilliant! :wink:[/quote:bd63c842b0]

i gave you thanks on there didnt i?

if not let me know so i can add your name in.. i added everybody else's in..

btw your a genious minion

Loop
August 29th, 2003, 03:18
[code:1:7c8c4a2e26]smtp-amavis unix - - y - 2 smtp
-o smtp_data_done_timeout=1200
-o disable_dns_lookups=yes
127.0.0.1:10025 inet n - y - - smtpd
-o content_filter=
-o local_recipient_maps=
-o smtpd_helo_restrictions=
-o smtpd_client_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,rej ect
-o mynetworks=127.0.0.0/8[/code:1:7c8c4a2e26]



Any reason you are runing amavisd in a chroot (the y on the first line), when you aren't running postfix chrooted? I was under the impression that you only did that if postfix was in a chroot jail.

Loop
August 29th, 2003, 03:36
[code:1:78c97e6eba]# /etc/sysctl.conf

kern.ipc.max_datalen=512
kern.ipc.maxsockbuf=2097152
kern.ipc.somaxconn=8192
kern.maxfiles=65536

net.inet.icmp.drop_redirect=1
net.inet.icmp.icmplim=500
net.inet.icmp.log_redirect=1

net.inet.ip.ttl=128

net.inet.raw.maxdgram=57344
net.inet.raw.recvspace=65536

net.inet.tcp.blackhole=1
net.inet.tcp.drop_synfin=1
net.inet.tcp.log_in_vain=1
#net.inet.tcp.recvspace=65536 (default)
net.inet.tcp.sendspace=65536

net.inet.udp.blackhole=1
net.inet.udp.log_in_vain=1
net.inet.udp.maxdgram=57344
net.inet.udp.recvspace=65536

net.local.dgram.maxdgram=57344
net.local.dgram.recvspace=65536

net.local.stream.recvspace=65536
net.local.stream.sendspace=65536[/code:1:78c97e6eba]

Run some benchmarks before and after enabling these and see how they work for you.

You prolly don't need to set all these sysctls. For instance, net.inet.ip.ttl will have zero effect on the speed of your network, it merely sets the TTL value on a packet. If there is any site (in regular use) more than 64 hops away, I would be very surprised indeed.

net.inet.icmp.icmplim should propably be left at the default (for 4.8-STABLE) of 200 rather than increasing it, as this would have a negative effect on a systems ability to drop an icmp flood.

Similarly, if the kern.ipc. settings are too generous, it could open your host up to a DoS by simply flooding the kernel with more data than it can handle.

My main point is this, since the sysctl's are very poorly documented, it is not the best idea to go changing everything at once without testing first.

cheers

soup4you2
August 29th, 2003, 09:23
Any reason you are runing amavisd in a chroot (the y on the first line), when you aren't running postfix chrooted? I was under the impression that you only did that if postfix was in a chroot jail.


Well damm.... thanks i'll correct that... i was planning on a revision w/ some other info.. and chrooting postfix is one of them.. i guess i didnt look too much into it when i pasted that..

thanks for noticing it..

|MiNi0n|
August 29th, 2003, 10:32
Good news is soup, chrooting postfix is fairly trivial! Just some master.cf settings and then copy a few files to the chroot :)

Loop
August 29th, 2003, 10:47
Good news is soup, chrooting postfix is fairly trivial! Just some master.cf settings and then copy a few files to the chroot :)

This is true (thankyou Wietse!!), but if you also want to use a virus-scanner I'm sure it's a little more involved than that.

soup4you2
August 29th, 2003, 10:57
care to give some examples?

|MiNi0n|
August 29th, 2003, 10:58
Yes, adding virus scan can be difficult, but doable! I did it on OpenBSD with postfix/amavisd in the chroot using FreeBSD emulation for McAfee vscan also running in the chroot :) Learned a lot about chroot setting that up!

SolarfluX
August 29th, 2003, 21:49
You prolly don't need to set all these sysctls. For instance, net.inet.ip.ttl will have zero effect on the speed of your network, it merely sets the TTL value on a packet. If there is any site (in regular use) more than 64 hops away, I would be very surprised indeed.

net.inet.icmp.icmplim should propably be left at the default (for 4.8-STABLE) of 200 rather than increasing it, as this would have a negative effect on a systems ability to drop an icmp flood.

Similarly, if the kern.ipc. settings are too generous, it could open your host up to a DoS by simply flooding the kernel with more data than it can handle.

My main point is this, since the sysctl's are very poorly documented, it is not the best idea to go changing everything at once without testing first.

cheersYah, yah, some of them (ttl, log_in_vain, etc.) have no effect on performance, I know what each sysctl does. If you (or anyone else) aren't sure about any of them, by all means, DON'T implement them. You can pick and choose what you want to try. From what I have researched, these are reasonable settings.

Perhaps you (Loop) would like to test the kern settings individually and let us know if you can DoS your kernel with these settings. The icmplim setting really is practically meaningless if you disallow pings to reach your box anyhow, I just copied everything from my /etc/sysctl.conf file. I just figured I'd throw them all out there for everyone's benefit, but if anyone's unsure, research them yourselves. I've been using these for a few months and have seen none of the ill effects you mention.

Have you actually tried these settings out?

|MiNi0n|
August 29th, 2003, 22:45
I just copied everything from my /etc/sysctl.conf file. I just figured I'd throw them all out there for everyone's benefit, but if anyone's unsure, research them yourselves.

I was actually doing some sysctl performance research myself today. I did find a few similar mentions to what Loop had suggested. These aren't carved-in-stone-your-box-will-get-hosed type things, but they do open your box up to things like memory consumption and other things.

Just use at your own discretion, like anything else. If I told you that rm -rf / really cleaned up your filesystem would you go and try it? :lol:

BTW - I did do a few tweaks SolarfluX suggested, but I was a bit more conservative.

Loop
August 31st, 2003, 09:37
[quote:d9ca6af1fc="Loop"]You prolly don't need to set all these sysctls.
<much snippage>
My main point is this, since the sysctl's are very poorly documented, it is not the best idea to go changing everything at once without testing first.

cheersYah, yah, some of them (ttl, log_in_vain, etc.) have no effect on performance, I know what each sysctl does. If you (or anyone else) aren't sure about any of them, by all means, DON'T implement them. You can pick and choose what you want to try. From what I have researched, these are reasonable settings.

Perhaps you (Loop) would like to test the kern settings individually and let us know if you can DoS your kernel with these settings. The icmplim setting really is practically meaningless if you disallow pings to reach your box anyhow, I just copied everything from my /etc/sysctl.conf file. I just figured I'd throw them all out there for everyone's benefit, but if anyone's unsure, research them yourselves. I've been using these for a few months and have seen none of the ill effects you mention[/quote:d9ca6af1fc].

What ill-effects did I mention?

Have you actually tried these settings out?

Haven't been able to DoS my stock kernel yet ... maybe Alphas are a little more resilient than Intels, but I did try some of the networking hints, mainly on the UDP side. I haven't tested them fully (the machine is an NFS server) but I'll let you know if I see any effect over a stock kernel

SolarfluX
August 31st, 2003, 20:06
Being DoS'd by the kern or icmp settings.

Loop
September 2nd, 2003, 10:52
Being DoS'd by the kern or icmp settings.

Nope, haven't had that happen with the default settings. I did get caught out the first time I tried to really bash on the network using ping -f from a Linux box, and all of a sudden the packets were getting dropped all over the place ... took a few minutes to both see it in the logs and read up and realise that FreeBSD was designed to do that 8)

laszlof
September 4th, 2003, 16:08
I found an error in your tutorial

[code:1:488d7a906a]kern.ps_shoallprocs=0[/code:1:488d7a906a]

which should be:

[code:1:488d7a906a]kern.ps_showallprocs=0[/code:1:488d7a906a]

Otherwise, Great work!

-Frank

laszlof
September 4th, 2003, 16:12
[code:1:18d3262856]kern.ps_shoallprocs=0[/code:1:18d3262856]

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)


that should be

[code:1:18d3262856]kern.ps_showallprocs=0[/code:1:18d3262856]


good work! :)

antman001
September 4th, 2003, 17:14
Hello Soup4you2,


I have noticed that you have taken down your site - bsdhound.com.
That's where you have your article on installing Sguil on FreeBSD,
I could not find it anywhere on the internet, and was wondering if
you have that artice on PDF - if so, please send it to me (ahuynh44@hotmail.com), if it's not any trouble to you. I would really
appriciate it....I can not find any article on the internet on how to do
this...

Do you have any other article on installing this on OpenBSD 3.3? If not,
do you plan to do one in the future...

Your help is greatly appriciated...

Thank you,

Anthony :?

elmore
September 4th, 2003, 17:20
Anthony,

Soup has most of his notes on sguil here on SE. There are also several other people here working on it as well. Try searching for sguil using our search function. Should turn up some good results

soup4you2
September 7th, 2003, 14:42
Correct... the howto should be in here also....

as for installing openbsd 3.3 you just cant beat the fine documentation on the openbsd website.. they go more indepth than i ever could..

antman001
September 9th, 2003, 14:50
Thanks guys!

I will search on the site for the documentation, and will also check
OpenBSD website. I assume that the install of Sguil on FreeBSD will
probably be very similar on OpenBSD...I'll try to follow the instruction
and apply it to my OpenBSD box...


Anthony

soup4you2
September 9th, 2003, 15:02
here's the link if you need it..

http://screamingelectron.org/phpBB2/viewtopic.php?t=667


also has anybody else found any errors in the mailserver doc.. i've been making a revision with a lot of corrections and more indepth on installing amavis.. want to try to get all bases covered before updating it..

soup4you2
September 15th, 2003, 14:44
Ok a updated copy of this howto with many corrections can be found in PDF format at:

http://bsdhound.com/downloads/Creating_a_Stable_Secure_FreeBSD_Mailserver.pdf

Stegnation
September 29th, 2003, 15:15
I'm having some trouble receiving mail. I stopped following the document before installing Courier POP and IMAP.

I get these errors:

Sep 29 19:52:50 freebsd sm-mta[79248]: h8T5fC21066965: to=<jeroen@stegg-inc.com>, ctladdr=<root@freebsd.stegg-inc.com> (0/0), delay=12:11:37, xdelay=00:01:17, mailer=esmtp, pri=660252, relay=stegg-inc.com. [62.166.33.121], dsn=4.0.0, stat=Deferred: Operation timed out with stegg-inc.com.
Sep 29 19:52:50 freebsd sm-mta[79248]: alias database /etc/mail/aliases.db out of date
Sep 29 19:52:50 freebsd sm-mta[79248]: h8T5fC21066965: h8THpV21079248: sender notify: Warning: could not send message for past 4 hours
Sep 29 19:52:50 freebsd sm-mta[79248]: h8THpV21079248: to=<root@freebsd.stegg-inc.com>, delay=00:00:00, xdelay=00:00:00, mailer=local, pri=31567, relay=local, dsn=2.0.0, stat=Sent

soup4you2
September 29th, 2003, 15:33
ensure your /etc/aliases is upto date.. then run newaliases

also since your hostname is root at freebsd.stegg-inc dot com

ensure you have a DNS zone for freebsd

optyk
September 29th, 2003, 15:35
This link may have some relevance here:
http://www.freebsdforums.org/forums/showthread.php?threadid=1003

And I wonder who this elmore is that made this? :P

elmore
September 29th, 2003, 15:42
hehe, It's also posted here too mike. ;)

http://screamingelectron.org/phpBB2/viewtopic.php?t=3

soup4you2
September 29th, 2003, 15:55
hehe It's also included in page 1 of this howto.. :)

my god it's everywhere... your famous elmore..

optyk
September 29th, 2003, 16:20
ok, I'm shutting up now...

rob897
October 10th, 2003, 00:29
Soup I did the following from your tutorial:

[code:1:3f98c74284] echo "ROBKERNAL" >> /etc/make.conf [/code:1:3f98c74284]

now when I try to issue the
make installkernel KERNCONF=MYKERNEL I get the following error:
"/etc/make.conf", line 11: Need an operator

here is what my make.conf looks like:
[code:1:3f98c74284]# -- use.perl generated deltas -- #
# Created: Sun Oct 5 19:57:07 2003
# Setting to use base perl from ports:
PERL_VER=5.6.1
PERL_VERSION=5.6.1
PERL_ARCH=mach
NOPERL=yo
NO_PERL=yo
NO_PERL_WRAPPER=yo

ROBKERNAL[/code:1:3f98c74284]
is there something missing?

rob897
October 10th, 2003, 00:49
Disregard I found out what it's supposed to be.

KERNCONF=YOURKERNELNAMEHERE

Stegnation
October 27th, 2003, 21:14
Hi,

I have no idea why I'm getting this errors.
I only get this when mail is sent to an alias. The user 'info' does not exist,
it's an alias specified in the aliases file.

Oct 28 01:16:08 server spamd[14284]: connection from localhost [127.0.0.1] at port 1046
Oct 28 01:16:08 server spamd[14297]: info: setuid to nobody succeeded
Oct 28 01:16:08 server spamd[14297]: Creating default_prefs [/nonexistent/.spamassassin/user_prefs]
Oct 28 01:16:08 server spamd[14297]: Cannot write to /nonexistent/.spamassassin/user_prefs: No such file or directory
Oct 28 01:16:08 server spamd[14297]: Couldn't create readable default_prefs for [/nonexistent/.spamassassin/user_prefs]
Oct 28 01:16:08 server spamd[14297]: processing message <00f601c39ce8$b994fa80$0201a8c0@stegnation> for nobody:65534.
Oct 28 01:16:11 server spamd[14297]: clean message (0.1/5.0) for nobody:65534 in 2.7 seconds, 1737 bytes.

Stegnation
October 27th, 2003, 21:40
I finally found the problem. The problem was that the mail was forwarded to root.
Then I found this http://www.postfix.org/faq.html#root

This solved it :D

soup4you2
October 27th, 2003, 22:20
Glad you figured it out.. Hey Elmore i think your server clock is off a wee bit..

newguy
July 4th, 2005, 12:16
when i run the command "/usr/local/share/courier-imap/mkimapdcert" to generate the imap ssl certs i get this error:

error on line -1 of /usr/local/etc/courier-imap/imapd.cnf
562:error:02001002:system library:fopen:No such file or directory:/usr/src/secur
e/lib/libcrypto/../../../crypto/openssl/crypto/bio/bss_file.c:104:fopen('/usr/lo
cal/etc/courier-imap/imapd.cnf','rb')
562:error:2006D080:BIO routines:BIO_new_file:no such file:/usr/src/secure/lib/li
bcrypto/../../../crypto/openssl/crypto/bio/bss_file.c:107:
562:error:0E064072:configuration file routines:CONF_load:no such file:/usr/src/s
ecure/lib/libcrypto/../../../crypto/openssl/crypto/conf/conf_def.c:197:

i'm pretty sure i followed all the steps...... anyone know what i did wrong?

newguy
July 5th, 2005, 10:30
ok, scracth that, i guess i just need more sleep :redface:
i just had to create that imapd.cnf file and it got rid of most of the error....
however i'm now getting:

Generating a 512 bit RSA private key
....++++++++++
.................+++++++++
writing new private key to '/usr/local/share/courier-imap/imapd.pem'
-----
unable to find 'distinguished_name' in config
problems making Certificate Request
884:error:0E06D06C:configuration file routines:NCONF_get_string:no value:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/conf/conf_lib.c:329:group=req name=distinguished_name

does this mean i need to add something to conf_lib.c? or is there a line that needs to be uncommented? or am i on the wrong track?

thanks in advance

Strog
July 5th, 2005, 15:34
An ssl certificate must have some basic info (Organisation, City, state, country, etc.) in it to really be legit (even self signed). This is part of what creates your distinguished name. Basically your cert needs some more info. I'm not sure where the script is getting the info and perhaps someone would like to shed some light on that. :wink:

newguy
August 4th, 2005, 11:14
umm, perhaps i missed it somewhere but i didn't see anything that mentioned how to start courier-imap..... could someone please tell me how to do that?

elmore
August 4th, 2005, 12:06
"imapd.rc start"

newguy
August 5th, 2005, 11:08
ok thanks, if i run "ps aux | grep imap" it should show up right? or is it "ps -a | grep imap"?

thesquib
January 18th, 2006, 23:48
Hey guys,
I'm very very new to FreeBSD / BSD / UNIX in general. I installed FreeBSD 6.0 as a test, learning environment, and followed right through these instructions - aside from the Mail server setup (which i haven't got around to yet).

Anyhow, Just after compiling the kernel, i noticed that i could not ping in or out.. and shortly after that I realised no communication was going in and out, not even a ping to the local host. I thought it must be because i had enabled the ipfilter and hadn't configured the ipf.rules. So I followed the firewall setup intructions too. Rebooted, didn't noticed anything in particular (not too sure what to look for here), and still had the same issues.

Does anyone have any idea what might be causing this? I can send through parts of the config if requested. When I send out a ping I get
ping: sento: unavailable.

bsdjunkie
January 19th, 2006, 11:44
Posting your config would definately help.

thesquib
January 22nd, 2006, 16:47
Just thought i should clarify -
the error message when I try and ping a domain name, such as google.co.nz is:
ping: cannot resolve google.co.nz: Host name lookup failure
-- so self explainatory there!
and an ip address:
ping: sento: Network is unreachable

I'm collecting the config so I can post it here shortly.

Apollo
March 4th, 2006, 00:44
Hey all, I was hunting down for basic texts to build my own howto for FBSD and came accross this text. And personally thought it was a great piece of work.

First and foremost, I would like to thank Soup4you2 for his great work and dedication into putting this little work together for others to beniffit from.

Second, I'd like to know if I can shove it on my personal website for extra visibility. I have loads of friends that are soon to become UNIX users. Not only that I firmly believe that MS should be put to death for the patronizing and proffiting off the ignorance of the masses. Pls let me know if you feel this is a good idea or not and I will respect your wishes. I do, tho, promise to respect your work for what it is, and will deliver proper credit to where it is due.

Thanks.

Marc aka Apollo.

elmore
March 4th, 2006, 04:34
You need to speak directly to Soup about reposting his how-to. Try pming him. :)