I am trying to ban 1 IP address that someone is using to send malicious attacks every 3 seconds.
However, when I use Google Cloud armor, the IP/attacks aren't blocked until the application is reset. At which point, I see that the attacker set it up so that the IP address automatically changes and attacks from a different IP.
Am I always suppose to reset to make Cloud Armor work? Or is this happening because I'm using a load balancer?
Another possibility is that Cloud Armor never worked in the first place, but when the application was reset, the attacker's script changed the IP automatically.
Related
https://www.whois.com/whois/34.101.115.42
This ip is from google (cloud) and today I discovered it trying to access via ssh....
The instinct is to block it, but the doubt comes, won't it be used by the google spider as well?
Can it be blocked without risk?
Firebase Hosting did not provide enough security, but I love the features of Firebase. So I wrote a firebase function that renders dynamic content. I put it behind a google load balancer to be able to block all traffic except whitelisted IPs.
I hope to write a function that will whitelist the IP into cloud armor after a successful sign in. I hope to whitelist as many IPs as possible (1000+) and I will add a TTL to each IP as each session expires.
My goal is to strictly limit access and prevent a DDoS attack that could potentially bring the function down and accrue charges. A bearer token is not enough for my use case.
So this is a two part question, is it possible to whitelist IPs programmatically? Is there a limit to how many IPs I can whitelist?
Update:
According to https://cloud.google.com/armor/quotas, I can have 200 rules each rule containing 10 IPs, meaning 2000 IPs. So my new question, is this an standard use case for Cloud Armor?
I understand I can get a quota increase, but there are other load balancer services such as Cloudflare with much larger IP whitelist. Although, I would like to stay within Google services.
According to the official documentation and #John Hanley recommendation you should not use IP whitelists filtering for your security model:
Note that using static IP address filtering is not considered a safe
and effective means of protection. Instead, we suggest that you take a defense
in depth approach using OAuth and Certs.
I have a database instance running on Amazon AWS. I use the RPostgreSQL package to connect my R session to my AWS database.
My issue is that every time I attempt to connect to my database instance after not having done so for a while, I get a "Connection timed out" error.
I can then use a browser to go to my AWS Console, edit the Inbound and Outbound rules for my security group to allow my IP Inbound & Outbound access. Then I can connect again just fine.
But then if I don't work on my database for a day or two, when I try to connect to my DB, it doesn't work, and the permissions for Inbound/Outbound access no longer match my IP address (which I'm sure is the cause of the problem).
So... is my IP address changing? Or are the edits I'm making to my security group's inbound/outbound permissions not being saved correctly?
To be clear, here's the order of events of how things have been going:
Haven't worked on DB for a few days, attempt to connect from my R sessions. I get an error.
Use browser to go to AWS Console and edit my security group's Inbound/Outbound rules by selecting "My IP"
Try again to connect to my DB from my R session. Hooray! It works.
A few days later - pick up the project again, attempt to reconnect to my AWS DB from R, and it no longer works...
Repeat this cycle of madness
Make post on SO hoping for an angel to help me
This isn't a debilitating problem, it's just extremely annoying to have to re-do my security settings every time I want to connect to my AWS DB.
Thanks in advance for any help you can provide!
It depends, but most possibly it seems to be that your IP is changing. Most of the ISP have Dynamic IP allocation, which means the IP can change if the router is restarted.
It is hence recommended to use DNS name instead of IP address in the security group setting.
It is easier to note down your IP address and check back after two days.
Can you see your IP address which you added two days ago in the Security Group page? If yes, you can just goto google "what is my IP" and see if both the values are same. Security Group (SG) setting does not get refreshed or changed on it's own(unless you are allocating a new Security Group).
One more thing you can try. Allow all connection (0.0.0.0) just to test. After two days or so, try again. If it works, it means there is issue with the IP address changing.
Usually we set AWS security group outbound as ALL since we may need to download/upgrade sth. from internet. using any port, from any IPs.
One concern is what if sb. who login EC2 tries to upload company's important data to his personal cloud storage?
If we can restrict AWS security group outbound, then this can be avoided.
I see some similar post about the concern on security group outbound setting. such as:
AWS Security Group for RDS - Outbound rules, but all the response said it is fine to set outbound as ALL, or just restrict to a few ports.
I still want to raise the question again. for example, how to resolve the above concern I have? and if we do not have solution, then is restricting port to 80/443 enough if we just want to upgrade/update OS and app, not anything else?
I have a web application that should behave differently for internal users than external ones. The web application is available over the Internet, and therefore obviously to the internal users as well.
All the users are anonymous, not authenticated, but the page should render differently for internal users than external. What I'm doing in my code is use Request.UserHostName and then Dns.GetHostEntry. The result is then compared to a setting in my web.config (that holds something like *.mydomain.local) . If the comparison gives a positive result then I render the HTML that the internal user should see otherwise I render the HTML the external user should see.
However, my problem is that I don't always get the expected value from Request.UserHostName. on the development site I get the IP-number (?) of the machine running the browser but on the customer site I don't get the IP-number of the user machine, I get some other IP-number. The browsers don't have any proxies set or anything like that.
Should I be using something else than Request.UserHostName?
I recommend using IP addresses as well. I'm dealing with this exact same situation setting up an authentication system right now as well and the conditions described by Epso and Robin M are exactly what is happening. External users coming to the site give me their actual IP address while all internal users provide the IP of the gateway machine(router) on to the private subnet the webservers sit on.
To deal with it I just check for that one IP. If I get the IP of the gateway, I provide the internal access. If I get anything else they get the external one which requires additional authentication in my case. In yours, it would just mean a different interface.
Try Request.UserHostAddress, which returns the client's IP address. Assuming your internal network uses IP addresses reserved for LANs, it should be relatively simple to check if an IP is internal or external.
There might be a firewall that is doing some sort of NAT, to enable inside clients to use the external dns-name to reach the server.
Is the IP-number you get on customer site the same at the external customer-server ip? In that case you can hard code for that one IP-address. All internal computers behind that firewall will appear to have to same ip-address and you can classify them as "internal".
It looks like you're being returned a public facing IP Address. Get the user to go to http://www.myipaddress.com . If this is the same as the IP Address returned to your software, then this is definitely the case.
The only solution I can see to get around this is to either get them to connect to the machine holding the asp.net application via a VPN, or to use some other kind of authentication. The latter is probably the best option.
It does sound like there is a proxy between users and the server on the customer site (it doesn't need to be configured in the browser). It may be an internal or external proxy depending on your network configuration.
I would avoid using the UserHostName for what is effectively authentication as it is presented by the browser duing the request and would be easy to spoof. IP address would be much more effective as it's difficult to spoof an IP address in a TCP/IP connection (and maintain a connection). It's still weak authentication but may be sufficient in this scenario.
Even if you are using IP address, if there's a NAT proxy between client and server, you may have to accept that anything coming through that proxy is trusted (I'm assuming that external/untrusted clients don't come through that proxy).
If that isn't acceptable, you're back to other methods of authentication. Rather than requiring a logon or VPN connection, you might consider a permanent cookie or client certificates and only give those to internal clients but you would need some way of delivering those to the client. You could certainly deliver a permanent cookie based on a one-time logon. Cookies can be spoofed in a similar way in that the UserHostName can be however you've got a better opportunity to create a cookie value that is less guessable than a domain name.