I have a requirement where GCP VM instance which is behind a squid proxy and NAT gateway should be able to send emails to AWS SES.
SES: email-smtp.eu-west-1.amazonaws.com
as far as I know, GCP has port 25 blocked and after referring to few articles on stackoverflow, it seems squid does not support SMTP as well.
can someone please help if they have worked on similar thing before?.
Thanks
Max
Use port 587. As per AWS SES and GCP documentation port 587 is without any restriction.
Option 1, AWS SES HTTP API:
If the email sending application could support sending emails via AWS SES with the use of their HTTP API instead of the SMTP protocol, you could allow that regional HTTPS endpoint in the outbound firewall (Squid in your case.)
The advantages of this approach address your concerns on bypassing the proxy by going through Cloud NAT directly, and maintaining restrictions on traffic originating from the source subnet.
Option 2, AWS SES SMTP over TLS:
Configure the application to connect with AWS SES SMTP endpoints on port 465 or 2465 while using TLS. This is also called SMTPS (where the trailing S stands for SSL/TLS, just like in HTTPS.) This is documented under TLS Wrapper in AWS' documentation.
Since Squid is primarily a proxy for HTTP, you will be better of replacing it with an outbound firewall that supports filtering traffic by FQDNs for SSL/TLS connections wrapping any protocol within. (In this case, SMTP wrapped in TLS.) These are typically called NGFW and available from the GCP marketplace on a free trial. One advantage of using these is the applications don't need explicit proxy settings for connecting to the Internet as the operation is completely transparent.
Related
First of all, I'm in no way an expert at security or networking, so any advice would be appreciated.
I'm developing an IOS app that communicates with an API hosted on an AWS EC2 linux machine.
The API is deployed using **FastAPI + Docker**.
Currently, I'm able to communicate with my remote API using HTTP requests to my server's public IP address (after opening port 80 for TCP) and transfer data between the client and my server.
One of my app's features requires sending a private cookie from the client to the server.
Since having the cookie allows potential attackers to make requests on behalf of the client, I intend to transfer the cookie securely with HTTPS.
I have several questions:
Will implementing HTTPS for my server solve my security issue? Is that the right approach?
The FastAPI "Deploy with Docker" docs recommend this article for implementing TLS for the server (using Docker Swarm Mode and Traefik).Is that guide relevant for my use-case?
In that article, it says Define a server name using a subdomain of a domain you own. Do I really need to own a domain to implement HTTPS? Can't I just keep using the server's IP address to communicate with it?
Thanks!
Will implementing HTTPS for my server solve my security issue? Is that the right approach?
With HTTP all traffic between your clients and the ec2 is in plain text. With HTTPS the traffic is encrypted, so it is secure.
FastAPI "Deploy with Docker"
Sadly can't comment on the article.
Do I really need to own a domain to implement HTTPS?
Yes. The SSL certificates can only be registered for domains that you own. You can't get the certificate for domain that is not yours.
I currently have a backend running in a container (ECS), this backend has a SES service for sending e-mail (user password recovery).
I implemented this same scenario using SUBNET for my backend, but sending e-mail is no longer working.
In both my old scenario (without using a subnet) and localhost, sending the email works perfectly.
I did a ping test from the container and got a timeout answer:
In this case it looks like you have the wrong address, you have
email-smtp.us-east-1.amazonaws.com (email-smtp) defined on your endpoint, and
email.us-east-1.amazonaws.com (email) in your ping.
Remember that a Ping may not respond if ICMP is not allowed through.
For a wider answer to this question, you have 2 options:
Make sure that you have an Internet Gateway configured correctly on your Subnet, and the security group added to your ECS host allows outgoing traffic to port 25 (this is throttled by AWS), 587 or 2587 depending on what you are using to talk to SES: https://docs.aws.amazon.com/ses/latest/DeveloperGuide/smtp-connect.html
Create an SES VPC Endpoint on your subnet, then direct all of your SES requests to this new endpoint/IP Address: https://docs.aws.amazon.com/ses/latest/DeveloperGuide/send-email-set-up-vpc-endpoints.html
If any of these are not working, check:
You are not in SES Sandbox mode (raise a support request)
You are not being throttled on port 25 from your host (use port 587 or raise a support request)
You can connect to the internet from your EC2/ECS instance
Port 587 is enabled on your security group
The URL Address is correct (email-smtp.us-east-1.amazonaws.com)
The IAM Role on your EC2/ECS Host (or IAM User) is enabled for SES Sending.
I'm very new to AWS, so if any of the info I give you is not correct, I would appreciate a correction.
I have a single EC2 instance, running Windows, and using Internet Information Services (IIS). That instance has an elastic IP address set, so anytime I want to access my web, I do it through "http://xx.xxx.xxx.xxx/myWeb/controller/view.
I have a mobile app that opens a webview through an address like the one before, to register a credit card, and the API i'm using for that is requesting to make the connection secure. Doing research, I found about AWS Certificate Manager. It's of my uderstanding that you can only deploy a Certificate generated from the certificate manager to an ELB or CloudFront, but I don't have any of those.
All the documentation I read is fairly advanced for my understanding at this point or is focused on Linux servers, so I would like to know, how would you guys solve this? should I put ELB in front of my EC2 to be able to use Certificate Manager? or is there a better way to enable a HTTPS connection?
I also read about having to enable port 443 (HTTPS), is this an extra step I have to take, besides getting the SSL certificate?
Sorry if I'm all over the place. Any help would be greatly appreciated :)
There are 2 options, host the SSL within the Instance, or use ELB/ALB to terminate SSL (and change port) and forward the connection to the Instance. In either case you would need a domain name registered (the trust relationship is against the domain name, not the IP address).
If you choose the AWS route:
(Optional) Register the domain in Route 53, or transfer it in
Register the certificate in ACM, or upload your own
Create an ELB / ALB. Set it to use the custom domain and enable SSL.
Create a 'listener' on the ELB / ALB listening on port 443 (IIRC the SSL is actually attached to this listener). Set the listener to forward all incoming connections to the Instance on a port of your choosing (e.g. 80 now that it is HTTP).
If you are using websockets you would need to use an ALB (not ELB)
Beware there is a monetary cost for using ELB / ALB.
I have used Gmail SMTP service with port 587 on the local server and it's working fine.
But it's not working on AWS EC2 instance. So I added SMTP rules on EC2 instance security inbound rules see below image but SMTP port can not be editable.
Now the issue is if your domain does not configure secured connections. Gmail does not offer port 25 in an unsecured connection.
So, there is any way to use SMTP on unsecured connection with 25 port or any other way.
I have fixed issue as of now for a development server. Please, not it's not the correct way to a production site.
For sending an email from AWS EC2 using Gmail SMTP service please follow below steps.
Edit security group of your EC2 Instance.
Edit inbound rules of the security group.
Add 587 port in inbound rules. See below image.
you need to set your instance inbound rules for coming mail and outbound for send.
After that, you can send email using 587 SMTP port from AWS EC2.
Please read this article. https://support.google.com/accounts/answer/6010255?hl=en
https://myaccount.google.com/lesssecureapps
Because of the spam abuse that has historically been sent from people using EC2 instances, virtually ALL popular mail providers block the receipt of email from EC2 instances. The world of email and anti-spam measures is part-technical, part-political. For this reason, AWS offers Amazon Simple Email Service.
Step to fix it-
Go to google account setting and Turn on Two-step verification.
Now generate an app password for the app you want to send mail.
Use the generated password for the app in SMTP with the same Email.
That's it.
To send email from C# hosted on Amazon EC2, make sure you have two things done.
Use following setting in your Web.config
<mailSettings>
<smtp deliveryMethod="Network" from="<from email goes here>">
<network host="smtp.gmail.com" port="587" enableSsl="true" userName="email id goes here" password="<password goes here> />
</smtp>
</mailSettings>
Login the above gmail account onto the Amazon EC2. If you do not login, then gmail blocks the email being sent from code due to security reasons.
According to Googles documentation, you can use the G Suite SMTP relay service through port 25. You can read more information here:
https://support.google.com/a/answer/176600?hl=en
and here:
https://support.google.com/a/answer/2956491
Hope this helps!
When Sticky Sessions are enabled on an AWS ELB it seems that the ELB will terminate SSL (AWS forum discussing this). I need information from the user's certificate to verify some things, so I need the ELB to forward this information to the EC2 instances.
How can I get the ELB to give me the user's certificate information? Is there a way to create custom headers? All I was able to find were these three headers: Amazon docs on x-forwarded-headers.
As discussed in the first link I posted another option is persistent sessions. Is this my only option?
ELB won't give you information regarding the certificate. And you cannot customize/add forwarded headers.
If you need the client certificate, you'll need to use TCP forwarding rather than HTTP/HTTPS.
This way, the ELB will simply forward the connection as-is on to the EC2 instance. It won't terminate the SSL connection, and you won't get sticky sessions.