Is it possible to use a milter under postfix to implement SPF?
It seems to me that this would not be possible, because of the way that postfix manages milters.
According do the postfix docs, the milter goes here in the message-processing chain:
Network => postfix smptd process => MILTER => postfix smtpd process => etc.
Given that the milter gets its message from the postfix smtpd, the milter will see its initial connection coming from postfix's IP address. This would mean that the milter has no knowledge of the original sender's IP address.
SPF needs the sender's IP, so it seems like it would be impossible to perform a proper SPF validation from within a postfix milter.
This seems to be exactly what is happening when I install a test milter into my postfix server.
Am I correct about this, or has anyone been able to implement SPF via a postfix milter?
Thanks in advance.
Sendmail/Postfix executes callback provided by given milter during incoming SMTP session. Postfix may reject some SMTP command based on results of the callbacks.
Postfix before-queue Milter support
Postfix implements support for the Sendmail version 8 Milter (mail filter) protocol. This protocol is used by applications that run outside the MTA to inspect SMTP events (CONNECT, DISCONNECT), SMTP commands (HELO, MAIL FROM, etc.) as well as mail content (headers and body). All this happens before mail is queued.
https://en.wikipedia.org/wiki/Milter
OK. I understand the issue better now. Apparently, the milter implementation I'm using is not properly setting {client_addr}. I will assume that my issue is that of the underlying milter implementation that I'm using (a recent version of pymilter).
Also, I figured out that I can work around this issue as follows: postfix puts the client's hostname and IP address into the topmost "Received" header that it sets before sending the message to the milter. I can therefore parse this first "Received" header in the milter to get the client address that I need for SPF.
Related
One of our clients has a wrong configured device which sends a wrong username. He can not find the device, so fail2ban keeps blocking him. When we add the ip to the whitelist it works, but he gets banned again, when his router sets a new ip address.
So, my idea was to set up a fail2ban filter to ignore his specific username in postfix and doevecot.
How would such a filter look like?
This is not a filter what you need, but rather an ignoreregex in jail configuration (one per jail dovecot or postfix).
Note that how the regex may look is depending on how the log-line (which cause the ban) would look.
If your log-line (which cause ban) looks for example like this:
... auth-worker(123): Info: sql(certain-user#example.de,192.0.2.1,<sessionid>): unknown user
you can add to the jail following config (in your jail.local):
[dovecot]
...
_ignore_users = (?:certain-user|some-user|another-user)#example.de
ignoreregex = sql\(%(_ignore_users)s,[^\)]*\): unknown user$
...
And fail2ban would stop banning such users if ban occurs only by this kind of messages, otherwise you have to write ignoreregex for several message formats.
Just by the way:
One of our clients has a wrong configured device which sends a wrong username. He can not find the device...
His system e. g. some of his hosts may be part of some botnet (always trying a bruteforce for some single username), so it is probably not advisable to white-list him.
When we add the ip to the whitelist it works, but he gets banned again, when his router sets a new ip address
If he has some kind of DynDns (or can configure it in his router), you can add its FQDN to ignoreip instead of IP.
The task turned out to raise the relay postfix, which can send messages from mynetworks, to attempts to send messages through it to the domain from other hosts, it
should issue 451. At the same time, NDR should be sent from it to the internal mail servers.
Please suggest how to implement it.
There were no problems with setting up opendkim, but there is not enough experience.
I run my own sip server (asterisk). Apparently my sip server allows to perform an INVITE without doing any REGISTER first. This leads to lots of unsuccessful attacks on my server. IS there any way to allow INVITE requests only from a successfully REGISTERed clients? Through asterisk or iptables?
You need change allowguest parameter to no in your sip.conf.
Check the link below for more tips about security in asterisk:
http://blogs.digium.com/2009/03/28/sip-security/
My study so far tells me that REGISTER is only for asterisk to reach or forward the INVITES but not to authenticate an INVITE request. When an INVITE comes, asterisk tries to check the given user name and if its a valid one, it sends a 407 (Authentication required) back to the client. Then client inserts the password (encrypted) in the response and sends INVITE2 to server. Now server authenticates the user and when credentials match, proceeds with establishing the call.
Conclusion: An INVITE has no relation with REGISTER and so my idea of restricting only REGISTERED clients to send an INVITE is not possible.
As a workaround, I have written my own script. Source is at https://github.com/naidu/JailMe
Consider a real Session Border Controller which pays for itself quickly when you get hacked. However, if you want a "good enough" option then read on:
There is an iptables module called "string" which will search a packet for a given string. In the case of SIP we expect to see "REGISTER" in the first packet from any given address, so combine this with -m state --state NEW or something similar. After that, we would want keep-alive happening to ensure that connection tracking remains open (usually Asterisk sends OPTIONS, but it can send empty UDP). You want that anyway in case the client is behind NAT.
It's not the ideal solution, because iptables cannot figure out whether a registration has been successful, but at least we can insist the other guy makes an attempt at registration. One of the answers linked below shows use of the string module in iptables:
https://security.stackexchange.com/questions/31957/test-firewall-rules-linux
You could also put an AGI script into your dialplan that does some additional checking, potentially looking at IP address and whether the extension is registered... ensure the INVITE comes from the same source IP.
Fail2Ban is an easy way to block unwanted traffic! fail2ban check system logs for failed attempts, if there are too many (exceeding defined threshold) failed attempts in specified time from some remote IP then Fail2Pan consider it as attack, and then add that IP address in iptables to block any type of traffic from it. following links can help
http://www.voip-info.org/wiki/view/Fail2Ban+(with+iptables)+And+Asterisk
http://www.markinthedark.nl/news/ubuntu-linux-unix/70-configure-fail2ban-for-asterisk-centos-5.html
I am about to setup SmarterMail v9.0 on our Windows 2008 server (IIS7) and would first like to know what some security considerations are when opening up port 25 and/or 587 - ie how to prevent relaying, etc.
Thank you.
You must not accept email from untrusted users/sources which is not bound for domains you control.
An open relay is a mail server which allows anyone on the Internet to email anyone else, without verifying that either the source or the destination is known - thus, a relay.
You can check that the source is known by looking for a trusted IP subnet, or by requiring authentication before mail can be sent (via LOGIN over TLS, GSSAPI [called "Integrated Windows Authentication" or whatever], X.509 client certs, or the like).
You can check that the destination is known by comparing it to the list of domains for which your mail server will be the "last stop" (or a relay to another domain you control).
Either a known source or a known destination should be sufficient, but you may also want to make sure that mail inbound for your domains is at least borderline valid (originates from a domain with an MX server, for instance).
Separately, you must be conscious of DoS issues (rate limit inbound mail), and the ability to use your server to send backscatter spam. Backscatter is when I connect to your mail server and say, "why yes, I am unsuspecting_target#not_my_domain.com, please queue up this message for not_an_address#yourdomain.com". Then your mail server delivers a "bounce" message to the unsuspecting target. To mitigate this, you can verify that the recipient is known before accepting mail, or limit the rate at which mail can be accepted from one host, or try to check that the host delivering a message is authorized to use that envelope sender.
These are all well-solved problems.
I want to use Postfix to accept incoming emails and have it send them to an external Python script which parse them and add them to a database.
I read that this could be done via a Policy file.
My first question is what should the policy file return to have Postfix delete the email from the queue with a success message to the sender.
My second question is can I use the Policy file to validate the SMTP authentication that was sent by the client? If not, is there any way of having it use an external script to validate the login?
Thanks!
Christian
If you need SMTP authentication anyway and just want a script to act as MDA, I think you can do it simply by
setting mailbox_command = /path/to/my/script in /etc/postfix/main.cf and configuring an authentication scheme. If you have dovecot running, too, I can recommend having postfix authenticate via dovecot, which is very configurable when it comes to SASL authentication.
Update
Since you will be having plaintext passwords going over the wire (assuming this service is reachable from the network), I recommend permitting authentication only over an encrypted line. The configuration I'm going to show will still accept mails for which the server is the destination without authentication. As far as I know, that behaviour is mandated by an RFC for SMTP servers which are reachable from the internet.
Announce SASL authentication only over encrypted connections
smtpd_tls_auth_only=yes
Don't require everyone to talk to you over an encrypted channel
smtpd_tls_security_level=may
SASL boilerplate
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_local_domain = $mydomain
For whom to accept mail. This is worked left to right, until a permitting or denying rule is encountered. Fallback behaviour would be to permit.
smtpd_recipient_restrictions = permit_auth_destination, reject_plaintext_session, permit_sasl_authenticated, reject
permit_auth_destination as first rule would make sure that clients may deliver mail to users for which I feel responsible unauthenticated. The clients may choose whether to use TLS or not.
reject_plaintext_session as second rule makes sure that all other rules further down the line can assume an ecrypted channel.
permit_sasl_authenticated is self-explanatory
reject as last rule basically changes the default policy to "deny".
If you don't want to accept mails without SMTP authentication, you may want to drop the first rule of smtpd_recipient_restrictions.
Not shown is the configuration of the SSL certificate and how to tell postfix about it (the latter of which is easy).