Mike Cardwell wrote: > * on the Thu, Jul 13, 2006 at 10:28:45AM +0800, W B Hacker wrote: > > >>Even 'ordinary' shell-account holders can usually drop their own smtp code >>into >>place. Essentially all of the interpreted languages have several available. >> >>and - at the end of the day, anyone who needs to do so can telnet to a >>distant >>server and manually send a message. It isn't hard to do. > > > You can get around such problems by building a tight firewall. I get around > this > particular problem on one of my systems by redirecting all outgoing > connections > on port 25 to localhost unless they're initiated by the exim user. I do this > using iptables: > > iptables -t nat -A OUTPUT -p tcp --dport 25 -d ! 127.0.0.1 -m owner ! > --uid-owner exim -j DNAT --to-destination 127.0.0.1 > > Someone might find that useful...
The intent is good, but that specific rule is not necessary on Unix, nor will it block outbound traffic. - ports below 1024 are reserved to 'root' anyway. - an(y) MTA running as a daemon will have been given that port (by initial invocation as root). - once a daemon has bound to port 25, the next entity (even root) that attempts to bind to it will be denied. Demo this by manually attempting to onvoke Exm a second time, and tailing /var/log/messages /var/log/maillog, /var/log/exim/paniclog (wherever you are logging). But perhaps most of all - an MTA ordinarily *listens* on port 25, and initiates outbound smtp on ports above 1024. And w/r user-installed mailing code - any port that they can get the use of will do. I'll presume you have a rule eleswhere that blocks that. > > As for limiting which addresses can be emailed by certain users, you > should be able to do this in the acl's. - and routers > There are at least > two ways they could > send the email, either by calling the exim binary directly, or by making > a local connection to port 25. There are different ways to identify the > sending user in both circumstances. > Careful crafting of the exim setup can prevent 'smtp incoming' from other ports on your own IP, and control non-smtp as well - long before acl's come into play. Careful crafting of routers, with or without acl aid, can add to that control. > If the sending is being done by calling the exim binary directly, you > can access the users uid inside $caller_uid. > > If the sending is being done by the user connecting to port 25 locally, > you should install an identd server and use $sender_ident > > Mike > An identd is not required, and usually brings more headache than relief. - properly configured, authentication should be required for any traffic not destined for on-host users. Non-authenticated smtp traffic addressed to off-host destinations should be treated as unauthorized relay attempts. At the end of the day, Exim rulesets can restrict 'proper' users to specific destinations and/or prohibit specific destinations. But the 'challenge' remains that a shell account holder who has either the ability to install and use executables or even to simply acess telnet, can connect to a destination server without ever touching Exim. Put another way: - Seeing to it that your Exim daemon is not misused is one 'world'. - Protecting the server overall from misuse is a different 'world'. And preventing 'wetware' from communicating *at all* gets into the zone of firearms and barbed wire. Even that has proven porous. ;-) Bill -- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
