The Situation
I have come across some very suspicious PUT and GET requests in my IIS server logs. After Googling the requesters address, I have found information linking the IP's to known hacking teams. After each PUT there is an immediate GET for the same resource that was attempted to be uploaded to my server.
Question 1:
Would this be considered a remote code execution attack?
Additional Testing Completed By Me:
The IIS logs show that the response given for the PUT request was 412 'Invalid file type all files are not uploaded'
I have turned on Failed Request Tracing and attempted to upload text files using CURL and this is the same response I am provided with and was not able to upload a file.
Question 2:
What can I do to help prevent these type of attacks from being successful?
I can turn on IIS request filtering, but I am concerned that if I deny PUT my IIS application may be negatively impacted for any future web services.
Question 1: Would this be considered a remote code execution attack?
It is impossible to determine the intentions of the attacker from the information given. They could be looking to gain code execution, or they may simply settle for uploading their own content to your server for you to host, or to try and deface your site with their content.
Question 2: What can I do to help prevent these type of attacks from being successful?
Server configuration and patching. The best advice I could give you is to reduce the attack surface - only enable the features you need. If you're not using PUT in your application, then disable it. Only reenable it if needed. Make sure you have the latest updates for your OS installed.
Security is a wide subject. You need everything from secure code when developing applications to rigorous security testing after.
I am using JBoss JMX Console to monitor my Web Application.
How can i find what http requests are being processed at any point in time?
For eg: I see 25 busy theads - i want to know what http requests are these threads processing.
I am not really sure if there is an ability to map a specific request to a thread but you can certainly see what HTTP requests are made to Tomcat using AccessLogValve. You can probably use the timestamps to map those requests if need be.
Jasper;
The arduous way to do this is to examine every instance of the MBeans that have this pattern:
jboss.web:name=HttpRequest1,type=RequestProcessor,worker=http-0.0.0.0-18080
They are MBeans that represent the web request serving threads and they have an attribute called currentQueryString which is the query string of the request currently being processed. There are also attributes for currentUri and method. You could script the collection of this data as well.
An easier way, which is enabled in JBoss servers by default, is to use the available at:
http://localhost:8080/web-console/status
It handily aggregates those same MBean's and reports them in one page.
There is also options for a fuller report
http://localhost:8080/web-console/status?full=true
and an XML formatted output
http://localhost:8080/web-console/status?XML=true
I have a .NET web service hosted in IIS. The web service has been used by clients over the past few years and there has been occassional timeout events when the client is on a slow connection (e.g. GPRS). On the other hand the clients sometimes have to POST some data to another web page (part of an ASP.NET web app) and usually the size of the data in the POST requests is bigger than the actual payloads in the web service calls. However the POST requests are far quicker as compared to the web service calls.
To establish this further I created a test web service with one method and another single web page with exactly the same operation i.e. receive 100K and send back 100K (random bytes) and I used a test client to call the web service method as well as did a post to the web page and got a response back using the same client. The difference in receiving a reply back from the web service and a response back from the web post request is huge i.e. about 1200 ms. Why is that the case? Is there any such configuration on the web service that would make such a big difference? Is it SOAP call stack? Serialization/Desrialization?
A number of factors could be contributing to this.
The first thing that leaps to mind for me is that SOAP could be considered a verbose protocol. That is, there's a LOT of data in the XML payload going both ways. XML is verbose in and of itself, and it's not exactly the fastest thing in the universe to process. Sure, you can use an optimized library to process it's data, but it'll be parsed out into object trees, then you can walk the nodes to drill down to the data you want. Unless you're using XPath, which will just do the same darned thing.
This is all presuming that you're actually using SOAP. And that your WebService is correctly configured. And that no packet loss is occurring while connecting to the Web Service. And that your firewall isn't creating issues. And that there's no encryption/decryption overhead.
In my own experience, one thing that frequently causes signficant slowdowns server side is one or more thrown exceptions. Try a Fiddler trace.
We have created an http module to mobile detection and redirection. What the http module will do is according to the coming request it will find the device and redirect accordingly.
So here we want to log the methods in the http module. But i don't know whether it is a good practice to log all the requests? We planned to use text file logging. We have concerns about the performance since it will log all requests.
Please give your suggestions.
Depending on what information you want to log, all request are logged in iis. You can these log at %SystemDrive%\inetpub\logs\LogFiles. If the information is not there you can add extra information or add extra logging in the global asax. Good loggers will have minimal impact on you application. You should watch you diskspace at all time, and make a business case on what you want to do with the information.
I am building an ASP.NET web application that will be deployed to a 4-node web farm.
My web application's farm is located in California.
Instead of a database for back-end data, I plan to use a set of web services served from a data center in New York.
I have a page /show-web-service-result.aspx that works like this:
1) User requests page /show-web-service-result.aspx?s=foo
2) Page's codebehind queries a web service that is hosted by the third party in New York.
3) When web service returns, the returned data is formatted and displayed to user in page response.
Does this architecture have potential scalability problems? Suppose I am getting hundreds of unique hits per second, e.g.
/show-web-service-result.aspx?s=foo1
/show-web-service-result.aspx?s=foo2
/show-web-service-result.aspx?s=foo3
etc...
Is it typical for web servers in a farm to be using web services for data instead of database? Any personal experience?
What change should I make to the architecture to improve scalability?
You have most definitely a scalability problem: the third-party web service. Unless you have a service-level agreement with that service (agreeing on the number of requests that you can submit per second), chances are real that you overload that service with your anticipated load. That you have four nodes yourself doesn't help you then.
So you should a) come up with an agreement with the third party, and b) test what the actual load is that they can take.
In addition, you need to make sure that your framework can use parallel connections for accessing the remote service. Suppose you have a round-trip time of 20ms from California to New York (which would be fairly good), you can not make more than 50 requests over a single TCP connection. Likewise, starting new TCP connections for every request will also kill performance, so you want pooling on these parallel connections.
I don't see a problem with this approach, we use it quite a bit where I work. However, here are some things to consider:
Is your page rendering going to be blocked while waiting for the web service to respond?
What if the response never comes, i.e. the service is down?
For the first problem I would look into using AJAX to update the page after you get a response back from the web service. You'll also want to consider how to handle the no response or timeout condition.
Finally, you should really think about how you could cache the web service data locally. For example if you are calling a stock quoting service then unless you have a real-time feed, there is no reason to call the web service with every request you get. Store the data locally for a period of time and return that until it becomes stale.
You may have scalability problems but most of these can be carefully engineered around.
I recommend you use ASP.NET's asynchronous tasks so that the web service is queued up, the thread is released while the request waits for the web service to respond, and then another thread picks up when the web service is done to finish off the request.
MSDN Magazine - Wicked Code - Asynchronous Pages in ASP.NET 2.0
Local caching is an absolute must. The fewer times you have to go from California to New York, the better. You might want to look into Microsoft's Velocity (although that's still in CTP) or NCache, or another distributed cache, so that each of your 4 web servers don't all have to make and cache the same data from the web service - once one server gets it, it should be available to all.
Microsoft Project Code Named "Velocity"
NCache
Other things that can go wrong that you should engineer around:
The web service is down (obviously) and data falls out of cache, and you can't get it back. Try to make it so that the data is not actually dropped from cache until you're sure you have an update available. Then the only risk is if the service is down and your application pool is reset, so don't reset it as a first-line troubleshooting maneuver!
There are two different timeouts on web requests, a connect and an overall timeout. Make sure both are set extremely low and you handle both of them timing out. If the service's DNS goes down, this can look like quite a different failure.
Watch perfmon for ASP.NET Queued Requests. This number will rise rapidly if the service goes down and you're not covering it properly.
Research and adjust ASP.NET performance registry settings so you have a highly optimized ASP.NET thread pool. I don't remember the specifics, but I seem to remember that there's a limit on IO Completion Ports and something else of that nature that are absurdly low for the powerful hardware I'm assuming you have on hand.
the trendy answer is REST. Any GET request can be HTTP Response cached (with lots of options on how that is configured) and it will be cached by the internet itself (your ISP, essentially).
Your project has an architecture that reflects they direction that Microsoft and many others in the SOA world want to take us. That said, many people try to avoid this type of real-time risk introduced by the web service.
Your system will have a huge dependency on the web service working in an efficient manner. If it doesn't work, or is slow, people will just see that your page isn't working properly.
At the very least, I would get a web stress tool and performance test your web service to at least the traffic levels you expect to get at peaks, and likely beyond this. When does it break (if ever?), when does it start to slow down? These are good metrics to know.
Other options to look at: perhaps you can get daily batches of data from the web service to a local database and hit the database for your web site. Then, if for some reason the web service is down or slow, you could use the most recently obtained data (if this is feasible for your data).
Overall, it should be doable, but you want to understand and measure the risks, and explore any potential options to minimize those risks.
It's fine. There are some scalability issues. Primarily, with the number of calls you are allowed to make to the external web service per second. Some web services (Yahoo shopping for example) limit how often you can call their service and will lock out your account if you call too often. If you have a large farm and lots of traffic, you might have to throttle your requests.
Also, it's typical in these situations to use an interstitial page that forks off a worker thread to go and do the web service call and redirects to the results page when the call returns. (Think a travel site when you do search, you get an interstitial page while they call out to an external source for the flight data and then you get redirected to a results page when the call completes). This may be unnecessary if your web service call returns quickly.
I recommend you be certain to use WCF, and not the legacy ASMX web services technology as the client. Use "Add Service Reference" instead of "Add Web Reference".
One other issue you need to consider, depending on the type of application and/or data you're pulling down: security.
Specifically, I'm referring to authentication and authorization, both of your end users, and the web application itself. Where are these things handled? All in the web app? by the WS? Or maybe the front-end app is authenticating the users, and flowing the user's identity to the back end WS, allowing that to verify that the user is allowed? How do you verify this? Since many other responders here mention a local data cache on the front end app (an EXCELLENT idea, BTW), this gets even MORE complicated: do you cache data that is allowed to userA, but not for userB? if so, how do you verify that userB cannot access data from the cache? What if the authorization is checked by the WS, how do you cache the permissions then?
On the other hand, how are you verifying that only your web app is allowed to access the WS (and an attacker doesn't directly access your WS data over the Internet, for instance)? For that matter, how do you ensure that your web app contacts the CORRECT WS server, and not a bogus one? And of course I assume that all the connection to the WS is only over TLS/SSL... (but of course also programmatically verify the cert applies to the accessed server...)
In short, its complicated, and many elements to consider here.... but it is NOT insurmountable.
(as far as input validation goes, that's actually NOT an issue, since this should be done by BOTH the front end app AND the back end WS...)
Another aspect here, as mentioned by #Martin, is the need for an SLA on whatever provider/hosting service you have for the NY WS, not just for performance, but also to cover availability. I.e. what happens if the server is inaccessible how quickly they commit to getting it back up, what happens if its down for extended periods of time, etc. That's the only way to legitimately transfer the risk of your availability being controlled by an externality.