6 ms·

When you say "no one needs vpn ssh access" vs "AWS ssh access", what is the difference between the two ?

by fmitga 3y ago

mrkstu 3y ago
As mentioned you then just need to lock down AWS, rather than AWS AND outside access to servers via VPN. Lessen the attack surface.
Sparkyte 3y ago
The console in AWS allows access within its system. There is no point increasing the access area to the hosts. More surface area the easier it is to be penetrated by ssh vulnerabilities. You also shift fault to AWS rather than your company and team. You did your diligence, you just have to access control and nothing more. IF AWS has a security breach that access to your systems completely on AWS and you can demand compensation. What you want to do is avoid fault, improve tolerance, but extend liability to the provider.
- AdieuToLogic 3y ago
  > AWS allows you to ssh into your hosts from within AWS. This is where your argument breaks down IMHO. Unless you are saying "don't expose port 22 to the world...", which is a common (small) part of security-in-depth. > You also shift fault to AWS rather than your company and team. You did your diligence, you just have to access control and nothing more. IF AWS has a security breach that access to your systems completely on AWS and you can demand compensation. This appears to be an instance of the "appeal to authority"[0] fallacy and is of little solace should server(s) one is responsible for become compromised. 0 - https://en.wikipedia.org/wiki/Argument_from_authority https://en.wikipedia.org/wiki/Argument_from_authority
  - Sparkyte 3y ago
    You still have to do your diligence. You established what is supposed be a secure system yet that system failed due to provider security. AWS is far more staffed than any other company why wouldn't you shift left to AWS? Why would you hire a fleet of security engineers to do what AWS already established? You are breaking convention, reinventing the wheel and complicating an already simple system. This isn't fallacy it is reducing a businesses cognitive load.
    - vel0city 3y ago
      McDonalds employs the most cooks. They must have the best food. Staffing count doesn't guarantee quality.
    - AdieuToLogic 3y ago
      > You still have to do your diligence. My point exactly. > You established what is supposed be a secure system yet that system failed due to provider security. This makes no sense. By your own recommendation, "provider security" is an AWS offering. > AWS is far more staffed than any other company why wouldn't you shift left to AWS? Why would you hire a fleet of security engineers to do what AWS already established? What does Amazon's staffing have to do with best practices when securing a server deployed on their platform? Who said anything about "a fleet of security engineers"? How does any of that relate to securing that which one constructs, and ultimately is responsible for, when using said hosting services? > You are breaking convention, reinventing the wheel and complicating an already simple system. Are you saying that your original statement of "You also shift fault to AWS rather than your company and team" is somehow an accepted convention? And what wheel did I "reinvent"? Finally, was my identification of the common practice which is moving sshd off of port 22 the complication to which you refer?
      - Sparkyte 3y ago
        Yeaaah you're trying poke holes. Problem is that there are larger holes in a network if you're setting up and safe guarding a VPN so you can SSH. Moving ssh if even needed at all should be to the provider's secured tools. https://aws.amazon.com/blogs/compute/new-using-amazon-ec2-instance-connect-for-ssh-access-to-your-ec2-instances/ https://aws.amazon.com/blogs/compute/new-using-amazon-ec2-in... I really don't recommend extending responsibility for creature comforts. However you want to do this so be it. > This makes no sense. By your own recommendation, "provider security" is an AWS offering. Are you stating your system is infaliable? So why would you want to bear the infaliable claim and not shift it to the company providing it? > What does Amazon's staffing have to do with best practices when securing a server deployed on their platform? Who said anything about "a fleet of security engineers"? How does any of that relate to securing that which one constructs, and ultimately is responsible for, when using said hosting services? Tooling takes a team to support it. You think every company can afford a team to manage that tooling? And why should they? Not all businesses are tech companies but still need a digital footprint. They need to be selfconcious and choose provider practices to get the most out of them. > Are you saying that your original statement of "You also shift fault to AWS rather than your company and team" is somehow an accepted convention? Providers own the responsibility of their technology. In terms of failure if access is correctly configured and managed, yet their technology fails they owe your businesses it is very simple. > And what wheel did I "reinvent"? Implementing old security practices. Why wouldn't you move to be better pratices and prevent larger holes in your network? Often companies get into this repetitious cycle of reimplementation or reinvention of existing tools and technology just to manage access especially ssh. The convention of using a cloud platform is to use a cloud platform's security access not some sketched up VPN and SSH system.
landemva 3y ago
The consoles at big hosts typically require good 2fa to log in to the web management console, which typically can open a command line on the instance. This is a nice authN layer.
- Jiocus 3y ago
  Note that it's possible to configure multi-factor authentication using e.g. one-time password (OTP) for those regular openssh logins. The setup to achieve that still seem quite involved though, so the reluctant sysadmin in me haven't got around to try it. Multiple factors: 1FA: Password(1F) OR private key (password blank)(1F) 2FA: Private key(1F) with password(2F) MFA: Private key(1F), w/ password(2F) AND OTP(3F)
- onlypositive 3y ago
  And have to use their shitty webui? Ssh has 2fa options if that's the real reason. Fwiw, this guide also suggests setting up a wg connection which is no better than ssh, and probably worse in some ways.
  - vel0city 3y ago
    It doesn't need to be through the web UI, it can be done through the cli. https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-sessions-start.html#sessions-start-cli https://docs.aws.amazon.com/systems-manager/latest/userguide... Google Cloud has a similar gcloud compute ssh instance-name command, and I imagine there's a similar one on azure.
    - onlypositive 3y ago
      That's ssh?
      - vel0city 3y ago
        There's massive differences of using this compared to throwing some keys on a server and opening 22. These systems use the cloud provider's proxying and authz/authn to dynamically grant access. One could have a box with no public IP and no open ports and still use this to connect.

When you say "no one needs vpn ssh access" vs "AWS ssh access", what is the difference between the two ?

by fmitga 3y ago

When you say "no one needs vpn ssh access" vs "AWS ssh access", what is the difference between the two ?

As mentioned you then just need to lock down AWS, rather than AWS AND outside access to servers via VPN. Lessen the attack surface.

Sparkyte 3y ago

The console in AWS allows access within its system. There is no point increasing the access area to the hosts. More surface area the easier it is to be penetrated by ssh vulnerabilities. You also shift fault to AWS rather than your company and team. You did your diligence, you just have to access control and nothing more. IF AWS has a security breach that access to your systems completely on AWS and you can demand compensation. What you want to do is avoid fault, improve tolerance, but extend liability to the provider.

AdieuToLogic 3y ago
> AWS allows you to ssh into your hosts from within AWS. This is where your argument breaks down IMHO. Unless you are saying "don't expose port 22 to the world...", which is a common (small) part of security-in-depth. > You also shift fault to AWS rather than your company and team. You did your diligence, you just have to access control and nothing more. IF AWS has a security breach that access to your systems completely on AWS and you can demand compensation. This appears to be an instance of the "appeal to authority"[0] fallacy and is of little solace should server(s) one is responsible for become compromised. 0 - https://en.wikipedia.org/wiki/Argument_from_authority https://en.wikipedia.org/wiki/Argument_from_authority
- Sparkyte 3y ago
  You still have to do your diligence. You established what is supposed be a secure system yet that system failed due to provider security. AWS is far more staffed than any other company why wouldn't you shift left to AWS? Why would you hire a fleet of security engineers to do what AWS already established? You are breaking convention, reinventing the wheel and complicating an already simple system. This isn't fallacy it is reducing a businesses cognitive load.
  - vel0city 3y ago
    McDonalds employs the most cooks. They must have the best food. Staffing count doesn't guarantee quality.
  - AdieuToLogic 3y ago
    > You still have to do your diligence. My point exactly. > You established what is supposed be a secure system yet that system failed due to provider security. This makes no sense. By your own recommendation, "provider security" is an AWS offering. > AWS is far more staffed than any other company why wouldn't you shift left to AWS? Why would you hire a fleet of security engineers to do what AWS already established? What does Amazon's staffing have to do with best practices when securing a server deployed on their platform? Who said anything about "a fleet of security engineers"? How does any of that relate to securing that which one constructs, and ultimately is responsible for, when using said hosting services? > You are breaking convention, reinventing the wheel and complicating an already simple system. Are you saying that your original statement of "You also shift fault to AWS rather than your company and team" is somehow an accepted convention? And what wheel did I "reinvent"? Finally, was my identification of the common practice which is moving sshd off of port 22 the complication to which you refer?
    - Sparkyte 3y ago
      Yeaaah you're trying poke holes. Problem is that there are larger holes in a network if you're setting up and safe guarding a VPN so you can SSH. Moving ssh if even needed at all should be to the provider's secured tools. https://aws.amazon.com/blogs/compute/new-using-amazon-ec2-instance-connect-for-ssh-access-to-your-ec2-instances/ https://aws.amazon.com/blogs/compute/new-using-amazon-ec2-in... I really don't recommend extending responsibility for creature comforts. However you want to do this so be it. > This makes no sense. By your own recommendation, "provider security" is an AWS offering. Are you stating your system is infaliable? So why would you want to bear the infaliable claim and not shift it to the company providing it? > What does Amazon's staffing have to do with best practices when securing a server deployed on their platform? Who said anything about "a fleet of security engineers"? How does any of that relate to securing that which one constructs, and ultimately is responsible for, when using said hosting services? Tooling takes a team to support it. You think every company can afford a team to manage that tooling? And why should they? Not all businesses are tech companies but still need a digital footprint. They need to be selfconcious and choose provider practices to get the most out of them. > Are you saying that your original statement of "You also shift fault to AWS rather than your company and team" is somehow an accepted convention? Providers own the responsibility of their technology. In terms of failure if access is correctly configured and managed, yet their technology fails they owe your businesses it is very simple. > And what wheel did I "reinvent"? Implementing old security practices. Why wouldn't you move to be better pratices and prevent larger holes in your network? Often companies get into this repetitious cycle of reimplementation or reinvention of existing tools and technology just to manage access especially ssh. The convention of using a cloud platform is to use a cloud platform's security access not some sketched up VPN and SSH system.

landemva 3y ago

The consoles at big hosts typically require good 2fa to log in to the web management console, which typically can open a command line on the instance. This is a nice authN layer.

Jiocus 3y ago
Note that it's possible to configure multi-factor authentication using e.g. one-time password (OTP) for those regular openssh logins. The setup to achieve that still seem quite involved though, so the reluctant sysadmin in me haven't got around to try it. Multiple factors: 1FA: Password(1F) OR private key (password blank)(1F) 2FA: Private key(1F) with password(2F) MFA: Private key(1F), w/ password(2F) AND OTP(3F)
onlypositive 3y ago
And have to use their shitty webui? Ssh has 2fa options if that's the real reason. Fwiw, this guide also suggests setting up a wg connection which is no better than ssh, and probably worse in some ways.
- vel0city 3y ago
  It doesn't need to be through the web UI, it can be done through the cli. https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-sessions-start.html#sessions-start-cli https://docs.aws.amazon.com/systems-manager/latest/userguide... Google Cloud has a similar gcloud compute ssh instance-name command, and I imagine there's a similar one on azure.
  - onlypositive 3y ago
    That's ssh?
    - vel0city 3y ago
      There's massive differences of using this compared to throwing some keys on a server and opening 22. These systems use the cloud provider's proxying and authz/authn to dynamically grant access. One could have a box with no public IP and no open ports and still use this to connect.