Jump to content
Sign in to follow this  
SquallStrife

Tips for securing public-facing SFTP?

Recommended Posts

Been hacking away at this issue for a few days, and I think it's in a state where I'm happy with it, but just wanted to pick y'all's brains to see if I've missed anything.

 

I run a website with a facility for users to upload files: http://www.vogonsdrivers.com

 

I have ProFTPd configured as an SFTP server, and using mod_sql for authentication.

 

When a user logged in to the website clicks a "Get FTP login" button, a row is inserted to (or updated in) ProFTPd's users table, and the user can log in to SFTP with the generated credentials. These credentials expire after 12 hours.

 

The trouble I was having was that since SFTP looks like an SSH service, I'm getting hundreds if not thousands of attempted connections a day trying credentials like "root" "www-data" "admin" "staff" etc etc.

 

I have configured fail2ban on the machine, such that repeated unsuccessful auth attempts will render the client's IP blocked. I also keep the VM up to date with a daily "apt-get update && apt-get upgrade".

 

Is there anything else you guys can think of?

Share this post


Link to post
Share on other sites
Posted (edited)

If the users are all Australian, IP geo-blocking works well.

Or at least, block countries that don't use English characters.

Also BOGON IP's and any range that falls within a known VPN network.

Should help.

 

Also, from a similar thing on our virtual firewall most of those login attempts will be because they found the server (as a whole) not because they specifically found an SSH server.

Disable responding to pings.

We saw over an 80% drop in attempts when we did this.

 

Are the clients savvy enough that they're required to type in their details?

One easy wasy to stop it looking like SSH, is to change the darn port; though thats obvious and I bet you considered that already.

Edited by Master_Scythe

Share this post


Link to post
Share on other sites
Posted (edited)

If the users are all Australian, IP geo-blocking works well.

Or at least, block countries that don't use English characters.

Also BOGON IP's and any range that falls within a known VPN network.

Should help.

I toyed with these ideas, but ultimately the target audience is very geographically diverse, including Russia, China, and the other usual suspects.

 

Some (but not all) are also "modern tech savvy" and use VPNs, so blacklisting them would get messy.

 

 

Also, from a similar thing on our virtual firewall most of those login attempts will be because they found the server (as a whole) not because they specifically found an SSH server.

Disable responding to pings.

We saw over an 80% drop in attempts when we did this.

I had thought of blocking pings, though there are sound technical reasons not to. I may consider it if the volume ramps up. Since implementing fail2ban, the frequency has dropped from several attempts per second, to one every few minutes, which I'm happy with for now.

Are the clients savvy enough that they're required to type in their details?

One easy wasy to stop it looking like SSH, is to change the darn port; though thats obvious and I bet you considered that already.

Some are, others not so much, it complicates something that's already not super straightforward.

 

Another change I've just made is to shorten the "AuthOrder" directive on ProFTPd, so it no longer falls back to /etc/passwd if a user isn't found in the database.

 

The immediate effect is that instead of "USER ROOT" returning "incorrect password", it now returns "no such user found", which would probably discourage bots/scripts from trying the same user again.

 

F7QBI9G.png

 

The proftpd-root filter bans IPs that try to login with "root" immediately, other usernames get 3 attempts (because legit users typing their password wrong still trip this rule).

Edited by SquallStrife

Share this post


Link to post
Share on other sites

You have me curious, I was just trying to resist posting it, because it feels dumb.....

What possible need do you have, for it to return a PING response? Its killin me!

 

Also every time I see just your thread title, my mind says "Air gap it" lol

Share this post


Link to post
Share on other sites
Posted (edited)

Ping, specifically, probably none.

 

But ICMP is used for other things (see the link I posted in the previous post), and I don't know if iptables lets you just drop one type of ICMP packet?

Edited by SquallStrife

Share this post


Link to post
Share on other sites

Pretty much. Being a public-facing site, I don't want it to be misbehaving in funny ways because I tried to do something spec-breaking.

Share this post


Link to post
Share on other sites

I'd still be tempted to risk it. disabled

I've seen, and had hands on tens of servers with ICMP disabled and not once heard of an issue.

 

I can see why it (potentially) is, and why you'd be nervous, but real world I've never seen it.

Share this post


Link to post
Share on other sites

I'll keep that in mind if ICMP traffic becomes a problem.

 

However I've discovered that you can indeed just drop ICMP echo, while still responding correctly to other types:

 

iptables -A INPUT -p icmp --icmp-type echo-request -j DROP

Share this post


Link to post
Share on other sites

I'll keep that in mind if ICMP traffic becomes a problem.

 

However I've discovered that you can indeed just drop ICMP echo, while still responding correctly to other types:

 

iptables -A INPUT -p icmp --icmp-type echo-request -j DROP

 

Well thats even better then.

 

In my experience, I'd say half of the 'hack attempts' come from a quick ping-check of a public IP range.

No point checking for, say, an SSH port, if the server doesn't ping.

Share this post


Link to post
Share on other sites

In my mind, a better host discovery method would be a SYN sweep on port 80 or similar, to find hosts offering at least one public-facing service, since ICMP blocking seems to be common practice.

 

Time will tell I suppose!

Share this post


Link to post
Share on other sites

In my mind, a better host discovery method would be a SYN sweep on port 80 or similar, to find hosts offering at least one public-facing service, since ICMP blocking seems to be common practice.

 

Time will tell I suppose!

 

Jump back to script kiddy days though;

If someone is ICMP blocking, they're likely doing other things too (like, securing their server).

If you can ping it, it's more likely a noob server with default access credentials.

 

Or so would be my 10th grade logic.

Share this post


Link to post
Share on other sites

I see what you're saying, but I've never been much of a believer in security-through-obscurity.

 

Given that the site is mentioned a lot in vintage computing circles, and now ranks highly in searches for old drivers, I'm not surprised at all that it's a target for more than just the most casual script kiddies.

Share this post


Link to post
Share on other sites

We blocked Russia and Africa traffic on our work firewall ... we can't block China because some of them are our suppliers.

Share this post


Link to post
Share on other sites

The iptables command already mentioned should stop your automated ping sweep related attacks (ie bots and script kiddies), but won't do anything to stop more targeted attacks where the attacker knows your host is live despite its failure to respond to pings. Also, if you are using IPv6, you can't block ICMPv6 as it is an essential aspect of the protocol.

 

You could try using a port that doesn't look like SSH and use a banner that also does not look like SSH. You could also use certificate-only authentication (so that you need a valid and allowed SSH cert to connect), though this would require you to implement a mechanism that generates certificates for new, allowed users. However, if the authentication requires a certificate, then people who try once and are rejected are less likely to try and fuzz or inject the authentication system. They will just give up as soon as they're told you need a certificate. But managing many certificates might be too cumbersome for your needs.

Share this post


Link to post
Share on other sites

The iptables command already mentioned should stop your automated ping sweep related attacks (ie bots and script kiddies), but won't do anything to stop more targeted attacks where the attacker knows your host is live despite its failure to respond to pings. Also, if you are using IPv6, you can't block ICMPv6 as it is an essential aspect of the protocol.

 

You could try using a port that doesn't look like SSH and use a banner that also does not look like SSH. You could also use certificate-only authentication (so that you need a valid and allowed SSH cert to connect), though this would require you to implement a mechanism that generates certificates for new, allowed users. However, if the authentication requires a certificate, then people who try once and are rejected are less likely to try and fuzz or inject the authentication system. They will just give up as soon as they're told you need a certificate. But managing many certificates might be too cumbersome for your needs.

 

Certificates also cost money to keep going.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×