0

I realize "secure" is a very loaded definition.

I need to connect to an SFTP logging server (user/pass only, no ssh key).

The SFTP server has IP whitelisting, and all my server IP's are dynamic. I want to set up a SOCKS5 proxy server with a static IP that will allow me to connect from my servers and proxy the SSH connection. Unfortunately I can't whitelist incoming IP's in the firewall because I'm using Heroku which uses any IP on Amazon

I'm mainly concerned about this proxy server being open to the world, and I want to make sure the steps I have done are good, or if I need to do more. I know that security can go in an extreme direction, but I am not super advanced, so I want a bit of a middle ground which is good for 99.95% of applications.

Here is the steps I have done, nothing else (so no extra configuration or software installation, etc).

  1. Create an instance on Google Cloud, use Ubuntu 18.04, give it a static IP
  2. Open port tcp:1080 in firewall using Google Cloud web interface, block 80 and 443

  3. Create a new user with the following command, using a very secure password (it's 24 characters in length, and includes letters and numbers)

    useradd -M -s /usr/sbin/nologin -p $(openssl passwd -1 PASSWORD) USERNAME

  4. Install Dante, with the following configuration (ens4 comes from running ifconfig and getting the adapter name. I guess this is what Google cloud calls it):

    logoutput: /var/log/danted.log

internal: ens4 port = 1080
external: ens4

socksmethod: username
clientmethod: none

user.privileged: root
user.unprivileged: nobody
# comment out user.libwrap lines

timeout.io: 43200

client pass {
  from: 0.0.0.0/0 to: 0.0.0.0/0
  log: error
}

socks pass {
  from: 0.0.0.0/0 to: logging-service.example.com
  log: error
}

Here were my main concerns:

  1. Is it OK to have port 1080 open? Some people have said this is bad but they link me to some things I don't understand, like "netplan.io". Is there a simple solution I can do if this is a bad idea?
  2. I notice you can use the keyword method inside the client and socks blocks... should I put something there? Or does it use what is above under socksmethod and clientmethod?
  3. Should I add something that blocks failed login attempts (I think it is called fail2ban?)
  4. I did add a restriction on the socks part to only allow connection to logging-service.example.com, although I figure if someone has intruded up until that point something is very wrong.
  5. The net-ssh/net-sftp libraries I'm using also support "jump" proxy's, is that more secure?
  6. It seems weird allowing the world to just connect to port 1080 and attempt to guess username/password. I suppose this makes it the weakest link. As long as the password is long and secure, is there anything else to strengthen this weakest link?

Any other ideas to make this more secure?

Tallboy
  • 179
  • 3
  • 15

2 Answers2

1

1) Not sure what they are talking about. Obviously you will need to have one port open, and as long as your servers can reach that port, it does not make much difference what that port number is.

1080 is the standard socks port however, so if somebody does a port scan and they see port 1080 is open, their first guess may be that there is a socks server running on that port and they will attack it with their "socks attack tools". If instead you let Dante listen on port 443, maybe they will initially guess it's an https server, and at first attack it with their "https attack tools. I.e., it might obfuscate things a bit for the attacker.

2) It will use what is above. Putting it inside is only useful if what is above is a list of several methods/clientmethods, and you want limit certain rules to a subset of that list.

3) Don't know what "fail2ban" is, but you might want to do rules for that. If you then notice a hundred blocked requests from the IP-address 'k' in your Dante logfile, perhaps its prudent to add a "client block" rule for that IP-address, rather than letting it continue to play the guessing game.

4) Makes sense.

5) Yes, if you can make it work in your use-case.

6) Maybe not. Some possibilities may however be:

  • Use "method: gssapi" instead of "method: username". This is much more secure (no plaintext username/passwords being sent over the network to Dante), but is also much more difficult to configure, and involves setting up Kerberos.

  • If the servers you connect to Dante from run identd/rfc931-servers, you can change "clientmethod: none" to "clientmethod: rfc931" and add an extra "identd" username on the Dante host for this purpose.
    Will serve as a sort of two-factor authentication, where someone will have to guess both what identd usernames Dante will accept connections from, and what usernames/passwords Dante will accept from these connections. This is however also a cleartext protocol, so if somebody can sniff the network traffic, they can see the identd name, as well as your socks username and password.

Michael Shuldman
  • 26
  • 2
0

i think your danted configuration allows whole world to be welcome.

here is mine (imagine this is your remote ip that is allowed: 11.25.10.52/0):

- block block ( block all means 0.0.0.0)

- pass (means to pass your data i guess)

- client pass probably from another way then pass.. :D

- well thats it. *** mucho besitos.. if you need help you can find me on fb: blaz kos (mas chulo q otros)

and good is not to use 1080 because all bots and scanners try this first...

#-------------------------------------------------------------



logoutput: stderr
internal: eth0 port = 1234
external: eth0
user.privileged: proxy
user.unprivileged: nobody
user.libwrap: nobody
client pass {
from: 11.25.10.52/0 port 1-65535 to: 0.0.0.0/0
}
pass {
from: 11.25.10.52/32 to: 0.0.0.0/0 port 1-65535
}
block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}


t3ch
  • 1
  • 1