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

Questions tagged with Security

Sort by most recent

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
44
views
asked a month 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
49
views
asked a month 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
49
views
asked a month ago
1
answers
0
votes
113
views
asked a month ago