Plesk 10 Greylist Problems

Recently on several Plesk 10 servers we’ve had users complain that they could not receive email from various domains. Upon investigation we found that the domains were all hosted on Microsoft’s Exchange email service. The bounce messages received by the sender were from bigfish.com and the source address in the server mail logs was a host in messaging.microsoft.com.

We found log entries like this:

Mar 16 09:06:42 cloud1 qmail-queue-handlers[25914]: to=test@technicorp.net
Mar 16 09:06:42 cloud1 greylisting filter[25916]: Starting greylisting filter...
Mar 16 09:06:42 cloud1 greylisting filter[25916]: list type: black, from: db3outboundpool.messaging.microsoft.com, match string: dsl|pool|broadband|hsd
Mar 16 09:06:42 cloud1 qmail-queue-handlers[25914]: handlers_stderr: REJECT
Mar 16 09:06:42 cloud1 qmail-queue-handlers[25914]: REJECT during call 'grey' handler

So the greylist filter in Plesk 10 is blocking server that are on “dsl|pool|broadband|hsd” address ranges. In this case it would be Microsofts cloud anti-spam service that is on “pool” addresses.

From the Plesk control panel there are very few settings for the greylist filter – you can turn the filter on/off and manage white/black list entries. But there are no options to configure the filtering rules. After some digging at the command line I found this:

/usr/local/psa/bin/grey_listing --info-server

This plesk utility give a listing of the configuration for the greylist filter and provides options for configuring the greylist:

/usr/local/psa/bin/grey_listing -h

Usage: grey_listing command [options]
    Available commands:
    --update-mailname or -um <mail@domain>
                                       updates the grey listing configuration
                                       for existing mail user
    --update-domain or -ud  <domain>   updates the grey listing configuration
                                       for existing domain
    --update-server or -u              updates the grey listing server-wide
                                       settings
    --info-mailname or -im <mail@domain>
                                       retrieves grey listing settings for
                                       given mailname
    --info-domain or -id   <domain>    retrieves grey listing settings for
                                       given domain
    --info-server or -i                retrieves server wide grey listing
                                       settings
    --help or -h                       displays this help page

    Available options:
    -status            <on|off>        enable/disable grey listing. Used with
                                       --update-domain or with
                                       --update-server command
    -personal-conf     <true|false>    allows or prohibits personal grey
                                       listing configuration for users. Used
                                       only with --update-server command.
    -grey-interval     <number>        updates grey interval value (in
                                       minutes). Used only with
                                       --update-server command
    -expire-interval   <number>        updates expire interval value (in
                                       minutes). Used only with
                                       --update-server command
    -penalty-interval  <number>        updates penalty interval value (in
                                       minutes). Used only with
                                       --update-server command
    -penalty-status
    enable/disable penalties for server.
                                       Used only with --update-server command
    -blacklist <add|del>:<pattern1[,pattern2]>;...
                                       adds, deletes e-mail(s) pattern of
                                       black list shared with spamassassin.
                                       Used with --update-mailname or with
                                       --update-server command
    -whitelist <add|del>:<pattern1[,pattern2]>;...
                                       adds, deletes e-mail(s) pattern of
                                       white list shared with spamassassin.
                                       Used with --update-mailname or with
                                       --update-server command
    -domains-whitelist <add|del>:<pattern1[,pattern2]>;...
                                       adds, deletes domains pattern of white
                                       list. Used only with  --update-server
                                       command
    -domains-blacklist <add|del>:<pattern1[,pattern2]>;...
                                       adds, deletes domains pattern of black
                                       list. Used only with  --update-server
                                       command

Here’s a sample of the info output:

/usr/local/psa/bin/grey_listing --info-server
Grey listing configuration.

Grey listing checking  enabled
Grey interval          5 minutes
Expire interval        51840 minutes
Penalty interval       2 minutes
Penalty                disabled
Personal grey listing
configuration          allowed

Server-wide black list:
 *@somedomain.com

Server-wide white list:
 *@bigfish.com

White domains patterns list:
 *google.com
 *mail.ru
 *parallels.com
 *rambler.ru
 *yahoo.com
 *yandex.ru

Black domains patterns list:
 *[0-9][0-9]-[0-9][0-9]-[0-9][0-9]*
 *[0-9][0-9].[0-9][0-9].[0-9][0-9]*
 *[0-9][0-9][0-9]-[0-9][0-9][0-9]-[0-9][0-9][0-9]*
 *[0-9][0-9][0-9].[0-9][0-9][0-9].[0-9[0-9]][0-9]*
 dsl|pool|broadband|hsd
 dynamic|static|ppp|dyn-ip|dial-up

SUCCESS: Gathering of server wide information complete.

Notice that the server admin tried to whitelist the “@bigfish.com” but it did not work because the “black domain patterns list takes precedent.

Now to solve the problem of mail from *.messaging.microsoft.com we can just add another “white domains pattern list” like this:

/usr/local/psa/bin/grey_listing --update-server -domains-whitelist "add:*messaging.microsoft.com"

And now the email from Microsoft hosted domains should be delivered without error.

Here’s a Parallels Knowledgebase Article on this subject:

How to configure Greylisting

And here’s a thread on Serverfault that got me on the right track:

e-mail gets rejected – bigfish.com error

View Comments

Passive Mode FTP with iptables

There’s lots of advice on the net about how to setup a server with iptables to allow passive mode FTP. Below is the approach that we’ve found to be most effective.

Start by configuring your FTP daemon to use a fixed range of ports. We use 41361 to 65534 which is the IANA registered ephemeral port range. The exact config depends on what FTP software you’re using:

vsftpd

Edit /etc/vsftpd/vsftpd.conf and add the following lines:

pasv_min_port=49152
pasv_max_port=65534

proftpd

Edit /etc/proftpd.conf and add to the Global section:

</Global>
......
PassivePorts 49152 65534
</Global>

Now restart your FTP service so the changes take effect.

Next you’ll need to configure the ip_conntrack_ftp iptables module to load. On Redhat/CentOS just edit /etc/sysconfig/iptables-config and add “ip_conntrack_ftp” to the IPTABLES_MODULES like this:

IPTABLES_MODULES="ip_conntrack_ftp"

Now restart the iptables service:

/sbin/service iptables restart

You can verify that the correct port range has been registered with lsmod like this:

lsmod | grep conntrack_ftp

and you’ll get something like this:

ip_conntrack_ftp       41361  0
ip_conntrack           91621  2 ip_conntrack_ftp,xt_state

And that’s all it takes to get passive mode ftp working behind iptables.

One extra note: If your server is NATed behind a physical firewall then you’ll probable need to load the “ip_nat_ftp” iptables module.

View Comments

NFS Server On RackSpace Cloud

Today we’re going to setup an NFS server and client on a pair of RackSpace Cloud Servers.

To get started create two cloud servers – one will be the NFS server and the other will be the NFS client. We’ll be using CentOS (RHEL) for our project but you can use the distribution of your choice.

We’re going to do the NFS share over the Private Net interface which is a 10.x.x.x unroutable network. This way NFS is not exposed to the public network and the security issues are simplified.

Our server will be named “file01″ and our client will be “client01″. We will share the /data directory tree on the server and mount it to /data on the client.

Server

  1. Install necessary packages. You’ll need nfs-utils and portmap. Additional dependent packages will be installed automatcially:
    yum install nfs-utils portmap
  2. Setup /etc/hosts. On the server, I like to add host entries to /etc/hosts for each client so that it’s easy to reference them in the configuration files. So we’ll add this line to /etc/hosts:
    10.10.232.1 client01-private

    Remember to use the private address of the client. We want the NFS traffic to use the non-public network for improved security.

  3. Setup /etc/exports. This text file defines what paths will be shared and to whom. Here is a simple case sharing /data to a single client:
    /data client01-private(rw,no_root_squash)

    There are a number of different configuration options available for the /etc/exports file. See the man page for full details.

  4. Setup /etc/hosts.allow. This text file defines access controls for the NFS related services. Here’s an example configuration:
    portmap: client01-private
    lockd: client01-private
    rquotad: client01-private
    mountd: client01-private
    statd: client01-private
  5. Setup iptables. Edit the /etc/sysconfig/iptables file and add the following line to the RH-Firewall-1-INPUT table right before the final COMMIT:
    -A RH-Firewall-1-INPUT -s 10.176.97.227 -j ACCEPT
    

    Notice that the IP address is the private interface on the client. You’ll need to add additional lines if you have more then one client. This is a very simple rule that allows all traffic from the client to the server. Now restart iptables:

    /sbin/service iptables restart
  6. Configure startup. Use the following commands to configure the nfs and portmap services to start on boot.
    /sbin/chkconfig --level 345 portmap on
    /sbin/chkconfig --level 345 nfs on
    
  7. Start services. Start or restart the portmap and nfs services. You’ll need to do this anytime that you change the NFS configuration.
    /sbin/service portmap restart
    /sbin/service nfs restart
    

Client

  1. Install necessary packages. You’ll need nfs-utils and portmap. Additional dependent packages will be installed automatcially:
    yum install nfs-utils portmap
  2. Setup /etc/hosts. On the server, I like to add host entries to /etc/hosts for the server so that it’s easy to reference them in the configuration files. So we’ll add this line to /etc/hosts:
    10.10.232.2 file01-private

    Remember to use the private address of the client. We want the NFS traffic to use the non-public network for improved security.

  3. Configure startup. Use the following commands to configure the portmap service to start on boot.
    /sbin/chkconfig --level 345 portmap on
  4. Start portmap service. Start or restart the portmap.
    /sbin/service portmap restart
    
  5. Setup /etc/fstab. The /etc/fstab text file contains a list of filesystems that should be mounted on the client server. We need to add new line at the bottom of the file for our NFS server. Here’s an example:
    file01-private:/data /data nfs rw,hard,intr 0 0

    Notice that we’ve stated that the /data share on file01-private should be mounted to /data on the client server.

  6. Create the mount point. The mount point is just an empty directory to which the remote filesystem will be connected.
    mkdir /data
  7. Mount the share. Next step is to mount the share with this command:
    mount /data

And now you should have a working NFS mount of file01:/data to client01:/data.

If it’s not working, here’s a good page of advice on how to troubleshoot:

http://tldp.org/HOWTO/NFS-HOWTO/troubleshooting.html

View Comments

Non-chrooted Cronjobs In Plesk 10

Plesk 10 has a bug (feature?) where it inserts this line into the crontab file for each user (including non-chrooted users):

SHELL=/usr/local/psa/bin/chrootsh

This effectively breaks the jobs, because it makes them try to run in a chroot jail, which won’t work. You can manually remove the lines but Plesk will restore them when the job is edited. A workaround, is to run this command on the server:

/usr/local/psa/bin/server_pref -u -crontab-secure-shell /bin/sh

That changes the SHELL setting to a normal default value, which should run the jobs correctly. This is not a great fix, because it probably messes up cronjobs for users who really are chrooted but it may be useful to some.

–ben

View Comments

Insert Varnish Cache With NAT Rule

Here’s a simple nat rule for iptables that will route incoming web traffic to your varnish cache. This allows you to implement varnish without reconfiguring apache. In the varnish config, set the backing do be 127.0.0.1:80.

iptables -D PREROUTING -s ! 127.0.0.1 -d 192.168.100.16 \
   -p tcp -m tcp --dport 80 -j DNAT \
   --to-destination 192.168.100.16:6081 -t nat

Here’s a different rule that also seems to work:

/sbin/iptables  -t nat -A PREROUTING \
   -i eth0 -d 46.105.124.96 -p tcp -m tcp \
   --dport 80 -j REDIRECT 6081
View Comments