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.
Related
We are sending some date from one system to another system (outside network). The data will be transferred over SFTP. Some the data is sensitive.
I was told that since we are sending it over SFTP, we don't need to encrypt the data. As per my understanding even if we are sending data over SFTP, we should encrypt it.
I want to know if it's true that we don't need to encrypt data if we are sending over SFTP?
SFTP uses SSH as the underlying protocol. SSH handles encryption for you. Provided the SSH connection is secured well (e.g. using a private key) and you trust the system you are communicating with, you don't need to implement any further encryption.
My application needs to access files from a remote FTPS or SFTP server depending on what my app user wants to connect to. I need to be able to access file content in a folder or create a folder.
1) What login properties differ for an FTPS and SFTP server that a user must enter?
2) Is there any way I can detect if it is an SFTP or FTPS server?
SFTP doesn't have any authentication. SFTP protocol is supposed to be used over SSH connection, thus it relies on SSH for authentication. So all authentication mechanisms of SSH apply. The list of such mechanisms is extensive - you can authenticate using password, a private key ("public-key authentication"), X.509 certificate (not a popular option), keyboard-interactive (challenge-response) dialog, also via GSS-API you can use Kerberos and possibly other mechanisms. FTPS as FTP-over-TLS can also use various mechanisms. FTP uses username/password by default, but potentially one can implement some tricky mechanisms using SITE command. TLS protocol includes client-side authentication using X.509 certificates, pre-shared symmetric keys, plain PKI keys, OpenPGP keys.
SFTP and FTP/FTPS are completely different protocols. Servers run on different ports. If you want to implement protocol autodetection, you can try the following: connect to the server, and if it sends a welcome SSH message within 200-500 ms, you know that it's an SSH (and potentially SFTP) server. If it sends a welcome FTP message, it's an FTP server (this includes explicit TLS mode of FTPS). If it sends nothing, then it can be a TLS server and you can have implicit FTPS over this connection.
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).
Apart from enhanced authentication options offered by SSH, is there any difference between basic working of SSH and SSL protocols ?
I am asking since we can use SFTP or FTP over SSL, both would require authentication.
What is the difference between SSH and SSL and why would we care?
SSL stands for "Secure Sockets Layer". We care because it enables browsers to transmit data to and from a web server in a secure cryptographic way to make life hard for third party spies monitoring all internet traffic.
SSH stands for "Secure Shell". We care because it enables a networked computer 1 to provide access to a shell on networked computer 2. The user can have a level of confidence that spies listening to the insecure channel cannot decrypt data sent between the networked computers.
SSL and SSH both have to do with providing a system to encrypt and decrypt data over an insecure channel.
When a browser visits a URL which begins with "https://", the browser speaks HTTP over an SSL connection.
SSL enabled Web Servers (for example Apache HTTP Server) can be configured to use SSL to become a "secure web server". A website served up by a secure web server will cause users to access the URL through the "https://" protocol instead of "http://". With the https protocol the users can have a level of confidence that third party spies monitoring the internet channel will only receive encrypted content.
SSL is a Protocol that could be implemented in the 6th layer (Presentation layer) of the OSI Model.
SSH has its own transport protocol independent from SSL, so that means SSH DOES NOT use SSL under the hood.
Cryptographically, both Secure Shell and Secure sockets Layer are equally secure.
An SSL Termination Proxy can handle incoming SSL connections, decrypting the SSL and passing on the unencrypted request to other servers.
SSL lets you use a PKI (public-key infrastructure) via signed certificates. With SSH you have to exchange the key fingerprints manually through another protocol like ftp or carrier pigeon.
The main difference is that SSL lets you use a PKI (via signed certificates). In SSH you have to exchange the key fingerprints out-of-band. But you might want to do without a PKI anyway, in which case it's a tie.
For a nice explanation, see http://www.snailbook.com/faq/ssl.auto.html
SSH and SSL are similar protocols that both use most of the same cryptographic primitives under the hood, so they are both as secure as each other. One advantage of SSH is that using key-pair authentication is actually quite easy to do, and built right into the protocol.
With SSL it's a bit of a mess involving CA certificates and other things. After you have the PKI in place you also need to configure your services to use the PKI for authentication instead of its internal password database; this is a nightmare on some services and a piece of cake on others. It also means you need to go to the hassle of signing all of your user's keys so they can log in with them.
Most competent users can grok SSH keys in no time but it takes a bit longer to get their heads around SSL keys (the extra CA certs and key certs confused me when I first discovered it).
Pick what's supportable. SSH+SFTP is great for Unix people, but FTP over SSL is probably easier to do if your users are Windows-based and are pretty clueless about anything other than Internet Exploiter (and you don't mind risking that your users will choose insecure passwords).
Cryptographically they are both equally secure (given that same ciphers are used). Other than that they are entirely different protocols...
First of all, TLS server authentication is optional since its protocol supports fully anonymous server authentication. In SSH this is mandatory.
TLS uses X.509 certificates for client and server authentication, which would require some sort of PKI. SSH does not scale in this point but offers a wider range of authentication methods: password, public key, etc.
Another difference is that SSH allows multiple connections and supports remote program execution, terminal management, TCP tunneling and so on.