View previous topic :: View next topic |
Author |
Message |
F.Ultra Apprentice
Joined: 17 Mar 2004 Posts: 169 Location: Sweden
|
Posted: Thu Dec 09, 2004 2:03 pm Post subject: Which services to safely disable in Postfix? |
|
|
I have a spam+virus checking mailgateway running postfix+amavisd-new+spamassassin+clamav which is working as a pure relay passing mails between the Internet and our internal Exchange server.
Now the default /etc/postfix/master.cf lists quite alot of servies, beeing cautios I really would like to minimize the number of available services in order to "tighten" the system.
So the question is which services are needed for such a setup?
Currently the master.cf is:
Code: |
smtp inet n - n - - smtpd
pickup fifo n - n 60 1 pickup
cleanup fifo n - n - 0 cleanup
qmgr fifo n - n 300 1 qmgr
rewrite unix - - n - - trivial-rewrite
bounce unix - - n - 0 bounce
defer unix - - n - 0 bounce
trace unix - - n - 0 bounce
verify unix - - n - 1 verify
flush unix n - n 1000? 0 flush
proxymap unix - - n - - proxymap
smtp unix - - n - - smtp
relay unix - - n - - smtp
showq unix n - n - - showq
error unix - - n - - error
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - n - - lmtp
anvil unix - - n - 1 anvil
policy-spf unix - n n - - spawn (skipping arguments)
smtp-amavisd unix - - n - 4 smtp (skipping arguments)
127.0.0.1:10025 inet n - n - - smtpd (skipping arguments)
|
|
|
Back to top |
|
|
d_m Guru
Joined: 12 Jun 2003 Posts: 570 Location: Philadelphia, PA, USA
|
Posted: Thu Dec 09, 2004 4:32 pm Post subject: Re: Which services to safely disable in Postfix? |
|
|
F.Ultra wrote: |
Now the default /etc/postfix/master.cf lists quite alot of servies, beeing cautios I really would like to minimize the number of available services in order to "tighten" the system.
So the question is which services are needed for such a setup?
Currently the master.cf is:
Code: |
smtp inet n - n - - smtpd
pickup fifo n - n 60 1 pickup
cleanup fifo n - n - 0 cleanup
qmgr fifo n - n 300 1 qmgr
rewrite unix - - n - - trivial-rewrite
bounce unix - - n - 0 bounce
defer unix - - n - 0 bounce
trace unix - - n - 0 bounce
verify unix - - n - 1 verify
flush unix n - n 1000? 0 flush
proxymap unix - - n - - proxymap
smtp unix - - n - - smtp
relay unix - - n - - smtp
showq unix n - n - - showq
error unix - - n - - error
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - n - - lmtp
anvil unix - - n - 1 anvil
policy-spf unix - n n - - spawn (skipping arguments)
smtp-amavisd unix - - n - 4 smtp (skipping arguments)
127.0.0.1:10025 inet n - n - - smtpd (skipping arguments)
|
|
If you look, only one of the services is an "inet" service (listening on a port, available remotely). The other "services" are available locally through unix sockets and fifos. So, if you are worried about a local user possibly subverting these services (which are used on lots of mailservers everywhere without problems) then maybe trying to disable them would be OK. My guess is you meant services like WWW, DNS, SSH, etc, in which case postfix only provides one: SMTP.
If you really do want to disable some of those services (which I wouldn't recommend at all, I know that many/most/all are needed) here are the ones I know about (AFAIK):
Code: |
INET services
smtp--you obviously need this to recieve mail externally
127.0.0.1:10025--???***
FIFO services
pickup--this recieves mail from local spools for processing
cleanup--not sure exactly, i think this
qmgr--this keeps track of pending messages in postfix's various queues
UNIX socket services
rewrite--this controls address re-writing (appending domains, maps, etc)
bounce--this allows postfix to bounce invalid/undesired mail
defer--this allows postfix to defer currently undeliverable mail
trace--not sure???
verify--i guess this allows postfix to verify mail is formatted correctly, or to a valid user, or something
flush--this allows postfix's queues to be flushed and messages retried
proxymap--????
smtp--i think postfix uses this to send outgoing mail to other hosts
relay--for relaying mail to other hosts
showq--administratively view the current queues
error--??? (presumably if postfix has errors)
local--local delivery
virtual--used for virtual address rewriting
[[ presumably this is for the AV stuff, or other extensions you installed? ]]
lmtp--???
anvil--???
policy-spf--???
smtp-amavisd--???
|
I'm not necessarily the biggest postfix expert but I have set up many different servers for medium to large sites with complicated setups. I can tell you that almost all of those services are necessary and disabling them out of a desire for security is probably a bad idea. If they were known to be insecure, Wietse Venema would probably disable them by default. Also, like I said, most of them are internal to the servers operation rather than exposed.
***This one looks weird--i've never used the AV stuff, but is that what's doing this? This is worth looking into. |
|
Back to top |
|
|
kashani Advocate
Joined: 02 Sep 2002 Posts: 2032 Location: San Francisco
|
Posted: Thu Dec 09, 2004 5:18 pm Post subject: |
|
|
You might get away disabling local and virtual, BUT I wouldn't bother. You're not going to increase your security in any appreciable amount by doing that and you're likely to break something. And you're going drive the next admin of the system nuts while he tries to figure out why Postfix can't delivery mail locally untill he gives up, wipes the box, and decides to install qmail.
kashani _________________ Will personally fix your server in exchange for motorcycle related shop tools in good shape. |
|
Back to top |
|
|
F.Ultra Apprentice
Joined: 17 Mar 2004 Posts: 169 Location: Sweden
|
Posted: Thu Dec 09, 2004 6:13 pm Post subject: |
|
|
Yes that line is for communicating with amavisd-new which handles the spam and virus checks.
I wouldn't worry about the next admin since I am quite sure there will be none
Perhaps I should clarify a bit, lets say someone hacked into postfix for whatever reason, since I am soon going to run this chrooted the only applications available for any intruder would be the different postfix services, so I still believe that disabling some would be good, but I could be wrong
Unfortunately the postfix documentation quite sucks big time... |
|
Back to top |
|
|
d_m Guru
Joined: 12 Jun 2003 Posts: 570 Location: Philadelphia, PA, USA
|
Posted: Thu Dec 09, 2004 6:38 pm Post subject: |
|
|
F.Ultra wrote: | Yes that line is for communicating with amavisd-new which handles the spam and virus checks.
I wouldn't worry about the next admin since I am quite sure there will be none :D
Perhaps I should clarify a bit, lets say someone hacked into postfix for whatever reason, since I am soon going to run this chrooted the only applications available for any intruder would be the different postfix services, so I still believe that disabling some would be good, but I could be wrong 8)
Unfortunately the postfix documentation quite sucks big time... |
As far as I know the only rights the postfix user(s) normally have are rights to write to /var/spool/postfix, /var/mail/${USER}, and bind to port 25. If someone hacks postfix they already have the first and third, and if there are no local users then the second isn't an issue. If it's chrooted I don't think there are any other issues, so at that point I don't see an advantage or disadvantage.
To be clear, the unix sockets are for inter-process communication. Both processes are running in the context of the chroot, and neither has special priveleges. If the postfix user (the one who binds to port 25) is compromised, do you really worry about the other processes running as that user? They won't gain any extra write permissions, or users, or new files to access.
You would be far better served by installing snort, configuring grsecurity, tripwire, etc, customizing syslog, and writing strong firewall rules for your network than by disabling any of these services (which I don't believe would have any positive security benefits). |
|
Back to top |
|
|
kashani Advocate
Joined: 02 Sep 2002 Posts: 2032 Location: San Francisco
|
Posted: Thu Dec 09, 2004 7:16 pm Post subject: |
|
|
F.Ultra wrote: |
I wouldn't worry about the next admin since I am quite sure there will be none
|
There is always another admin. I know as I've often been the guy hired to make sense of nonsense like this. While not as bad as using non RFC 1918 space for internal space behind the firewall "in order to fool the hackers" it's not that far either.
kashani _________________ Will personally fix your server in exchange for motorcycle related shop tools in good shape. |
|
Back to top |
|
|
d_m Guru
Joined: 12 Jun 2003 Posts: 570 Location: Philadelphia, PA, USA
|
Posted: Thu Dec 09, 2004 7:55 pm Post subject: |
|
|
kashani wrote: |
While not as bad as using non RFC 1918 space for internal space behind the firewall "in order to fool the hackers" it's not that far either.
kashani |
Oh man! Obviously this guy was a giant of science.
I guess what he meant to say was "in order to have better job security"!
Kind of like writing all your system maintenance scripts in AWK... only like 5% of admins will figure out what you were doing and they will all hate your guts. |
|
Back to top |
|
|
F.Ultra Apprentice
Joined: 17 Mar 2004 Posts: 169 Location: Sweden
|
Posted: Fri Dec 10, 2004 8:52 am Post subject: |
|
|
Quote: | There is always another admin | Trust me, not here
Anyway, I will probably leave these postfix services running. And yes the rest is taken care of, we have a tightly configured PIX-firewall at the perimiter and this mail-gateway is running iptables with restrictions for both in and out traffic. No remote admin (no ssh or telnet) so you have to get physical access and the machine is located inside or secure server room.
So chrooting will be next but that would probably be better in a new topic. |
|
Back to top |
|
|
|
|
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
|
|