OSS R&D

How to install webmin on CentOS 4

2009-07-30T02:04:00.000-07:00

Webmin is a web based control panel for system administrators for Unix/Linux. I use Webmin for reports mainly. More about Webmin here.

This is how you would install Webmin on Centos 4.

1. First start by downloading the latest version of Webmin. The current version is 1.400.

I prefer to use use wget to directly download the file onto the server but it’s up to you.

wget http://prdownloads.sourceforge.net/webadmin/webmin-1.400-1.noarch.rpm

2. Install the Webmin rpm package.

rpm -ivh webmin-1.400-1.noarch.rpm

[root@proxy0 /]# rpm -ivh webmin-1.400-1.noarch.rpm
warning: webmin-1.400-1.noarch.rpm: V3 DSA signature: NOKEY, key ID 11f63c51
Preparing... ########################################### [100%]
Operating system is CentOS Linux
1:webmin ########################################### [100%]
Webmin install complete. You can now login to https://proxy0.klm1.netcel360.com:10000/
as root with your root password.

3. Check if the Webmin service has been started.

service webmin status

[root@proxy0 /]# service webmin status
webmin (pid 4878) is running

That’s it, you can now login using your root id at https://localhost:10000

InstantSSL Certificate Installation: Apache & mod_ssl / OpenSSL

2009-07-30T02:00:00.000-07:00

Solution
Installing your Certificate on Apache Mod_SSL / OpenSSL
Step One: Copy your certificate to a file on your apache server

You will receive an email from Comodo with the certificate in the email. The certificate will be called 'yourDOMAINNAME.crt' and will be within a *.zip file you have received as an email from us. When viewed in a text editor, your certificate will look something like this:

-----BEGIN CERTIFICATE-----
MIAGCSqGSIb3DQEHAqCAMIACAQExADALBgkqhkiG9w0BBwGggDCCAmowggHXAhAF
UbM77e50M63v1Z2A/5O5MA0GCSqGSIb3DQEOBAUAMF8xCzAJBgNVBAYTAlVTMSAw
(.......)
E+cFEpf0WForA+eRP6XraWw8rTN8102zGrcJgg4P6XVS4l39+l5aCEGGbauLP5W6
K99c42ku3QrlX2+KeDi+xBG2cEIsdSiXeQS/16S36ITclu4AADEAAAAAAAAA
-----END CERTIFICATE-----

Copy your Certificate into the same directory as your Private Key. In this example we will use '/etc/ssl/crt/'. The private key used in the example will be labeled 'private.key' and the public key will be 'yourDOMAINNAME.crt'.

Note: It is recommended that you make the directory that contains the private key file only readable by root.
Step Two: Install the Root and Intermediate Certificates

You will need to install the Root and Intermediate CA certificates in order for browsers and devices to trust your certificate. The Root and Intermediate CA certificates are contained within the 'ca-bundle' file that was attached to your email in the *.zip file we sent you (this should be named 'yourSERVERNAME.ca-bundle'). In the relevant 'Virtual Host' section for your site, you will need to do the following to get this file correctly referenced:

a. First, copy the 'yourSERVERNAME.ca-bundle' file to the same directory as the certificate and key files. As a reminder, in this example we called the directory '/etc/ssl/crt/'.

b. Next, add the following line to the SSL section of the 'httpd.conf' file. Again we assume that '/etc/ssl/crt/' is the directory to where you have copied the intermediate CA file. If the line already exists amend it to read the following:

SSLCertificateChainFile /etc/ssl/crt/yourSERVERNAME.ca-bundle

c. If you are using a different location and different certificate file names, you will need to change the path and filename to reflect the path and filename that you are using. The SSL section of the updated config file should now read:

SSLCertificateFile /etc/ssl/crt/yourDOMAINNAME.crt
SSLCertificateKeyFile /etc/ssl/crt/private.key
SSLCertificateChainFile /etc/ssl/crt/yourSERVERNAME.ca-bundle ***

d. Save your 'config' file and restart Apache.
*** For Apache 1.x: Please use: SSLCACertificateFile /etc/ssl/crt/yourSERVERNAME.ca-bundle

apache apache apache apache apache apache apache apache apache
Note: The SSL configuration file will always be referenced in the apache config file if the configuration is not included in it. Look for the lines starting 'include', which is the directive for including other files etc. For example, depending on the distribution, it might be called ssl.conf, httpd-ssl.conf etc

LF not found where expected

2009-07-16T00:38:00.000-07:00

I put here for reference

[Dovecot] LF not found where expected

I'm using Dovecot 0.99.13 on a fedora core 3 server.
I keep getting these errors from time to time.
There user ends up retrieving no mail (but no error in their client, be it web mail or pop3 client)
What usually fixes it is this procedure:
Cp mbox file to mbox_
Remove original mbox
Send a test message to recreate mbox.
Cat mbox_ >> mbox
Problem solved!

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

pop3(mjmurray): Jun 27 11:16:38 Error: Error indexing mbox file /var/mail/mjmurray: LF not found where expected
pop3(mjmurray): Jun 27 11:16:38 Error: Error indexing mbox file /var/mail/mjmurray: LF not found where expected
pop3(mjmurray): Jun 27 11:16:38 Error: Couldn't open INBOX: Internal error occured. Refer to server log for more information. [2005-06-27 11:16:38]
pop3-login: Jun 27 11:17:06 Info: Login: mjmurray [64.203.167.125]
pop3(mjmurray): Jun 27 11:17:06 Error: Error indexing mbox file /var/mail/mjmurray: LF not found where expected
pop3(mjmurray): Jun 27 11:17:06 Error: Error indexing mbox file /var/mail/mjmurray: LF not found where expected
pop3(mjmurray): Jun 27 11:17:06 Error: Couldn't open INBOX: Internal error occured. Refer to server log for more information. [2005-06-27 11:17:06]
imap-login: Jun 27 11:17:28 Info: Login: mjmurray [127.0.0.1]
imap(mjmurray): Jun 27 11:17:28 Error: Error indexing mbox file /var/mail/mjmurray: LF not found where expected
imap(mjmurray): Jun 27 11:17:28 Error: Error indexing mbox file /var/mail/mjmurray: LF not found where expected
imap-login: Jun 27 11:19:12 Info: Login: mjmurray [127.0.0.1]
imap(mjmurray): Jun 27 11:19:12 Error: Error indexing mbox file /var/mail/mjmurray: LF not found where expected
imap(mjmurray): Jun 27 11:19:12 Error: Error indexing mbox file /var/mail/mjmurray: LF not found where expected

... Miles Mawyer -=- Webmaster . Centralva.net ...
... mmawyer at rosecomputers.com ...

Linux setup default gateway with route command

2009-07-07T00:16:00.000-07:00

Linux setup default gateway with route command

Q. How do I setup default gateway with a route command?

A. route command show and/or manipulate the IP routing table under Linux and UNIX oses.

Route manipulates the kernel's IP routing tables. Its primary use is to set up static routes to specific hosts or networks via an interface after it has been configured with the ifconfig program. When the add or del options are used, route modifies the routing tables. Without these options, route displays the current contents of the routing tables.
Display default route

Following three-command display the current routing table:
# route
Output:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 * 255.255.255.0 U 0 0 0 ra0
default dsl-router 0.0.0.0 UG 0 0 0 ra0

$ /sbin/route
Output:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
191.255.255.0 * 255.255.255.0 U 0 0 0 eth0
169.254.0.0 * 255.255.0.0 U 0 0 0 eth0
default 191.255.255.1 0.0.0.0 UG 0 0 0 eth0

You can use -n option, to display numerical addresses instead of trying to determine symbolic host names (via dns or /etc/hosts file). This is useful if you are trying to determine why the route to your nameserver has vanished.$ /sbin/route -nOutput:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
191.255.255.0 0.0.0.0 255.255.255.0 U 0 0 0 venet0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 venet0
0.0.0.0 191.255.255.1 0.0.0.0 UG 0 0 0 venet0

Please note that a destionation entry 0.0.0.0 (or default) is the default gatway. In above example 191.255.255.1 is a default gatway.
Add / setup a new route

The syntax is as follows:
route add default gw {IP-ADDRESS} {INTERFACE-NAME}

Where,

* IP-ADDRESS: Specify router IP address
* INTERFACE-NAME: Specify interface name such as eth0

For example if your router IP address is 192.168.1.254 type the following command as the root user:
# route add default gw 192.168.1.254 eth0OR use hostname such as dsl-router:
# route add default gw dsl-router eth0

Setting route using GUI tools/command under Linux

If you find above command hard to use, consider using GUI tools. If your are using Red Hat/CentOS/Fedora core Linux type following command:# redhat-config-networkOR If you are using other Linux distribution use command:
# network-admin

PCLinuxOS 2009.1

2009-06-20T12:02:00.000-07:00

PCLinuxOS 2009.1 Final Released

This release features kernel 2.6.26.8.tex3, KDE 3.5.10, Open Office 3.0, Firefox 3.0.7, Thunderbird 2.0.0.14, Ktorrent, Frostwire, Amarok, Flash, Java JRE, Compiz-Fusion 3D and much more. We decided to use kde3-5-10 as our default desktop as we could not achieve a similar functionality from kde4. We will however offer kde4 as an alternative desktop environment available from the repository once we stabilize it. PCLinuxOS is an rpm based distribution utilizing apt-get with a Synaptic Software Manager frontend. In addition to the above PCLinuxOS comes with mklivecd GUI, a nice utility to build a custom live CD from your install. Install or remove what you want then remaster your own cd. Great for backups or to give to friends. PCLinuxOS is also known as as rolling release distribution. What that means is you install once and update it when new applications become available from our repository.

More details..

Setup a Spam Filter with SpamAssasin with Postfix

2009-06-15T09:46:00.000-07:00

If you receive a lot of spams here is a quick solution to filter spams using SpamAssasin and Postfix. Also spamd will be used (which is include within SpamAssasin). There are other implementations that we will cover in other tutorials.

Step 1. Install Postfix
-----------------------------
We will install Postfix from Ports:

cd /usr/ports/mail/postfix
make install

If you want to use Postfix with MySQL, you must check MySQL before compilation, also you may want to check Dovecot, to use Dovecot SASL authentication method. We recommend you dovecot over cyrus-imap.

After installation, configure postfix by editing: /usr/local/etc/postfix/master.cf and /usr/local/etc/postfix/main.cf

# -------------------- main.cf -----------------------------------------
queue_directory = /var/spool/postfix
command_directory = /usr/local/sbin
daemon_directory = /usr/local/libexec/postfix
mail_owner = postfix
unknown_local_recipient_reject_code = 550
mynetworks_style = host

debug_peer_level = 2

debugger_command =
PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
xxgdb $daemon_directory/$process_name $process_id & sleep 5

sendmail_path = /usr/local/sbin/sendmail
mailq_path = /usr/local/bin/mailq
setgid_group = maildrop
html_directory = no
manpage_directory = /usr/local/man
sample_directory = /usr/local/etc/postfix
readme_directory = no
#smtpd_recipient_restrictions = check_relay_domains, permit

mydomain = example.com
myhostname = firewall.$mydomain
myorigin = $myhostname
mydestination = $myhostname, localhost,$mydomain

mynetworks = 10.0.0.5/32
mynetworks_style = subnet
# --------- end of file main.cf --------------------

Also add the following line to /etc/rc.conf
postfix_enable="YES"

Notes:
Note1
--------
Don't forget to setup in main.cf the variable: mydestination = $myhostname, localhost,$mydomain
If you forget to do that, you will get rely denied error, and emails that comes to your domain name will be rejected.
If you have many domains you can use transport_maps variable:

mydestination = $mydomain, $myhostname, $transport_maps, localhost

Transport maps can be also used from within mysql (for large mail servers with postfix compiled and configured with virtual users and MySQL support. If you are interested there is a tutorial on that topic on our website.

Note2
--------
Make sure you either add your IP in main.cf with your mynetworks variable or setup smtp server with authentication and allow your username to use SMTP with authentication.

mynetworks = 10.0.0.2/32

Step 2. Install SpamAssasin
---------------------------------------
cd /usr/ports/mail/p5-Mail-SpamAssassin
make install

Step 3. Configure SpamAssasin
--------------------------------------------
After compilation and installation of SpamAssasin (which is written in Perl) from ports, as described in Step 2, create a config file for spamassasin:

touch /usr/local/etc/mail/spamassasin/local.cf

with the following content:
# ---------- local.cf --------------
rewrite_header Subject *****SPAM*****

# trusted_networks 10.0.0.
# lock_method flock
# use_bayes 1
# bayes_auto_learn 1

required_score 5.0
report_safe 1

whitelist_from dan@example.com This email address is being protected from spam bots, you need Javascript enabled to view it
# --------- end of local.cf

If you want to catch more spams, but also you will have more false positive, lower required_score. Higher score will catch less spams.

Step 4. Start spamd
----------------------------
Edit /usr/local/etc/rc.d/sa-spamd and change spamd_enable to "YES".
Then, start spamd:

/usr/local/etc/rc.d/sa-spamd start

Step 5. Edit master.cf and add support for spamassasin
-------------------------------------------------------------------
Edit /usr/local/etc/postfix/master.cf, replace line:

smtp inet n - n - - smtpd
with:
smtp inet n - - - - smtpd
-o content_filter=spamassassin

And then add the following lines to master.cf.

spamassassin unix - n n - - pipe
user=spamd argv=/usr/local/bin/spamc -f -e
/usr/sbin/sendmail -oi -f ${sender} ${recipient}

Step 6. Restart postfix and test the setup
---------------------------------------------------------

/usr/local/etc/rc.d/postfix restart

To Forwarding /NATing using iptables

2009-06-15T09:35:00.000-07:00

iptables file configuration /etc/sysconfig/iptables,

To forwarding /NATing :

Assuming external internet card is eth0, and external IP is 123.12.23.43 and the internal network card is eth1, then:

iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to x.x.x.x

to allow port webmin xs

iptables -A INPUT --protocol tcp --dport 10000 -j ACCEPT

Last step for Fedora/RHEL users. In order for your system to save the
iptables rules we setup in step two you have to configure itpables
correctly. You will need to edit /etc/sysconfig/iptables-config
and make sure IPTABLES_MODULES_UNLOAD,
IPTABLES_SAVE_ON_STOP, and
IPTABLES_SAVE_ON_RESTART are all set to 'yes'.

sources : http://tldp.org/HOWTO/html_single/Masquerading-Simple-HOWTO/

How to uninstall ISPConfig

2009-05-23T01:14:00.000-07:00

How to uninstall ISPConfig ?

Log in to your command line as root and type the following:

/root/42go/uninstall

If the uninstall script fails, you can remove ISPConfig manually by deleteing these directories:

rm -rf /root/ispconfig
rm -rf /home/admispconfig

What is the difference between complete and partial deinstallation of the ISPConfig system ?

* Partial deinstallation means that only the ISPConfig system itself will be uninstalled, not the objects created by it (web sites, users, DNS records, etc.).
* With complete deinstallation also the objects created by the systems (web sites, users, DNS records, etc.) will be uninstalled. Thus, the server is reset to its original state.

The following Error messages during uninstall !

shell-init: could not get current directory: getcwd: cannot access parent directories: No such file or directory

This is normal. The program /root/ispconfig/uninstall deletes its own parent directory ie /root/ispconfig and thus cannot find it anymore. Nevertheless the uninstall will be completed. Just ignore the error message.

Installing Sun VirtualBox in CentOS-5

2009-05-19T22:10:00.000-07:00

Installing Sun xVM VirtualBox in CentOS-5

Hello i find this is the best way of installing the VirtualBox for your CentOS
Just follow the steps below and i hope you will be done with it soon.

Just go to the below url and download the RPM
https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_SMI-Site/en_US/-/USD/ViewProductDetail-Start?ProductRef=innotek-1.6-G-F@CDS-CDS_SMI

Then select your platform as Redhat 5, and tab on “I Agree” and Click on Continue
And here you go now your download starts and once its done.
Go to the directory where your download have been saved and just right click on the package and select the option “Open With Software Installer”
Now your system may ask for the “root password” kindly supply the same then tab on “Apply” and then tab on “Install Anyway” your are done with this
now your Sun xVM VirtualBox has been installed and can be found in “Application–> System Tool–>Sun xVM VirtualBox… go ahead and enjoy

Postfix message and mailbox size limits

2009-05-18T22:06:00.000-07:00

*I learned some more about Postfix today*

This morning I got a call from my client with the new mail server. They were getting an error message when trying to send a file with a 7 MB attachment. Since they send and receive a lot of attachments (of which a 7 meg file would be on the small side) this needed to be fixed. The message they were getting indicated and inability to access a mailbox. I skimmed through /var/log/maillog and found this:

Dec 12 10:48:47 postoffice postfix/local[14046]: 0671D344040: to=, relay=local, delay=33, status=bounced (cannot access mailbox /var/spool/mail/foo for user foo. error writing message: File too large)

I was a bit surprised, since I made sure that /etc/postfix/main.cf did not include any limits on email sizes. After some time searching on Google, it looked like the default value for a mailbox size according to Postfix is 51200000 bytes. I wanted it to be unlimited, so I used postconf to explicitly set the value to 0, for no limit, like so...

% postconf –e mailbox_size_limit=0

... then restarted Postfix.

I then tried to send a 12 MB file from my Gmail account to my test account on the box. I got an SMTP 552 error, “Message too large” back from the box. Again, I skimmed the maillog file and this time came across:

Nov 7 15:51:33 postoffice postfix/postdrop[14200]: warning: uid=48: File too large

Back to Google, whereupon I learnt that the default max message size for Postfix is 10240000 bytes. To fix it I ran:

% postconf –e message_size_limit=0

Again, I restarted Postfix and then resent my test email. This time it went through.

If you want to view the default settings for all the parameters you can configure in main.cf, use postconf –d. The output of postconf –d | grep size looks like:

[root@foo]# postconf -d | grep size
berkeley_db_create_buffer_size = 16777216
berkeley_db_read_buffer_size = 131072
body_checks_size_limit = 51200
bounce_size_limit = 50000
header_size_limit = 102400
mailbox_size_limit = 51200000
message_size_limit = 10240000

As an aside, since Postfix on this box is started by MailScanner, I restarted the MailScanner daemon to restart Postfix, like this:

% /etc/init.d/MailScanner restart

which stops the inbound and outbound Postfix queus then starts them again.

Lawan malware dan spam dengan Postfix | Fighting malware and spam with Postfix

2009-05-18T20:22:00.000-07:00

*i found this from others site, then i put here for reference.*

Background

Postfix ( http://www.postfix.org/ ) is the popular Sendmail replacement that is fast, secure, and easy to administer.

Postfix also makes an outstanding email security gateway or "mail firewall", shielding fragile Intranet mail systems such as WOE (Windows/Outlook/Exchange) or Lotus Notes from direct contact with the Internet.

Postfix's functionality can be extended by filtering mail through external programs. By using external filters, Postfix can do content filtering including scanning for viruses and MS Outlook exploits, and identifying spam.

This paper demonstrates how to use the filtering capabilities of Postfix to perform high-level content filtering including:

* Dropping potentially hostile attachments such as .EXE and .VBS files
* Preventing MS Outlook from auto-executing unknown attachments
* Preventing exploits embedded in HTML email and MIME headers
* Disabling "web bugs" that spammers use to track recipients
* Identifying spam based on message content

The method shown here is multi-purpose: it is suitable for local mail (where the email is stored on the Postfix server itself) and also suitable for when Postfix is used as a "mail firewall" to relay mail to an internal mail system. Unlike endpoint solutions like Outlook plugins that must be installed and managed on each workstation. This method also has the advantage of applying one spam and content filtering policy for all users. Users can also share one auto-whitelist database, reducing the chance that legitimate mail will be labelled as spam.

However, if you require unique settings for each user it may be better to filter mail via a mail delivery agent such as procmail or maildrop (http://www.courier-mta.org/maildrop/) instead of using the method shown here.
The software

We extend the capabilities of Postfix using two best-of-breed open source programs that perform content filtering and spam identification:
Anomy Sanitizer

Anomy Sanitizer ( http://mailtools.anomy.net/ ) is an open source email content filter that disables all the hostile content of email messages that anti-virus programs ignore: potential buffer overflows, MIME exploits, web bugs, dangerous HTML tags, and other problems that have made MS Outlook such a security nightmare.

Anomy Sanitizer is written in Perl. It filters SMTP messages checking for most known exploits and hostile file attachments. It can remove attachments, rename unknown file types, "defang" exploitable HTML tags, fix MIME headers and generally cleans up malformed email.

Cleaning up malformed email is essential: virus scanners have a history of missing attachments in malformed email. Attackers regularly alter MIME structures in email so malicious content becomes invisible to antivirus but still works when the user opens it in the email client
SpamAssassin

SpamAssassin ( http://spamassassin.apache.org/ ) is a mail filter that attempts to identify junk e-mail ("spam"). It examines the content of mail messages looking for key phrases and other identifiers commonly used by spammers.

SpamAssassin uses a scoring system: messages are tagged as spam only when they have enough spam characteristics in total. When combined with other features this results in very few false positives. In our experience, a properly managed SpamAssassin installation correctly identifies 95% to 98% of spam with less than 1% false positives.

SpamAssassin doesn't block spam. Instead, it tags messages as probable spam by changing the message headers and (optionally) the Subject line. This is wise: no automated system can recognize spam with complete certainty... deciding "what is spam" is a judgement call. All automated spam filters will produce some false positives (wanted e-mail mistakenly tagged as spam) and false negatives (spam not identified as such).

SpamAssassin identifies messages that are probable spam, but leaves the choice of what to do with it up to you. Most organizations instruct their users how to add rules to their e-mail software to delete identified messages or, better yet, move them to a folder for later review. Others choose to use an additional filter automatically delete extremely high scoring messages or put them in a holding area for further review by an administrator.

In our opinion, the best approach is to tag low scoring messages as possible spam and deliver it to the user so they can make the final call. For high scoring spam, sideline it for review by an administrator or automatically delete it.

The method shown here only tags suspected spam. No automated deletion or sidelining is performed. However, we have a collection of alternative filter script that will sideline or delete suspected spam available at http://advosys.ca/examples/filter-misc/.
Preparing the server
Prerequisites

Before you begin, here is what you will need:

1. A Unix-type server such as Linux or BSD. The method shown here has been used on Solaris, Debian Linux, Ubuntu Linux, RedHat Linux and FreeBSD.
2. Postfix version 2.0.1 or higher (type postconf mail_version at the Unix command line to see the version number). This method does not work with Postfix 1.1.x.
3. At least Perl 5.005_03 or higher. Type perl -v at the command line to see the version number. Perl 5.6 or higher is recommended, but it is best to stick with the version of Perl your system provides by default.

NOTE: Your server must already have Postfix installed and working. Please do not try to follow these instructions until you first have a basic installation of Postfix working.
Creating a filter account

To use external filtering with Postfix, first add a new a Unix group on the server named "filter" (use groupadd or addgroup as appropriate to your system).

Next, add a new user account named "filter" on the server and make it a member of group "filter". Set the account's home directory to /var/spool/filter. This will be the account used by the filtering scripts.

No other user should belong to group "filter". For now, give the filter account a password and a valid login shell. You should be able to use the "su" command to login as user filter. This will make troubleshooting easier. Don't worry... later we will disable logins for the account to improve security.
Installing required Perl modules

Also, download and install the following Perl modules from CPAN ( http://search.cpan.org/ ):

* MIME::Base64
* MIME::QuotedPrint
* Net::DNS
* DB_File

If you've set up the CPAN module in your Perl installation, the easiest way to add these modules is to use CPAN to download, build and install automatically:

perl -MCPAN -e shell
o conf prerequisites_policy ask
install MIME::Base64
install MIME::QuotedPrint
install Net::DNS
install DB_File
quit

Installing Anomy Sanitizer

Download the latest version of Anomy Sanitizer from http://mailtools.anomy.net/

Install it by unpacking the tar file into a suitable directory on your mail server. We recommend using directory /usr/local/anomy but any other directory will work. After unpacking, it's a good idea to read the instructions and notes in file sanitizer.html in the anomy directory.
Anomy configuration

In directory /usr/local/anomy, create a file named anomy.conf and add your anomy configuration rules. The specific settings you choose depends on your particular e-mail policies and the type of internal e-mail software you are protecting. The "real world configuration" shown in the Anomy documentation is a good starting point.

Below is a configuration we've used on mail gateways to protect Windows-Outlook-Exchange users. It defangs HTML and MIME exploits, plus drops all executable attachments (we strongly recommend dropping executable attachments as a general policy: see our paper "E-mail policies that prevent viruses" at http://advosys.ca/papers/mail-policies.html).

Download: anomy.conf

Once the config file is in place, change ownership of the entire anomy directory tree to owner "root", group "filter". For example:

chown -R root:filter /usr/local/anomy

Change permissions on the anomy directory tree so it is not world readable. For example:

chmod 0750 /usr/local/anomy

Installing SpamAssassin

Some Linux distributions provide packaged versions of SpamAssassin and Anomy Sanitizer as RPM or DEB files. Usually these packaged versions are out of date, move files from the default locations and make other subtle changes. To avoid problems, we recommend removing packaged versions of SpamAssassin and installing manually as described below.

Refer to your system documentation for details on how to use its package manager (e.g.: on Redhat Linux, the command is rpm. On Solaris, use pkginfo).

The SpamAssassin documentation describes how to install and configure that software. As described above, if you have the CPAN module set up on your server, it can download and install SpamAssassin automatically. For example:

perl -MCPAN -e shell
o conf prerequisites_policy ask
install Mail::SpamAssassin
quit

SpamAssassin configuration

SpamAssassin is installed "out of the box" with a good set of spam identification rules. You can specify your own settings in file /etc/mail/spamassassin/local.cf.

It's a good idea to leave local.cf unchanged until you get things working and have a feel for how the default rules work. Later on you can fine tune SpamAssassin settings in local.cf as required.

However, we recommend making one change to local.cf right away: Whitelist well-known senders so their mail will never be identified as spam:
Manual whitelists

You should whitelist the e-mail addresses of well-known legitimate senders to avoid the chance of them being misidentified by the SpamAssassin default rules. Add "whitelist_from" settings to file /etc/mail/spamassassin/local.cf for each important client, mailing list and other known spam free senders. For example:

whitelist_from director_8345@ hotmail.com # whitelist one sender
whitelist_from *@advosys.ca # whitelist entire domain
whitelist_from *@securityfocus.com

Configuring filtering in Postfix

You must have Postfix installed and accepting mail the way you want. To preserve your mental health, do not attempt to add filtering and get a first-time installation of Postfix working at the same time. Many have tried, all have failed. Be wise: install and configure Postfix first, and verify it is working the way you want (accepting mail for your domain(s), relaying to and from internal servers, and so on). Getting Postfix running the first time is complex enough without also trying to add filtering.

The After queue content filter README (http://www.postfix.org/FILTER_README.html) in the Postfix documentation describes ways to add external content filtering to Postfix. Here we use a variation of the "Simple content filtering" method described in that file: plug a shell script into Postfix by modifying the master.cf file.
Creating the filter script

The following method pipes each message sent to it through Anomy Sanitizer, then through SpamAssassin. The command-line "sendmail" compatibility command that is part of Postfix is then used to queue the result for final delivery.

Note: Modify the file locations specified in this file to match the locations on your server. File locations vary depending on your flavour of Unix/Linux/BSD and other factors.

Download: filter.sh

Place the filter.sh script into the same directory you installed Anomy Sanitizer (e.g.. /usr/local/anomy ). The script should have the following permissions:

-rwxr-x--- owner=root group=filter

Create a temporary directory

The script needs a directory to store temporary files. Create a directory that is writable by group "filter". For example:

mkdir /var/spool/filter
chown root:filter /var/spool/filter
chmod 0770 /var/spool/filter

The directory should be located on a partition large enough to store a few incoming mail messages. On most systems, the /var partition is the best choice. Whatever directory you choose, change the INSPECT_DIR setting in filter.sh to match.
Send a test message

Before activating all this in Postfix, it's wise to first try sending a few test messages from the command line.

As root, use the "su" command to change to user filter. For example:

su filter

Change to the /var/spool/filter directory if not there already. Use your favorite text editor to create a file named "test.txt" containing the following:

From:
To:

Hi there. This is a test message.

(The blank line between the "To:" and "Hi there" is required).

Send the above test message through the filter script as follows:

cat test.txt | /usr/local/anomy/filter.sh -f tester -- root

If things are working, no error messages should be printed and the shell prompt should return. Check the mail for account "root": you should have received the test message.

SpamAssassin may emit a warning that it "cannot create user_prefs". Ignore this warning.

If you see error messages, such as "cannot execute..." or "cannot find...", or the message arrives but is blank, double check what you just typed and try again. Depending on your system, the error messages should lead you to where the error is... in the anomy program, the filter.sh shell script, or file permissions. Incorrect file and directory permissions or wrong pathnames in the filter script are the most frequent cause of problems... check everything twice!

The Anomy filter can be debugged by temporarily changing the value of $ANOMY_LOG in filter.sh from /dev/null to an actual file, such as /tmp/anomy.log (make sure the user filter has write access to that file), then set feat_log_inline = 1 in file anomy.conf. Remember to change the settings back to the original when you are finished troubleshooting.

Resolve all the errors before proceeding... if you can't send mail manually using this method, Postfix won't be able to send any either.
Creating a recipient map

We need to create a recipient access map so Postfix will know which e-mail domains to filter. Without this map, Postfix will not filter any e-mail, inbound or outbound, through SpamAssassin and Anomy.

Change to directory /etc/postfix and create a new file named filtered_domains. Add something like to following to the file:

# Filter only mail addressed to local domains:
example.com FILTER filter:dummy
example.net FILTER filter:dummy
otherdomain.ca FILTER filter:dummy

Of course, replace the above domains with your own e-mail domain names. You need one line for each domain you receive mail for.

If you have a domain you receive mail for but don't want filtered, simply don't list it in the file: Postfix will still accept mail for the domain and deliver it, unfiltered.

Save the file and use command postmap filtered_domains to create the corresponding data file.
Changing main.cf

In file /etc/postfix/main.cf look for the setting smtpd_recipient_restrictions

That setting may not be present or may be commented out, depending on your particular installation of Postfix. Add the setting or if it already exists, edit it similar to the following:

smtpd_recipient_restrictions =
check_recipient_access $default_database_type:/etc/postfix/filtered_domains
...existing settings, if any...
reject_unauth_destination

* If there is already a check_recipient_access setting present, do not replace it... add the above as a second setting, but place it after any other check_recipient_access settings.

Here is an example of what the smtpd_recipient_restrictions setting could look like it it's entirety. Your setting does not have to be the same... this is just an example:

smtpd_recipient_restrictions =
reject_non_fqdn_sender
reject_non_fqdn_recipient
permit_mynetworks
reject_unknown_sender_domain
check_recipient_access $default_database_type:/etc/postfix/recipient_access
check_recipient_access $default_database_type:/etc/postfix/filtered_domains
check_sender_access $default_database_type:/etc/postfix/sender_access
reject_unknown_recipient_domain
reject_rbl_client zen.spamhaus.org
reject_unauth_destination

Save the changes to main.cf and proceed to the next step.
Changing master.cf

Add the following to the bottom of file /etc/postfix/master.cf:

filter unix - n n - - pipe
flags=Rq user=filter argv=/usr/local/anomy/filter.sh -f ${sender} -- ${recipient}

Save the changes to master.cf and use command postfix reload to tell Postfix to re-read the configuration files.
Testing it out

Postfix should now be filtering messages it receives for your local domains through both Anomy Sanitizer and Spamassassin.

Test it by sending a few messages with MIME attachments through Postfix addressed to recipients in your domain. The Postfix log file should show each the message being received twice: once by the SMTP daemon with "recipient address", then again by the command-line "sendmail" compatibility program.

Each message should also now have SpamAssassin headers such as X-Spam-Status:.
Tightening security

Now that things are working, disable interactive logins for user "filter". Allowing logins for accounts used only by scripts and daemons is a dangerous security hole.

To disable logins, change the shell for user "filter" to /bin/false or some other invalid shell (use the chsh or usermod commands, or edit /etc/passwd). On Linux and Solaris, you can also "lock" the account using "passwd -l filter".
Separating inbound mail from outbound

The configuration described above filters messages based on the recipient domain in each e-mail message. This prevents outbound mail from being filtered through Anomy and SpamAssassin.

Local e-mail (e.g.. someone in "example.com" sending to another person with an "example.com" address) will also not be filtered, provided two conditions are met:

1. Your smtpd_recipient_restrictions setting lists permit_mynetworks before it lists check_recipient_access (the restrictions list shown above illustrates this).
2. The sender's IP address is within the range specified by the $mynetworks setting in your main.cf file.

If your organization has remote users who send mail to your domain from outside your $mynetworks range (e.g.. laptop travelers using an ISP dialup, home telecommuters, etc.), mail from them will be filtered.

To prevent this, you might be tempted to just expand your $mynetworks range to include the external ISPs. However, that makes your mail server an open relay... allowing spammers on those ISPs to freely abuse your mail server.

A better method is to using SASL authentication: external users require a username and password to send mail through your server. The Postfix documentation page ( http://www.postfix.org/docs.html ) lists several HOWTOs on adding SASL authentication to Postfix. Most versions Linux that include Postfix provide additional packages to enable SASL.

Once SASL is enabled, list permit_sasl_authenticated right after permit_mynetworks in smtpd_recipient_restrictions and senders who use a username and password to connection to the server will be able to bypass the content filtering and mail relay controls.
A word about performance

The method shown here is an easy and reliable way to filter messages with Postfix. However, performance suffers because each e-mail message has the overhead of invoking a shell, starting the Perl interpreter, and creating a temporary file.

The file creation overhead can be greatly reduced by mounting directory /var/spool/filter as a memory filesystem ("tmpfs" in Linux and Solaris). These filesystems are thousands of times faster than physical disk and are ideal for short-lived temp files.

SpamAssassin performance can be improved by using spamd, the "daemonized" version of that program ( http://svn.apache.org/repos/asf/spamassassin/branches/3.2/spamd/README ). See our collection of alternative scripts, below, for a spamd version of filter.sh.

Ideally the Anomy program should also have a daemon version, but no such version exists yet. Tricks like compiling sanitizer.pl using the perlcc compiler in Perl 5.6+, or using Persistent Perl ( http://daemoninc.com/PersistentPerl/ ) helps a little.

However, even without tmpfs or daemon versions of the programs, the method described above has been able to filter upwards of 50,000 messages per day on one dual-processor Sun e250 server with 512MB memory. A Linux implementation on a single-cpu 750Mhz Pentium II platform with 512MB demonstrated similar performance levels.
Other filtering scripts

It's easy to change the filter.sh shell script to suit your own needs. Each email message is a standard text file so basic shell programming or Perl can be used to process it as you wish.

We've written a few alternative filtering scripts and made them available here:
http://advosys.ca/examples/filter-misc/

The scripts are fully functional and demonstrate ways to extend the functionality of Postfix filtering. Feel free to experiment with the scripts and adapt them for your own use.

SMTP Authentication for Mail servers

2008-09-21T23:43:00.000-07:00

SMTP Authentication for Mail servers

SMTP AUTH for mail server is a feature that is often required to relay mail through other mail servers. To enable SMTP AUTH for Postfix, acting as mail client in this scenario, you need to do the following steps:

Procedure 10. Configure SMTP AUTH for mail servers

Provide a file, which will holds necessary information about credentials
Configure Postfix to enable SMTP AUTH for the smtp daemon
Configure Postfix to use the file with the SASL credentials.

1. Add credentials to sasl_passwd

Postfix, acting as mail client in this scenario, will need to be able to

know when to provide a username and password
pick the right credentials when there is more than one mail server who requires Postfix to SMTP AUTH

1.1. Enter credentials

These informations are layed down in /etc/postfix/sasl_passwd:

[root@mail postfix]# less /etc/postfix/sasl_passwd
# foo.com         username:password
# bar.com            username:password

	Using the hostname Postfix can identify the correct username:password when there are multiple entries in sasl_passwd
	username:password are entered in plaintext format. They are separated by a single colon “:”

The mail server that we want to relay through in this example is mail.my-isp.org; username is test and it's password is testpass. We open /etc/postfix/sasl_passwd and add our credentials. When we are done it looks like this:

[root@mail postfix]# cat /etc/postfix/sasl_passwd
mail.my-isp.org      test:testpass

1.2. Secure sasl_passwd

As you have noticed, the credentials in sasl_passwd are entered plaintext. That means that anybody who can open the file will be able to read this sensitive information. Therefore we change ownership and permission to root and r/w only.

[root@mail postfix]# chown root:root /etc/postfix/sasl_passwd && chmod 600 /etc/postfix/sasl_passwd

After these commands ownership and permissions read like this:

[root@mail postfix]# ls -all /etc/postfix/sasl_passwd
-rw-------    1 root     root           79 Dec 30 23:50 /etc/postfix/sasl_passwd

Note
You wonder why Postfix running as user postfix can read this file? Postfix will start as user root, read all files that need root permission and switch to user postfix after that.

Note

You wonder why Postfix running as user postfix can read this file?

Postfix will start as user root, read all files that need root permission and switch to user postfix after that.

1.3. Create sasl_passwd DB file

Now that we have set correct ownership and permissions there is one more thing to do. A plaintext file can't be read as fast as database. Postfix requires this file to be a database, because it doesn't want to spend a lot of time looking the credentials up when it needs to get it's job done. We create a sasl_passwd.db with the help of postmap:

[root@mail postfix]# postmap hash:/etc/postfix/sasl_passwd

After that there will be a new file sasl_passwd.db in /etc/postfix/.

[root@mail postfix]# ls -all /etc/postfix/sasl_passwd.db
-rw-------    1 root     root        12288 Mar 13 23:13 /etc/postfix/sasl_passwd.db

From the onwership and permissions you can see that postmap applied the same as in the source file. That's it for sasl_passwd; you only need to get back when the informations need an update.

Note
Don't forget to postmap the file, when you change credentials. Postfix will tell you anyway by claiming that sasl_passwd is newer than sasl_passwd.db in the maillog.

2. Enable SMTP AUTH

There are only three options that you must set to enable SMTP AUTH for mail servers in Postfix.

Note
You can easily tell that these parameters are settings for the smtp daemon. They all begin with smtp_.

2.1. Enable SMTP AUTH

The first thing we do is enabling SMTP AUTH for the smtp daemon. We open main.cf and enter some documentation first and then we set smtp_sasl_auth_enable to yes.

# SASL SUPPORT FOR SERVERS
#
# The following options set parameters needed by Postfix to enable
# Cyrus-SASL support for authentication of mail servers.
#
smtp_sasl_auth_enable = yes

2.2. Set path to sasl_passwd

Then we tell Postfix where to find sasl_passwd by adding smtp_sasl_password_maps = hash:/path/to/sasl_passwd to the configuration.

smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd

2.3. Set security options

Finally we set security options. In our scenario we will allow Postfix to use anonymous and plaintext authentication. That's why we set the paramter, but leave it empty:

smtp_sasl_security_options =

All settings together will give this listing in main.cf.

# SASL SUPPORT FOR SERVERS
#
# The following options set parameters needed by Postfix to enable
# Cyrus-SASL support for authentication of mail servers.
#
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options =

2.4. Reload Postfix

All that you need to do now is to reload Postfix and you're ready to use your ISPs mail server to relay mail.

[root@mail postfix]# postfix reload
postfix/postfix-script: refreshing the Postfix mail system