Monday, April 23, 2012

Awstats Rebuilding files from old logs

SkyHi @ Monday, April 23, 2012

This is using AWStats 6.3 on Windows Server 2003 and IIS 6.0
My log files will not be processed for 2010. The stats are all fine up to 31/12/2009.
The last file in my DirData folder is 'awstats122009.[config].txt' – there is no 'awstats012010.[config].txt' or later.
If I change my LogFile entry in the conf file to LogFile="C:/Inetpub/vhosts/[domain]/statistics/logs/W3SVC[nnnnn]/ex100101.log" and run "perl awstats.pl -config=[domain] -update", the expected awstats012010.[config].txt is not generated and I get:
Update for config "./awstats.[domain].conf"
With data in log file "C:/Inetpub/vhosts/[domain]/statistics/logs/W3SVC[nnnnn]
/ex100101.log"…
Phase 1 : First bypass old records, searching new record…
Direct access to last remembered record has fallen on another record.
So searching new records from beginning of log file…
Jumped lines in file: 0
Parsed lines in file: 35616
 Found 6 dropped records,
 Found 18 corrupted records,
 Found 35592 old records,
 Found 0 new qualified records.
Attempts at subsequent log files result in the same problem; AWStats thinks these are all old records even though the file for that month does not exist. Any pointers to how to resolve this would be greatly appreciated.



Solution:

Temporarily move all files contained in DirData to another directory and try again. This will allow you to generate the AWStats data files for January 2010. When this is done, move the 2009 data files back to DirData.

OR
backup and comment the "highlighted part" /var/lib/awstats/domain.txt


# LastLine    = Date of last record processed - Last record line number in last log - Last record offset in la
st log - Last record signature value
# FirstTime   = Date of first visit for history file
# LastTime    = Date of last visit for history file
# LastUpdate  = Date of last update - Nb of parsed records - Nb of parsed old records - Nb of parsed new records - Nb of parsed corrupted - Nb of parsed dropped
# TotalVisits = Number of visits
# TotalUnique = Number of unique visitors
# MonthHostsKnown   = Number of hosts known
# MonthHostsUnKnown = Number of hosts unknown
BEGIN_GENERAL 8
LastLine 20120101000113 257865 25669630 36390796923
FirstTime 20111201000008
LastTime 20111231235838
LastUpdate 20120101040228 26376 0 26375 0 0
TotalVisits 16978
TotalUnique 7482
MonthHostsKnown 0
MonthHostsUnknown 11032
END_GENERAL




 So you have a bunch of old logs and you want to put it all together into AWStats to put the historical data in.  Firstly you have to remove any existing AWStats monthly data files from the data directory as AWStats won't enter log information from the past.

Then you need to use a script like the one below to feed the logfiles back into AWStats and have it regenerate the monthly data files:
for %i in (D:\sites\www.fridaynightgaming.com\logs\W3SVC2008\*.log) do perl awstats.pl -config=fridaynightgaming -logfile=%i -update
Obviously change out the example logfile path above for your own.  This is the only way I know of how to import historical log data into AWstats.




REFERENCES
http://www.internetofficer.com/forum/awstats-iis-installation-and-configuration/problem-generating-old-files/
http://www.nakedmcse.com/Home/tabid/39/forumid/1/postid/9/scope/posts/Default.aspx



WordPress Vulnerabilities and How to Fix Them

SkyHi @ Monday, April 23, 2012
Did you know that more than 73 million web sites in the world run on the WordPress publishing platform? This makes WordPress more popular than Microsoft SharePoint, Blogger, or Drupal. It also means that WordPress is a large target for hackers.
Half of the WordPress sites out there are self-hosted, which means that the WordPress administrator carries the lion's share of responsibility for a secure installation. Out of the box, there are several ways that WordPress security can be tightened down, but only a fraction of sites actually do so. This makes WordPress an even more popular target for hackers.
The following five strategies can help any WordPress installation become significantly more secure, and raise awareness of the types of vulnerabilities to defend against.

Vulnerability # 1: SQL Injection & URL Hacking.

The problem: WordPress is a database-backed platform that executes server-side scripts in PHP. Both of these characteristic can make WordPress vulnerable to malicious URL insertion attacks. Commands are sent to WordPress via URL parameters, which can be abused by hackers who know how to construct parameters that WordPress may misinterpret or act on without authorization.
SQL injection describes a class of these attacks in which hackers embed commands in a URL that trigger behaviors from the database. (SQL is the command language used by the MySQL database.) These attacks can reveal sensitive information about the database, potentially giving hackers entrance to modifying the actual content of your site. Many of today's web site defacement attacks are accomplished by some form of SQL Injection.
Other versions of URL hacks can trigger unintended PHP commands which, again, can lead to injecting malware or revealing sensitive information.
The defense: Most WordPress installations are hosted on the popular Apache web server. Apache uses a file named.htaccess to define the access rules for your web site. A thorough set of rules can prevent many types of SQL Injection and URL hacks from being interpreted.
The code below represents a strong set of rules that you can insert into your web site's .htaccess file that will strip URL requests of many dangerous attack injections:

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK) [NC]
RewriteRule ^(.*)$ - [F,L]
RewriteCond %{QUERY_STRING} \.\.\/ [NC,OR]
RewriteCond %{QUERY_STRING} boot\.ini [NC,OR]
RewriteCond %{QUERY_STRING} tag\= [NC,OR]
RewriteCond %{QUERY_STRING} ftp\:  [NC,OR]
RewriteCond %{QUERY_STRING} http\:  [NC,OR]
RewriteCond %{QUERY_STRING} https\:  [NC,OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|%3D) [NC,OR]
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(\[|\]|\(|\)|<|>|ê|"|;|\?|\*|=$).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*("|'|<|>|\|{||).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(%24&x).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(%0|%A|%B|%C|%D|%E|%F|127\.0).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(globals|encode|localhost|loopback).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(request|select|insert|union|declare).* [NC]
RewriteCond %{HTTP_COOKIE} !^.*wordpress_logged_in_.*$
RewriteRule ^(.*)$ - [F,L]

Vulnerability # 2: Access to Sensitive Files.

The problem: A typical WordPress install contains a number of files which you don’t want outsiders to access. These files, such as the WordPress configuration file, install script, and even the “readme” file should be kept private.
The defense: As with preventing URL hacking, you can add commands to the Apache .htaccess file to block access to sensitive private files. For a typical WordPress installation, the following code will block access to directory listings, plus a set of specific files related to WordPress and the Web server itself.
Options All -Indexes

Order allow,deny
Deny from all


Order allow,deny
Deny from all


Order allow,deny
Deny from all


Order allow,deny
Deny from all


Order allow,deny
Deny from all


Order allow,deny
Deny from all


Order allow,deny
Deny from all


Order allow,deny
Deny from all

Vulnerability # 3: Default Admin User Account.

The problem: Many default WordPress installs include an administrator user account whose username is simply “admin”. Hackers may try to log into this account using guessed passwords.
The defense: Any element of predictability gives hackers an edge. Although a hacker would still need to guess or brute-force your password to access the admin account, you are even more secure without an “admin” account at all.
Instead, log into WordPress and create a new user with an unpredictable name. Assign administrator privileges to this user. Now delete the account named “admin”. A hacker would now need to guess both the username and password to gain administrator access, a significantly more challenging feat.

Vulnerability # 4: Default Prefix for Database Tables

The problem: The WordPress database consists of numerous tables. In many WordPress installs, these tables are named with a default prefix that begins with “wp_“. For hackers, the ability to predict anything can provide an extra advantage.
The defense: Changing the prefix of your WordPress tables can eliminate this predictability. Some security experts argue that this will not stop a savvy hacker who can use other means to determine the table names in your installation. While this is true when talking about a knowledgeable hacker, many amateur hackers use pre-packaged scripts to perform their dirty work and these are more likely to be successfully blocked by eliminating predictable table names.
When setting up a new WordPress install, you can specify the database table prefix yourself. This gives you the opportunity to choose something unique and unpredictable. If WordPress is already installed, you can retroactively change the table names. Although this can be done manually, the process requires directly manipulating the database in several places.
An easier way to change table prefixes for an existing WordPress installation is by using the plugin named Better WP Security. This plugin contains several defenses including some discussed elsewhere in this article, with a simple point-and-click interface to change your table names to include a randomly-generated prefix.

Vulnerability # 5: Brute-Force Login Attempts

The problem: Hackers often rely on automated scripts to do their dirty work. These scripts can make numerous attempts to log into your WordPress administration page by trying thousands and millions of combinations of usernames and passwords. Not only can being bombed with login attempts slow down your web site for legitimate users, it may also succeed—giving hackers complete control of your site.
The defense: Of course, you should start with always using strong passwords. A longer, mixed-type password will take longer for a brute-force attack to decode. These attacks typically use combinations of dictionary words and numbers. (But remember that malware can render strong passwords useless.)
An even more effective defense is to install a login limiter for WordPress. A login limiter can essentially block or quarantine an IP address or username which tries and fails to send login requests above a threshold rate. For example, a login limit of 10 attempts per 5 minutes can be backed up with a penalty timeout of 1 hour.
A successful brute-force attack against a strong password effectively becomes impossible with these limits in place, because the hacker can never try enough variations (or rather, it would take many years of continuous attempts).
Two WordPress plugins which let you enforce a login limiter are Limit Login Attempts and the aforementioned Better WP Security.
These five strategies are the beginning of effective WordPress security—not the end. Like any form of security, defending WordPress is an ongoing process that must involve awareness of new threats combined with specific details about your own install environment.

REFERENCES