Setting the source port for outgoing SMTP connections in exim4
 

Hello,

I am trying to implement firewall rules for outgoing connections on my mail server (Debian 4.0, exim 4.6.3). As one of my firewall rules, I would like to prevent connections from my server to port 25 on remote machines, with an exception for exim4 so it can send out email. Unfortunately, exim4 uses a random ephemeral (i.e. unprivileged) port to make outgoing connections, so there is no easy way to tell legitimate (i.e. exim4) connections from illegitimate ones. Hence, I would like to set up exim4 so that it uses a fixed, privileged port to make its outgoing SMTP connections to other mail servers. Reading the documentation, I have found options for using a particular interface (ip address) to connect from ("interface") and for setting the port to connect to on the remote server ("port") but none to set the source port for outgoing SMTP connections. Does such an option exist in exim4?

Thanks

Christoph

that's not unfortunate, that's how tcp works and going against that is horrible. if you have other users using that mail server for some reason then you can use iptables on the box to filter outbound traffic based on process names or user accounts. http://iptables-tutorial.frozentux.n...tml#OWNERMATCH to be honest it does seem pretty paranoid what you're asking, or something driven from lack of suitable hardware and architecture.

Thanks for the link, I had actually not encountered owner match in iptables before and that is an elegant solution. Unfortunately, it is not available on the server I am using. I'd just compile it into a custom kernel but since this is a virtual private host, the kernel binary that it will boot is outside of my control - so "lack of suitable hardware and architecture" describes it pretty well.

W.r.t. random source ports, I will have to respectfully disagree with your assessment that changing that is "horrible". I am aware that this is tcp's default behaviour but there is nothing wrong with fixing the source port or at least limiting the source port range for outgoing connections. Many programs allow this, the first ones that come to mind right now are asterisk and openvpn. So my question remains: is there any way to do this in exim4?

Both asterisk and openvpn are much more limited in scope than a mail server. If your client machine and vpn server both decide to use port 12345 for connecting, that's no problem and fine. Asterisk (back when I used it around 2004) also tended to have 1 or 2 targets for its traffic. Again, as long as the client and server agree on the port, no problem.

Mail servers don't work like that. The intention is that your server both accept all incoming connections on port 25, and initiate all connections to other mail servers on port 25. That means if a server on Japan wants to send a mail to your machine in Toronto it can, and if you email Moscow it can also work. I believe the server being connected to tells the connecting machine what port to switch to once the connection is initiated at 25, so you also can't restrict the allowed ports for the connection.

You've said that you can't control the kernel, but haven't explained why you are looking to restrict what ports mail flows out from. Blocking incoming mail is trivial on a server, but I fail to understand what you hope to accomplish by restricting the outbound traffic?

Peace,
JimBass

Let me explain why I want to do this: I am trying to put some safeguards in place so my server does not end up on an RBL because it would be a royal pain to try to get off those again. An IP address may end up on an RBL if it is found to send spam. Obviously, nobody would do any such thing on purpose but my users may run programs they shouldn't. Hence, (besides the usual spam filters on incoming mail), I set up exim4 so it runs a strict spam filter on outgoing mail as well. The problem that I want to address here is that currently, there is no barrier in place that prevents programs started by users to directly connect to other mail servers and unload spam directly on them. If I could prevent outgoing connections to remote port 25 from programs other than exim4, I could close that loophole since then the only way to send email would be through exim4, which will at least filter the messages before delivering them.

Granted, as acid_kewpie pointed out, that's a bit paranoid but other system admins I know have been hit with this through the stupidity of their users and it wasn't pretty. They spent weeks trying to get off RBLs. Putting some safeguards in place can't hurt. They aren't perfect but they'd be better than nothing.

I am not sure what you were trying to say by "Mail servers don't work like that" - my mail server will still be listening for incoming connections on port 25 and it will connect to port 25 on other mail servers. What I want to change is the local port from which it connects to other mail servers (from currently random, non-privileged to fixed, ideally but not necessarily privileged). The remote server, which my server connects to couldn't care less from which port the connection originates - as long as it terminates on port 25 on their side. Hence, this would not affect the email server's connectivity (incoming or outgoing) in any way but it would allow my firewall to tell if an outgoing SMTP connection is from exim4 (because it would come from the specified port) or from another program (because that one wouldn't).

Something like that happens in ftp and a couple of other really messed up protocols - it has nothing to do with SMTP.

I hope this explanation makes it clear what I am trying to do and why... Does anybody know the exim4 configuration well enough to tell me if and how this can be accomplished?

In a quick read earlier, I thought you were trying to change the SMTP port from 25 to something else, taking a page from the "security by obscurity" book, my bad.

I understand what you're getting at about spam lists, but they are not that difficult to get off of, assuming you aren't actually spamming. I've had several mail servers for companies for a good number of years now, and a simple matter of fact is people will identify even legitimate mail as spam from time to time. When you get listed, all lists have a way to be removed from the lists. For some it is just time, for others you have to jump through hoops, but it will happen to you, even if you and all your users do everything right.

Now, what you've written about users abusing your server (unintentionally) strikes me as a bit strange. If you're concerned with people who have shell access to your server doing stupid things, then restrict what they can do. Don't give them root access, link /usr/bin/mail to your exim server, and basically take away anything that isn't needed. If you run a GUI front end on a server, you're asking from trouble, and whatever problems your server develops you've clearly earned. Having CLI (ssh) access only is the best way to control things. Stupid users are easily kept in check by a system they can't/aren't willing to learn, and my experience has been if they need to type anything more than a url or the body of an email, they won't do it!

If however by users you mean "people with mail accounts", they can't control how mail is sent out of your server. Whatever they mail will be processed only by the exim4 server, assuming you've disabled everything else. If you have a small office setup, and your concern is that people's desktops send out email (viruses/bots), then block all LAN traffic to port 25, and only allow it if it is headed to your server, which means nobody can effectively spam in the name of your server. I may be missing what you're going at here?

I haven't looked through the source code of exim, but I doubt it is possible to restrict what port the mail can originate at.

Peace,
JimBass

It's exactly the people with user-level shell access I am concerned about. They may not even do bad things themselves but they may log in to the server from virus infested windows machines, thereby handing their login and password to the dark side.

The systems I am talking about are actually two quite different ones, and only one of them is a virtual server on which I can't boot a custom kernel. I had hoped that I can implement the same solution on both of them (sigh...) but I guess now I will just use iptables owner-match on the physical machine (with a custom kernel) and on the virtual server I will yank shell access for regular users (can't really do that on the other one).

Thanks to acid_kewpie and JimBass for your help.

I wouldn't consider myself security-paranoid, but the guy who got me started on linux is, and he forced all of our machines to only allow ssh with passkey instead of password authentication. I'm not at all certain how putty does its key authentication, but I believe putty+pagent+(password protected key) = keystroke logger resistant means of authentication. They get the username and password for the key, but not the key itself. So there is a way around it, but you would have to force the users to generate keys, and insist on passphrases.

You're very welcome for the help!

Peace,
JimBass