Knowing if a "friendly robot" or "malicious" attack 2

[southbeach]

So, I normally just write code but I am concern about what I see in my error.log

[client 146.0.77.100:49621] script '/var/[URL unfurl="true"]www/html/index2.php'[/URL] ...

If I google the IP I get Netherland and some references about it having been reported once or twice for abuse ...

What would be the suggested course of action given that entries like this appear in the error.log and/or access.log? (Running Linux)

Thank you all in advance for your assistance!


--
SouthBeach

http://www.fp2php.com

The good thing about not knowing is the opportunity to learn - Yours truly, 2008.

 

[ChrisHirst]

Given that it is the 'error log' it didn't get anywhere, so don't worry about it. It's a 'bot' looking for a specific file that is generally found on Joomla! 'powered' websites, in your case it was given a 404 response and probably will not be back.

Anything in the server 'error log' are failures to do or access something and rarely need any action on your part, unless the response was a 5xx code, which would indicate a server error or a code issue.

Chris.

Indifference will be the downfall of mankind, but who cares?
Time flies like an arrow, however, fruit flies like a banana.

Never mind this jesus character, stars had to die for me to live.

 

[southbeach]

known issue with Joomla?

I monitor the error.log to see if I have PHP errors, warnings or, like you said, issues with my code.

Thanks!

--
SouthBeach

http://www.fp2php.com

The good thing about not knowing is the opportunity to learn - Yours truly, 2008.

 

[ChrisHirst]

known issue with Joomla?

Not particularly, the bot is just looking for a 'footprint' to flag for further exploit tests. You may find requests for 'wp_[something]' as they are hunting for WordPress footprints.
The place to look for site code errors is not the access logs, but in a file called error_log which is located in the website root folder. That is what PHP writes to when something goes wrong or malformed requests are made, and should contain more useful data about the event than the access logs do.

Chris.

Indifference will be the downfall of mankind, but who cares?
Time flies like an arrow, however, fruit flies like a banana.

Never mind this jesus character, stars had to die for me to live.

 

[southbeach]

never knew about the error_log file ... certainly a must know.

thanks!

--
SouthBeach

http://www.fp2php.com

The good thing about not knowing is the opportunity to learn - Yours truly, 2008.

 

[spamjim]

If this is a malicious sniffing then you need to compare entries in the access log for the same time period. The access log will show what landed closer to the target.

I'm not sure how "index2.php" identifies joomla. A good sniffing bot would likely look for files like "robots.txt", "index2.php", "index.php.old", "index-old.php", etc to see if there's any smoke.

If you run analytics on your site for at least a couple weeks, you can figure out which IPs are legitimate spiders for search engines and which are poking around where they should not. Once you know the good guys, you can craft a mechanism to filter/throttle possible hammering attacks.

 

[ChrisHirst]

I'm not sure how "index2.php" identifies joomla.

Because Joomla! has both 'index.php' AND 'index2.php', and 'index2.php' is used by template 'component' requests to include 'index.php' rather than calling it directly.

Chris.

Indifference will be the downfall of mankind, but who cares?
Time flies like an arrow, however, fruit flies like a banana.

Never mind this jesus character, stars had to die for me to live.

 

[spamjim]

Right, but...

https://www.google.com/#q=index2.php

 

[ChrisHirst]

Your point being?

Certainly there can be many examples of a index2.php being present on web site architecture,... ... but index2.php returning a 200 response is a quick test for a high probability of there being a Joomla! website at the URL/IP that the script-kiddy bot has visited.

Plus if had you happened to look at the source code of the first page of results you would have found that at least FOUR of them ARE running Joomla! as their CMS, including the top result.


Chris.

Indifference will be the downfall of mankind, but who cares?
Time flies like an arrow, however, fruit flies like a banana.

Never mind this jesus character, stars had to die for me to live.

 

[spamjim]

Is "index.php" a general indicator that you're looking at a WordPress site?

I was just suggesting that it may not be useful to narrow focus to Joomla. There are other reasons why a script may be looking for "index2.php". There may be complacency about this particular poking if someone thinks they're safe because they're not using Joomla. On my Google results page, I did not get any Joomla-powered sites when searching for index2.php (0/10). Even in your results, you were only able to see 40% as Joomla.

The problem with this discussion is that we're only looking at a single line in a log. While an occasional error log entry is not a big deal, there should be a concern if there is an identifiable pattern apparent in the log.

 

[ChrisHirst]

Is "index.php" a general indicator that you're looking at a WordPress site?

Now you a just being ridiculous in trying to score 'points'

No, of course not but /wp-config.php/... returning a HTTP: 200 response is.

Please read what I stated;

specific file that is generally found on Joomla! 'powered' websites,

specific file ... generally found, NOT "specific file that is ONLY found on Joomla!

Patently you wouldn't make a good 'script-kiddie'/'cracker', getting a HTTP: 200 status from any particular request means that one is worthwhile taking a closer look at, and if you are working from a list of a million or more website base URLs to check, the initial 'test runs' are going to be generic, so if your target CMS to hack is Joomla!, grabbing any 200 responses from

http://domain.tld/index2.php,

gets a list of possible Joomla! websites. Speed is the 'crackers' first concern, not absolute precision, that comes after the 'chaff' has been winnowed out of the list.



Chris.

Indifference will be the downfall of mankind, but who cares?
Time flies like an arrow, however, fruit flies like a banana.

Never mind this jesus character, stars had to die for me to live.

 

[southbeach]

Now guys, lets play nice!


--
SouthBeach

http://www.fp2php.com

The good thing about not knowing is the opportunity to learn - Yours truly, 2008.

 

[spamjim]

Now you a just being ridiculous in trying to score 'points'

Now you are just being ridiculous in assuming what I'm "trying". Lighten up.

 

[spamjim]

Patently you wouldn't make a good 'script-kiddie'/'cracker', getting a HTTP: 200 status from any particular request means that one is worthwhile taking a closer look at...

I'm not sure you're demonstrating yourself to be an ideal judge with what you've presented. Calm the personal insults... not that I have any ambitions to be a good cracker.

As you've noted in your google search results, your own best case scenario is that 40% of sites with "index2.php" are running Joomla. That is a bizarre token to seek when there are much better indicators, including direct access to particular ini/xml files that not only reveal Joomla but the running version so that the script can apply the right exploit. Whatever speed you think you're enjoying in a scan for "index2.php" is lost when that file makes database calls and other includes. The identifying Joomla ini/xml is a much smaller file to access and does not pull dependencies with it. That call to "index2.php" is the slowest thing you can do. Not even joomscan bothers with "index2.php".

If one is detecting/scanning any index file, it would be the base index.php where the script can identify the meta name="generator" as either Joomla, Drupal, etc.

I was never arguing with you. Yes, "index2.php" has been used by Joomla. I was pointing out that it is shortsighted to assume calls to "index2.php" are a Joomla exploit sniff. What does one do with that assumption, aside from ignoring the other possibilities of attack when sniffing this file?

 

[ChrisHirst]

I was pointing out that it is shortsighted to assume calls to "index2.php" are a Joomla exploit sniff

From the 'cracking' point of view it does not matter if you think it is "short-sighted", it is how expedient it is.

If I wanted to identify Joomla! sites to attack it pays me NOT to try 'hacking' every URL on this million+ site list, because the vast majority of them are NOT going to be Joomla! and therefore a waste of time trying to hack them, so I run a trivial request for a known document name on Joomla and if the response code is not 404 that request is regarded as a positive so is marked for more extensive querying.
This way a million plus list with an success rate of probably much less than ten percent can be thinned out to much smaller list with a potential success rate of ~forty percent in only a few hours.

The Joomla! sites that are identified on the first run have no idea that they ARE about to become a target, and the sites that are not Joomla! just see a failed URL request which they disregard because it has failed for an obvious reason, that being; it does not exist, and for the 'cracker' they have increased their chances of 'real' hit significantly by doing nothing other than code a trivial HTTP: 'HEAD' or 'GET' request in their preferred language and starting it running.

You are thinking like a developer and thinking about what would be the "elegant" solution, malicious 'hackers' are not interested in being 'elegant' they just want to find the most likely candidates in the shortest possible time, and whenever I find a log entry with a UA (User Agent) of 'script' on any of my 'honeypot' sites requesting a URL that I KNOW would not be normally requested by an external UA, it gets blocked at the server firewall for a couple of weeks, because we have clients on the same server using Joomla! [or whatever], that we need to protect where possible.
I see this kind of request hundreds of times a day, mainly from IPs in Eastern Europe, South East Asia, South America, plus IPs from Amazon and Google 'Cloud' services, cheap end VPS providers (Rackspace, Godaddy and Hostgator predominantly).

Every day I 'grep' out a list of possible 'rogue' log entries from server logs and have scripts on my machine that I can feed in a list of IPs and get back a geoiplookup report, a whois report and a hostname report.

I try to think like a 'hacker' because prevention and a little anticipation IS far, far better than curing a compromised server.


Chris.

Indifference will be the downfall of mankind, but who cares?
Time flies like an arrow, however, fruit flies like a banana.

Never mind this jesus character, stars had to die for me to live.