I am having an issue with a server where someone is sending thousands of requests from same IP in a minute. How do you limit amount of requests per minute per IP on Azure and if possible ban the IP temporary or permanently after that?
If you want to Permanently Ban a specific IP use an IPsec policy in your VM.
Find the details in the below link
http://www.serverintellect.com/support/windowsserversecurity/ipsec-blockip/
Otherwise If you Can to do it programatically. This is basically to prevent DDOS attacks. Please go through the below links
http://omaralzabir.com/prevent_denial_of_service__dos__attacks_in_your_web_application/
In Case You want to limit the no of requests from an IP
http://codingfreak.blogspot.com/2010/01/iptables-rate-limit-incoming.html
Related
My understanding is that when querying a domain's DNS records, the response can vary depending on the client's IP address. Is there a simple way to obtain all DNS records for all possible IP addresses?
You can not.
The response can vary on many factors.
You can not from remote discover the business policies of a nameserver, or in fact any server. It can decide to reply 192.0.2.1 for odd hours and 192.0.2.11 for even ones, or any other non trivial business rule.
A more realistic one: there can be a service on 3 IP addresses. A nameserver may be programmed to reply with the IP address of the box being currently less loaded. Hence you will never be able to see those details remotely.
I’m investigating a scenario with a live dashboard (Angular web app) that is refreshed every 5 seconds (polling). The API is sitting behind Azure Traffic Manager which will fail over to a second region in the event of a failure in the primary region. Keep in mind, Azure Traffic Manager works at the DNS level.
The problem I am facing is that the browser maintains a persistent connection to the primary region even after the Traffic Manager has failed over. The requests initially fail with 503s, but then continue to fail with 502s. The DNS lookup is never performed again as the requests occur more frequently than the keep-alive timeout. This causes the browser to continue to make requests to the failed region.
Is there anyway to explicitly kill the connection to force a DNS lookup? The only way I’ve found so far is to stop making requests for 2 minutes, or to close and reopen the browser. Neither is an acceptable solution for a dashboard that is supposed to be hands off and always fresh.
What’s interesting is after getting the browser to fail over to the secondary region, if I restart the primary region the browser will automatically switch back to the primary region after about a minute. This tells me the connection is respecting the DNS TTL when the service is functioning properly, but not when the server is unavailable. This makes no sense to me why the browser would lock onto a single IP forever when it’s not found.
Is there something I am missing about implementing georedundant failover with Traffic Manager for a web application? It seems very odd to me that the user would have to stop making requests for 2 minutes in any scenario before the browser would renegotiate the IP to the failed over server. Is it expected to turn of keep-alive to truly support near instant failover?
Here's a diagram that describes this scenario:
Diagram
Generally, Azure Traffic Manager works at the DNS level. Clients connect to the service endpoint directly, not through Traffic Manager. Traffic Manager has no way to track individual clients and cannot implement 'sticky' sessions.
For initial DNS lookup performance impact, you could find the explanation details here1 and here2
DNS name resolution is fast and results are cached. The speed of the
initial DNS lookup depends on the DNS servers the client uses for name
resolution. Typically, a client can complete a DNS lookup within ~50
ms. The results of the lookup are cached for the duration of the DNS
Time-to-live (TTL). The default TTL for Traffic Manager is 300
seconds.
The TTL value of each DNS record determines the duration of
the cache. Shorter values result in faster cache expiry and Longer
values mean that it can take longer to direct traffic away from a
failed endpoint. Traffic Manager allows you to configure the TTL as
low as 0 seconds and as high as 2,147,483,647 seconds. You could
choose the value that best balances the needs of your application.
Like the above, if you want the DNS lookup faster, you could set the TTL value as low as possible. Once the connection set up, the clients persistently connect to the selected endpoint until the endpoint is unhealthy via the health check.
You can enable and disable Traffic Manager profiles and endpoints. However, a change in endpoint status also might occur as a result of Traffic Manager automated settings and processes.. Get more details here.
For Geographic routing method,
The endpoint mapped to serve the geographic location based on the
query request IP’s is returned. If that endpoint is unavailable,
another endpoint will not be selected to failover to, since a
geographic location can be mapped only to one endpoint in a profile
(more details are in the FAQ). As a best practice, when using
geographic routing, we recommend customers to use nested Traffic
Manager profiles with more than one endpoint as the endpoints of the
profile.
I am trying to find a powershell command which helps find out a way that there is no open connections or any traffic is flowing to endpoint1 or confirm traffic is moving smoothly to endpoint2 after disabling endpoint1:
$e[0].EndpointStatus = "Disabled"
Set-AzureRmTrafficManagerEndpoint -TrafficManagerEndpoint $e
Is there a command to do this? I am not able to find anything in google or should I use some wait command to wait for like a minute to flush out all open connections?
*Basically looking for a way to make sure all in-flight connections are drained from one endpoint before disabling it.
Traffic does not flow through your Traffic Manager instance. Therefore, the functionality you are asking for from Traffic Manager does not exist. Traffic Manager simply resolves DNS queries to an IP address of one of your endpoints using the routing method (priority, weighted, performance, etc) you configured it for.
After disabling an endpoint, you could still see traffic going to the disabled endpoint for a period of time measured by your Traffic Manager profile DNS TTL setting. For example, if you disable an endpoint at 3:01:00 and your DNS TTL setting is 90 seconds, then you could see traffic until 3:02:30 because that's how long it could take for any client's DNS cache to expire. One way to monitor this is through the Queries by Endpoint Returned metric described here. This should work in most cases. However, it's not 100%. Just because you disabled an endpoint in Traffic Manager won't stop a client that know's the IP address of your endpoint from calling it. You can decide whether or not this scenario is likely for your application and clients. So, to be absolutely certain there are no active clients using the endpoint, you will need some monitoring in place at the endpoint.
Finally, if you gracefully stop your web app, virtual machine, or other service hosting the endpoint you want disabled, then any active requests to your application will complete before the service shuts down, assuming your application completes requests in a reasonable time (a few seconds).
Documentation on how to test and verify your Traffic Manager settings is available here.
For several days I am experiencing that Azure Web Services is receiving many requests in seconds. Due to this Website is not able to load.
Since many days I am experiencing that Azure Web Services is receiving many requests in seconds.
You could check the request logs by enable Web Server Logging in Azure Portal. By researching the log, you could know whether the requests are from legitimate users or programs. If they are from trusted users or programs, you could scale up or out your web app to meet the large number of requests.
If the requests are from attackers, you could block these kinds of requests by configuring Dynamic IP Address Restrictions(DIPR). The DIPR feature provides two main protections for developers:
Blocking of IP addresses based on number of concurrent requests
Blocking of IP addresses based on number of requests over a period of time
For more information, link below is for your reference.
Configuring Dynamic IP Address Restrictions in Windows Azure Web Sites
If IP addresses of the requests are stable, you can also block these addresses or a range of IP addresses using ipSecurity configuration. For more information, link below is for your reference.
IP and Domain Restrictions for Windows Azure Web Sites
We are nearing our maximum allowable whitelisted IP addresses.
We'd like to find out if any of the ones we whitelisted are no longer in use so we can reallocate that slot.
Didn't tested ..but here is an overview of how i think you can do this..
when you run below DMV you can get all Firewall rules
sys.firewall_rules
Now you can monitor connections through
1.Sys.dm_exec_connections
2.Auditing
With approach 1 ,you will have to devise a way to log the DMV output to table for the period required and then you can delete those IP's from firewall
With approach 2,you can enable auditing and log only login info like below
when you explore logs now,you can see IP address of clients connected