On 3 Jul 2016, at 0:36, [email protected] wrote:
This is probably more of a freebsd question, but it seems to me that Postfix should be hogging (bound) to the mail ports, so if something is sending email, it has to be using Postfix.
That's not how TCP/IP or Postfix works. Postfix binds listeners to the *LOCAL* IP+port pairs that you tell it to listen on. Typically this includes at least port 25 on all local IP's and possibly port 587 on all local IPs. See your own master.cf for specifics...
This does not prevent other programs from using ephemerally-allocated *LOCAL* ports (typically <48k) to open connections connect to port 25 or 587 on REMOTE addresses where other people run their MTAs on their machines. And of course Postfix has nothing to do with the various ports POP and IMAP servers can be listening on, which usually use a common authentication mechanism to the MTAs on the same hosts.
I suppose modifying IPFW to log all mail port activity is also a good idea.
Sure, you could do that. Correlating ipfw logging of outbound SYNs and Postfix logs is a... um... painful task.
One approach that is useful and much less annoying to use is to make your mail services use only a non-default IP address, so that most forms of system compromise which result in something running that is not under your control and tries to engage in mail naughtiness can be blocked by ipfw (or on Linux, iptables) rules that prohibit outbound port 25/587/465/110/143/993/995 on the IP address that a program would use by default if it does not specify one when opening a socket. This can be a bit tricky to set up if your system is directly connected to the Internet with only one public IP available, but it's still possible. The more subtle initial configuration buys you the ability to block bad traffic rather than just logging it and no need to use the Postfix logs to sift out the legitimate outbound mail traffic from the illegitimate.
Another useful tool on FreeBSD is the "jail" mechanism. On FreeBSD I only run Postfix in jails that include at most only a few intimately related services (e.g. Dovecot, Unbound) precisely because that allows me to prohibit all traffic to ports 25 and 587 from other jails running riskier things (e.g. webservers) except to the jailed Postfix.
Wouldn't a script need to be in the rc.d to get fired up when I boot?
Not if someone has cracked your machine in a stealthy manner. There are cracks which don't bother trying to make themselves permanent, they just hide themselves very well by running under innocent names and unlinking their visible locations in the filesystem. There are also FreeBSD rootkits which are very hard to find short of booting from immutable media after reflashing the BIOS.
But don't go that far quite yet... There's another possible (and more likely) explanation.
One thing that can make Postfix act like a "dictionary attack" bot is the non-default abusive misfeature "reject_unverified_sender" which implements what is sometimes called "SMTP Callback," verifying each sender by running a fake SMTP transaction that looks like a bounce through the point of a response to RCPT and then quitting. This is done synchronously during each SMTP session that offers an unknown RFC5321.MailFrom address. This technique sounds like a great idea until you consider the secondary consequences and responses outside of your own system. If you do SMTP callback, you make your system a public nuisance that actual spammers can (and eventually will) use as a dictionary attack proxy for discovering deliverable addresses. Sender address verification by SMTP callback is an example of a spam-fighting tactic that looked and worked great when it was first conceived, as long as one didn't think about the scaling effects, external reactions, and vulnerabilities to abuse. Postfix's implementation is arguably the least obnoxious in widespread use, but it remains an intrinsically problematic tactic.
If you're using sender address verification you should stop, immediately. There are spamtrap tactics in fairly widespread use for detecting spam sources which cannot distinguish between spammer systems and those doing sender address verification and whose users do not see any reason to make such a distinction. There are DNSBLs which are fed by such trap mechanisms. There are useful *non-abusive* anti-spam tactics which break even the least-bad implementations of sender address verification, causing them to see valid addresses as invalid. The beliefs that it is possible to make a 99.99% accurate determination of whether a sender address is deliverable in real time between receiving a MAIL FROM command and responding to DATA, that trying to do so will not reduce objective performance and add to resource demands, and that it won't cause the blockage of legitimate messages are all simply incorrect. It can take years to notice any problems or to be noticed as a source of problems, but once you are listed by a public DNSBL as a result of doing SMTP callbacks, you'll never be able to do them safely again and you will lose legitimate inbound mail as a result before you notice problems with outbound deliverability.
