All web hosting providers support full FTP access but many do not support SFTP.
But how do they ensure FTP is secure? FTP sends information (passwords, etc) in clear-text right.
I was told by one of the Sales/Support staff from one of the hosting providers that since users get individual access to FTP accounts via CPanel then the access to the user's website directory using FTP is secure.
Is this true?
SSL question:
Also I would like to use SSL on the admin login with my hosted customized wordpress website. What is involved in this? I know it is possible to configure this http://codex.wordpress.org/Administration_Over_SSL
But the web hosting provided need to support SSL? Is there a need for certificate, etc and by who?
If you can passively sniff the traffic you see username and password used by the FTP user in clear, unless the client uses FTPS. This is about the security you get with plain telnet (instead of SSH) or authorized access to mail servers which are not protected by TLS (most providers now offer TLS).
Once you have the credentials you can compromise the account. This is not only deleting the data (i.e. denial of service), but grab any sensitive data, manipulate data to spread false information etc. If the credentials are also usable for SSH an attacker can log into the system as an unprivileged user and from there it is often not far away to a whole system compromise. Also, the same credentials are often used to access the users email so you can compromise this too.
Which means, yes, it is completely insecure.
Apart from that, don't mix up FTPS and SFTP. FTPS is the FTP protocol with TLS extended, while SFTP is file transfer over SSH. Some clients like FileZilla support both and if you have the choice prefer SFTP because it is much less hassle with firewalls.
Related
I have a simple app connected to a server via some sockets and the traffic is not yet encrypted users must log in or create accounts before using the app and afterwards traffic is shared between users and server. i want to know if i must encrypt all traffic or just the authentication and account creation?
Use https for all traffic (or an equivalent TLS-based protocol for non-HTTP traffic). Yes, encrypt and certificate-authenticate everything. For modern systems, there are vanishingly few cases where TLS is not the correct answer for network traffic. It is ubiquitously available across platforms, languages, and protocols.
On any modern network system you need an argument for why you wouldn't encrypt and authenticate the connection. It's not a matter of "must" you. It's a matter of "why wouldn't you?"
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've heard from more than one IT Manager that they don't allow users to user RDP to connect to their internal network from the outside, because it's not safe. They claim that if they'd allow their users to do so, then anyone from the outside will have access to their network as well.
I'm not getting it. In order to use RDP, you need a user name and password, and you can't get in without it. The same is for using Gmail, online banking, and any other web service.
So what do they use instead? LogMeIn. Or a VPN connection, and then use internal RDP. VPN also requires a user name and password.
If they're afraid of a brute-force attack, then someone can brute-force attack the VPN server or LogMeIn just the same. And if these other technologies have lockouts (after x number of failed attempts) then why can't the same be set up for RDP?
Similarly, people always say that VPN is very secure because it uses a "tunnel". I don't fully understand what that means, but regardless, why can't the username and password be cracked the same way any website or web service which uses a user name and password can be.
With proper configuration, RDP is capable of 128-bit RC4 encryption, virtually any port or set of port allocations, and has proven to be relatively bug-free, with only extremely minor flaws ever discovered.
On the other hand, the secure tunnel created in a VPN is far more secure than Remote Desktop. All your data is encrypted for safe transfer from one remote location to another.
Moreover, VPN only allows shared content to be accessed remotely to tighten the security. If your device falls in the wrong hands, they won’t be able to access and manipulate unshared data and resources.
The bottom line is that both RDP and VPN have their own advantages, however, with high security, better performance and manageability, VPN seems to be a clear winner in the competition of Remote Desktop VS VPN service.
We have configured ftp within IIS7 to allow the use of SSL certificates. We need to ensure that most of your users use FTPS, but due to legacy system we cannot enforce all ftp users to use SSL. What would we need to do to achieve this?
he didn't say SFTP, he said FTPS which is FTP over SSL... FTP over SSL is indeed FTP (not ssh) run over an SSL'd connection, and is supported by IIS 7.x. Like the user, I too have not been able to find a mechanism for enforcing FTPS and disallowing clear text auth... IIS 7.x's FTP server seems to only make FTPS available as an option, but does not provide a mechanism (that I can find yet) for enforcing/requiring it.
I've been looking around and haven't been getting very far in my research of WCF security. I have a low-risk service I want to create so I just want some basic security required for client's on different servers outside of the domain to be able to use it.
What's the easiest way in WCF? Is it just through the use of certificates?
Check this, it covers many security scenarios, use whichever suits your need.
And for authentication purpose you can easily opt Username security, where you just need to pass user name and password.
Easiest way to simply encrypt the transmission is if you're just using net.tcp binding, then you can turn on Transport security or Message security without needing to set up a certificate.
With WsHttpBinding message-level security (contents of the message are encrypted) is enabled by default and doesn't require an SSL cert. And if the clients are on the same Windows network then it'll use Windows Authentication and credentials by default, too, so you should be able to enable Transport security without needing an SSL cert there, either.
If you want to expose your service over HTTPS to the public internet then you'll need to obtain an SSL certificate and bind it to the port on the server that the service runs on, using httpcfg.exe (comes with Windows Server).