I am hosting a small test website in ec2 and there should be only 2-3 test users with valid login to my server. However, I am seeing a lot of junk logs in my apache access_log(
/var/log/httpd/access_log):
198.2.208.231 - - [13/Dec/2013:21:11:07 +0000] "GET http://ib.adnxs.com/ttj?id=1995383&position=above HTTP/1.0" 302 - "http://www.minbusiness.net/?p=611" "Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/533.18.1 (KHTML, like Gecko) Version/5.0 Safari/533.16"
173.234.32.69 - - [13/Dec/2013:21:11:07 +0000] "GET http://ads.creafi-online-media.com/st?ad_type=iframe&ad_size=728x90,468x60§ion=5172215&pub_url=${PUB_URL} HTTP/1.0" 302 - "http://lookfashionstyle.com/index.php?option=com_content&view=category&layout=blog&id=42&Itemid=98&limitstart=24" "Mozilla/4.0 (compatible; MSIE 6.0; WINDOWS; .NET CLR 1.1.4322)"
198.136.31.98 - - [13/Dec/2013:21:11:07 +0000] "GET http://ad.tagjunction.com/st?ad_type=ad&ad_size=468x60§ion=4914662&pub_url=${PUB_URL} HTTP/1.0" 302 - "http://www.benzec.com" "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.13) Gecko/2009073022 Firefox/3.0.13"
....
Not exactly sure what's going on... Am I being attacked?
thanks!
One possibility is that your server is configured as an open proxy and some ad scams are proxying traffic through it to hide their real origin.
There is alot of bots around the web attempting all kinds of exploits,
I spawned my web server just yesterday and already received lots of spamming/exploit attempts. Like the ones in the thread I've just created ( and not only, quite a few others.. Cloudflare is helping but it doesn't catch it all, at least not in the free version, which is what I am using to get some protection):
Exploit Attempts in nginx access log, Some logs without IP, what to do about it?
Related
We never had any problem and we didn't deploy anything, but one particular customer on his ipv6 addr is now getting 403 error from our Apache and I just can't figure out why.
I'm not sure what to provide but I double check every a2 config file.
I can see the customer access in the access.log (with the 403 code status), but nothing in the error.log.
access.log :
2a02:2788(...):102f - - [17/May/2021:12:54:12 +0200] "GET /page_url HTTP/1.0" 403 368 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.114 Safari/537.36 Edg/89.0.774.75"
2a02:2788(...):102f - - [17/May/2021:12:54:15 +0200] "GET /page_url HTTP/1.0" 403 368 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.114 Safari/537.36 Edg/89.0.774.75"
It's not on the application level too, we don"t have anything that return a 403 error.
Any idea on what Apache can do to trigger 403 error specificly on IP ?
Why/how is the customer seemingly making an HTTP/1.0 request? This alone could be sufficient reason for the server to reject the request since normal users using normal browsers don't send HTTP 1.0 requests. (HTTP/1.1 is expected.)
Generally, only certain bots make HTTP 1.0 requests.
An Apache module like mod_security could potentially have a rule that would block such requests. (Or any other rule using mod_rewrite, for instance, could also block such requests - but this is certainly not a default.)
Edg/89.0.774.75
It would seem this may have been a bug with Microsoft Edge, as the following Microsoft community post (from around the same time as this question) would seem to suggest:
https://answers.microsoft.com/en-us/microsoftedge/forum/all/internet-explorer-and-ms-edge-sends-ssl-requests/22708bcd-f196-45fb-84c9-6d8c34e7e08f
And as also noted in the above article, this would seem to have been "fixed" in later versions. So, your customer may also now be "fixed". (?)
I just got a quick question. My apache access log has random IPs from China, Japan, etc. It looks like they are trying to execute scripts from where they are.
The log looks like this: 171.117.10.221 - - [29/Jan/2018:08:05:04 -0800] "GET /ogPipe.aspx?name=http://www.dongtaiwang.com/ HTTP/1.1" 301 0 "-" "Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.3$
1.202.79.71 - - [29/Jan/2018:08:05:06 -0800] "GET /ogPipe.aspx?name=http://www.epochtimes.com/ HTTP/1.1" 301 0 "-" "Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (K$
113.128.104.239 - - [29/Jan/2018:08:05:11 -0800] "GET /ogPipe.aspx?name=http://www.wujieliulan.com/ HTTP/1.1" 301 0 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Ge$
117.14.157.148 - - [29/Jan/2018:08:05:17 -0800] "GET /ogPipe.aspx?name=http://www.ntdtv.com/ HTTP/1.1" 301 0 "-" "Mozilla/5.0 (Linux; U; Android 4.3; en-us; SM-N900T Build/JSS15J) AppleWebKit/$
110.177.75.106 - - [29/Jan/2018:08:05:37 -0800] "GET /ogPipe.aspx?name=http://www.dongtaiwang.com/ HTTP/1.1" 404 3847 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Firefox/$
221.11.229.244 - - [29/Jan/2018:08:05:57 -0800] "GET /ogPipe.aspx?name=http://www.epochtimes.com/ HTTP/1.1" 404 3847 "-" "Mozilla/5.0 (Linux; U; Android 4.3; en-us; SM-N900T Build/JSS15J) Appl$
182.101.57.39 - - [29/Jan/2018:08:06:03 -0800] "GET /ogPipe.aspx?name=http://www.epochtimes.com/ HTTP/1.1" 404 3847 "-" "Mozilla/5.0 (Linux; U; Android 4.3; en-us; SM-N900T Build/JSS15J) Apple$
113.128.104.88 - - [29/Jan/2018:08:06:13 -0800] "GET /ogPipe.aspx?name=http://www.epochtimes.com/ HTTP/1.1" 404 3847 "-" "Mozilla/5.0 (Linux; U; Android 4.3; en-us; SM-N900T Build/JSS15J) Appl$
106.114.65.1 - - [29/Jan/2018:08:06:14 -0800] "GET /ogPipe.aspx?name=http://www.wujieliulan.com/ HTTP/1.1" 404 3847 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45$
113.128.104.148 - - [29/Jan/2018:08:06:31 -0800] "GET /ogPipe.aspx?name=http://www.ntdtv.com/ HTTP/1.1" 404 3847 "-" "Mozilla/5.0 (iPhone; CPU iPhone OS 9_1 like Mac OS X) AppleWebKit/601.1.46$
114.221.124.84 - - [29/Jan/2018:08:06:45 -0800] "GET /ogPipe.aspx?name=http://www.ntdtv.com/ HTTP/1.1" 404 3847 "-" "Mozilla/5.0 (iPhone; CPU iPhone OS 9_1 like Mac OS X) AppleWebKit/601.1.46 $
172.104.108.109 - - [29/Jan/2018:08:17:50 -0800] "GET / HTTP/1.1" 302 830 "-" "Mozilla/5.0" (None of these are my IPs, that's why I am putting them out there.)
I used an IP lookup site to see where they are. Does anyone have any advice towards what I should do?
It's a new tls prober from GFW.
The https://example.com/ogPipe.aspx is a tool to bridge some blocked news website in china.(you can see the target websites in log lines)
GFW indeeds to detect/figure out it.
Here's my splunk search result of these 3 days.
remote_ip.png
user_agent.png
The features of the prober.
Source ip is a one-shot address
User-Agent is simulated to Chrome/Safari/Firefox
TLS Protocol is TLSv1.2
Short answer: Ignore them.
Long answer: There are plenty of vulnerabilities in various web servers / application frameworks that hackers want to abuse. Those originating IPs may not be the hackers themselves but victims of some malware / trojan horses remotely controlled by hackers. Those victims were used by hackers to dig if your server is vulnerable for a more promising rewards, e.g. access to your database or passwords. If you are hosting a .net framework application, look closely for any announcement of vulnerability and apply security patches if available. Especially if you have a "ogPipe.aspx" file serving, you should examine every line of code in it to see whether there is security loophole. As shown in your server log, it responded http code 404 meaning that you don't serve ogPipe.aspx, so you are safe. As a prevailing security advice, look closely for any announcement of vulnerability (from your software vendor, e.g. Apache / Microsoft) and apply security patches if available.
I'm running an Apache2 web server
Server version: Apache/2.2.22 (Ubuntu)
Server built: Mar 19 2014 21:11:10
Every once in a while it silently fails to return content yet writes a 200 status code to the log file. For example, here is the regular log entry for a particular file.
50.158.90.90 - - [17/Nov/2014:06:18:16 -0800] "GET /beta/images/supported_browsers_64h.png HTTP/1.1" 200 12028 "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko"
But every once in a while an entry like this shows up.
50.158.90.90 - - [17/Nov/2014:07:30:38 -0800] "GET /beta/images/supported_browsers_64h.png HTTP/1.1" 200 0 "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko"
Nothing shows up in the error log when this happens. Any idea of what is going on?
I have a XAMPP installation on Windows 2008 R2 that I have to support. The facts are these:
The computer has 3 IP addresses (25, 59 and 130, each 192.168.43.)
Apache and IIS need to run side by side (IIS is used for application pools)
The apache is configured to listen only on IP 25
Accessing any of the other IP addresses yields a message from the apache
The following configuration files have been adapted to the IP address listen/bind change (from the default installation):
httpd.conf lists "Listen 192.168.43.25:80"
httpd.conf lists "ServerName 192.168.43.25:80"
extra/httpd-ssl.conf lists "Listen 192.168.43.25:443"
I have no explanation for this behaviour. Whenever I access one of the other IP addresses, I get the following lines in the "access.log":
192.168.43.130 - - [25/Apr/2012:11:41:47 +0200] "GET / HTTP/1.1" 302 - "-" "Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20100101 Firefox/11.0"
192.168.43.130 - - [25/Apr/2012:11:41:47 +0200] "GET /xampp/ HTTP/1.1" 403 1371 "-" "Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20100101 Firefox/11.0"
I'm not sure what to make of this. I'm pretty sure that this is my fault, that I somehow do not get the configuration, yet it seems straight forward correct.
Please help me. Thank you. I'll try to answer any questions in a matter of minutes.
We run a service on JBoss. Sometimes we receive requests that have params completely decoded. Below are the apache access log entries. Look at the redirect_url params in following urls. For such urls to work the params need to be encoded. Urls that we post are encoded. Either somebody is explicitly decoding stuff before it reaches us, some faulty browser plug-in etc or our server is doing something we do not understand.
78.150.249.12 - - [30/Apr/2009:19:44:58 +0000] "HEAD /r/?client_id=2&redirect_url=http://www.amazon.co.uk/gp/search?ie=UTF8&keywords=William+Kentridge&search-alias=stripbooks&tag=inhouse3408608&token=3to08p0nn54916kfc000db5gmf HTTP/1.1" 400 - "-" "User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
78.150.249.12 - - [30/Apr/2009:19:44:58 +0000] "GET /r/?client_id=2&redirect_url=http://www.amazon.co.uk/gp/search?ie=UTF8&keywords=William+Kentridge&search-alias=stripbooks&tag=inhouse3408608&token=3to08p0nn54916kfc000db5gmf HTTP/1.1" 400 965 "-" "User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
The HEAD/GET pattern looks like a web accelerator plugin/proxy of some kind - HEAD-ing a link to see if it exists/is modified and then fetching it. Assuming you don't have some other web server in front of your JBoss, then it's unlikely to be your fault.
Also, I don't think that's actually a real user-agent string (real IE6 UAs on XP generally send their CLR version as well), which would support the theory that it's a broken proxy server.