I'm trying to set up my Ec2 server on AWS, and I want to make it so only requests from the same ip address are allowed (for my backend port.). What security group allows this? The reason I want to restrict which ips can make requests to the backend is to stop abuse ips from making a ton of random requests.
Related
We have an Azure PostgreSQL Flexible Server on a VNET subnet which we're trying to lock down as much as possible via NSG rules.
As per the Microsoft documentation we've added rules to cover the guidance given:
High availability Features of Azure Database for PostgreSQL - Flexible
Server require ability to send\receive traffic to destination ports
5432, 6432 within Azure virtual network subnet where Azure Database
for PostgreSQL - Flexible Server is deployed , as well as to Azure
storage for log archival. If you create Network Security Groups (NSG)
to deny traffic flow to or from your Azure Database for PostgreSQL -
Flexible Server within the subnet where its deployed, please make sure
to allow traffic to destination ports 5432 and 6432 within the subnet,
and also to Azure storage by using service tag Azure Storage as a
destination.
And we have added another rule to deny all other outbound traffic to lock things down further, but in the Network Watcher Flow Logs we're seeing blocked outbound traffic to port 443 from the PostgreSQL IP address.
The IP addresses being called are associated with Akamai and Microsoft when investigated, but we're a little puzzled what they may be doing and how to add relevant rules to cover this seemingly un-documented behaviour.
A sample of the outbound IP address calls being blocked:
104.74.50.201
23.0.237.118
52.239.130.228
What are the best practices to lock things down but allow PostgreSQL to call out to what it needs to? Is there some more comprehensive documentation somewhere?
The outbound NSG rules:
We understand that there's default rules in place, but we're trying to restrict traffic further to very specific resources.
In my knowledge, recommended steps will be
Create a new Priority rule to Deny all the traffic in Inbound and Outbound. On top we can create a new rule to allow traffic.
If applications that are deployed on subnets within the virtual network, allow only those subnet range on NSG inbound rule
Example:
Deployed PostgresSQL with Vnet
Address Space: 10.1.0.0/16 and Subnet range: 10.1.0.0/24
In Inbound always allow only specific port and Destination IP addresses
If application is consuming any load balancer / Cluster ip's we should allow only those IPs on outbound rules under destination
I am just experimenting with my phone system and I'm wondering how both endpoints know they are on the same LAN, I have both endpoints breaking out to the cloud phone system with two separate public IP addresses, I've segmented them off from each other with a firewall so they can't see each other however every time I attempt a call between the two end points the call is setup as a peer to peer call and attempts to traverse the local LAN via RTP through the firewall, the firewall blocks the RTP communication and the call has no audio.
I am just wondering how both endpoints are realizing they are behind the same firewall/router since they are both registering with the cloud system from different public IP addresses, I wanted the call to be bridged in the cloud and not traverse the local LAN but somehow both endpoints only attempt the call over the LAN every single time and no idea how they're realising they're on the same LAN.
Anyone else encountered this before?
SIP endpoints don't have to know they are on the same LAN. They just make best use of the IP addresses you provide.
Your INVITE request will provide more insight, but from what you write my guess is that you use public IP addresses for your contact/request URI and local IP addresses in your SDP offer. The local IP addresses are probably routable through the firewall.
With ICE and STUN endpoints may select the best IPs for media traffic - but for that to work the RTP/STUN packets should be able to traverse the firewall in your LAN.
Attempts to communicate directly may mean that LAN uses IPs from public ranges or endpoints a SIP proxy were not smart enough to detect NAT in front of your LAN.
I am trying to configure webhook connection to my server but smooch is not able to connect( firewall policies). I need to allow smooch IP but the ping test returns different IP address all the times.
Is there any set of IP(s) which I can allow in the firewall directly?
Smooch does not currently have a static set of IPs from which it sends webhooks, but the team is actively working on supporting this.
If you absolutely need static IPs in the meantime to bypass your firewall, you would need to host your own server outside the firewall that relays Smooch webhooks from a static IP that you've configured yourself. Then, configure Smooch to send webhooks to your proxy server instead of your real server.
My internet connection has a dynamic IP adress which keeps changing every time the modem is restarted, so I have a hard time configuring the Authorized Networks in Access Control.
This is explained at https://cloud.google.com/sql/docs/access-control#dynamicIP .
Your options are, and I quote:
Use a proxy service so that your application appears to come from only one IP address. Add this address to the authorized networks that can connect to the instance.
Use a CIDR range that covers all of the IP addresses from which your service might connect.
Use the CIDR range 0.0.0.0/0, which allows all external IP addresses to connect.
The third and last option, despite its attractive simplicity has implications that may make it undesirable -- read the docs I'm pointing to.
How is it possible to access an internal resource (email server / FTP server) using its external IP address but from within the network ?
The situation is that a number of users have laptops and work out of the office several days per week. I don't want them to have to change the connection details from 217.x.x.x to 10.0.0.x every time they come into the office, then back again when they leave.
I have external access working, so they can connect using the 217.x.x.x IP when on the road, but it doesn't work when they are in the office.
We have a router providing NAT access to the net and different servers for FTP, email etc.
This is what DNS is for - your external DNS provides the 217.x.x.x address for the names, while your internal DNS returns the 10.0.0.x IP address. Clients access resources by hostname, not IP address, and it's done.
Unless you have filters forbidding access to the external NAT'ed address from internal clients, I do not see why it should not work.