After implementing the firewall rules, I reconnected the network cable to the system.

Since accessing http://virustotal.com redirects one to http://www.virustotal.com, I wasn't able to access the VirusTotal website until I added the IP address 74.125.34.4 to the list of destination IP addresses the infected system was allowed to access through the firewall. Even though I could then access the site's webapge and select a file to upload, I was unable to actually upload a file that I wanted to check for malware.

So I then added the IP address for the Jotti's malware scan website to the permitted outbound access list for the infected system. I was able to access it with a web browser on the system and upload a suspect file to have it scanned by the 22 antivirus programs the site currently uses to scan uploaded files.

[/security/scans] permanent link

[Sat Mar 22 15:23:58 2014] [error] [client 171.216.29.98] PHP Notice: Undefined index: HTTP_USER_AGENT in /home/jdoe/public_html/index.php on line 39
[Sat Mar 22 15:23:58 2014] [error] [client 171.216.29.98] PHP Notice: Undefined index: HTTP_USER_AGENT in /home/jdoe/public_html/index.php on line 46
[Sat Mar 22 15:23:58 2014] [error] [client 171.216.29.98] attempt to invoke directory as script: /home/jdoe/public_html/blog/

The error was occurring because of PHP code in the file that checks the value for HTTP_USER_AGENT.

I found that the IP address, which is allocated to a system in China, is listed at the Stop Forum Spam site as being associated with someone trying to post spam into forums today - see 171.216.29.98. And when I checked Apache's CustomLog to check the user agent for the browser the user or software program running at the site might be using to identify itself, I found that the log entries indicated that it wasn't providing user agent information, which browsers and web crawlers normally provide. The log also showed that other than that one file at the site's document root, the user or program accessing the site only queried a directory that has "forums" as part of the path. I have blog entries posted on forum software, so that may have prompted the visit to the site from that IP address, if the person or program is looking for sites where he or it can post forum spam.

I checked the "reputation" of the IP address at other sites that provide information on whether an IP address has been noted to be associated with malicous activity and found the following:

1. Site: WatchGuard Reputation Authority
   Rating: Bad
   Reputation Score: 95/100
   Comment: The score indicates the overall ReputationAuthority reputation score, including the name and location of the ISP (Internet Service Provier), for the specified address. A score of 0-50 indicates a good to neutral reputation. 51-100 indicates that threats have been detected recently from the address and the reputation has been degraded.
2. Site: Barracuda Reputation
   Reputation: Poor
   Comment:
   
3. Site: McAfee Trusted Source
   Reputation: Unrated
   Comment:
4. Site: Check Your IP Reputation - Miracare of Mirapoint
   Reputation: High Risk
   Comment: This IP address is used for sending Spam on a regular basis
5. Site: BrightCloud Security Services URL/IP Lookup
   Reputation: High Risk
   Comment: Location - Chengdu, China. Spam Sources found. Webroot IP Reputation is listed as "High Risk", but lower down on the page the status assigned to the address is "Moderate Risk".

To stop any futher access to the server from that IP address, from the root account, I used the route command to reject access by the IP address.

# route add 171.216.29.9 reject

Note: the command is valid on a Linux system, but though the route command is available on a Microsoft Windows system, that operating system doesn't support the "reject" parameter.

The blocked route can be seen by issuing the route command with no parameters.

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
171.216.29.9    -               255.255.255.255 !H    0      -        0 -

If I ever want to permit access to the server from that IP address again, I could use route del 171.216.29.9 to permit access from that address.

References:

1. Stopping an Attacker with the Route Reject Command
   MoonPoint Support
   Date: April 15, 2007

[/security/scans] permanent link

[ More Info ]

[/network/web/crawlers] permanent link