I would like to know if there is a way to detect auto DDoS on a website?
Currently, we have a site in .NET that static resources (styles and JS) are being down totally on random date-time, so we have tried everything like permissions, etc. However, nothing seems to work.
Any help or hint on what can be causing the issue to stop loading static resources randomly? We think this could have something related to a DDoS attack, but we would like to know how to detect it and probably skip this option if that is not happening.
Btw, this issue is fixed when we recycle the IIS app pool in the server.
You should check if a DDoS attack actually occured by checking the web server logs.
Is there any unusual number of connections, are the request slower than usual ?
If it is just some part of the website who refuses to load, caching may be an issue.
There are several Web Application Firewalls that can help detecting DDoS attacks, but I have no experience regarding their efficiency.
Regards
Related
Is there a way to make a machine that is connected to the internet unreachable by any means except REST requests? For background as to my quetion:
I have a really nice REST server/client project, with encrypted communication, in which the weak spot in the encryption technique is the code. Without seeing the code it is impossible to break the encryption, but if you see the code it is probably possible to figure out how to decrypt intercepted communication.
Due to this, I would like the server code at least to be as well protected as possible. Is there a way to make a machine that is connected to the internet unreachable by any means except REST requests to stop any hope of an attacker gaining access to the code or data that the server is serving up? I'm open to the idea of a bare metal solution if that would make for the safest system, the server's only job really will be just to server information requested via REST requests and nothing else.
(I'm aware this will still leave the client code as a weak spot, but I'm taking this one step at a time. Protecting the client code is presumably going to be a much bigger problem and probably impossible as I intend to eventually distribute the client executables).
First, I'm way over my head as I know just about nothing about managing a server, even less a server's security settings (I have been externally hosted for 20 years!).
My shared environment host (Newtek) has recently turned off sslV3, (I understand is a good thing -see poodle bug), but since then, some API calls that are being made are slow and some are not.
All API calls to UPS, CanadaPost and Paypal are slow (average of 20 sec per call ) while all calls to FB or Google map are fast (1 sec. per call).
All API calls use HTTPS.
My question to you is either:
-Does anybody have some clues has to what is going on? And if not, does anybody have any suggestions as to how to find out what is going on? Basically where and how to even look for the source of trouble!?! (As I don't know enough about what is going on behind the scene for any part of these connections to troubleshoot.)
A few notes:
After my host investigated various things, they have ruled out xmlParser as the cause,since the slowness can be observed even on dumping the cfhttp.filecontent.
My host installed a new version of my domain ssl which now uses SHA256.
My host server is running CF10 on IIS 7
I can't reproduce this on my local development server and of course don't have full access to the live server.
There is no CF error to report. Only very slow connection.
Thank you for any help you can provide!
I have written an iPhone application communicating with a server. The app sends a message to the server and prints the result.
Now I have a question: Is there a way to know if the message sent to the server came from an iPhone?
I am asking this because I want to prevent attackers from sending messages from somewhere else and flooding the server.
If you use in-app purchases, then there is a full authentication chain that validates device X purchased the app. You're server can track this and then only give full responses to previously authenticated devices.
This approach also keeps pirated apps pretty much out of the picture.
This approach wouldn't stop a concerted DDOS attack, but your server can at least ignore non-valid clients and thus reduce its workload significantly. Since your server is ignoring invalid requests here, it also makes it less appealing to potential non-device users and the illicit user would probably only attack you if they disliked you, as opposed to them just bogging down your server for its free web services.
If you don't use in app purchases, you could set up your own authentication process and give a token to the device and have your server remember said tokens, and then later only serve valid responses for requests that had the said token (appropriately hashed and salted). This approach would not stop pirated apps from using your service, but would effectively stop non-devices from using your web service (again, except for concerted hacking efforts).
An even simpler approach is to have an obfuscated request format that would take a concerted effort to reverse engineer.
In all of these approaches, you might have to monitor your server for unusual activity and then taking appropriate steps.
I would encourage you to match your efforts to the expected risk. You can spend days, months, even years, properly securing an app, make sure the cost is worth the reward.
You could do some form of authentication, encryption or fingerprinting, eg. using SHA, MD5, etc. That way you could make it difficult (but not impossible) for an attacker to abuse your server.
You can't tell it's from an iPhone until you have received and examined the connection on the server. If you do that, you have already opened the possibility of a DOS (Denial of service) attack due to connection exhaustion.
I'm looking to add some sort of HTTP push-like functionality, implemented via long polling or another standard means, to a page built with Perl on top of Apache.
Is there a way to do this without setting up a separate server such as Meteor or Stardust? Is there a module that would help with the server code? Is there a way other than long polling?
If your need a quick and dirty fix to avoid major changes to your current application or design, and you do not need instant updates, then one simple approach is to use regular AJAX polling from the browser to the server.
In other words you would have javascript in your browser check the server every couple of seconds to see if there is any message and/or data on the server for this browser session. This will most likely not scale very well, especially with short poll timeouts, and will eat up server resources, but it may be a useful stopgap solution.
Just to reiterate, this is just a quick fix workaround - general consensus is you need to use COMET (probably on a separate server in your case) as a proper solution (until websockets arrive...) - see some good analysis in these links:
http://cometdaily.com/2007/11/06/comet-is-always-better-than-polling/
http://stackoverflow.com/questions/2975290/comet-vs-ajax-polling
I'm banging my head here trying to figure out why there is a three to four second overheard for when an NSURLConnection object is created with a POST based NSMutableURLRequest. The overhead which I speak of, is after an NSURLConnection gets fired off, watching Apache access logs, I see the request come in substantially longer after invoking the request. On any other platform, I'd troubleshoot the latency that it takes to resolve DNS before going further. I shouldn't exclude the iPhone in this case as well. Has anyone else noticed similar behavior?
Thanks.
Sounds plausible that DNS is your bottleneck. Try making the request by address instead of name - at least for debugging.
Is DNS a known bottleneck for the iPhone. I've noticed this as well on my 3G connection. Did you workaround the problem by using the address instead of the hostname?