Ever log into a UNIX-like system and need to find what’s happening with Apache or lighttpd? Sure, on a server you’ve set up you can use apache-top or mod_status, but on a server needing attention NOW and one you’ve never logged into what can you do? Well, I wrote a simple one-liner to help.

This is one ugly one-liner. It’s also useful on an unfamiliar server (UNIX-y) to find popular virtual hosts and scripts without knowing too much about the implementation details of Apache or lighttpd for that server. To try it log into a system running Apache or lighttpd with superuser privileges (due to the netstat -ltpn and lsof dependencies) and then Copy/Paste on the command line.

Here’s output on a dev machine with almost no traffic (a busy server is much more interesting):

-------/var/log/apache2/this-access.log------02.Nov.2009:

1	02	03.10 - 03.19	00K
1	02	04.00 - 04.09	00K
1	02	08.40 - 08.49	00K
103	02	11.00 - 11.09	26K
1	02	11.30 - 11.39	00K
1	02	15.40 - 15.49	00K
1	02	16.30 - 16.39	00K
1	02	17.20 - 17.29	00K
-------/var/log/apache2/other_vhosts_access.log------02.Nov.2009:

-------/var/www/sites/other.otr/logs/ins.pect.me-access.log------02.Nov.2009:

The output line shows the number of hits, day of the month, time in 10 min increments and kilobytes of transfer. If an IP had triggered the limits for TOPFILES or TOPIPS there would be a list of those IPs and popular request targets by number of occurrences for the given timeframe.

Recently The Official Google Blog posted an article entitled Managing Your Online Reputation Through Search Results. The bullet points are worth repeating:

• Think twice
• Tackle it at the source
• Proactively publish information

While the second and third points are helpful to remove or hide (read: “bury”) already published information, the first point, if followed, will go a long way to avoiding ever needing the other two.

That is, for the main part, your online reputation is up to you. Think twice before posting or replying online.

But, what should one consider prior to making a comment, uploading a picture, giving a shout-out to a buddy, etc., online? First and foremost always remember this maxim:

The Internet Never Forgets

Indexing engines, content scrapers, RSS/ATOM feed readers, etc., mean that once something is available online it generally remains available even if the original source of the posting is removed. In fact, sometimes removing a questionable posting from the source creates more attention to the item than leaving it alone. Ever seen an Outlook user request a recall on an errant email? The resulting “so@so.com wants to recall” message usually guarantees more people will review the original message itself (few email clients respect this “recall” feature). The same attention is garnered by removing posts or entire threads to forums, etc.

One example in particular is Twitter. Posting to Twitter is easy – so easy a person unable to drive due to substance abuse can still “tweet.” Sure, going back the next day and deleting the post may appear to remove the evidence of a wild night from one’s Twitter page, but simply using the http://search.twitter.com page will reveal the errant posts for anyone who is interested. While deleting posts is still recommended on occasions the sad fact is; “Once Tweeted, Never Deleted.” There are even services that will “recover” deleted tweets from any Twitter user – example: http://tweleted.com/ [rjt: now defunct, see below].

Update: According to TechCrunch as of 10/24/2009 Twitter now removes deleted tweets from the search results as well as a users tweet stream. However, the fact remains that any service that automatically collects tweets and stores them outside of Twitter’s control *may* still be able to reproduce “deleted” tweets. ALWAYS act under the assumption that what you post in a public forum will remain publicly available.

Before posting, keeping the above in mind, there are two other questions you should ask yourself. These two were suggested to me by Rob La Gesse and I’ve come to treasure their simplicity and profundity:

Q: Is it hurtful?

We’ve all seen it – flamewars over operating systems, programming languages  or other religious matters. Debates that spin wildly out of control enhanced by the apparent anonymity of the Internet. But this is only one obvious form of “hurtful.’ Other more serious hurtful examples include:

• violations of SEC disclosure/insider trading regulations,
• corporate trade secrets,
• items under NDA,
• violations of employee privacy (such as compensation, HR issues, health information)

But moreover there are hurtful things that may be less obvious. For example, when a competitor is experiencing a service failure there’s a tendency to say, “Woo hoo! XYZ Co. blew it!” Sometimes co-workers even say something about this to each other, privately. But posted publicly it hurts. First, it creates a negative reaction from third party observers: it’s just flat-out ugly. Like cheering when an opposing team loses a player due to injury: revolting. Second, “Pride comes before a fall”: cheer when XZY Co. suffers failure *only* if you’re positive you’ll never suffer a failure yourself. People will remember the hubris and use it against you when the stars misalign over you.

For a real-world case study showing the harm that can come from gloating over a competitor’s misstep read this blog post by Shel Israel regarding Rackspace, OnlineTech and ServInt. As a bonus it shows what can be gained by correctly maneuvering these two questions for one’s own benefit.

Other examples include mixing personal opinions with official company positions. Now, not many of us think we might do this, but by announcing publicly one is an employee of ABC Company that one takes on added scrutiny of his or her online activities. Have a company twibbon? Your 2 AM tweets about being inebriated are branded with your company. That’s hurtful to more than just you: now your reputation is tied to your company’s as well. Unfair? Sure! But this is an opt-in problem: when in doubt, don’t link personal life and work.

Bottom line: if it’s hurtful, it’s not helpful and should probably not be posted publicly.

Q: Is it helpful?

This question goes to the heart of managing your online reputation. If others find you as a resource of helpful information, whether technical, inspirational, educational, or even entertainment, your reputation online will grow in positive ways. Think in this way: what reputation do I want to have online? Then work towards creating that reputation with your actions.

A great example of one creating a helpful reputation is Major Hayden, AKA RackerHacker. Sure, he, I and others get into silly #YELLING fits at times on Twitter, but generally Major’s reputation is set by the excellent work he does with his blog, RackerHacker.com, and his frequent linking to helpful information via his Twitter account. He manages to be himself (Chinchillas!) yet present information people technically inclined tend to respect. His work on mysqltuner.pl helps to give credence to his helpful persona. It’s who he is and what he does.

So, avoid the call from a lawyer demanding you to remove a public disclosure faux pax by remembering: Is it hurtful? Is it helpful? We’ll all be the better for it.

]]> http://www.rjamestaylor.com/once-tweeted-never-deleted-your-reputation-online/feed/ 1 http://www.rjamestaylor.com/wp-blocking-php-scripts-from-illegitimate-locations/ http://www.rjamestaylor.com/wp-blocking-php-scripts-from-illegitimate-locations/#comments Sun, 13 Sep 2009 18:55:52 +0000 rjamestaylor http://www.rjamestaylor.com/?p=302

Continuing from my last post on using mod_rewrite to block certain actions against a WordPress blog, this brief article decribes how to block PHP script execution from directories where such are not expected to exist.

Note that this is needed only on a platform that does not allow full system level access by the WordPress admin/maintainer. The blog I am dealing with in this example is not mine and I do not have full access to that system. While waiting on the proper system admin on that particular blog, I have made temporary stop-gap changes to block things I don’t like with only .htaccess and mod_rewrite rules. Had I full system admin access I would implement much more elegant protections. Alas, many WordPress blogs are on similar type platforms and this may be useful to stop bad behavior between patches and proper system administration.

Problem: Executable PHP scripts in illegitimate locations

I found a hacker-friendly PHP script in {DOCUMENT_ROOT}/wp-admin/css/{filename}.php. That a file beneath the wp-admin directory can be accessed and executed by anonymous users is baffling to me as a (currently burned out) web application developer, but I’m not trying to second guess the architecture of the WordPress platform itself. In any event, I definitely want to prevent:

• Unauthorized file uploads to sensitive directories
• Execution of scripts in unexpected locations

Since I’m not the system admin of the system this particular blog resides, my ability to limit file uploads is limited. But, using .htaccess and mod_rewrite I can prevent script access and execution in locations I don’t believe there should be such activity.

With this in mind, I set out to stop PHP execution and access of anything other than a CSS (regex: /^.*.css$/) file in the particular directory where the aforementioned hacker-friendly script existed. I will use two techniques to accomplish this:

• Turn off PHP for this directory and any subdirectories
• Disallow access to anything other than a CSS file

I only expect CSS files to be accessed from this directory — and in case someone tries to embed PHP within a CSS file I’m disabling the PHP engine itself from within this directory, thus rendering PHP script as a plain text file (usually a Bad Thing™) and therefore harmless. I added the following .htaccess file to {DOCUMENT_ROOT}/wp-admin/css:


<IfModule mod_php4.c>
php_flag engine off
</IfModule>
<IfModule mod_php5.c>
php_flag engine off
</IfModule>

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
AddDefaultCharset UTF-8

RewriteCond %{REQUEST_FILENAME} !^(.+)\.css$
RewriteRule ^(.*)$ / [R=301,NC,L]
</IfModule>


Once again, please direct comments to this post or to me directly: rjamestaylor {at} gmail {dot} com.

By the way, the hacker-friendly script I found is the same one found using this Google search.

I don’t fully know why, yet, but a cleanly installed WordPress 2.8.4 blog I have familiarity with is still being hacked with a password recovery attack. As a stop-gap until we find the actual vector of compromise I threw together the following Apache mod_rewrite rules to thwart these attacks. The downside of these rules is that now if I forget my password I’ll have to change it via direct database manipulation (which is fine with me).

I added the following snippet to the .htaccess file in my webroot (DOCUMENT_ROOT) before any other mod_rewrite sections. Warning: this is not authoritatively guaranteed to do anything, it’s just done out of frustration while the real vulnerability is identified and fixed (and it could be social engineering, plugin, system or WordPress vulnerability — I really can’t say for sure where the problem lies at this time). Without further disclaimer, here’s the snippet:


# BEGIN Block recover password
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /

RewriteCond %{QUERY_STRING} ^.*action=lostpassword.*$
RewriteCond %{REQUEST_METHOD} =GET
RewriteRule ^(.*)$ /index.php? [R=301,L]

RewriteCond %{REQUEST_URI} ^/wp-login.php.*$
RewriteCond %{REQUEST_METHOD} !=GET
RewriteRule ^(.*)$ http://lmgtfy.com/?q=get+a+clue [R=301,L]

</IfModule>
# END Block recover password


You may notice I do one of two things: if you simply request the “action=lostpassword” function you’re silently redirected to my front page. But if you forcibly POST a request to recover a lost password (say using your own self-made form…it’s damn easy to do so) I insult your intelligence by sending you to Let Me Google That For You for the phrase “get a clue”. I seriously do not recommend taunting attackers, automated or not. If you just want the silent action, use this instead (RECOMMENDED):


# BEGIN Block recover password
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /

RewriteCond %{QUERY_STRING} ^.*action=lostpassword.*$
RewriteRule ^(.*)$ /index.php? [R=301,L]

</IfModule>
# END Block recover password


That should hold me over until I find out what the heck is responsible for allowing turkeys to get admin control of blogs they really aren’t committed to maintaining.

Oh, send criticisms, suggestions, corrections and opinions to rjamestaylor {at} gmail {dot} com.

Ok… If you want to test the POST, use this form (it’s one of those “damn easy” to make forms I was talking about):

Username or E-mail:

Vuln: MySQL MyISAM Table Privileges Secuity Bypass Vulnerability (source: SecurityFocus Vulnerabilities)

In all modern versions of MySQL (that is, beginning early in MySQL 4's development history) the use of the "CREATE TABLE ( ) DATA DIRECTORY … INDEX DIRECTORY …" command can be used to escalate privileges to access and change data created by other MySQL users. MySQL AB has changed MySQL 4 and MySQL 5 behavior to remedy this problem.

However, this is also a case to point out restricting direct RDBMS access to any untrusted system user or application and instead forcing all access to be made through the application layer. That is, of course, as long as one locks down the application layer's access to the RDBMS, too! Besides controlling access for security purposes, managing access at the application layer improves chance of enforcing business rules with the database (without resorting to stored procedures and triggers).

– Robot Terror

While reviewing my logs for recent hits on my blog I came across the following request:

 URL: /mosConfig_absolute_path%3Dhttp%3A/[...]/f1.txt
 Date: Monday, January 28, 2008 - 05:59
 Remote Host: 69.57.148.17

Fortunately I am not using Mambo or Joomla (though the blog-ware I am using has its own troubles) or I would have been infected with malware that would turn my server into an attack platform for DDoS attacks, spam, IRC, phishing scams and a host of illegal content of all kinds.

So, let me ask you: is your server able to survive such an automated attack as this? Is it already serving illegal purposes?

If there is no end to spam and automated attacks against a server and you do not (or cannot) invest in a high-quality firewall, this technique may offer a respite.

The idea is to pro-actively block all “well-known” malicious net-blocks (according to spamhaus.org’s definition, of course). The source for these net-blocks is the Spamhaus DROP list, which is described as:

DROP (Don't Route Or Peer) is an advisory "drop all traffic" list, consisting of stolen 'zombie'
netblocks and netblocks controlled entirely by professional spammers. DROP is a tiny sub-set of
the SBL designed for useby firewalls and routing equipment.

Spamhaus promises:

 The DROP list will NEVER include any IP space "owned" by any legitimate network and reassigned -
 even if reassigned to the "spammers from hell". It will ONLY include IP space totally controlled
 by spammers or 100% spam hosting operations. These are "direct allocations" from ARIN, RIPE,
 APNIC, LACNIC, and others to known spammers, and the troubling run of "hijacked zombie" IP blocks
 that have been snatched away from their original owners (which in most cases are long dead corporations)
 and are now controlled by spammers or netblock thieves who resell the space to spammers.

 When implemented at a network or ISP's 'core routers', DROP will protect all the network's users from
 spamming, scanning, harvesting and dDoS attacks originating on rogue netblocks.

I combine this list with Portsentry (customizing /etc/cron.hourly/portflush and the killroute BASH script) to release and renew these blocks each hour. This is not really necessary, but it’s my way. As an added benefit, however, using Portsentry to block routes will make those routes subject to the portsentry.ignore routes you have configured, which will likely prevent you from blocking yourself or close associates if the DROP list somehow includes your netblock one day!

Here’s the one-liner to grab the DROP list and run it through killroute:

 curl -s http://www.spamhaus.org/drop/drop.lasso |grep ^[1-9]|cut -f 1 -d ' ' | \
 xargs -iX -n 1 killroute  X "source: spamhaus.org/drop"

This can also be run as “xargs -iX -n 1 iptables -A INPUT -s X -i eth0 -j DROP“, instead.

In /etc/cron.hourly/portflush I add the above one-liner before the “exit” statement so that the now-flushed iptables entries are replaced with the (possibly) updated list of net blocks from the DROP list.

A minor edit to portsentry’s killroute (vi `which killroute`) allows a custom “source” comment. Here’s my edited killroute:

 #!/bin/sh

 source /etc/sysconfig/portsentry

 # Make sure we have a target
 if [ "x$1" = "x" ]
 then
        echo "$(basename $0):  Error no target specified."
        exit 1
 #else
        #echo "Arg 1: $1"
 fi

 if [ "y$2" = "y" ]
 then
        PREFIX="portsentry attack alert"
 else
        PREFIX="$2"
        #echo "Arg 2: $2"
 fi

 # Figure out which firewall tool to run... backwards compat blows chunks.
 case "$(basename $IPTOOL)" in
        ipchains)
                ipchains -I $PORTSENTRY_CHAIN -s $1 -j DENY -l
                ;;
        iptables)
                iptables -I $PORTSENTRY_CHAIN -s $1 -j LOG --log-prefix "$PREFIX"
                iptables -I $PORTSENTRY_CHAIN -s $1 -j DROP
        ;;
        *)
                echo "Unrecognized option.... no action taken against $1"
                exit 1
        ;;
 esac

 exit 0

I also use this technique in conjunction with Mitigating brute-force password attacks with pam_abl to help protect against brute-force password attacks. Fun, fun, fun.