6 ms·

you care about network security, why are you exposing ssh ports in public anyhow? Put them behind a VPN. There are ways to configure salt with masterless or be

by 23david 13y ago

you care about network security, why are you exposing ssh ports in public anyhow? Put them behind a VPN. There are ways to configure salt with masterless or behind vpcs or with syndics that are perhaps an enhanced security model. But defaults are for regular use cases, and for most cases the defaults are fine. I suggest checking it out.

calpaterson 13y ago
> you care about network security, why are you exposing ssh ports in public anyhow? Put them behind a VPN. You don't need to do this. SSH is secure enough. Require key-based authentication and leave SSH on port 22.
- hexedpackets 13y ago
  Switching SSH to any other port is a good idea as it will reduce the random attacks against it. Sure, those drive-by attacks are pretty weak and not much of a threat against a hardened configuration and the real attackers will find the new port anyway, but it reduces noise significantly. Cleaner logs are easier to parse, so the net result is that you can spot attacks that you care about much more easily.
  - nuclear_eclipse 13y ago
    Install fail2ban, leave ssh on port 22, and have clean logs.
    - antihero 13y ago
      If someone knows your IP, can't they spoof the packets and get you banned from your own server? Or did they solve this issue somehow already?
      - nuclear_eclipse 13y ago
        a) This was suggested as a method to combat random trolling from botnets, so this sort of response is highly unlikely unless you're already getting DDOS'd [1], and b) Fail2Ban allows you to whitelist some IP's that won't be banned, if you really need to protect against that sort of attack. 1: at which point you'd most likely need to be a lot more involved anyways, and you should most likely be running something more serious in front of your server anyways...
      - greenail 13y ago
        there is a whitelist capability
      - pilif 13y ago
        The ssh authentication works over TCP which isn't realistically spoofable because to open a connection (which you need first, before you can fail to authenticate ssh), you need to be able to receive the response packets to your spoofed sender address
darkarmani 13y ago
> you care about network security, why are you exposing ssh ports in public anyhow? Put them behind a VPN. Why are you exposing VPN ports in public anyhow? Put them behind a VPN. Seriously though, there isn't anything to say a VPN is any more secure than SSH.
- peterwwillis 13y ago
  SSH is secure. The configuration of SSH, and the system that it's running on, its operating system, accounts and applications, might not be. It all comes down to how secure you want to be. There is a longer conversation that can be had to explain this. There are lots of mistakes one can make in managing a box with SSH that will easily lead to an account compromise, not even considering universal methods like 0-days, stack attacks, mitm, phishing, etc. The simplest defense to all these problems is a hardened VPN device on a separate network segment with separate authentication and strictly defined ACLs. If you just run a personal VPS, I wouldn't worry about it. But if you ever start handling customer data, get serious about security and don't run SSH in the open.
  - gizzlon 13y ago
    This just sounds like FUD. What makes whatever vpn software or "hardware" you're using better, or harder to mismanage, than OpenSSH. Something concrete please..
    - peterwwillis 13y ago
      Keep in mind that most of the time, penetration happens because of operator error. Most common vulnerabilities are patchable or preventable in one way or another. SSH contains many features which may make it vulnerable to attack. If configured incorrectly it will expose the machine, and depending on the machine this could expose a big portion of your network. I could write 5 pages on abusing SSH options for entry. After SSH itself, there's the operating system. PAM has had holes for years and yet people everywhere rely on it for their authentication. Their OS might not be patched up, and probably has had no hardening of the kernel or userland against typical attacks. The box is also probably on a shared network segment, meaning your attack surface is now a whole lot bigger: many machines and user sessions to hijack. On the other hand, a VPN on a separate network segment provides protection for all these components, if you do it right. Usually the VPN should be an appliance of some kind, with service by a company who spends its time hardening the device and patching the software regularly. This makes sure the configuration of the software is correct, the system itself is resistant to attack, and authentication/authorization is managed outside the machine, which means limited access to the network for specific user sessions. You cut the attack surface down by separating their network access away from a specific network and shared server. You also cut down on mistakes in managing said service because everything is a managed service, not a config file edited by one or more admins. Also consider that SSH just doesn't have the features of a standard VPN that make it useful on a network level. Its tunneling feature is a joke; using ppp is the closest way to provide an actual remote vpn tunnel. Persistent connections are nonexistent. Network access control is nonexistent. Pushing routing, DNS and other network information is nonexistent. It is not meant to be a network-level tunnel, it's a single-session user tunnel for remote hosts, not networks. The extra options and features for more network access are hacks. If you wanted to emulate a VPN using SSH, you could: * put a machine on a separate network segment * apply Grsec and other patches * harden the filesystem and stop all services other than SSH * disable user logins * disable all features of ssh * enable all strict ciphers, modes, options for ssh * add ssh config options to run pppd as soon as the user logs in * configure PAM to use RADIUS or SQL to auth with a remote database * use iptables and some kind of packet-marking module to track network sessions by user id * create a custom application that configures iptables rules per user * constantly update all patches That would get you close to a real, normal VPN. Unfortunately, it's also a metric shit-ton more code and services to do the same thing as one service, and considering you'd be setting it up for the first time, there's probably gonna be some mistakes made. SSH is not a VPN, and a VPN is not SSH. Like I said before, if you're just remoting into your personal box, I don't think you'll have issues, because nobody would care to break in. Bigger networks are a different matter.
ishbits 13y ago
At some point, to gain any form of remote access you have to put your trust in one piece of software. Being it VPN, ssh, or something. For many people ssh is considered secure enough. And any secure issues get immediate attention so you can be updated pretty quickly. Now any software could have unpublished zero days, which is why I also do some other host based security.

by 23david 13y ago

calpaterson 13y ago

> you care about network security, why are you exposing ssh ports in public anyhow? Put them behind a VPN. You don't need to do this. SSH is secure enough. Require key-based authentication and leave SSH on port 22.

hexedpackets 13y ago
Switching SSH to any other port is a good idea as it will reduce the random attacks against it. Sure, those drive-by attacks are pretty weak and not much of a threat against a hardened configuration and the real attackers will find the new port anyway, but it reduces noise significantly. Cleaner logs are easier to parse, so the net result is that you can spot attacks that you care about much more easily.
- nuclear_eclipse 13y ago
  Install fail2ban, leave ssh on port 22, and have clean logs.
  - antihero 13y ago
    If someone knows your IP, can't they spoof the packets and get you banned from your own server? Or did they solve this issue somehow already?
    - nuclear_eclipse 13y ago
      a) This was suggested as a method to combat random trolling from botnets, so this sort of response is highly unlikely unless you're already getting DDOS'd [1], and b) Fail2Ban allows you to whitelist some IP's that won't be banned, if you really need to protect against that sort of attack. 1: at which point you'd most likely need to be a lot more involved anyways, and you should most likely be running something more serious in front of your server anyways...
    - greenail 13y ago
      there is a whitelist capability
    - pilif 13y ago
      The ssh authentication works over TCP which isn't realistically spoofable because to open a connection (which you need first, before you can fail to authenticate ssh), you need to be able to receive the response packets to your spoofed sender address

darkarmani 13y ago

> you care about network security, why are you exposing ssh ports in public anyhow? Put them behind a VPN. Why are you exposing VPN ports in public anyhow? Put them behind a VPN. Seriously though, there isn't anything to say a VPN is any more secure than SSH.

peterwwillis 13y ago
SSH is secure. The configuration of SSH, and the system that it's running on, its operating system, accounts and applications, might not be. It all comes down to how secure you want to be. There is a longer conversation that can be had to explain this. There are lots of mistakes one can make in managing a box with SSH that will easily lead to an account compromise, not even considering universal methods like 0-days, stack attacks, mitm, phishing, etc. The simplest defense to all these problems is a hardened VPN device on a separate network segment with separate authentication and strictly defined ACLs. If you just run a personal VPS, I wouldn't worry about it. But if you ever start handling customer data, get serious about security and don't run SSH in the open.
- gizzlon 13y ago
  This just sounds like FUD. What makes whatever vpn software or "hardware" you're using better, or harder to mismanage, than OpenSSH. Something concrete please..
  - peterwwillis 13y ago
    Keep in mind that most of the time, penetration happens because of operator error. Most common vulnerabilities are patchable or preventable in one way or another. SSH contains many features which may make it vulnerable to attack. If configured incorrectly it will expose the machine, and depending on the machine this could expose a big portion of your network. I could write 5 pages on abusing SSH options for entry. After SSH itself, there's the operating system. PAM has had holes for years and yet people everywhere rely on it for their authentication. Their OS might not be patched up, and probably has had no hardening of the kernel or userland against typical attacks. The box is also probably on a shared network segment, meaning your attack surface is now a whole lot bigger: many machines and user sessions to hijack. On the other hand, a VPN on a separate network segment provides protection for all these components, if you do it right. Usually the VPN should be an appliance of some kind, with service by a company who spends its time hardening the device and patching the software regularly. This makes sure the configuration of the software is correct, the system itself is resistant to attack, and authentication/authorization is managed outside the machine, which means limited access to the network for specific user sessions. You cut the attack surface down by separating their network access away from a specific network and shared server. You also cut down on mistakes in managing said service because everything is a managed service, not a config file edited by one or more admins. Also consider that SSH just doesn't have the features of a standard VPN that make it useful on a network level. Its tunneling feature is a joke; using ppp is the closest way to provide an actual remote vpn tunnel. Persistent connections are nonexistent. Network access control is nonexistent. Pushing routing, DNS and other network information is nonexistent. It is not meant to be a network-level tunnel, it's a single-session user tunnel for remote hosts, not networks. The extra options and features for more network access are hacks. If you wanted to emulate a VPN using SSH, you could: * put a machine on a separate network segment * apply Grsec and other patches * harden the filesystem and stop all services other than SSH * disable user logins * disable all features of ssh * enable all strict ciphers, modes, options for ssh * add ssh config options to run pppd as soon as the user logs in * configure PAM to use RADIUS or SQL to auth with a remote database * use iptables and some kind of packet-marking module to track network sessions by user id * create a custom application that configures iptables rules per user * constantly update all patches That would get you close to a real, normal VPN. Unfortunately, it's also a metric shit-ton more code and services to do the same thing as one service, and considering you'd be setting it up for the first time, there's probably gonna be some mistakes made. SSH is not a VPN, and a VPN is not SSH. Like I said before, if you're just remoting into your personal box, I don't think you'll have issues, because nobody would care to break in. Bigger networks are a different matter.

ishbits 13y ago

At some point, to gain any form of remote access you have to put your trust in one piece of software. Being it VPN, ssh, or something. For many people ssh is considered secure enough. And any secure issues get immediate attention so you can be updated pretty quickly. Now any software could have unpublished zero days, which is why I also do some other host based security.