This is a fine one.  Anyone who uses WordPress may need to deal with this.  Unfortunately, despite using reCAPTCHA, Akismet still picks up tons of span on my blog.  So why am I getting spam comments when I have reCAPTCHA? 

I really had no idea, but it turned out reCAPTCHA is marking those that come in as spam and putting them in the Akismet spam folder making it appear that Akismet caught them. I would imagine spammers are not breaking through the CAPTCHA box but have been reading online that either:

1. CAPTCHA’s are potentially breakable by software.
2. Some foreigh workers get payed to do that sort of spam to make CAPTCHA look breakable.

I really don’t know or would like to believe they are unbreakable.  I do know I’m getting spam and I don’t want it.  So off I go seeing how I can deal with this because:

1. I won’t read, buy or visit any link in a message I feel is spam
2. The only thing I’ll do with it is to try to prevent it when I see it.
3. I really don’t want these things hitting my site generating extra bandwidth to begin with.

I’ve decided to deal with this from the database side using phpMyAdmin of my provider (WORD OF CAUTION: If you haven’t done any sort of SQL before, I recommend you take caution, even though we’re not deleting or modifying anything):

SELECT distinct comment_author_IP, count(comment_author_IP) as Occurrance
FROM `wp_comments`
WHERE comment_approved LIKE ‘%spam%’
GROUP BY comment_author_IP
ORDER BY Occurrance DESC
LIMIT 0, 500

So with a rather simple query I tried to mimick the results Akismet reports it on the WordPress Dashboard, I get this list of offending IP’s: 

 
So what does someone do with a list like this.  In my case, as I have no access to the firewall on my host so I’m going to use .htaccess file for this but before I just plug all the IP’s there, I’m going to check on some of the less frequently noted IP’s above with this query and omit the ones that have one occurrance.   This should prevent a couple of things:

1. In case a comment within one of the single occurrances is not really spam.
2. I’ll use a rule of thumb and say everything around five occurrances and that is already marked as spam by Akismet is really Spam.
3. I don’t want to get overly complicated and keep a large .htaccess file.

So I use this query to check on a few of the less often ones just to see if they are spam or not:

SELECT *
FROM wp_comments
WHERE comment_author_IP
IN ( ‘194.8.75.161′,
‘86.122.164.46′,
‘70.70.10.78′,
‘114.127.246.36′,
‘194.8.75.159′,
‘194.8.74.133′,
‘212.95.54.40′)
LIMIT 0 , 500

Going over the list quickly, I see it’s all spam.  So everything with two or more occurrances, get’s a spot in my .htaccess file.  I decide to use this query to automate some of the labour:

SELECT CONCAT("deny from", " ", comment_author_IP) as Action
FROM wp_comments
WHERE comment_approved LIKE ‘%spam%’
GROUP BY comment_author_IP
HAVING COUNT(comment_author_IP) >= 2
LIMIT 0, 500

 .htaccess relevant code

.
.
.
<Limit GET POST>
order deny,allow
# Old Entries
deny from 209.47.94.52
deny from 72.20.4.30
deny from 92.48.193.55
deny from 87.118.104.158

# New Entries
deny from 114.127.246.36
deny from 194.8.74.133
deny from 194.8.74.171
deny from 194.8.75.141
deny from 194.8.75.159
deny from 194.8.75.161
deny from 212.117.176.186
deny from 212.95.54.40
deny from 70.70.10.78
deny from 86.122.164.46
deny from 91.214.44.201
</Limit>
.
.
.

And that is that.  The only thing that’s left now is to save and upload the new .htaccess file to your web root and see if there is any improvement.

The baffling thing for me is user registrations.  I’ll use a combination of LINUX and SQL here.  I’m interested in all the user names I’m getting that have registered but are listed as spam bots.  I also want to know the IP’s of the registrations but really I would prefer a CAPTCHA style code to filter stuff like this.  So the first thing I get is a list of users that have been registered recently:

SELECT user_email, user_registered, user_nicename
FROM wp_users
WHERE user_login NOT LIKE ‘%admin%’
LIMIT 0 , 100

This gives me something like this:

which I then stick it in some file on my UNIX box called:

# cat ureg.txt
fdghjweudyf@konversia-aero.ru   2009-04-20 06:16:04     analia
draimacleroic@gmail.com         2009-04-20 21:16:31     sopssheerce
changfuuu@gmail.com     2009-04-21 02:08:15     anavoinkemi
actichziniunc@gmail.com         2009-04-21 11:32:10     joannahopkin
katyai4857@atlaskit.com         2009-04-21 13:25:08     hewatmom
qapocahemiekid12763@gmail.com   2009-04-23 06:27:04     kesenasikacusa
.
.
.
#

Now that I have this file, I would like to check if these are legitimate users or spammers:

http://www.stopforumspam.com
http://www.botscout.com

I’ll then use that network and the below tiny script to find out which ones are legitimate and which ones I should get rid of:

 #!/bin/bash

# Short code for checking forum spam user registrations:

currdate=$(date +%d_%m_%Y-%H_%M_%S);
tmpfile=ureg.tran.$currdate.dat;
ipfile=ureg.ip.$currdate.dat;

>$tmpfile;
>$ipfile;
for email in $(cat $1|awk ‘{ print $1 }’); do
        lwp-request "http://www.stopforumspam.com/search?q=$email&export=xml" > $tmpfile;
        if [[ $(cat $tmpfile|egrep "no results found.") != "" ]]; then
                printf "%50s%-30s\n" $email " : ";
        else
                printf "%50s%-30s\n" $email ": LISTED";
                for ipv in $(cat $tmpfile|egrep "<ip>"|sed -e "s/[<>]/ /g"|awk ‘{ print $2 }’|sort|uniq); do
                        echo "$ipv" >> $ipfile;
                done
        fi
        sleep 2;
done

echo -ne "UNIQUE IP’S\n";
cat $ipfile|sort|uniq -c;
/bin/rm $tmpfile

This will give something like:

fdghjweudyf@konversia-aero.ru: LISTED
draimacleroic@gmail.com: LISTED
changfuuu@gmail.com: LISTED
actichziniunc@gmail.com: LISTED
katyai4857@atlaskit.com: LISTED
qapocahemiekid12763@gmail.com: LISTED
payomacon@gmail.com :
rackflinciatt@gmail.com: LISTED

The code also generates an IP file called something like ureg.ip.<DATE>.dat.  The unfortunate thing is that the IP’s are all varied with only a few with the same subnets so it made it impractical to block these with .htaccess files.  So it turned out it simply wasn’t worth blocking them though the method did tell me which ones are valid and which ones are not.  This was the main thing I wanted.  The effort simply outweighed the benefit.

Least but not last, I’ll add a plugin here called: WP-reCAPTCHA to help handle these when they come in so I don’t have to repeat this procedure too often. 

Good Luck!

PROBLEM

Another day brings another bug. This time it’s with the Akonadi server failing or unable to start.  This error followed a recent update I’ve done on my Fedora box.  This is what greeted me each time I started up KDE:

The QtSQL driver ‘QMYSQL’ is required by your current Akonadi server configuration.
The following drivers are installed: QSQLITE, QMYSQL3, QMYSQL.
Make sure the required driver is installed.

Personally, I don’t like uninvited guests, especially the ones that crash the party.  So off I went to see what broke.  The error gave some clues where I should look which included MySQL, akonadi and QtSQL.  Here’s how I went about resolving this one.

SOLUTION

The solution to this one was fairly straightforward.  it followed these steps:

1. Open command console such as konsole
2. Check if you have the config file, run: ls -al /root/.config/akonadi/mysql-local.conf
3. Run echo "user=root" > /root/.config/akonadi/mysql-local.conf
4. Either type kcmshell4 kcm_akonadi on the command line to start Akonadi configuration panel or follow steps 4 & 5 below.
5. Go to KDE Start -> System Settings
6. Under System Settings dialog click the  Advanced tab then Akonadi configuration.
7. Click the Akonadi Server Configuration tab then the Restart button.
    

THE PROCESS

Getting to the solution was another matter alltogether.  The first order of business was to check the akonadi server logs to narrow down the problem:

/root/.local/share/akonadi/akonadiserver.error

Database process existed unexpectedly during intial connection!
executable: "/usr/libexec/mysqld"
arguments: ("–defaults-file=/root/.local/share/akonadi//mysql.conf", "–datadir=/root/.local/share/akonadi/db_data/", "–socket=/root/.local/share/akonadi/db_misc/mysql.socket")
stdout: ""
stderr: "090322 23:25:47 [Warning] option ‘max_join_size’: unsigned value 18446744073709551615 adjusted to 4294967295
090322 23:25:47 [Warning] option ‘max_join_size’: unsigned value 18446744073709551615 adjusted to 4294967295
090322 23:25:47 [ERROR] Fatal error: Please read "Security" section of the manual to find out how to run mysqld as root!

090322 23:25:47 [ERROR] Aborting

090322 23:25:47 [Note] /usr/libexec/mysqld: Shutdown complete

"
exit code: 1
process error: "Unknown error"
"[
0: akonadiserver(_Z10kBacktracev+0x35) [0x8051f75]
1: akonadiserver [0x8052456]
2: [0xc62400]
3: [0xc62416]
4: /lib/libc.so.6(gsignal+0×50) [0x1dd460]
5: /lib/libc.so.6(abort+0×188) [0x1dee28]
6: /usr/lib/libQtCore.so.4(_Z17qt_message_output9QtMsgTypePKc+0×95) [0x5886855]
7: akonadiserver(_ZN15FileDebugStream9writeDataEPKcx+0xc4) [0x8053164]
8: /usr/lib/libQtCore.so.4(_ZN9QIODevice5writeEPKcx+0×9e) [0x59143ce]
9: /usr/lib/libQtCore.so.4 [0x592139e]
10: /usr/lib/libQtCore.so.4(_ZN11QTextStreamD1Ev+0×68) [0x5921698]
11: akonadiserver(_ZN6QDebugD1Ev+0×44) [0x804d674]
12: /usr/lib/libakonadiprivate.so.1(_ZN7Akonadi13AkonadiServer20startDatabaseProcessEv+0×1a8e) [0x3f9e9e]
13: /usr/lib/libakonadiprivate.so.1(_ZN7Akonadi13AkonadiServerC1EP7QObject+0×72) [0x3fbc02]
14: /usr/lib/libakonadiprivate.so.1(_ZN7Akonadi13AkonadiServer8instanceEv+0×56) [0x3fcd06]
15: akonadiserver(main+0×398) [0x804c9e8]
16: /lib/libc.so.6(__libc_start_main+0xe5) [0x1c86e5]
17: akonadiserver [0x804c581]
 

So that error narrowed down the problem alot.  We now know Akonadi wants to run as the root user.  Or at least is trying to run as root in an unsupported manner.  First I checked with MySQL to see what they say about this even though it’s an Akonadi related problem.  Here’s what MySQL has to say about all of this:

http://dev.mysql.com/doc/refman/5.0/en/changing-mysql-user.html

Further down the page we see that to run MySQL as root we need to set:

user=user_name

in /etc/my.cnf which for us would amount to user=root in /etc/my.cnf.  The problem with this is that also according to the above MySQL page, you should never run the MySQL server as root.  It’s also fairly common knowledge that MySQL runs as the mysql user on Fedora Linux installations at least .  So let’s see what the Akonadi folks say about this I visit http://pim.kde.org/.  Then choose the Akonadi link when I get there.  Sadly nothing searchable could be dug up.  Let’s try plan B.  Configuration files for applications ran from a user account, typically exist within the users home directory.  So in this case let’s check your ID (Assuming root here).  So we run this command:

# cd ~;find ./ -name *akonadi*
./.kde/share/config/akonadiconsolerc
./.local/share/akonadi
./.local/share/akonadi/db_data/akonadi
./.local/share/akonadi/akonadiserver.error.old
./.local/share/akonadi/akonadiserver.socket
./.config/akonadi
./.config/akonadi/akonadiconnectionrc
./.config/akonadi/akonadiserverrc
#

So looks like we have some Akonadi stuff inside our user account.  Great.  Since Akonadi is giving MySQL errors it should be related.  Let’s dig deeper to see what we can find inside above folders:

# cd ~/.config/akonadi/
# find ./ -iname *mysql*
./mysql-local.conf
# cd ~/.local/share/akonadi/
# find ./ -iname *mysql*
./mysql.conf
#

So looks like Akonadi has it’s own mysql configuration files, which is good, and perhaps for it’s own purposes it needs to run as root for a local instance of mysql (What other reason is there for another MySQL config file).  That would be safer.  But which one of the above do I put user=root under.  Checking my system, it was empty of any sort of documentation for Akonadi.  So I try the RPM:

# rpm -aq|grep akonadi
akonadi-1.1.1-1.fc10.i386
# rpm -lq akonadi-1.1.1-1.fc10.i386
.
.
/etc/akonadi/mysql-global.conf
.
.

But all we get is another mysql config file, which isn’t helpful.  We need to know which one we need to set user=root in. 

# vi /root/.local/share/akonadi/mysql.conf
# cat /root/.local/share/akonadi/mysql.conf|head
#
# Global Akonadi MySQL server settings,
# These settings can be adjusted using $HOME/.config/akonadi/mysql-local.conf
#
# Based on advice by Kris Köhntopp <kris@mysql.com>
#
[mysqld]
skip_grant_tables
skip_networking

#

Which gives us the answer (green above) which we were looking for.  Doing the above but for /etc/akonadi/mysql-global.conf instead says the same thing (files are copies of each other).  Hence the SOLUTION above. 

Cheers and Good Luck!

PROBLEM

On Linux, you receive this error when trying to open up links from inside Thunderbird emails:

Error showing url: Failed to execute child process "/usr/lib/firefox-3.0.5/firefox" (No such file or directory)

SOLUTION

The solution to this was fairly simple.  Just create the link to firefox binary in the folder it was looking in for firefox

1. cd /usr/lib/firefox-3.0.5
   
2. which firefox
   /usr/bin/firefox
   
3. ln -s /usr/bin/firefox firefox
4. ll
   total 236
   4669475 lrwxrwxrwx   1 root root     16 2009-03-17 22:41 firefox -> /usr/bin/firefox*
   4669742 drwxr-xr-x   3 root root   4096 2008-12-27 20:02 updates/
   4669550 drwxr-xr-x   3 root root   4096 2009-03-17 22:41 ./
   4456449 drwxr-xr-x 291 root root 225280 2009-02-27 04:07 ../
5. #

This resolved the issue in Thunderbird and links could be launched from within emails.
 

PROBLEM

Just today an issue came up for me installing the google toolbar.  (This Google toolbar has been in Beta for a while now, which caught my attention and may or should catch yours: Beta releases are buggy.  That may be beside the point though since I don’t care as long as it does it’s job well since some company’s betas are better then other companies official releases.  :)    )

I got this cryptic error:

Firefox could not install the file at

http://dl.google.com/firefox/google-toolbar-beta-linux.xpi

because: Signing could not be verified
-260

Below are a number of possible solutions for this issue.  If one doesn’t work, give another a try:
 

SOLUTION 1

A required certificate or all of your certificates have the "This certificate can identify software makers." option disabled / unchecked.  Here’s how to go about determening which one you need to check off.

DETERMINE THE CERTIFICATE

First you need to determine which certificate your .xpi file uses.  In this case we will look at the google-toolbar-beta-linux.xpi file:

1. Make a temporary folder such as /tmp/workingonit
2. Get the extension:
   $ wget http://dl.google.com/firefox/google-toolbar-beta-linux.xpi
3. Check that it’s there:
   ll google-toolbar-beta-linux.xpi
   932082 -rw-r–r– 1 root root 1280456 Jan 28 19:00 google-toolbar-beta-linux.xpi
4. Extensions are zip files.  So we unzip them:
   $ unzip google-toolbar-beta-linux.xpi
5. Find the file with the certificates (Something named .rsa should be it.):
   $ find ./ -name *.rsa
   ./META-INF/zigbert.rsa
   $
6. Use strings command to print printable characters in file (Take note, what we highlighted below in orange will make sense a bit later on):
   $ /usr/bin/strings META-INF/zigbert.rsa|egrep -i "sign|cert"
   VeriSign, Inc.1
   VeriSign Trust Network1;09
   2Terms of use at https://www.verisign.com/rpa (c)041.0,
   %VeriSign Class 3 Code Signing 2004 CA0
   ,Digital ID Class 3 - Netscape Object Signing1
   /http://CSC3-2004-crl.verisign.com/CSC3-2004.crl0D
   https://www.verisign.com/rpa0
   http://ocsp.verisign.com0?
   3http://CSC3-2004-aia.verisign.com/CSC3-2004-aia.cer0
   VeriSign, Inc.1705
   .Class 3 Public Primary Certification Authority0
   VeriSign, Inc.1
   VeriSign Trust Network1;09
   2Terms of use at https://www.verisign.com/rpa (c)041.0,
   %VeriSign Class 3 Code Signing 2004 CA0
   https://www.verisign.com/rpa01
    http://crl.verisign.com/pca3.crl0
   VeriSign, Inc.1705
   .Class 3 Public Primary Certification Authority
   VeriSign, Inc.1
   VeriSign Trust Network1;09
   2Terms of use at https://www.verisign.com/rpa (c)041.0,
   %VeriSign Class 3 Code Signing 2004 CA
   $
7. Above tells us that the xpi file is signed with VeriSign and gives a few other details on it.  Now you have your info.  On to the second half of instructions.

ENABLE THE VERFICATION ON CERTIFICATE

1. Start Firefox (if it isn’t already).  This assumes FireFox version 3+ so menu item names below may differ for other FireFox versions but you should be able to browse to something that has a list of certificates (See image below).
2. Go to Edit -> Preferences.  New panel appears.
3. On the new panel, click Advanced category followed by the Encryption tab then View Certificates button.
4. Browse down to VeriSign certificates.  You may see something similar to the below:
   
5. Notice in the above image the highlighted certificate "Verisign Class 3 Public Primary Certification Authority" I’ve chosen.  It matches exactly what we got highlighted in orange earlier in step 6 from first part above.
6. Click Edit on the highlighted.  You should be presented with three choices:
   This certificate can identify web sites.
   This certificate can identify mail users.
   This certificate can identify software makers.
7. Check off "This certificate can identify software makers."
8. Click Ok to save then Ok on other open panels or Save as the case may be and restart FireFox. 
9. Try to download your extension again.  The error should be gone.
10. You’re done!
     

SOLUTION 2

Another possibility is to try to disable OCSP (Online Certificate Status Protocol).  Here’s how to go about this:

• Select Edit -> Preferences (Config panel should appear)
• Click Advanced (Tab / Option )
• Click Encryption sub Tab.
• Click Validation button.
• Uncheck "Use the Online Certificate Status Protocol (OCSP) to confirm the current validity of certificates"

Download your file.  All should be well.

Repeat above to reenable OCSP again for other plugins, themes, etc.

Now if I could only remember what I wanted this crazy toolbar for anyway. 

Hope you Enjoy!  Cheers!

Hashes are a certainly very important part of any language.  If you’re not used to hashes, you may not see their potential at first.  However, having used them in several languages now, hashes always ended up reducing my code significantly especially when only complex solutions would only do otherwise.  However, bash or ksh for that matter, don’t really come with such a construct.  Reading up on how to do such a thing really didn’t provide any elegant solutions that I wanted for most scenarios.  What I really wanted is something that had these features:

• I needed to define my hashes easily similar to the pearl construct %hash= { "key" => "value", "key1" => "value2" }
• I needed easy key / value retrieval without excessive code and something with minimal implementation that’s easy to use in looping and conditional constructs.
• Finally, some flexibility so I can have the freedom to define various kind of hashes depending on my needs.
• Avoid (NOT) using arrays (define -a array1), conditionals (if, case ) and loops (for, while, do)

Well what I did is using a combination of strings and the unix sed utility to accomplish all of the above in the below script (hashv retrieves values from keys.  hashk retrieves keys from values):

#!/bin/bash

mhash="Jan:01 Feb:02 Mar:03 Apr:04 May:05 Jun:06 Jul:07 Aug:08 Sep:09 Oct:10 Nov:11 Dec:12";

function hashv {
        hkey="";
        mh="";
        if [[ $2 != "" ]]; then hkey=$2; else echo ""; return 0; fi
        if [[ $1 != "" ]]; then mh=$1; else echo ""; return 0; fi

        echo $mh|sed -e "s/.*\([ \t]*\)\($hkey\):\([^ \t]*\?\)\([ \t]*\).*/\3/gi"
}

function hashk {
        hvalue="";
        mh="";
        if [[ $2 != "" ]]; then hvalue=$2; else echo ""; return 0; fi
        if [[ $1 != "" ]]; then mh=$1; else echo ""; return 0; fi

        echo $mh|grep "$hvalue"|sed -e "s/\([^ \t]*\)[:]\($hvalue\)/\|\1|\2\|/i" -e "s/.*\?[|]\(.*\)[|].*[|].*\?/\1/i";
}

echo "____________________________________";
hashv "$mhash" "Dec";
hashk "$mhash" "12";
echo "____________________________________";
hashv "$mhash" "";
hashk "" "12";
echo "____________________________________";
hashv "$mhash" "Oct";
hashk "$mhash" "10";
echo "____________________________________";
hashv "$mhash" "Jan";
hashk "$mhash" "01";
echo "____________________________________";

Saving to a file hash.bash, the above gives the output:

# ./hash.bash
____________________________________
12
Dec
____________________________________

____________________________________
10
Oct
____________________________________
01
Jan
____________________________________

which is what I was looking for.  It turns out that the above code is more flexible in it’s implementation then I really had hoped for.  If spaces and colon (:) isn’t really satisfactory as a delimeter, I can easily change it to something else I know I won’t be using.  The string definition makes defining hashes easy, even more so then the perl counterpart I was used to (though, yes, probably not as powerfull)  Which brings up another interesting point, I also have the ability to change the behaviour of this type of hash definition something I don’t get in other languages.

Hope you found this useful!  Enjoy and don’t hesitate to write below!

INTRODUCTION

Most people today know or have some idea what a firewall is.  For those not too familiar with it, it’s essentially a piece of software or hardware that sits between your computer and the internet (outside world) helping to prevent unauthorized access to your computer / workstation.  The firewall does this by blocking certain ports on your workstation that applications normally use to communicate with over networks. It does this to hide vulnerable applications from being exposed to potentially malicious break in attempts.  The firewall’s granularity typically reaches and is limited to filtering the type of protocols allowed on as little as a single IP, the direction (IN / OUT = TO / FROM your computer) of the traffic and as broad as blocking entire sets of IP’s (For example 50.N.N.N - 150.N.N.N).  This is really the broad range of what a typical firewall can do.

What it does not do is filter based on the type of traffic on a single IP and a single protocol going in either direction.  What we mean is that it doesn’t look at the type of traffic going in and out to decide if the intent is good or bad.  The internet which uses port 80 is the prime example here.  We know very well that when we browse, viruses, spyware and malware can get into our systems.  Firewalls are typically not designed to tell the difference here. For example a request such as this:

 http://<your IP>/’c:\; format c:’

cannot be distinguished by your operating system and firewall to be different from

http://<your IP>/

Simply put, to your computer, firewall or not, the two requests on port 80 (World Wide Web / http) are identical in terms of safety.

This is where mod_security comes in. In this case it scans all traffic on port 80 coming in and out of your PC, matches this to a bunch of rules we can write and based on the written rules, decides to either deny, warn or allow the traffic.  So for example, if we know a certain break in attempt and gathered data on it, we can write a rule to block it in on port 80.  We can then distinguish between the two above examples to deny the first one (it has format c: in it) and allow the second.

SETUP

Mod security has progressed significantly in the past few years and is fairly easy to install and configure.  In fact, as we will see it comes out of the box with some written rules to catch most of the common intrusion types on the internet on port 80 (httpd / www ).  This makes for fairly easy setup and configuration.

BASIC INSTALLATION

1. yum search mod_security  (or yum search modsecurity)
   (Should yield mod_security.i386 as one of the results: mod_security.i386 : Security module for the Apache HTTP Server) 
2. yum install mod_security
   (This installed package mod_security-2.5.6-1.fc10.i386)
3. rpm -ql mod_security-2.5.6-1.fc10.i386
   /etc/httpd/conf.d/mod_security.conf
   /etc/httpd/modsecurity.d
   /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf
   /etc/httpd/modsecurity.d/modsecurity_crs_20_protocol_violations.conf
   /etc/httpd/modsecurity.d/modsecurity_crs_21_protocol_anomalies.conf
   /etc/httpd/modsecurity.d/modsecurity_crs_23_request_limits.conf
   /etc/httpd/modsecurity.d/modsecurity_crs_30_http_policy.conf
   /etc/httpd/modsecurity.d/modsecurity_crs_35_bad_robots.conf
   /etc/httpd/modsecurity.d/modsecurity_crs_40_generic_attacks.conf
   /etc/httpd/modsecurity.d/modsecurity_crs_45_trojans.conf
   /etc/httpd/modsecurity.d/modsecurity_crs_50_outbound.conf
   /etc/httpd/modsecurity.d/modsecurity_localrules.conf
   /etc/httpd/modsecurity.d/optional_rules
   /etc/httpd/modsecurity.d/optional_rules/modsecurity_crs_20_protocol_violations.conf
   /etc/httpd/modsecurity.d/optional_rules/modsecurity_crs_21_protocol_anomalies.conf
   /etc/httpd/modsecurity.d/optional_rules/modsecurity_crs_40_generic_attacks.conf
   /etc/httpd/modsecurity.d/optional_rules/modsecurity_crs_42_comment_spam.conf
   /etc/httpd/modsecurity.d/optional_rules/modsecurity_crs_42_tight_security.conf
   /etc/httpd/modsecurity.d/optional_rules/modsecurity_crs_55_marketing.conf
   /usr/lib/httpd/modules/mod_security2.so
   /usr/share/doc/mod_security-2.5.6
   /usr/share/doc/mod_security-2.5.6/CHANGES
   /usr/share/doc/mod_security-2.5.6/LICENSE
   /usr/share/doc/mod_security-2.5.6/README.TXT
   .
   .
   (Highlighted items are most important: the Apache HTTPD .so module, .conf config files and the main mod_security.conf )
4. rpm –verify mod_security-2.5.6-1.fc10.i386
   (Does various verifications such as MD5, Modification time of files etc verification from the RPM since the RPM was installed: No news (results) is good news in this case)
5. rpm -q –whatprovides /usr/lib/httpd/modules/mod_security2.so
   mod_security-2.5.6-1.fc10.i386 (Verify where mod_security2.so came from, in case old copies resided.)
6. cat /etc/httpd/conf/httpd.conf|grep "Include conf.d"
   Include conf.d/*.conf
   ( This ensures that mod_security.conf will be loaded automatically.  mod_security.conf will then load mod_security2.so.
7. OPTIONAL: Follow Linux: Enable extended httpd status reports in Apache if you have not already.  Test with service httpd fullstatus (If there is no error and you get detailed printouts, you are fine.)
8. Run apachectl configtest to check the config file for syntax errors or simply run service httpd restart.
9. Test the configuration for some basic intrusion attempts.  Type
   http://localhost/update.php?entries=2837%27;DELETE%20FROM%20t_entries–
   in a browser.  It simulates an SQL injection.
10. Check the log file with 
    # tail -f /var/log/httpd/error_log
    [Tue Jan 13 01:11:16 2009] [error] [client 127.0.0.1] ModSecurity: Warning. Pattern match "(?:\\b(?:(?:s(?:elect\\b(?:.{1,100}?\\b(?:(?:length|count|top)\\b.{1,100}?\\bfrom|from\\b.{1,100}?\\bwhere)|.*?\\b(?:d(?:ump\\b.*\\bfrom|ata_type)|(?:to_(?:numbe|cha)|inst)r))|p_(?:(?:addextendedpro|sqlexe)c|(?:oacreat|prepar)e|execute(?:sql)?|makewebtask)|ql_(? …" at ARGS:user. [file "/etc/httpd/modsecurity.d/modsecurity_crs_40_generic_attacks.conf"] [line "66"] [id "950001"] [msg "SQL Injection Attack"] [data "delete from"] [severity "CRITICAL"] [tag "WEB_ATTACK/SQL_INJECTION"] [hostname "localhost"] [uri "/login.php"] [unique_id "SWwwhMCoAAQAACz4CDwAAAAA"]

    The result in error_log tells you the attempt was caught but only a Warning was issued.

11. You’re done!   (w/ basic configuration)
     

Now follow the link below and let’s add example rules for some real-life situations found at Security: Round cube webmail scans spreading on the web: roundcube, msgimport, nonexistenshit and webmail.

Cheers!

Apache HTTPD is the most popular web server to date.  It’s extensible and configurable to meet various needs both small and big.  Here we’ll focus on extending it’s reporting functionality by enabling full status capability to see more granularity in status reports.  As you probably know, the service on Red Hat Linux systems can be controlled with the service command like this:

• service httpd restart
  
• service httpd stop
  
• service httpd start
  
• service httpd status (tells if the process is running and reports the PID of the process: nothing else useful is reported)

The configuration httpd parameter above actually refers to a script and can be viewed by editing the file /etc/init.d/httpd using vi, pico, nano or other CLI editors to look up other parameters httpd can be given (ie stop, start, restart, status etc as above).  One of the commands of interest is fullstatus which does not yet come configured out of the box.  Here are the steps to enable it:

• cat /etc/httpd/conf/httpd.conf|egrep "Location.*\-status"
  # <Location /server-status>
  (Checks if fullstatus has not already been enabled.  A pound (#) before Location above indicates it is disabled)
• service httpd fullstatus (or apachectl fullstatus )
  Forbidden

  You don’t have permission to access /server-status on this server.
  .
  .
  (If error is thrown, as above fullstatus has not been enabled)

• rpm -aq|grep elinks
  elinks-0.12-0.6.pre2.fc10.i386
  (Checks if elinks is installed.  Do this before installing elinks.)
• yum install elinks
  (IF elinks is NOT installed)
• rpm -aq|grep elinks
  elinks-0.12-0.6.pre2.fc10.i386
  (To verify installation worked)
• vi /etc/httpd/conf/httpd.conf
  (Or use pico or nano if you are not comfortable with vi.)
• Find and uncomment the line ExtendedStatus On (Remove # from start of line)
• Find and uncomment the following directives.  Change configuration

  From

  #<Location /server-status>
  #   SetHandler server-status
  #    Order deny,allow
  #    Deny from all
  #    Allow from example.com
  #</Location>

  To
  
  <Location /server-status>
      SetHandler server-status
      Order deny,allow
      Deny from all
      Allow from localhost 127.0.0.1
  </Location>

• Save the configuration file and exit (In vi type :wq )
• service httpd restart
  (Restart the httpd service)
• service httpd fullstatus (or apachectl fullstatus)
  

The last command should print output similar to the below:

                       Apache Server Status for localhost

   Server Version: Apache/2.2.10 (Unix) DAV/2 PHP/5.2.6 Apache/2.2.0 (Fedora)
   mod_perl/2.0.4 Perl/v5.10.0

   Server Built: Oct 21 2008 07:51:36

   --------------------------------------------------------------------------

   Current Time: Wednesday, 14-Jan-2009 01:15:24 EST

   Restart Time: Tuesday, 13-Jan-2009 09:57:34 EST

   Parent Server Generation: 0

   Server uptime: 15 hours 17 minutes 50 seconds

   Total accesses: 13 - Total Traffic: 14 kB

   CPU Usage: u.71 s.09 cu0 cs0 - .00145% CPU load

   .000236 requests/sec - 0 B/second - 1102 B/request

   1 requests currently being processed, 7 idle workers

 ______W_........................................................
 ................................................................
 ................................................................
 ................................................................

   Scoreboard Key:
   "_" Waiting for Connection, "S" Starting up, "R" Reading Request,
   "W" Sending Reply, "K" Keepalive (read), "D" DNS Lookup,
   "C" Closing connection, "L" Logging, "G" Gracefully finishing,
   "I" Idle cleanup of worker, "." Open slot with no current process

Srv PID   Acc  M CPU   SS   Req Conn Child Slot    Client       VHost           Request
0-0 2465 0/2/2 _ 0.43 26995 74  0.0  0.00  0.00 24.102.58.189 127.0.0.1 GET /nonexistenshit
                                                                        HTTP/1.1
1-0 2468 0/2/2 _ 0.00 26995 1   0.0  0.01  0.01 24.102.58.189 127.0.0.1 GET /mail/bin/msgimport
                                                                        HTTP/1.1
2-0 2471 0/2/2 _ 0.00 26994 1   0.0  0.00  0.00 24.102.58.189 127.0.0.1 GET /bin/msgimport
                                                                        HTTP/1.1
3-0 2474 0/2/2 _ 0.37 26994 1   0.0  0.00  0.00 24.102.58.189 127.0.0.1 GET /rc/bin/msgimport
                                                                        HTTP/1.1
                                                                        GET
4-0 2476 0/2/2 _ 0.00 26994 1   0.0  0.00  0.00 24.102.58.189 127.0.0.1 /roundcube/bin/msgimport
                                                                        HTTP/1.1
                                                                        GET
5-0 2478 0/2/2 _ 0.00 26993 1   0.0  0.00  0.00 24.102.58.189 127.0.0.1 /webmail/bin/msgimport
                                                                        HTTP/1.1
6-0 2480 0/1/1 W 0.00 0     0   0.0  0.00  0.00 127.0.0.1     127.0.0.1 GET /server-status
                                                                        HTTP/1.1

   --------------------------------------------------------------------------

    Srv  Child Server number - generation
    PID  OS process ID
    Acc  Number of accesses this connection / this child / this slot
     M   Mode of operation
    CPU  CPU usage, number of seconds
    SS   Seconds since beginning of most recent request
    Req  Milliseconds required to process most recent request
   Conn  Kilobytes transferred this connection
   Child Megabytes transferred this child
   Slot  Total megabytes transferred this slot

   --------------------------------------------------------------------------

    Apache/2.2.0 (Fedora) Server at localhost Port 80

In the above case it caught the popular nonexistenshit scan attempt discussed earlier in Security: Round cube webmail scans spreading on the web: roundcube, msgimport, nonexistenshit and webmail

Cheers!

It’s still a surprise to most just how much scanning and probing by either hackers or malicious software is going on on the web when they do find out.  I mean, do you really know how many times your workstation or home network get’s hit by attempted intrusions and invasions?  I was never able to find this sort thing out or to see it until I ran Linux.  This, imho, makes the Linux OS a bit more open to reporting such things, which is one of the things I like about it. 

Just recently looking over my logs I see there is a large 0-Day scan hitting boxes around the web with regards to the roundcube webmail application. The scan has been spreading over the web and has now been hitting my box since yesterday.  Initially I responded with an ad-hoc solution to this and I’ve blocked some IP’s namely the ones below:

 92.48.127.158 - - [08/Jan/2009:04:52:44 -0500] "GET /nonexistenshit HTTP/1.1" 301 326 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5"
92.48.127.158 - - [08/Jan/2009:04:52:45 -0500] "GET /mail/bin/msgimport HTTP/1.1" 301 330 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5"
92.48.127.158 - - [08/Jan/2009:04:52:45 -0500] "GET /bin/msgimport HTTP/1.1" 301 325 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5"
92.48.127.158 - - [08/Jan/2009:04:52:45 -0500] "GET /rc/bin/msgimport HTTP/1.1" 301 328 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5"
92.48.127.158 - - [08/Jan/2009:04:52:45 -0500] "GET /roundcube/bin/msgimport HTTP/1.1" 301 335 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5"
92.48.127.158 - - [08/Jan/2009:04:52:46 -0500] "GET /webmail/bin/msgimport HTTP/1.1" 301 333 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5"
61.19.252.4 - - [08/Jan/2009:05:08:59 -0500] "GET /nonexistenshit HTTP/1.1" 301 326 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5"
61.19.252.4 - - [08/Jan/2009:05:09:00 -0500] "GET /mail/bin/msgimport HTTP/1.1" 301 330 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5"
61.19.252.4 - - [08/Jan/2009:05:09:01 -0500] "GET /bin/msgimport HTTP/1.1" 301 325 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5"
61.19.252.4 - - [08/Jan/2009:05:09:01 -0500] "GET /rc/bin/msgimport HTTP/1.1" 301 328 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5"
61.19.252.4 - - [08/Jan/2009:05:09:02 -0500] "GET /roundcube/bin/msgimport HTTP/1.1" 301 335 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5"

But this is just one small set of them.  In addition to the above, earlier I’ve been noticing these as well:

209.163.188.49 - - [06/Jan/2009:17:19:00 -0500] "GET /user/soapCaller.bs HTTP/1.1" 301 330 "-" "Morfeus Fucking Scanner"
82.215.135.141 - - [27/Dec/2008:20:16:26 -0500] "GET /user/soapCaller.bs HTTP/1.1" 404 295 "-" "Morfeus Fucking Scanner"
78.109.23.224 - - [02/Jan/2009:06:24:46 -0500] "GET /user/soapCaller.bs HTTP/1.1" 301 330 "-" "Morfeus Fucking Scanner"

And these:

61.119.173.150 - - [30/Jan/2009:13:36:51 -0500] "GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 311 "-" "-"
195.250.148.253 - - [30/Jan/2009:14:11:34 -0500] "GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 311 "-" "-"
87.59.40.54 - - [30/Jan/2009:21:42:40 -0500] "GET http://proxytest.pr.funpic.de/ HTTP/1.0" 400 313 "-" "-"

and they just kept coming!  Some of the IP’s can be blocked with these lines in iptables however these appear to come from infected systems themselves (ie victims):

$ iptables -A INPUT -s 195.184.65.90 -i eth0 -p tcp -m multiport –dports 80,25,110 -j REJECT –reject-with icmp-host-unreachable

Above iptables command line blocks the IP simulates an unavailble host, basically making your PC invisible to the IP you’ve blocked.  This can keep your box from getting scanned or attacked further from this IP, which is probably what you want.  However, unless you have the application the scans are probing or hackers are trying to exploit, likely you may not be vulnerable.  In the event your box is not mission critical, it may be worth stopping HTTPD on stand alone workstations just to be safe.  But run and hide isn’t an option for all.  If you have the Apache HTTPD application or any other web server like IIS, try to apply paches or upgrade your version to the latest available from the owner of the app. 

One less noticable side effect of the above scans is that the foreign server is also exposing those IP’s on the web actively running httpd, which could make victims prone for other attacks.  Not good!

OVERVIEW

The first basic way to keep your workstation secure is to have a good firewall.  Here’s our how to on The Linux Firewall Configuration.  I took it upon myself then to secure my own Apache HTTPD installation with ModSecurity.  Turns out this was fairly easy and came out of the box, nearly fully configured.  This is an absolutely great module that anyone can install and I highly recommend it.  It’s really like a firewall for your web applications and probably one of it’s kind.  Below code will assume usage of the module.  More on this further down.

Following the above ModSecurity installation, I automated above with this little script that blocks IP’s for a duration of time then unblocks after a certain amount of time has expired (one day or seven days, depending on severity and frequency), as in cases such as above (You can tweak the variables for your own tastes) Here are the features of the script:

• Monitors the HTTPD log file from cron, ModSecurity and other traffic on port 80 / httpd.
• Works from within HTTP ModSecurity using the
• Starts a server.
• Allows client connections to the server from non previlidged accounts.
• Actively monitors, blocks and unblocks (After a period of time) offending IP’s that match various criteria.
• Keeps track of when IP’s were blocked and unblocks them according attack frequency from a single IP.
• Logs messages to various log files including messages, access_log with regards to what the script is doing.
• A script remotely intelligent to be able to function as a server / client, be able to detect it’s surroundings sufficiently and take different actions depending on it’s running environment.
   

The script blocks the trouble IP’s from scanning your system further and blocks the IP’s of the attacking host for a length of time.  Of course as with any script, you will need to customize for your own tastes and needs and usage is at your own risk, as mentioned. 

To figure out where a hack came from, who has done it, etc, is a vast topic that I’ll leave for another time.  I’m not particularly eager to setup a honey pot server or figure out who done it and start some sort of investigation.  Just interested in keeping these things from consistently hitting my workstation.

Currently, the attacks have been coming from the following locations, so it may be worth your time to check the scans from your location:

24.102.58.189
131.162.130.185
131.162.130.187
131.162.130.189
131.162.130.191
131.162.169.77
148.244.120.4
155.100.137.112
173.45.68.130
193.138.172.14
195.184.65.90
195.245.119.150
195.3.206.45
201.116.17.162
203.211.130.68
203.81.48.126
208.111.34.21
209.160.20.34
209.163.188.49
209.92.24.221
210.245.123.177
211.136.184.138
212.68.34.107
212.95.37.126
213.251.174.41
216.245.195.90
217.147.30.185
220.233.179.199
24.102.58.189
24.213.90.168
58.215.88.10
61.19.252.4
66.154.97.57
66.36.243.132
66.79.162.235
67.159.44.179
67.202.54.191
67.205.76.148
67.207.74.76
67.210.225.242
67.210.235.154
67.215.231.250
67.228.238.194
69.162.117.108
69.60.117.215
72.20.4.254
72.233.93.144
78.110.173.247
80.18.145.59
85.112.3.165
86.34.134.162
87.233.139.98
87.233.176.117
87.98.132.141
87.98.222.87
87.98.228.69
89.108.124.239
89.149.244.134
89.163.145.92
91.196.169.226
92.48.127.158
94.76.206.2
 

The script will continue to detect new intrusion attempts and block them as they happen.  Previously blocked IP’s will be unblocked after one day (86400 seconds) or seven days (604800 seconds).  Script will reblock any previously blocked IP’s if the same scan is again detected from an IP.  So it’s a self-maintaining script, which, if no further attempts are detected, will unblock all the IP’s it blocked.

As briefly mentioned earlier, in this case, the ideal solution would be to use mod_security which we will be briefly discussed here.  Naturally the Apache mod_security is a preferred way because it would be handling these at the time when they happen.  Before we look into adding rules for mod_security have a look at Apache: Configuring mod_security (modsecurity) for Apache on Fedora. for configuring the basic ModSecurity setup on your workstation prior to any custom ModSecurity configuration.

Below is a script to handle the above issues.

INSTALLATION

Reveiw then copy the script source found at the link below (as a .tar.gz file or .sh file, whichever) into some file such as /root/bin/imr.sh, set permissions and follow configuration instructions below:

 INSTALLATION ( crontab )

WARNING: This will block all non local IP’s so you should take note before adding it to crontab.  If you need to customize which sorts of IP’s you need to exclude/include, at this time you may need to modify the script to do so though I do plan to add the feature at some point in time.  

Here’s how to add the script to run every 5 minutes within cron:

$ crontab -e
$ Add line "*/5 * * * * nice -n 10 /root/bin/imr.sh" to the configuration to run every 5 minutes.

The script will now scan your apache log files for any remote activity generated and take action.  Again, this isn’t the best sort of option unless you want to block all non-local incoming IP’s but is fine if you are doing some testing / development and don’t want to have your box overly exposed on port 80 (HTTP). 

INSTALLATION ( ModSecurity )

This is the preferred means of handling such issues.  The problem IP is blocked when the incident happens and even prevents intrusion.  This script, as mentioned, supports a basic client/server model through nc.  In so doing, it can be used in ModSecurity to issue directives between HTTPD ModSecurity and the server which can then take action on an IP.  Here are the steps to set this up:

• As before, ensure you copied above script into a folder somewhere accessible by root and now also by Apache HTTP such as /usr/bin/shared/imr.sh.
• Run the script.  It should create a work folder under /tmp/ called imr.sh.  The folder may contain several files:
  imr.sh.log              # Script log messages, if script could not write to standard log files.
  imrArchive.txt        # List of all IP’s encountered since script was initially ran.
  imrIPSet.txt            # List of currently blocked IP’s coupled with the time when they were blocked.
• Run /usr/bin/shared/imr.sh –server start to start the server:
  # /usr/bin/shared/imr.sh –server start
  #
• Run /usr/bin/shared/imr.sh –server status to check that the server is running.
  # /usr/bin/shared/imr.sh –server status
  Tue Feb 3 13:56:42 EST 2009 Status of service on port 11235 is:
  Tue Feb 3 13:56:42 EST 2009 ONLINE and listening
  #
• To stop the server at a later date, issue /usr/bin/shared/imr.sh –server start
• Add the text in green below to the corresponding ModSecurity rule and file below:
  /etc/httpd/modsecurity.d/modsecurity_crs_21_protocol_anomalies.conf
  .
  .
  # Check that the host header is not an IP address
  #
  SecRule REQUEST_HEADERS:Host "^[\d\.]+$" "phase:2,t:none,deny,log,auditlog,status:400,exec:/usr/bin/shared/imr.sh,msg:’Host header is a numeric IP address’, severity:’2′,id:’960017′,tag:’PROTOCOL_VIOLATION/IP_HOST’"
  .
  .
• Optionally create your own rule inside this file or within your own file (Click links on below mind map mockup for an explanation of what they do in the rule):
  # cat /etc/httpd/modsecurity.d/modsecurity_localrules.conf
  # Drop your local rules in here.

  SecRule  REQUEST_URI_RAW "(/mail/bin/msgimport|/nonexistenshit|/bin/msgimport|/rc/bin/msgimport|/webmail/bin/msgimport|w00tw00t.at.ISC.SANS.DFind|proxytest.pr.funpic.de)" " phase:2,t:none,t:lowercase,t:normalisePath,deny,log,status:404,exec:/usr/bin/shared/imr.sh,msg:’RoundCube Webmail scan from %{REMOTE_ADDR}.  Blocked.  More on RoundCube Webmail found at http://roundcube.net.  See site for possible further news on this.’,id:99999"
  #

• Add the below lines to have the server started at each boot up time:
  # vi /etc/rc.d/rc.local
  .
  .
  .
  /usr/bin/shared/imr.sh –server start
  /usr/bin/shared/imr.sh –server status
  
• You’re done!

WORKING SAMPLE

Here is a few samples of how the script will work.  Recently, this attack occurred from 210.245.123.177 and here is what the script did:

# cat /var/log/httpd/access_log|grep 210.245.123.177
210.245.123.177 - - [29/Jan/2009:14:19:04 -0500] "GET /nonexistenshit HTTP/1.1" 400 304 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5"
#

The subseuent lines following the text /nonexistenshit no longer appear as we saw them above, which is a good sign.  Corresponding to the above, you should see a line similar to:

Thu Jan 29 14:19:05 EST 2009 imr.sh : (Blocking the IP) : Blocking IP:|210.245.123.177|

To test the rules, you can issue http://localhost/nonexistenshit and see if the rules, and script pick up the test intrusion:

Tue Feb 3 14:44:29 EST 2009 imr.sh: Invoked from ModSecurity. The following IP (127.0.0.1), if not local type, will be blocked.
Tue Feb 3 14:44:29 EST 2009 NOTE: Either the IP to block is local, or you are within modsecurity where iptables is inaccessible. No actions performed

CONCLUSION

I suppose there may be some sort of means available now to do this with another app however looking for some sort of functionality in the zoo of software packages available today seamed more daunting to me then simply writing one.  Best of all this gives me some sort of integrated option for keeping my workstation secure without having to cost me much of my time.  Just like doing things manually with a GUI firewall, I prefer to script this sort of stuff to decide on a best sort of action to take under certain conditions, keep my box secure and free my time for other stuff.

Hope you enjoy.  Don’t forget to leave a comment.

HF! Cheers!

PROBLEM

One of the first things that went wrong after upgrading to Fedora 10 was the UI screen was unreadable / undescernable.  The screen was entirely messed up and though the keyboard worked fine, it wasn’t easy to discern the UI windows from the shades of red, yellow, blue, green etc grany dots that showed up.  In my case, I’ve solved this by lowering the video resolution in the below manner.  I have the ATI Radeo 9600 card.

SOLUTION

Here is how to change the video resolution on your system.

1. At the UI login screen hit CTRL-ALT-F2 to switch to a ready terminal login screen.
2. cd /etc/X11/
3. vi xorg.conf
4. I had the Modes item below like this with highest resolution listed as 1280×1024:
   Modes    "1280×1024" "1280×960" "1152×864" "1024×768" "832×624" "800×600" "720×400" "640×480"
5. Change above to the below to lower the maximum resolution allowed:
                   Modes    "1152×864" "1024×768" "832×624" "800×600" "720×400" "640×480"
   #               Modes    "1280×1024" "1280×960" "1152×864" "1024×768" "832×624" "800×600" "720×400" "640×480"
6. Type :wq <enter> to save the file.
7. Type $ init 1 at the console to go to single user mode. 
8. Once in single user mode (verify using runlevel) type $ init 5.
9. Your screen should now be fixed for you.

There after you could try to use these Graphics and Video: Changing the graphics/video resolution with xrandr instructions here to test the various resolutions Fedora 10+ can now handle once you are in the UI.

PROBLEM

In Fedora 10, the root login was disabled into the GUI, giving you a unable to authenticate user message.  You may have noticed that you got a warning about this in Fedora 9 but it wasn’t yet disabled then.  Not so in Fedora 10 so this might be something you would want to do prior to rebooting after upgrading to Fedora 10.  I’m not all too surprised this eventually happened.  It’s not uncommon to hear of this whereever you happen to ask.  So essentially the pot finally boiled over and we have no root login.  This effects Gnome, KDE and the whole lot.

Essentially the problem relies in the GDM file.

SOLUTION

Anyway, here is how to enable or reenable it should you run into the same problem.

1. At the UI login screen hit CTRL-ALT-F2 to switch to a ready terminal login screen.
2. Login as the root user ID.
3. cd /etc/pam.d/
4. cp -aR gdm gdm.old
5. vi /etc/pam.d/gdm
6. Comment out the line like this (add item in green):
   # auth       required    pam_succeed_if.so user != root quiet
7. Type :wq to write the file out and quit.
8. Type CTRL-ALT-F7 to return to the login session.
9. Try to login as root again.

Of course there could be other issues.  Possibly you may need to reset your password and if you are trying to edit the /etc/pam.d/gdm file from within the UI as an unprevilidged user, then you’ll also need to su - or sudo as root.  If the above doesn’t work, you’ll need to restart the system and login using the root account in single user mode.