Forum Discussion
NimbostratusF5 LTM logs and application access logs
MVPHi enen ,
if there is a SQLi attack using the SLEEP command, it will pass LTM without affecting it. The SLEEP command will only affect the SQL server in the backend, where it is executed.
The packet first passes the load balancer, before it reaches the web server. However, the latency added by a load balancer is negligible, it is between milliseconds and microseconds.
Since webserver logs are usually in seconds and not milliseconds or microseconds, you won't notice it. Logs can easily be correlated.
It is important to know, that LTM in it's default configuration won't log the payload of a HTTP request. From the LTM log you cannot see the SQLi attack.
If you want to protect yourself from SQLi and similar attacks - get a WAF :)
Cheers
Daniel
NimbostratusHi Daniel_Wolf ,
Thanks for your kind response and help. Since we do not have the access to test this kind of scenario, but we would like to know just in case we do not have WAF enabled, would this be one of the limitations from not having WAF, thereby preventing us to justify whether this kind of attack was really succeed or not, by simply looking at LTM logs and server access logs, and trying to correlate between them. Therefore, may need to gain more information on how would these logs reveal to us in this kind of scenario.
If let's say the payload was logged in LTM logs, in the URL path, (the payload was not in the request body), and when trying to correlate the attack events timeline, if most of the attack timing from LTM logs matched the server access logs, would it be valid to justify the attack events as not succeed?
E.g., if let's say the SQLi attack with SLEEP command, for like certain minutes, would it be expecting the LTM logs would have logs with earlier logged time, which could be certain minutes earlier than the server access logs? Or would the LTM and server logs would just record it with the almost same request time, probably the timing when the request reached the LTM and the server itself (without showing any delay in server access logs)?
Regards
enen
- Daniel_Wolf
Hi enen ,
let's go over your questions one after the other.
- By simply looking at the LTM logs you won't be able to see the attack. LTM does not log URLs, Headers, Cookies, Query Parameters or anything that would help you identify any kind of injections attacks. You can configure such level of logging with the help of iRules and High-Speed Logging.
Do not log locally on the F5, use Remote High-Speed Logging. Many customers confuse their BIG-IP with a log storage device... - If you correlate the logs from LTM and Web Server and you see an injection attack, you cannot say whether the attack was succesful or not.
Take look at the diagram below, let's assume you have F5 BIG-IP with only LTM and a LAMP stack behind the F5.
An attacker tries a time-based injection attack on your SQL server, like SLEEP. The payload will pass the BIG-IP and the Apache server, because they don't parse it. They are like bystanders.
Then it comes to the PHP layer where the payload is parsed and transformed to a query. If no input sanitization happens here, the malicious query will be forwarded to the SQL server.
Here first part of the query is executed and the the second part of the query is pausing the database for a specified amount of time, before returning the query result.Now for the logging:
- BIG-IP LTM by default does not log HTTP requests.
- In the Apache access_log you should be able to see the full request URI/query string.
- In the PHP layer logs you might also not see a lot. Depends on your settings.
- In the SQL server log you should see every query and you should be able to find keywords like SLEEP.
If you want to solely rely on the F5 for logging, you should not only log the HTTP requests but also the HTTP responses. Then you can search for keywords like SLEEP in the logs and check if the response really comes 5 or 10 or whatever seconds later compared to the same request without the SLEEP command.
Take into account that the SQL query also needs time to execute. If this is the query string
GET /product?id=1' AND SLEEP(5)-- -the execution of searching the product with the ID 1 might already take 5 seconds and then the sleep with add another 5.
So you would need to know how long the execution of a benign query takes and then add 5 or 10 or X seconds and correlate HTTP request and response logs to figure out if the SQL injection attack was successful.Just get yourself a WAF 😁 It'l make you happy and your life will be easier.
Cheers
Daniel- enen
Hi Daniel_Wolf ,
Thanks for the clarification and the detailed explanations given, greatly appreciate all these. So sorry about this, I think I confused with the LTM logs and F5 virtual server logs. Seemingly the logs I'm currently referring to is the F5 virtual server logs which would log some HTTP request details like http_method, uri, http_status, response_size, etc. If this is the case, do you think it would somehow help us in correlating the logs by correlating the event time in the f5 virtual server logs and the server access logs itself? Or would you think we can't really tell whether the attack was successful?
Regards,
enen
- Daniel_Wolf
Also nothing a virtual server would log by default. Sounds like you have AVR enabled besided LTM. Can verify that?
Cheers
Daniel
- By simply looking at the LTM logs you won't be able to see the attack. LTM does not log URLs, Headers, Cookies, Query Parameters or anything that would help you identify any kind of injections attacks. You can configure such level of logging with the help of iRules and High-Speed Logging.
