I'm trying to set up IP-level throttling (using Carbon console) for a range of IP. Suppose my IP is 10.100.1.115. Adding the following range (equivalent to 10.100.1.*) works ok:
<wsp:Policy>
<throttle:ID throttle:type="IP">10.100.1.0 - 10.100.1.255</throttle:ID>
<wsp:Policy>
<throttle:Deny/>
</wsp:Policy>
</wsp:Policy>
But trying to add a range of 10.100.0.0-10.100.255.255 (equivalent to 10.100..) does not work, i.e the IP is not denied access.
Is there a limitation of a.b.c.* range?
Is there a way to specify a range of a.b..?
The above range you are trying to specify contains of IP addresses from 2 different networks (10.100.0.0 and 10.100.255.255).
If you are to limit the application of throttling to a specific range , the IP addresses should belong to the same network.
It does not make sense to use the above range (ie. 10.100.0.0-10.100.255.255) as the IP addresses don't belong to the same network.
Instead the range should be something similar to 10.100.0.0-10.100.0.10
Related
I have set up Google Cloud Armor security policy referring to https://cloud.google.com/armor/docs/rules-language-reference. It worked fine. My simulated SQL injection attack from my office was detected and subsequent accesses were blocked. Stackdriver log entry shows corresponding enforcedSecurityPolicy outcome of "deny" and applied expression ID was "owasp-crs-v030001-id942421-sqli". The key WAF rule is as follows:
evaluatePreconfiguredExpr('xss-stable') && evaluatePreconfiguredExpr('sqli-stable')
One point I cannot control. After my simulated attack, all accesses from my office are blocked all the way along. Once I detached and re-attached the Cloud Armor security policy from and to LB, the access from my office are still blocked. Deleting that security policy and re-created it again does not help. This implies there is an unseen persistent database of SQLi & XSS attackers and my office IP might be registered in it, causing that 'all-the-time' denial.
Question is : how can I remove my IP from that unseen 'SQLi & XSS blacklist' database to regain backend access without modifying rules? In our Cloud Armor production operation, once-forbidden IP may want to regain access to the target backend service after its attack source is removed.
Certainly, if I add higher priority permission rule than the WAF rule, I can regain access to the target backend, but WAF check will be bypassed, which is not what I want.
Thank you in advance for your time.
R.Kurishima
I had a similar situation and almost concluded the same thing you did -- that there's some kind of hidden blacklist. But after playing around some more, I figured out that, instead, some other non-malicious cookies in my request were triggering owasp-crs-v030001-id942421-sqli ("Restricted SQL Character Anomaly Detection (cookies): # of special characters exceeded (3)" -- and later owasp-crs-v030001-id942420-sqli ("Restricted SQL Character Anomaly Detection (cookies): # of special characters exceeded (8)"). Not a hidden blacklist.
Near as I can tell, these two rules use the number of 'special' characters in the Cookies header, and not the number of special characters in each cookie. Furthermore, the equals sign -- which is used for each cookie -- counts as a special character. Same with the semicolon. Irritating.
So this request will trigger 942420:
curl 'https://example.com/' -H 'cookie: a=a; b=b; c=c; d=d; e=e;'
And this will trigger 942421:
curl 'https://example.com/' -H 'cookie: a=a; b=b;'
So probably best to disable these two rules, something like
evaluatePreconfiguredExpr('sqli-canary', [
'owasp-crs-v030001-id942420-sqli',
'owasp-crs-v030001-id942421-sqli'
])
I cannot find the server with IP 54.240.3.17 in the IP ranges list published by Amazon https://ip-ranges.amazonaws.com/ip-ranges.json
According to ip-location it is in Seattle, but it should be in EU West.I know that the ip-location is normally not that reliable, but does anyone know why it is not in the IP ranges list?
As the list of public AWS IP-ranges is pretty long and matching an IP-address with a network can be error prone I wrote a little script to check if the IP-address is really not included in the list:
#!/usr/bin/env python3
import ipaddress
import json
import urllib.request
IP_ADDRESS_TO_CHECK = ipaddress.IPv4Address('54.240.3.17')
response = urllib.request.urlopen('https://ip-ranges.amazonaws.com/ip-ranges.json')
json_response = json.loads(response.read())
for ip in json_response['prefixes']:
if IP_ADDRESS_TO_CHECK in ipaddress.IPv4Network(ip['ip_prefix']):
print(ip)
Running this does indeed verify that the IP address is currently not included in the list of public IPv4 ranges published by AWS.
I can only guess why that's the case, but it seems likely that AWS just hasn't updated the list yet to include the network the IP-address is part of. Note that the currently served list is already three days old, as you can see from the embedded createDate:
"createDate": "2019-10-18-19-53-09",
I have some Rails 6 applications, deployed at AWS, via Opsworks.
After upgrading to Rails 6 the app blocks the health check of its own instance and it causes the load balancer to take the instance down.
I would like to know how to whitelist all my EC2 instances automatically with dynamic IP addresses? Instead of adding one by one to config/application.rb?
Thanks
Rails.application.configure do
# Whitelist one hostname
config.hosts << "hostname"
# Whitelist a test domain
config.hosts << /application\.local\Z/
# config.hosts.clear
end
The work-around that worked for me was
config.hosts.clear
I posted this question a while back. A safer solution would be reading the IP addresses from environmental variables that can be set from the AWS console.
config.hosts << ENV["INSTANCE_IP"]
config.hosts << ENV["INSTANCE_IP2"]
...
config.hosts << ENV["INSTANCE_IPn"]
At least in this way it does not require a new git commit every time the IP address changes when the instance has a dynamic IP.
Simple solution is to allow the Health Checker user agent, add this to your production.log
config.host_authorization = {
exclude: ->(request) { request.user_agent =~ /ELB-HealthChecker/ }
}
Looks like it has been resolved in the latest versions atleast works on 6.1 and above
https://guides.rubyonrails.org/configuring.html#actiondispatch-hostauthorization
You can exclude certain requests from Host Authorization checks by setting config.host_configuration.exclude:
# Exclude requests for the /healthcheck/ path from host checking
Rails.application.config.host_configuration = {
exclude: ->(request) { request.path =~ /healthcheck/ }
}
"The bind address of this member. The difference between localMemberHost & localMemberBindAddress
is that localMemberHost is the one that is advertised by this member, while localMemberBindAddress
is the address to which this member is bound to."
We are in the process of making API Manager components HA ready. As a result of that, we are upgrading configurations as per the cluster guide. HazelcastClusteringAgent configs are getting updated as well. As I quoted at the top most section provided comment is bit unclear, much appreciated if you can eloborate more. Furthermore, would like to know that, this is still a valid set of parameters that need to be fulfilled if we are following the AWS clustering configs for Hazelcast.
In the event of AWS clustering the bind address is constructed (if using aws discovery) by the resulting IP address returned from the ec2:describe instances and the configured listen port (5701 default). So you would not set the bind address it is set by the plugin.
I am trying to setup an email server using an EC2 instance(postfix)
I am trying to understand the value "10 mailserver.domainame.com".
does it mean I must do "hostname mailserver.domainame.com" on my email server? which means having mailserver.domainame.com as the hostname?
what about the number "10"?
thanks.
10 is the "cost" of the mail exchanger. If you had a primary and a backup, you'd set the backup as a higher value, such as 20... so that servers trying to deliver mail to your domain would try the "lowest cost" (10) before the higher cost (20) server, and only use the 20 machine if they found the 10 machine inaccessible. The number 10 is arbitrary. It could be 5 or 0 or 17. It has no real meaning if you only have one mail exchanger, but is still required.
You do not need to set the internal hostname of the machine at mailserver.example.com. Nobody really sees or cares about that except you. As long as you have a DNS A record for mailserver.example.com that returns the correct IP address, that is sufficient for MX configuration.