Screaming Electron Forum Index
Log in Register FAQ Memberlist Search Screaming Electron Forum Index

Building a Fairly secure FreeBSD Mail server
Goto page 1, 2, 3, 4, 5  Next
Post new topic   Reply to topic    Screaming Electron Forum Index -> How-To's
View previous topic :: View next topic  
Author Message
Full Fledged Geek
Full Fledged Geek

Joined: 22 Jan 2003
Posts: 975

PostPosted: Wed Aug 20, 2003 4:17 pm    Post subject: Building a Fairly secure FreeBSD Mail server Reply with quote


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.

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.

Here we see Mr. Billy Demonstrating Corporate Security Policy's

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.

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.


* 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

($:~)=> sockstat –4

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/ file

($:~)=> vi /etc/mail/

(Depending on your experience if you don't like vi you can use ee or something different)

now search for a line that states:

O DaemonPortOptions=Port=587, Name=MSA, M=E

Once you find the line put a comment in front of it. Then save and close. Now execute:

($:~)=> killall -HUP sendmail

The -HUP won't stop sendmail, but will tell it to read the changes you made to /etc/mail/ 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:


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:


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:

($:~)=> shutdown now

Press enter when prompted, then type exit. Once you've logged back in, see if you can send a test message to your 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):


Portmap is only needed if you are running NFS, which you won't be on a stand-alone FreeBSD server. It also has a long history of security issues; so if you don't absolutely need it, disable it.

syslog (port 514) will probably also show in your output. You don't want to disable syslog completely, as you do want to receive logging messages. However, you don't need to have this port open to do so. In your /etc/rc.conf file, make sure syslog is enabled and add a second line with some options:


Those two ss’es (make sure you have two, not just one) in the flags will disable logging from remote hosts and close that port, but still allow your localhost to keep its logging capabilities. After doing this do another shutdown now command then once in singleuser mode press control+D to return to regular mode.. Issue the sockstat command again and the syslog port should now be closed.

Next, make sure inetd_enable is not set to YES in /etc/rc.conf. If inetd is showing up in your sockstat output, something has been uncommented out in /etc/inetd.conf. If you don't need it, put a # back in front of that line, and do a killall inetd.

If you get your address from your ISP's DHCP server, keep dhclient (port 68) open, or you won't be able to renew your IP address.

Some other things to possibly add in your rc.conf are:


If you didn't, it is a good option to include, as it logs all attempts to closed ports. This can get to be annoying after awhile though.

An interesting option is:


This will enable system accounting. If you're new to system accounting, read man sa and man lastcomm to decide whether this option would be useful to you or not.

Finally, this is a good option to include:


as it will clear /tmp at startup, which is always a good thing.

Let's leave /etc/rc.conf and see what else we can do to tighten up your system. I like to change the default algorithm used when encrypting a user's password to the Blowfish algorithm, as it provides the highest security at the greatest speed

To implement Blowfish hashes, edit /etc/login.conf and change the passwd_format line so that it looks like this:


Also add the following to set the password defaults. These changes will 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.


Save your change, and then rebuild the login database with this command:

($:~)=> cap_mkdb /etc/login.conf

You'll then have to change all of your user's passwords so they will get a new Blowfish hash. You can do this by typing:

($:~)=> passwd username

As the superuser. Whatever username you use, 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:

($:~)=> more /etc/master.passwd

All of the passwords for your users should begin with $2.

Finally, configure the adduser utility to use Blowfish whenever you create a new user by editing /etc/auth.conf. Change the crypt_default line so that it looks like this:


You've probably noticed when you log in to your FreeBSD system that your login prompt reminds you that you are running FreeBSD. And that after you log in, you receive the FreeBSD copyright information, which is followed by the version of FreeBSD and the name of your kernel, and finally, a useful (but rather boring) motd which again reminds you that you are running FreeBSD. You probably already know what version of FreeBSD you are running and might not want to share that information with the rest of the world. And the motd is a good place to remind the rest of the world that they shouldn't be messing with your system anyways.

You can edit /etc/motd to say whatever suits your purposes, be it anything from your favorite sci-fi excerpt to all the nasty things that will happen to someone if they continue to try to log in to your system. Below is a good example of a common motd.


* * * * * * * * * * * * * * W A R N I N G * * * * * * * * * * * * * * *
* * * * * * * * * * * * * W A R N I N G * * * * * * * * * * * * * * *

Next, to remove the copyright info:

($:~)=> touch /etc/COPYRIGHT

Then to change the text that appears at the login prompt, edit /etc/gettytab. Find the line in the default: section that starts with


Carefully, change the text between r : to whatever text you wish to appear. Double-check that you have the right amount of s and s and save your change. For example, my login prompt looks like this:

I'm a node in cyberspace. Who the hell are you?

You can test your changes by going to another terminal and logging in.

Finally, even though you've edited your motd to remove your version and kernel information, by default FreeBSD will still re-add it to /etc/motd every time you log in. To prevent this behavior, add the following line to /etc/rc.conf:


This change requires a reboot, so make sure you've first tested your previous changes and have saved all of your work on any other terminals.

No one (including you) should ever log in to your system using the root account. To prevent this from happening, edit /etc/ttys. Once you get past a page's worth of comments, you'll notice a section that goes from ttyv0 to ttyv8. Change the word secure on each of those lines to insecure. This is a file you don't want a typo in, so double-check your changes carefully. Test your change by trying to log in as root on one of your terminals. You should receive a "Login incorrect" message.

Personally, I tend to use all nine terminals on my desktop. If you don't, you can also change the word "on" to "off" on some of the ttys in /etc/ttys. Remember to leave at least one terminal "on," or else you won't be able to log in, which will severely hamper the usefulness of your system. You'll also note that ttyv8 is "off" by default, which means you have to manually start an X Window session. If you'd like X to start automatically at bootup, change that "off" to "on."

Another good thing to do inside your ttys file the top part says:

console none unknown off secure

I like to completely 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.

($:~)=> vi /etc/group

and edit the first line (after the # comments) which starts with wheel,

wheel:*:0:root becomes wheel:*:0:root,soupx

Where soupx is the normal user that was created at installation time.
As a normal user, FreeBSD will only allow minimal privileges. No changes to the system configuration files are allowed. For the purpose of securing the system, configuration would have to be changed. Unix systems have a superuser account for the purpose of system configuration and maintenance. The name of this account is “root”, it is the God mode account, and a root user can do anything to the system. Given this amount of privileges, it is considered to be dangerous to login using this account for day to day operation because the consequence of a simple mistake is just too great, therefore, it is much safer to operate or “use” the system with a normal user account and only become the “root” user as need arises. To allow this to happen the user must be a member of wheel group (group 0), which is where user “soupx” was assigned above.

Similarly, when an attacker performs reconnaissance on a system, the knowledge of which OS platform is running would be of great value. Sometimes, an attacker would send out of spec packets to a host and by the information returned, 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.


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


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

($:~)=> vi /etc/sysctl.conf

This file should only contain comments. After the comments, add the following lines


Tips: This is not a replacement for a firewall (packet filter). It should be used in conjunction with a packet filter and possibly be a failsafe mechanism for the firewall. With a proper firewall configured, any log produced by log_in_vain should be a warning that the firewall is failing or misconfigured.

While you’re in the sysctl.conf add in this:


Please note if your running earlier than 5.2 the name changed. The old name is:


That will make it so users will only be able to display the processes that are owned by that user. But root will still be able to display all processes. (This option first appeared in FreeBSD 4.7)

Updating Your Server

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.

($:~)=> pkg_add -r cvsup-without-gui

Now if the package system is not your cup of tea you can also use the ports tree. If you’ve never used the ports tree before this is what makes FreeBSD such a great operating system. So if you installed the ports collection you can

($:~)=> cd /usr/ports/net/cvsup-without-gui ; make install clean

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.

($:~)=> /stand/sysinstall

Welcome back to the installer app. Normally I try to stay away from automated things like this to do my bidding. But I’m not fully going to go into the packaging system yet.

* Choose the 4th Option labeled Configure
* Choose the 2nd Option labeled Packages
* Choose the 1st Option labeled CD-ROM

Now pop in your FreeBSD cd1 in the cd-rom and select your cd-rom from the menu

Scroll on down to net and select cvsup, once your done installing cvsup we can continue to update our sources. You can also install from the FreeBSD ftp server instead of using the old outdated binaries from the cd-rom.

Create configuration file for CVSup

CVSup can update all the source code provided by FreeBSD or just download and update ones that the user specifies. 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.

($:~)=> vi /root/cvs-supfile

Put this in it.


*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=.

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.

($:~)=> /usr/local/bin/cvsup /root/cvs-supfile

Building Your World

The source tree and ports tree will be synchronized with the FreeBSD distribution server.

So once your sources finished updating. Lets go ahead and compile and install them.

($:~)=> cd /usr/src
($:~)=> make buildworld

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.

($:~)=> cd /usr/src/sys/i386/conf
($:~)=> cp GENERIC KERNNAME (kernname is whatever you wish to call your kernel)
($:~)=> vi KERNNAME

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.

options IPSEC

Now we should also choose the type of firewall we would like to make our server use.

options IPFILTER

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


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)

pseudo-device snp 4

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.

($:~)=> cd /dev
($:~)=> ./MAKEDEV snp0
($:~)=> ./MAKEDEV snp1
($:~)=> ./MAKEDEV snp2
($:~)=> ./MAKEDEV snp3

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.

($:~)=> cd /usr/src
($:~)=> make buildkernel KERNCONF=KERNELNAME

Hopefully everything will go well there. The kernel is ready to be installed at this point. You can ultimately issue the command:

($:~)=> echo “KERNELNAME” >> /etc/make.conf

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.

($:~)=> make installkernel KERNCONF=MYKERNEL

This will install the kernel.

To activate the kernel, a reboot is necessary. As root user, type the command

($:~)=> reboot

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,

($:~)=> shutdown now

After the system gets into single user mode,

($:~)=> cd /usr/src
($:~)=> make installworld

This will install all the updated binaries compiled from source downloaded by CVSup,
and the system is then ready to be rebooted.

($:~)=> reboot

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.

($:~)=> vi /etc/crontab

And add the following in there:

0 3 * * * root /usr/local/bin/cvsup /usr/local/etc/ports-supfile 1>/dev/null 2>&1

So what’s all this mean? Crontabs are pretty simple but commonly overlooked by system administrators. An easy breakdown of it is:


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.

($:~)=> chmod 700 /root

You might also want to look at the permissions in the users home directories. I would recommend changing them to 700 also.

Change permission of suid and sgid binaries Suid binaries allows a user to execute the program as a different user (usually root). Sgid works in similar fashion and allows the user to become another group. Some of the suid binaries are badly implemented and 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,

($:~)=> find / -perm –4000

To find all sgid binaries on a machine,

($:~)=> find / -perm –2000

Some binaries are almost for sure never to be touched, for those binaries, permission 000 should be given, this will disallow any read, write and execute from any user. For the binaries that are only useful to root, permission 500 should be given and should be owned by root, it would only allow root to execute and read them. Later in this document we will go over how permissions are defined.

Now I’m going to help you out a little bit here and show you an excellent application for managing suid and sgid binaries.

($:~)=> cd /usr/local/src ; fetch

($:~)=> tar –xzvf suidcontrol-0.1.tgz

($:~)=> cd suidcontrol ; make

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:

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,

($:~)=> 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

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

($:~)=> cd /var && mv ./tmp/* /tmp/ && rm –rf tmp && ln –s /tmp tmp

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.

($:~)=> chflags schg /bin/*
($:~)=> chflags schg /sbin/*
($:~)=> chflags schg /usr/sbin/*

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)

($:~)=>  chflags schg /kernel

The file /boot.config can be used to change kernel used at system bootup. To prevent this, do the following:

($:~)=>  touch /boot.config
($:~)=>  chflags schg /boot.config

Moving on, we need to change some permissions in /var/log. The permissions set by default tend to be a bit too liberal for my taste.

Remove any logs you don't use (refer to /etc/syslog.conf to see what you actually use) and chmod the files 600 (except the file wtmp which may be sane to chmod 640 so at least the wheel user may be able to use the 'last' command).

($:~)=>  cd /var/log
($:~)=>  chmod 600 *
($:~)=>  chmod 640 wtmp

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.

($:~)=>  touch /etc/ipf.rules
($:~)=>  touch /etc/ipnat.rules
($:~)=>  chmod 600 /etc/ip*.rules

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.

($:~)=> chmod 600 /etc/crontab
($:~)=> chmod 700 /root
($:~)=> chmod 700 /home/*
($:~)=> chmod 650 /etc/rc.*
($:~)=> chmod 600 /etc/master.passwd

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.

($:~)=> vi /etc/ssh/sshd_config

The key lines to change or add are the following:

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

Now you notice that were only going to allow users login that are in the ssh group. Lets go ahead and create one.

($:~)=> echo “ssh:*:666:soupx” >> /etc/group

Please remember to change soupx to your NORMAL user name. If you decide not to can you at least 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.

($:~)=> tar –cvvpzf /root/etc.tar.gz /etc
($:~)=> chmod 600 /root/etc.tar.gz

Now for an extra layer of protection lets encrypt that file.

($:~)=> openssl enc –blowfish –in /root/etc.tar.gz –out /root/

To unencrypt the file you would issue:

($:~)=> openssl enc –d –blowfish < /root/ | tar –xzf –

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


Disable probing of idle TCP connections to verify the peer is up and reachable


Do not respond to broadcast ping packets


ICMP error response bandwith limiting. Helps protect against DoS attacks.


And now jump back into the /etc/sysctl.conf file.

To defend against sequence number attacks based on rfc1948 by randomize initial sequence number


To verify that an incoming packet arrives on an interface that has an address matching the packet's destination address


Increase TCP Window size for increase in network performance


Change the ELF Branding fallback


Block SYN Cookies and other ICMP Stuff


"Tomorrow will be canceled due to lack of interest."

Last edited by soup4you2 on Wed Aug 20, 2003 6:02 pm; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website
Full Fledged Geek
Full Fledged Geek

Joined: 22 Jan 2003
Posts: 975

PostPosted: Thu Aug 21, 2003 12:36 pm    Post subject: Reply with quote

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.


Lets look at a simple example of a file.

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

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:

-rw-rw-r-- 1 soup4you2 soupx 852B Feb 22 00:26 note.txt

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

-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

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:


The information is divided into four parts


     -                rw-                        rw-                            r--
File Type, Owner Permissions, Group Permissions, World Permissions

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


     -     A Normal File
     d    A Directory
      l    A Symbolic link
     s    A Socket

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


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

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.

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

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

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

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

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

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.

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

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:

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

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:

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

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:

($:~)=> 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

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

($:~)=> umask

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.


Files: Directories
666    777
002    002
664    775

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.

($:~)=> cd /usr/ports/mail/postfix
($:~)=> make install clean

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

($:~)=> ln -s /usr/local/etc/postfix /etc/postfix

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

($:~)=> vi

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

"myhostname ="

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:

"mydomain ="

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:

"myorigin = $mydomain"

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:

"mydestination = $myhostname, localhost.$mydomain $mydomain virtualdomain1 virtual domain2"

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:

"home_mailbox = Maildir/"

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:

"relay_domains = $mydestination,"

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:

"mynetworks =,"

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:

"local_destination_concurrency_limit = 2"
"default_destination_concurrency_limit = 10"

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 mapped back to
If you’re using one of the above add it in, if not don't worry about it!

"sender_canonical_maps = hash:/etc/postfix/canonical"
"recipient_canonical_maps = hash:/etc/postfix/canonical-receive"

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!

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

(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 I like it a lot and it's free!

"maps_rbl_domains ="

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

"header_checks = regexp:/etc/postfix/header_checks"
"body_checks = regexp:/etc/postfix/body_checks"

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

"unknown_hostname_reject_code = 554"
"unknown_client_reject_code = 450"
"message_size_limit = 5000000"

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.

strict_rfc821_envelopes = yes

With this done, we are now through with the 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.

($:~)=> postmap

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 file it must be defined here. Basic syntax is one user per line followed by an OK so edit /etc/postfix/access now

"userid1@domain1 OK"
"userid2@domain1 OK"
"userid3@domain2 OK"

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:

"webmaster@domain1 OK"
"webmaster@domain2 OK"
"postmaster@domain1 OK"
"postmaster@domain2 OK"

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:

($:~)=> postmap access

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:

($:~)=> postfix reload


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 file, you don't need to worry about it here.


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 -> you need to specify that here. Syntax is: userid@domain userid@virtualdomain, or, userid@domain this file handles mail outgoing only! edit /etc/postfix/canonical now

"userid@defaultdomain userid@virtualdomain"
"userid2@defaultdomain userid2@virtualdomain"




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!

"userid1@defaultdomain userid1@defaultdomain"
"userid1@virtualdomain userid1@virtualdomain"
"userid2@virtualdomain userid2@virtualdomain"
"postmast@virtualdomain userid2@virtualdomain"
"webmaster@defaultdomain webmaster@defaultdomain"
"webmastr@virtualdomain userid2@virtualdomain"

Or for virtual usernames

" userid@domain"

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.


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 function where x is an ip address and function is either OK or REJECT!

" OK"

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!


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 function where the function is a reject code.

" 550 No Spam Accepted"
" 550 What kind of bogus address is that?"

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!


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.

"/^(.*)name="(.*). (com|vbs|vbe|js|jse|exe|bat|cmd|vxd|scr|hlp|swf|mpeg|mpg|mov|mp3|avi|pif|mpe|shs|ini)"$/ REJECT"

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!


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:


# 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"

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.


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!

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

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


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.


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

($:~)=> postfix start

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

($:~)=> cd /usr/ports/mail/courier-imap ; make install clean

Next we need to generate our imap ssl certs

($:~)=> /usr/local/share/courier-imap/mkimapdcert
($:~)=> cd /usr/local/etc/courier-imap/

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

($:~)=> for foo in *.dist; do cp $foo `basename $foo .dist`; done
($:~)=> mv quotawarnmsg.example quotawarning

Pretty simple on this one.

($:~)=> vi /usr/local/etc/courier-imap/imapd
($:~)=> vi /usr/local/etc/courier-imap/imapd-ssl

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.

($:~)=> cd /home/soupx
($:~)=> su soupx
($:~)=> maildirmake ./Maildir

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

($:~)=> maildirmake -q 10000000S ./Maildir

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.

($:~)=> maildirmake -S /var/mail/shared

Now we create our individual folders that we want shared.

($:~)=> maildirmake -s write -f bugtraq /var/mail/shared

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.

($:~)=> vi /usr/local/etc/courier-imap/maildirshared

An example is listed below:


# ===========================================
# Shared IMAP Folders
# ===========================================

Bugtraq    /var/mail/Shared/Bugtraq
FreeBSD /var/mail/Shared/FreeBSD
OpenBSD /var/mail/Shared/OpenBSD
NetBSD  /var/mail/Shared/NetBSD

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..

($:~)=> cd /usr/ports/mail/procmail ; make install clean

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

($:~)=> vi /etc/postfix/

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

mailbox_command = /usr/local/bin/procmail -m /usr/local/etc/procmailrc

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 for the information on this one.

($:~)=> cd /ports/mail/p5-Mail-SpamAssassin/ ; make install clean

Now we need to create a procmailrc file

($:~)=> vi /usr/local/etc/procmailrc


# tell procmail we use Maildir style

# specify the location for identified spam

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

# 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

# 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)

* ^X-Razor2-Warning: SPAM

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

| /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

* ^X-Spam-Flag: YES

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):


# Approve message identified as spam and deliver it
macro index A "| /usr/sbin/sendmail"

Now we need to create the Maildir for our spam.

($:~)=> maildirmake /var/mail/spam ; chown root:mail /var/mail/spam

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

($:~)=> mutt -f /var/mail/spam

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/ 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:

rewrite_subject 0
report_header 1
defang_mime 0

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.

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

Here’s a good starting configuration to use


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 =
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

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

($:~)=> cd /usr/ports/security/amavisd-new ; make install clean

Now lets move onto configuring it.

($:~)=> vi /usr/local/etc/amavisd.conf

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.

($:~)=> vi /etc/postfix/

And add in:

content_filter = smtp-amavis:[]:10024

Next edit the

($:~)=> vi /etc/postfix/

And add in:

smtp-amavis unix - - y - 2 smtp
-o smtp_data_done_timeout=1200
-o disable_dns_lookups=yes 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,reject
-o mynetworks=

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

Next we need our virus scanner

($:~)=> cd /usr/ports/security/clamav ; make install clean

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.

"Tomorrow will be canceled due to lack of interest."
Back to top
View user's profile Send private message Visit poster's website
Full Fledged Geek
Full Fledged Geek

Joined: 22 Jan 2003
Posts: 975

PostPosted: Thu Aug 21, 2003 12:37 pm    Post subject: Reply with quote

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.

($:~)=> vi /etc/rc.conf

Here’s the changes were going to be making.


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


If your using IPFW you would use something like this:


Now here we will activate the Ip monitoring utility.

ipmon_flags="-Dvn /var/log/firewall.log"

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.

($:~)=> vi /etc/ipf.rules


# ============================================
# 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 port < 3500 flags S keep state
pass out quick on sis0 proto tcp from any to port < 3500 flags S keep state
pass out quick on sis0 proto tcp from any to port < 3500 flags S keep state
pass out quick on sis0 proto tcp from any to port < 3500 flags S keep state   
pass out quick on sis0 proto tcp from any to port < 3500 flags S keep state
pass out quick on sis0 proto tcp from any to port < 3500 flags S keep state

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.

block out quick on sis0 proto igmp all

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 ! to any
block out quick on sis0 from any to
block out quick on sis0 from any to
block out quick on sis0 from any to
block out quick on sis0 from any to
block out quick on sis0 from any to
block out quick on sis0 from any to
block out quick on sis0 from any to
block out quick on sis0 from any to
block out quick on sis0 from any to
block out quick on sis0 from any to
block out quick on sis0 from any to
block out quick on sis0 from any to
block out quick on sis0 from any to
block out quick on sis0 from any to
block out quick on sis0 from any to
block out quick on sis0 from any to
block out quick on sis0 from any to
block out quick on sis0 from any to
block out quick on sis0 from any to
block out quick on sis0 from any to
block out quick on sis0 from any to
block out quick on sis0 from any to
block out quick on sis0 from any to
block out quick on sis0 from any to
block out quick on sis0 from any to
block out quick on sis0 from any to
block out quick on sis0 from any to
block out quick on sis0 from any to
block out quick on sis0 from any to
block out quick on sis0 from any to

#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 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

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).


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

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

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

block in quick on sis0 proto igmp all

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 to any
block in quick on sis0 from to any
block in quick on sis0 from to any
block in quick on sis0 from to any
block in quick on sis0 from to any
block in quick on sis0 from to any
block in quick on sis0 from to any
block in quick on sis0 from to any
block in quick on sis0 from to any
block in quick on sis0 from to any
block in quick on sis0 from to any
block in quick on sis0 from to any
block in quick on sis0 from to any
block in quick on sis0 from to any
block in quick on sis0 from to any
block in quick on sis0 from to any
block in quick on sis0 from to any
block in quick on sis0 from to any
block in quick on sis0 from to any
block in quick on sis0 from to any
block in quick on sis0 from to any
block in quick on sis0 from to any
block in quick on sis0 from to any
block in quick on sis0 from to any
block in quick on sis0 from to any
block in quick on sis0 from to any
block in quick on sis0 from to any
block in quick on sis0 from to any
block in quick on sis0 from to any

block in log quick on sis0 all

# Loopback Interface
pass in quick on lo0 all
pass out quick on lo0 all

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


A Updated copy of this howto may be found in PDF format at:

"Tomorrow will be canceled due to lack of interest."

Last edited by soup4you2 on Mon Sep 15, 2003 1:43 pm; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website
Full Fledged Geek
Full Fledged Geek

Joined: 22 Jan 2003
Posts: 975

PostPosted: Thu Aug 21, 2003 12:37 pm    Post subject: Reply with quote

Updated w/ more content.. enjoy Very Happy

"Tomorrow will be canceled due to lack of interest."
Back to top
View user's profile Send private message Visit poster's website

Joined: 13 Aug 2002
Posts: 61
Location: London, UK

PostPosted: Fri Aug 22, 2003 3:01 am    Post subject: Reply with quote

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. Smile

Stay a while, stay forever...
Back to top
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger

Joined: 13 Dec 2002
Posts: 375
Location: The void

PostPosted: Fri Aug 22, 2003 12:10 pm    Post subject: Reply with quote

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" Laughing

You know you've been playing Nethack too much when you look both ways down the corridor, start to sweat... then realise you're looking at your E-Mail address.
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
Full Fledged Geek
Full Fledged Geek

Joined: 22 Jan 2003
Posts: 975

PostPosted: Fri Aug 22, 2003 12:24 pm    Post subject: Reply with quote

i think we discussed this before..

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

"Tomorrow will be canceled due to lack of interest."
Back to top
View user's profile Send private message Visit poster's website

Joined: 13 Dec 2002
Posts: 375
Location: The void

PostPosted: Fri Aug 22, 2003 1:10 pm    Post subject: Reply with quote

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

You know you've been playing Nethack too much when you look both ways down the corridor, start to sweat... then realise you're looking at your E-Mail address.
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
Full Fledged Geek
Full Fledged Geek

Joined: 22 Jan 2003
Posts: 975

PostPosted: Fri Aug 22, 2003 1:28 pm    Post subject: Reply with quote

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

"Tomorrow will be canceled due to lack of interest."
Back to top
View user's profile Send private message Visit poster's website

Joined: 04 Feb 2003
Posts: 53

PostPosted: Tue Aug 26, 2003 12:12 pm    Post subject: 'ipfilter' options/files != PF Reply with quote

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:


options IPFILTER

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



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!


Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Screaming Electron Forum Index -> How-To's All times are GMT - 5 Hours
Goto page 1, 2, 3, 4, 5  Next
Page 1 of 5

Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB 2.0.6 © 2001, 2002 phpBB Group
Theme created by Vjacheslav Trushkin