The Multi Router Traffic Grapher or just simply MRTG is free software for monitoring the traffic load on network links. It allows the user to see traffic load on a network over time in graphical form. MRTG generates HTML pages containing graphical images which provide a LIVE visual representation of this traffic. How does it work? MRTG uses the Simple Network Management Protocol (SNMP) to send requests with two object identifiers (OIDs) to a device. The device, which must be SNMP-enabled, will have a management information base (MIBs) to lookup the OID’s specified. After collecting the information it will send back the raw data encapsulated in an SNMP protocol. MRTG records this data in a log on the client along with previously recorded data for the device. The software then creates an HTML document from the logs, containing a list of graphs detailing traffic for the selected device.

This is a “How to” for installing MRTG (2.9.17) on a cpanel server. Let’s start:

# Download the software (http://SERVER_IP/mrtg) and move it to your download folder on your server. Or use the RPM installation information further down below.
cd /root/downloads

# Unninstall any older version in case we have an old/broken installation
rpm -e mrtg

# Get the latest rpm. The RPM might not reflect the latest available stand-alone version
wget http://SERVER_IP/mrtg
# Or grab a newer version from here: http://SERVER_IP/mrtg

# Installing the application
rpm -Uvh mrtg-2.9.17-1cpanel.i386.rpm

# Moving libpng
cd /usr/lib
mv libpng.so.2 libpng.so.2.OLD

# Creating the symlink
ln -s libpng.so.3 libpng.so.2

# Edit language at and specify only “en_US”
pico /etc/sysconfig/i18n

# Restarting MRTG
service mrtg restart

# Configure MRTG to allow only your local IP to see the reports at http://SERVER_IP/mrtg – Important: If your local IP changes due to DHCP very often, you should skip this step.
# This can be happening often when being on DSL.

pico /usr/local/apache/conf/httpd.conf

#Search for the line (CTRL+W):
# It should look like this:

Options Indexes FollowSymlinks MultiViews
AllowOverride None
Order allow,deny
Allow from all

#After the last line () paste this and change allowed IPs:

order deny,allow
allow from [ SERVER IP ]
allow from [YOUR LOCAL IP]
deny from all

# Restarting httpd
service httpd restart

# Let’s put MRTG to start with the system
chkconfig –level 0123456 mrtg on

# Important: Add MRTG to the up2date skip-list of your server. If you don’t do this, after the system updates your MRTG installation will be broken.
up2date –configure
# Select the skip-list option
# Add mrtg to the skip-list
“mrtg*”

Thats it….

Criminals often register their own domain name to perform phishing attacks. Unlike the other common phishing site scenarios (including hacked servers, open redirects, and abuse of free webhosting), phishing sites that have their own domain name can be harder to remove, because the website owner and domain owner is the fraudster. Only the hosting and DNS providers and the domain registrar are able to take the site down and also likely to cooperate.

The operation of top-level domains is generally split between a registry, which operates the infrastructure that answers DNS queries, and registrars, which sell domain names and provide the process for owners to maintain their records. Registries generally are not directly involved in removing phishing domains, and refer those to the registrar through which the domain was registered.

However, it is relatively easy to become a registrar, so large numbers of hosting companies, web design firms and domain name resellers are able to handle registrations. Registrars may not all respond quickly to abuse complaints. And in unusual cases registrars themselves may be involved in illegal activity.

There is a particular problem with so-called fast flux phishing attacks. Here the attacker uses a large pool of compromised hosts — often personal computers on DSL connections — and from these randomly chooses a number to act as web servers to host the phish (and also some to act as DNS servers for the phishing domain). The set of hosts used to support the phishing site is changed regularly, so efforts to contact the owner of one hacked system would at best cause the phishing site to be temporarily unavailable. ICANN (which hands out the contracts to operate generic top level domains including .com) published a report earlier this year looking at whether it should intervene to encourage adoption of more effective policies by registrars to prevent the abuse of fast-flux setups; but it seems reluctant to compel registrars to stop a practice that may also have some legitimate uses.

The one common point for any phishing attack is the URL sent to victims. In the case of fast-flux attacks, the owner of the domain will not cooperate and there are too many hacked systems hosting the phish for contacting the hosting provider to be effective. The only place where the attack can be quickly stopped is for the registrar or registry to suspend its domain name.

The policies of the DNS registry for the top-level-domain containing the site are therefore important. The most practical indication of the relative success of these policies is to look and see which top-level-domains (TLDs) are most often used for whole-domain phishing attacks:

The high placement of .tk is unsurprising, given that it is possible to register .tk domains for free that redirect to any URL, completely anonymously. .com is the most common TLD for phishing domains, perhaps due to the ease of registering .com domains, and because the large number of registrars for .com domains gives an opportunity for fraudsters to look for registrars with weak checks or that respond slowly to abuse reports.

Finding an efficient escalation process in the case where the registrar is slow to cooperate will be the key to reducing the number of domains registered for phishing. The system that was designed to deal with domain disputes around ownership and trademarks is now looking too cumbersome when dealing with the problem of phishing attacks, where fast responses are essential to minimising fraud.

go to www.netcraft.com for full article

In the June 2009 survey we received responses from 238,027,855 sites, an increase of 2,137,329 on last month. A reduction in activity at Microsoft Live Spaces was responsible for the large drop in the number of Microsoft-IIS sites detected. Apache retains the dominant market share of 47.12%, approximately 112.2 million sites in total, and saw a modest increase in market share of 0.63 percentage points this month.

Meanwhile, Google has increased its market share by 1.3 percentage points to nearly 12 million sites, due mainly to increased activity on Blogger.

nginx continues to grow strongly, increasing its market share by 1 percentage point. It gains around 2.5 million sites this month, mostly due to more activity seen by the survey on blogging provider NetEase. nginx is also used by Wordpress.com, where Netcraft saw 180,000 more active blogs this month.

Total Sites Across All Domains August 1995 - June 2009

Market Share for Top Servers Across All Domains August 1995 - June 2009

Totals for Active Servers Across All Domains June 2000 - June 2009