By using AWS re:Post, you agree to the Terms of Use

Questions tagged with Security

Sort by most recent
  • 1
  • 12 / page

Browse through the questions and answers listed below or filter and sort to narrow down your results.

End-to-end encryption (to be or not to be)

Hi community, What is your position on end-to-end encryption (regardless of regulations), but from a practical security point of view. Scenario: classic scenario of a web service being front-ended by an application load balancer. No questions ask we do encryption in transit for the front end part. BUT for the communication between the load balancer and the server the security position of AWS seems to be "encrypt everything" but when i read AWS documentation from sysops perspective i get the following "Terminating secure connections at the load balancer and using HTTP on the backend might be sufficient for your application. Network traffic between AWS resources can't be listened to by instances that are not part of the connection" As a security Practioner, i will push for end to end encryption but i willl like to understand this other point of view from AWS that, when reading it might suggest that the encryption between the load balancer and the EC2 is optional. I am in security now but my background is sysadmin and when i talk to operations people i dont like to just "impose" security regulations/standards/policies etc ... I like to explain why its required from a technical security point of view. When it comes to our on-prem applications ... its easy to explain the risks. But in AWS its a little bit confusing for me to justify my point when they show me AWS documentation stating that it might be enough just by encrypting the front end part of the communications.
1
answers
0
votes
12
views
asked 8 hours ago

API Gateway with mTLS request billing

We want to start using **public API Gateway** endpoints with AWS Lambda integration **secured with mTLS** [https://aws.amazon.com/blogs/compute/introducing-mutual-tls-authentication-for-amazon-api-gateway/] but it is not clear for us from the documentation whether rejected requests are billed or not, we analyze this situations: * **missing client certificate** - unauthorized access from anybody, bots etc. - request fails with `OpenSSL SSL_connect: Connection reset by peer` or something similar - missing information about this requests in any statistics on API Gateway dashboard * **invalid client certificate** - certificate from wrong Certificate Authority - API GW will respond with a *403 Forbidden* + response header `x-amzn-errortype: ForbiddenException`. These requests are visible under API Calls and 4xx error dashboard status, without lambda invocation * **expired client certificate** (but valid CA) - also *403 Forbidden* + response header `x-amzn-errortype: ForbiddenException`. These requests are visible under API Calls and 4xx error dashboard status, without lambda invocation * **valid client certificate** (common application state) - application will respond, lambda invoked, billed We assume that only a random request without client certificate is not charged, is that right? This information would help us to make a decision about this solution for security and potential costs. We don't consider using WAF yet, only if it will be necessary by our analysis. Thanks for any clarification
0
answers
0
votes
14
views
asked 15 hours ago

Amazon Linux 2 - How can I know if a CVE has been patched?

Hi, My question is - how can we see what CVEs are patched? Where is it recorded if Amazon Linux has patched a particular CVE? There is the security centre here: https://alas.aws.amazon.com/alas2.html, however, that only lists the advisories as far as I can tell - it doesn't say what's patched and what isn't. Is it the case that if an item there shows that there are new packages, we can just assume it's patched in AL? Thanks in advance for any help. **Context** We've had a pen test conducted in our Elastic Beanstalk / Amazon Linux 2 environment. It flagged some potential common vulnerability & exposures (CVEs) - a number of which turned out to be false positives as Amazon Linux maintains its own release of packages. We found that Nginx running in our environment was not version 1.20.0 - vulnerable to CVE-2021-23017, but was version 1.20.0, release 2.amzn.2.0.4 - which according to https://github.com/aws/elastic-beanstalk-roadmap/issues/221 , has been patched against this vulnerability. Having the same version number for each seems like a recipee for disaster. It certainly cost me a few days time trying to look into the issue. ``` [ec2-user@ip-x ~]$ yum info nginx Loaded plugins: extras_suggestions, langpacks, priorities, update-motd 207 packages excluded due to repository priority protections Installed Packages Name : nginx Arch : aarch64 Epoch : 1 Version : 1.20.0 Release : 2.amzn2.0.4 Size : 1.7 M Repo : installed From repo : amzn2extra-nginx1 ``` I've a number of other CVE's that I need to determine if our elastic beanstalk environment is potentially compromised by: If I can just look them up, it would be helpful. ``` OpenSSH <= 8.6 Command Injection Vulnerability CVE-2021-23017 Diffie-Hellman Ephemeral Key Exchange DoS Vulnerability (SSH, D(HE)ater) CVE-2002-20001 nginx <= 1.21.1 Information Disclosure Vulnerability CVE-2013-0337 OpenSSH 6.2 <= 8.7 Privilege Escalation Vulnerability CVE-2021-41617 OpenBSD OpenSSH <= 7.9 Multiple Vulnerabilities CVE-2018-20685, CVE-2019-6109, CVE-2019-6110, CVE-2019-6111 OpenBSD OpenSSH Information Disclosure Vulnerability (CVE-2020-14145) CVE-2020-14145 SSL/TLS: BREACH attack against HTTP compression CVE-2013-3587 OpenSSH 'auth2-gss.c' User Enumeration Vulnerability - Linux CVE-2018-15919 OpenSSH 'sftp-server' Security Bypass Vulnerability (Linux) CVE-2017-15906 OpenSSH < 7.8 User Enumeration Vulnerability - Linux CVE-2018-15473 OpenSSH Information Disclosure Vulnerability (CVE-2016-20012) CVE-2016-20012 ```
1
answers
0
votes
16
views
asked a day ago
1
answers
0
votes
89
views
asked 4 days ago

AWS Game Lift Server: Best Solution for Generating and Rotating API Keys for AWS Server Authentication?

We are currently setting up some authentication systems for our UE4 game servers so that we are sure they are the only devices/users that are capable of accessing our internal API / LAMDBA functions. With that in mind, there is a desire to not hard code any COGNITO user ID's or tokens into the actual server-code itself. Instead, we would like to pursue having these tokens be generated and cycled through on AWS's side, to keep it decoupled. We are undecided whether these tokens should be for the life of the Gamelift server or for a set period of time—whichever is most feasible. This way, if we need to adjust access to certain features down the road, it will not require an update to the deployed Unreal Engine server build. Does AWS API or LAMDBA have any features out of the box to check if an API request is coming from within AWS, ideally from one of the active Gamelift instances? While we may still need to create a COGNITO identity for the servers, or just check the local IP of the running Gamelift servers, the ideal flow would look like: 1) UE4 game server on AWS asks for a token on Startup. 2) LAMDBA Authorization script checks to make sure it is valid and coming from within AWS/Gamelift 3) Once Validated, LAMDBA function provides a token to enable server to use in backend LAMDBA functions. 4) Before Gamelift Server shutdown, revoke access or add to a "black-listed" token Database to prevent second use before token expiration.
1
answers
0
votes
34
views
asked 6 days ago
  • 1
  • 12 / page