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).
Related
I have a proxy server and I am making an application for the internet. I have no idea, the username and password exchange in between proxy server and client can be encrypted or not? If yes what encryption squid uses? I am curious to send my username and password using encryption. I have done with base64 authorization string.
Well, for a corporate environment it's great to use Kerberos or NTLM authorization type to implement a secured authorization process. This is first option (more details here: https://serverfault.com/questions/106846/squid-authentication-encryption).
The second option is to use HTTPS_PORT directive in Squid, so your clients will be able to establish a fully encrypted SSL-connection to the proxy-server (http://wiki.squid-cache.org/Features/HTTPS#Encrypted_browser-Squid_connection — not just authorization, so since this moment you can use even plain-auth one).
To implement this Squid should be compiled with --enable_ssl flag, server should have a FQDN and attached to that domain name certificate.
Example:
https_port 3143 cert=/etc/squid3/ssl/cert.pem key=/etc/squid3/ssl/private.key
Note, that certificate should be exactly in PEM format and private key shouldn't be locked with password. You may get a free and legit one from StartSSL, to example. Or you may use a self-signed one, but it's not a great idea.
There are few limitations:
1) HTTPS-proxy (do not confuse it with proxy, which simply supports CONNECT method) is well supported only by Firefox and Chrome at this time.
2) It works only in cooperation with proxy auto-configuration (PAC) file, more details here: http://www.chromium.org/developers/design-documents/secure-web-proxy
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
If you log in to an sftp server,
Are the username and password sent securely?
Or do you have to have certificate-based authentication to ensure that the entire transmission is encrypted?
If this is client-dependent, then do you know if Tumbleweed and WinSCP can be configured to send username and password securely?
SFTP goes over SSH, which establishes a secure tunnel by exchanging keys (recall how when you first connect you are prompted to accept and store a key?). Once the secure tunnel is established, all communication through it is encrypted. The username and password are sent via the tunnel, hence they are sent securely.
Depends on what you mean by SFTP. For "real" SFTP which stands for SSH File Transfer Protocol authentication is done on SSH layer and it's secure. Some people use "SFTP" as a synonym of FTP-over-TLS, and in this case it depends - in most cases the command channel is encrypted before username and password are sent (this is true only for SSL/TLS-secured connection, not plain FTP!) but it's possible to authenticate in clear text (eg. for debugging purposes).
SFTP itself does not authenticate at all. According to its specification it assumes that it runs over a secure channel. As such it expects that underlying channel handles authentication (if any).
So the question is, what channel does your particular instance of SFTP run over. In 99% cases it runs over SSH though (port 22), which sends username and password securely. Note that majority of SFTP clients (WinSCP definitely) and servers do not even support any other channel than SSH.
Strictly speaking even SSH can be configured encryption-less or with inferior encryption. Though again in most cases it is secure. And again, most SSH clients (WinSCP definitely) and servers do not allow encryption-less SSH setup.
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.
Im implementing my own RPC framework and well moste of the stuff is done but i need some help how do i verify a auth_unix? the structure of the data is definied in http://www.faqs.org/rfcs/rfc1050.html 9.2 UNIX Authentication but how should i verify the user?
UID and GID are compared to the UID and GID on the server to validate their authenticity. These IDs can be shared across unix systems using NIS or some other facility. Anything subsequently executed on the remote system is run under that effective UID and GID.
The application behind the server may implement further authentication, but note that AUTH_UNIX does not authenticate the user in itself; it trusts the UID and GID supplied.
From Section 9.3:
9.3 DES Authentication
UNIX authentication suffers from two major problems:
(1) The naming is too UNIX oriented.
(2) There is no verifier, so credentials can easily be faked.
DES authentication attempts to fix these two problems.
If you use Unix authentication you can only assume that the message originates from a trusted host and some mechanism was in place to authenticate the user before they got the chance to do something that originated the call.
In this case it would be up to the application to verify user credentials. The originating machine name is also supplied so you could make sure that the originating IP address matches it and only reply to that address - this has obvious vulnerabilities to DNS cache poisoning attacks. Also, making this play nicely with DHCP or NAT is left as an exercise to the reader ;-}
Which means you have little choice but to trust the UID and GID or do additional verification within the application sitting on top of your RPC library. The RFC discusses more secure authentication mechanisms. However, Sun RPC is not the most secure of protocols and is generally not recommended for services provided to untrusted clients.