Date: Wed, 23 May 2007 17:48:38 0100 (BST)
From: Kiss Death <kiss_death31@yahoo.co.in>
Subject: BE WARNED
To: kiss_death31@yahoo.co.in

Sorry Marie,

I am very Very sorry for you, is a pity that this is how your life is going to end is a pity but I will like to give you some chance to help your self RIP.

As you can see there is no need of introducing my self to you because I don't have any business with you, My work as I am talking to you now is just to kill you and a have to just do that as I have already been paid for that. Some one that I will not like to tell you the name came to me and told me that he want you and the whole of your family dead and he provide us with your name, Address and Phone Number and with my network I sent my boys to track you down and they have done that but I told them not to kill you that I will like to contact you and see if your life is Important to you so

Icalled the him back (I mean my client) and ask him of you email which I didn't tell him what I want to do with it and he gave it to me and I am using it to contact you. As I am writing to you now my men are monitoring you and there telling me every thing about you.

So I will like to know if you Like to live or die as some one has paid for you to die.

I am given you just two days to get back to me or I will just make a call and tell my boys to wipe you and your family out.

GOOD LUCK AS I AWAIT YOUR REPLY.

Grammar and familiarities
I'll pass on the obvious grammar mistakes (he did bother to run it through a spell checker of some sort at least!) and move on straight the to familiarities...

I must say I hate when somebody call me by my family name just like that, without any mister or whatever. I'm not a football star, nor a famous actor, so I don't deserve this treatment. Besides, it reminds me too much of the army style. I believe it would be very interesting to run that scam through an expert psychologist that would tell us what sentence or words the naive public would react to in order to reply. Looks like a new sort of "Nigerian Scam".

Obvious scam
Apparently the email comes from India if you believe at the usual From: kiss_death31@yahoo.co.in header. However it would be deceiving, since the email has actually been sent from West Africa (Nigeria ?):

Received: from [208.70.7.28]
   by web94304.mail.in2.yahoo.com
   via HTTP; Wed, 23 May 2007 17:48:38 BST


# host 208.70.7.28
host28.fobsky7.juch-tech.com

# whois 208.70.7.28
Juch-Tech Inc JUCHTECH (NET-208-70-0-0-1)
                        208.70.0.0 - 208.70.7.255
F.O.B. SKY Inc. JTI-FOBSKY-6 (NET-208-70-6-0-1)
                        208.70.6.0 - 208.70.7.255

# links http://www.fobsky.com/aboutus.htm
[...] We offer two way internet over satellite [...]
in West Africa [...]

So it doesn't start so well for him. Why would an Indian guy want to kill me, especially if he's in Africa (when I'm in the opposite part of the globe) ? (by the way, for those of you who don't know where is Nigeria it is located in West Africa...)

Then of course, the email strategy stinks of rat scam. The killer tells you he has been paid loads of money to kill you and all your family. He contacts you to tell you so. Hoping that you will propose him to pay him more to leave you and your family in peace. Obviously, if you are crazy/scared enough to reply him this, he will definitely tell you how much he supposedly was paid and ask you to increase that sum substantially to drop the case.

Conclusion
An obvious scam, so do not even bother to reply. Enough said.

find is extremely useful to get a nice file tree that you can grep later from your Linux box (unless again you installed grep on Windows).

The Script
So when you don't have find and still need a basic find output eventually, you could use this script. It turns an output that looks like this:

 Volume in drive C has no label.
 Volume Serial Number is B0B8-957C

 Directory of C:\WINDOWS

12/19/2006 09:36 PM <DIR>        .
12/19/2006 09:36 PM <DIR>        ..
12/21/2006 03:44 PM            0 0.log
03/21/2006 11:01 AM <DIR>        addins
08/23/2001 08:00 PM        1,272 Blue Lace 16.bmp
08/23/2001 08:00 PM       82,944 clock.avi
08/23/2001 08:00 PM       17,062 Coffee Bean.bmp
12/19/2006 06:49 PM       43,027 comsetup.log
03/21/2006 11:01 AM <DIR>        Config
03/21/2006 11:01 AM <DIR>        Connection Wizard
03/21/2006 04:02 AM            0 control.ini
03/21/2006 03:55 AM <DIR>        Cursors
10/11/2006 05:43 PM <DIR>        Debug
...

Into an output that looks like this:

C:/WINDOWS
C:/WINDOWS/0.log
C:/WINDOWS/Blue Lace 16.bmp
C:/WINDOWS/clock.avi
C:/WINDOWS/Coffee Bean.bmp
C:/WINDOWS/control.ini
C:/WINDOWS/comsetup.log
C:/WINDOWS/addins
C:/WINDOWS/Config
C:/WINDOWS/Connection Wizard
C:/WINDOWS/Cursors
C:/WINDOWS/Debug
...

The script makes it easy to grep for particular files like .exe or .log or any other pattern that you may be looking for.

Native GNU tools on Windows
The better alternative of course is to install some vital GNU tools onto your Windows system.

Karl M. Syring has ported essential GNU tools to native Windows on his http://unxutils.sourceforge.net/ project.

Here are some ports of common GNU utilities to native Win32. In this context, native means the executables do only depend on the Microsoft C-runtime (msvcrt.dll) and not an emulation layer like that provided by Cygwin tools.

The tools included (at the time of this writing) are:

bc	bison	bzip2	diffutils
fileutils	findutils	flex	gawk
grep	gsar110	gzip	indent
jwhois	less	m4	make
patch	recode	rman	sed
shellutils	tar	textutils	unrar
wget	which

Emulated GNU tools on Windows
A team of enthusiasts originally from Cygnus (now part of RedHat) have created an emulation layer that allows to re-compile and run most GNU or standard Linux tools on Windows. You can download this environment called cygwin (in pre-compiled binary, or in source form).

Cygwin is a Linux-like environment for Windows. It consists of two parts:

• A DLL (cygwin1.dll) which acts as a Linux API emulation layer providing substantial Linux API functionality.
• A collection of tools which provide Linux look and feel.

The Cygwin DLL works with all non-beta, non "release candidate", ix86 32 bit versions of Windows since Windows 95, with the exception of Windows CE.

Cygwin contains an amazing number of GNU or Linux tools that come very handy on Windows, including mamoths like XWindow, XEmacs, openssh or ddd

Conclusion
In order of robustness & speed you should use:

• the native version of find
• or the cygwin version of find
• or the script converting output from Windows' DIR /S into find format

If you should ever be forced by a robber to withdraw money from an ATM machine, you can notify the police by entering your PIN number in reverse. For example if your pin number is 1234 then you would put in 4321. The ATM recognizes that your pin number is backwards from the ATM card you placed in the machine.

The machine will still give you the money you requested, but unknown to the robber, the police will be immediately dispatched to help you.

This information was recently broadcasted on TV and it states that it is seldom used because people don't know it exists.

Why is it nonsense?

1. What happens if your pin is the same in straight order as in reverse order? (i.e.: 9229, 3113, etc...)
2. Tell me (without thinking more than a second) you PIN number in reverse... can you? You probably would have to think longer...
3. How would the bank call the police? And who would be responsible if people would start abusing this "service" in case the bank calls automatically?
4. Even if the police gets automatically notified, by the time they do actually reach the ATM, the robber will be long gone with your cash... (and maybe your life)

The old saying "Your money or your life!" has always been ill-worded. It should have been "Your money or your life AND your money!"

What could work?
On the other hand we could think of better protections from ATM money snatching. I'm not really serious with these recommendations, but it would be fun if it existed:

• The out of money solution
  The bank could put in place a discreet button or a buttons-combination that when pressed would instruct the ATM to refuse dispensing money, appearing to have ran out of money. The thief would genuinely believe that this particular ATM ran out of money (that's Murphy's Law after all), and would walk away (with or without your ATM card, and with or without having taken your life!).
  
  Of course for this to work, the bank would need to enable this function only to people who already successfully entered their PIN, otherwise non-customers would definitely abuse this to cause DoS. Of course this does not prevent the thief to steal your money, it's just that he wouldn't be able to steal it right here right now, he me still steal your ATM card, and kill you after you reveal him your code...
   
  
• The 5^th Element Solution
  [ You should really watch The 5^th Element if you haven't seen it yet. ] Anyway at some point in the movie, a bad guy attempts to pass as somebody else at an airline check-in counter and gets detected. Straight away a cage falls on him and prevent him from leaving, electronic aimed machine guns point at him to deter him from trying to break the cage, and a loud alarm start ringing.
  
  Now that would be a great way to prevent a bunch of ATM attacks like ATM money snatching, ATM tampering, ATM forcing and more! Having said that it's a bit extreme... ;-)
   
  
• The Run! Forest, run! solution
  Of course the best solution is to run as fast as you can. There's nothing better than a big guy with a big blade pointed towards you to motivate you to break the 100 meters sprint world record...

What happens on NETs enabled machines?

NETS was founded as a result of a need for a centralised e-Payment operator by Singapore's local banks: DBS, Keppel Bank, OCBC, OUB, POSB, Tat Lee Bank and UOB, in 1985.

NETs enabled machines are machines that accept payment via the NETs network. All local banks ATM cards support NETs, which make these NETs enabled machine very convenient to use.

You can use NETs in government building when paying for various fees, in super markets and almost every shop in Singapore (notorious exceptions are food stalls and pubs or cafes). You can use NETs to pay your bills on SAM machines, or AXS machines. You can also top-up your public transport fare card using NETs. Now you can use NETs to pay for your cab fares too. NETs is basically everywhere and extremely convenient.

Problem with ATM cards
Most ATM cards are just a dumb storage media. On the magnetic strip of the card is encoded such information as your bank ID and your bank account number among others. Information encoded on your ATM card is not encrypted, and therefore anybody with a magnetic card reader can swipe your card in, in order to copy it.

There is a little problem with reading ATM cards using off-the-shelf magnetic card reader. The driver of the magnetic card reader will validate the content of the card against the checksum to protect against read errors. ATM cards usually have an invalid checksum on purpose. So reading them with regular magnetic card readers will fail. In order to succeed, you have to have a lower-lever card reader, or a 'dumb card reader' that does not validate checksums.

Of course the card alone is not enough to perform a fraud. An attacker would also need the corresponding PIN. Recent ATM frauds are based on stealing the card information and the PIN at the same time. Some fraudsters have put a mini magnetic card reader just before the real ATM's card reader: when the victim slides-in his card into the ATM, the fraudster's reader reads the card, then when the card goes deeper the ATM card reader can read the card. It is completely transparent to the victim. The fraudster before hand has put a pin-hole camera in the corner of the ATM booth so he can record the victim's PIN while he types it.

Mitigating Factor
The biggest mitigating factor is the fact that every ATM has a CCTV camera attached to it, so that anybody approaching the ATM will be seen and could potentially be identified after a successful attack. Banks put in place specially shaped card reader enclosures to make it easier for a phony card reader to be spotted by a user.

Convenience vs. Security
While AXS stations seem to have a digital camera, apparently it is only used to take digital pictures, which is used for application like ePostcards. It does not appear to be CCTV like, in the sense that it does not appear that it films every users while they approach or use the machine.

SAM machines do not have cameras either. Almost all POS in Singapore do not have a CCTV camera or have a CCTV camera that cannot see if the cashier swipes the NETs card in the rightful reader or if he swipes it in a recording card reader device first. If such an employee (cashier, taxi driver, etc..) decides to become rogue and steal ATM card information it would be absolutely trivial, and the user would not notice, since he would not be the one sliding the card himself. Before the user realizes his card was misused, it would be too late, and he would have no idea which merchant is to blame.

Possible Solution
A possible solution would be to have a hardware token, very much like the ones recently launched for Internet Banking by Singapore banks.

A user could use the same hardware token on ATMs. Before asking for the PIN, the ATM or POS would check if the card supports NETs. If it does, it would request for the hardware token displayed number instead of asking for the PIN. These hardware token displayed numbers are time dependent and cannot be re-used. A fraudster could still copy the card and film the user entering the number, it would become useless:

• The number cannot be reused
• The number would not be supported on foreign ATMs since it is not the usual PIN

If the card is a foreign card that does not support NETs and instead supports VISA, PLUS, or any other usual payment network, then the ATM would ask for the usual PIN and the protection would not apply.

A user of a Singaporean bank ATM card overseas would still have to enter his PIN. But at least using his card in Singapore, the user would face no risk (and neither would the bank or the merchant).

Conclusion
Although this solution would prove to be very effective (the only way to defeat it is to steal/copy the card and the token, as opposed to just steal/copy the card and watch the PIN), it would end-up being costly for the bank:

• Each ATM customer would require on hardware token (could be shared for his various cards: credit card, ATM card, Internet Banking)
• Bank would have to have an extensive support program in place to teach users how to use the token during the first few months of the transition

SpamCop is a service for reporting spam. SpamCop determines the origin of unwanted email and reports it to the relevant Internet service providers. By reporting spam, you have a positive impact on the problem. Reporting unsolicited email also helps feed spam filtering systems, including, but not limited to, the SpamCop blacklist used in SpamAssassin as a DNSBL.

Unfortunately, this is an ongoing battle. Spammers adapt quickly and persistently. Report spam and help SpamCop turn the tide. SpamCop makes this otherwise slow and technical task quick and easy.

The SpamCop reporting service is free.

The easiest way to use SpamCop is to sign up with them. The best is to support them is through donations or to sign up for their services

Sending Your Spam to SpamCop
Once you have your account set up, I recommend that you forward your complete spam message using attachments, to your personal spam reporting email address instead of going through the pain of submitting them via the web based form. Mine looks like this (scrubbed): submit.hXfjblahblablahB@spam.spamcop.net.

Note: make sure you forward to your personal spam reporting address only genuine spam!

I use the excellent Thunderbird with the Okopipi plugin.

Okopipi plugin for thunderbird reports spam to SpamCop, to the FTC, FDA, SEC, ACMA and/or Knujon.com. It also allows you to put in your own custom addresses to report spam to such as your ISP or corporate abuse address.

This will properly forward any message in your current folder marked as junk to the places you configure in your preferences. All you will have to do is hit send.

After you have installed Okopipi, configure it to forward spam to your personal SpamCop reporting address. Customize your top -window thunderbird toolbar: right click on toolbar ->  Customize. Add the Okopipi Report button to your toolbar.

All you have to do now when you receive email, is to carefully mark as Junk spam messages and to mark as Not Junk these emails that were incorrectly marked as junk by Thunderbird. Then hit the Okopipi Report button, and click send. SpamCop will receive all your spam, ready to report them for you.

Getting SpamCop to Report the Spam Messages for you
A this point, you may have a few dozens email messages in your SpamCop queue. The main problem right now is that SpamCop requires you to report your spam messages one by one. To report a spam and remove it from the queue, you have to perform 2 clicks. It's hardly usable: if you just forwarded 100 messages that would make 200 clicks...

I seriously hate to click, so I spent half an hour writing a simple Perl script that would process the SpamCop reporting web-based forms, and click "submit" on my behalf. It basically does the monkey job of clicking through all the web based forms for you, all from one command line.

The Script
You can download the script here. Save it somewhere. And don't forget to edit it to reflect your SpamCop settings.

Edit the following stanza to match your settings:

##########################################
##
## EDIT HERE
##
##########################################
my $username = 'william.gates@msn.com';
my $password = 'My Password Rocks';
##########################################

Further down, you may want to set your HTTP proxy address if you are using any. Uncomment the following line, and set your proxy:

# if you need proxy, uncomment that.
# $browser->proxy(['http', 'ftp'],
'http://username:password@127.0.0.1:8080/');

Don't forget to modify the ISP settings, lower down in the script. I could have made a configurable array at the beginning of the file, but I was seriously lazy to do it..

You are almost ready to go. Now you'll have some Perl modules dependencies to solve first.

Necessary Perl Modules
use Tie::InsertOrderHash;
use LWP;
use HTTP::Cookies;
use HTML::TreeBuilder;
use MIME::Base64;

Some of these modules may already be installed on your Linux or *BSD distribution. Most of them will be available as a distribution package in .rpm, .deb, .pkg, etc... or you can download them manually and install. Additionally you may want to use the CPAN Shell to download the module and any dependency.

Warning
Please use this script only to report genuine spam. If you abuse this script, SpamCop will respond by changing its form to include Captchas which will disturb real users even more and that will totally spoil the purpose of this script.

Enjoy. If you have any problem with that script, don't hesitate to comment.
Download the script here.

Update 2006-11-17
Apparently, there is a similar script available on sourceforge called SpamCup. I haven't checked yet to see how the two scripts compare though.

Attacker may attempt some man-in-the-middle attack whereby they fool the client and the server to negotiate a weak cipher suite. Note also that some web browser are too old, and still locked to "export grade" ciphers. In any case the result ends up the same, the cipher negotiated during the SSL handshake may not be strong enough, and a man-in-the-middle could decrypt the traffic.

Solution
A common solution is to force your web-server (or any other SSL enabled service that can be configured in such a way) to accept only strong ciphers during the negotiation.

On apache, you can do this in the mod_ssl configuration file. The keyword that you need to modify is SSLCipherSuite.

My cipher suite line looks like this (all on one line):

SSLCipherSuite !EXPORT40:!EXPORT56:!LOW:!ADH:!NULL:!AECDH-AES256-SHA: !AECDH-AES128-SHA:!AECDH-DES-CBC3-SHA:!AECDH-RC4-SHA: !RC2-CBC-MD5:SSLv3:SSLv2:TLSv1

This translates to having the following ciphers enabled:

# openssl ciphers -v '!EXPORT40:!EXPORT56:!LOW:!ADH:!NULL:!AECDH-AES256-SHA: !AECDH-AES128-SHA:!AECDH-DES-CBC3-SHA:!AECDH-RC4-SHA: !RC2-CBC-MD5:SSLv3:SSLv2:TLSv1'

DHE-RSA-AES256-SHA   SSLv3 K=DH   A=RSA  E=AES(256)  M=SHA1
DHE-DSS-AES256-SHA   SSLv3 K=DH   A=DSS  E=AES(256)  M=SHA1
AES256-SHA           SSLv3 K=RSA  A=RSA  E=AES(256)  M=SHA1
DHE-RSA-AES128-SHA   SSLv3 K=DH   A=RSA  E=AES(128)  M=SHA1
DHE-DSS-AES128-SHA   SSLv3 K=DH   A=DSS  E=AES(128)  M=SHA1
AES128-SHA           SSLv3 K=RSA  A=RSA  E=AES(128)  M=SHA1
DHE-DSS-RC4-SHA      SSLv3 K=DH   A=DSS  E=RC4(128)  M=SHA1
KRB5-RC4-MD5         SSLv3 K=KRB5 A=KRB5 E=RC4(128)  M=MD5 
KRB5-DES-CBC3-MD5    SSLv3 K=KRB5 A=KRB5 E=3DES(168) M=MD5 
KRB5-RC4-SHA         SSLv3 K=KRB5 A=KRB5 E=RC4(128)  M=SHA1
KRB5-DES-CBC3-SHA    SSLv3 K=KRB5 A=KRB5 E=3DES(168) M=SHA1
EDH-RSA-DES-CBC3-SHA SSLv3 K=DH   A=RSA  E=3DES(168) M=SHA1
EDH-DSS-DES-CBC3-SHA SSLv3 K=DH   A=DSS  E=3DES(168) M=SHA1
DES-CBC3-SHA         SSLv3 K=RSA  A=RSA  E=3DES(168) M=SHA1
RC4-SHA              SSLv3 K=RSA  A=RSA  E=RC4(128)  M=SHA1
RC4-MD5              SSLv3 K=RSA  A=RSA  E=RC4(128)  M=MD5 
DES-CBC3-MD5         SSLv2 K=RSA  A=RSA  E=3DES(168) M=MD5 
RC4-MD5              SSLv2 K=RSA  A=RSA  E=RC4(128)  M=MD5

As explained in the mod_ssl documentation

• K means Key Exchange Algorithm (RSA or Diffie-Hellman variants).
• A means Authentication Algorithm (RSA, Diffie-Hellman, DSS or none).
• E means Cipher/Encryption Algorithm (DES, Triple-DES, RC4, RC2, IDEA or none).
• M means MAC Digest Algorithm (MD5, SHA or SHA1).

Conclusion
The exclamation mark means that we request the SSL layer to remove a particular algorithm or algorithms suite from the list of algorigthms to negotiate. Here we took care to remove all algorithm combinations that have low or no encryption. No encryption would defeat the purpose, wouldn't it? ;-)

In God we trust
Everyone else must have an X.509 certificate.

Intro
Secure applications use HTTPS for transport to ensure privacy and integrity. SSL used in HTTPS encrypts and signs all communication between the client and the server.

In a classic HTTPS connection, the client verifies the authenticity of the server X509 certificate (a.k.a. SSL Certificate) by ensuring that all the signatures in the "chain of trust" are valid and all the signer's certificates are trusted. This step is simply to ensure that the server is really who it claims to be. What we are going to discuss is the use of the same method to authenticate the client.

It's not new, it has been there for as long as SSL exists in fact. It's just that very few people use it, or know how it works. Some choose not to use it because of the drawbacks.

How does it work?
An SSL session always, like all polite protocol conversations, begins with formal introductions (think of it as an exchange of name-cards...). The process is called an SSL handshake.

The SSL handshake allows the server to "present" itself (authenticate itself) to the client by using public-key techniques. The client and server then cooperate in creating symmetric keys that will be used for encryption, decryption, and integrity validation during the SSL session that follows. The SSL handshake also allows the client to authenticate itself to the server, which is the part that interests us really.

There is no need to explain in details how it works when others do it so well... A regular SSL handshake involves the server authenticating itself to the client, while the client does not authenticate itself to the server. A detailed explanation along with schematics can be found here

The SSL server can be configured to request authentication of the client, in which case the client has to send a certificate to be authenticated. The same "chain of trust" verification will be performed. So the SSL handshake with client authentication has a few additional steps. Again, a detailed explanation can be found here

How is the actual user authentication done?
You need to have a central in-house certificate authority. You can use command-line tools like openssl or CA.pl which are part of the OpenSSL package. Or you can use OpenCA PKI software which is designed just for that.

You have to

• Generate a Certificate Authority keypair (key + certificate)
• Get the users to generate their keypair (key + certificate signing request)
• Sign each user's certificate using the Certificate Authority keypair

Now since the authentication of the client is performed by SSL as part of the handshake, you don't need to authenticate the user further (of course you can if you want to). In other words, either the client has a valid keypair (key and valid certificate signed by your Certificate Authority) and he can connect. Or he doesn't have any, in which case the SSL connection will fail at handshake time.

Smart Card
The most secure way to go about this is to store your keypair on a smart card. The private key remains on the smart card at all time, while the public key (the certificate) can be installed in the browser, or any other public key or certificate store.

This way, when you want to connect to the server, you have to have your smartcard reader plugged-in and the card properly inserted before you can even connect. The browser will pop-up a window asking you for your smart card pin. Once the pin is entered, the SSL handshake can be done properly.

Nowadays, online services requiring heavy security prefer to use USB smart card + smart card reader devices. It looks like a regular USB mass storage key, except that it's a smart card reader and smart card combined. It's easier to carry, and you just have to install the driver for it to work.

Drawbacks
Obviously, the main problem is that the user must have his certificate + key wherever he roams.

Sometimes, some companies with ultra-strict security policies will force their proxy to play man-in-the middle, so they can still intercept your SSL connections. It will break the server SSL certificate authentication but you can still choose to ignore your browser's warning. This will break the SSL client certificate authentication too but the server will obviously not ignore it and won't let you connect.

Finally, most of the integrated USB smart card reader + smart card dongles have no driver for Linux, *BSD or Solaris.

Conclusion
Although client certificates are more troublesome to set up than username and passwords, they offer a lot more security and resistance to targeted attacks. While they are inconvenient to the road-warriors users, they are perfect authentication tokens for workstation-based employees.

The "filesystem full" argument

If I use a separate partition for /var/log, when the log gets full it will not DoS my machine

Two problems here:

• The log should never get full: use logrotate, backup old logs and remove them from the working system. Review your logs regularly!!!
• If the the log directory does get full there are two more problems:
  • programs will start crashing because they can't log anymore and they didn't expect that to happen,
  • It is very dangerous to run without keeping traces (a smart attacker may create a lot of fake noise in order to get your logs full prompting the system to stop logging, before carrying on the real attack which will be unrecorded due to lack of logs)

Conclusion: creating a separate partition for /var/log is a false sense of security.

The "mount option" argument

I can mount /tmp with nosuid option and /usr with ro (read-only) option.

Mounting /tmp with nosuid is hardly a security enhancement. The only interesting kind of suid files that are really interesting are suid-root files. To create such a file you need to be root. If you are root already (using an exploit payload or with a root-shell) you can very well remount /tmp without the no-suid option...

Mounting /usr with ro option is exactly the same false sense of security. To write in /usr you need to be root to start with, and if you already are, you can remount it without the restriction.

If you truly want to prevent non authorized users (including an attacker who succeeded in getting a rootshell on your system) to write to /usr consider using the excellent RSBAC, a Linux implementation of Trusted Operating Systems security policies. Obviously RSBAC allows you to do a great deal more than just that.

The "easier to upgrade" argument

If I use partitions for let's say the /home directory, it is easier to upgrade my system.

That is true only if you upgrade your system the Windows way: "Reformat and reinstall". Otherwise, any decent Linux distribution, or any other decent Unix flavor will let you upgrade without ever touching anything in /home

The problems of partitioning

• Limited number of partitions: x86 systems let you create a maximum of 4 primary partitions per disk. You can elect to use extended partitions instead which themselves allow you to create 4 partitions per extended partition. The bottom line is that you have a limited number of partitions, so use them wisely.
• Partition full while others are free: if you have 10 megs free in your /boot partition, that's 10 megs that /var/log or any other directory cannot use since it is on another partition. Some smartasses thereafter use soft-link like /var/log/httpd -> /boot/httpdlog but needless to say that these are ugly tricks.
• Tinkering with the partition table: is very dangerous, if you screw up your partition table, your system will be lost (unless you do like me and keep a print-out of all your machines' partition tables in a printed file so you can later re-layout and restore the partition table by hand in case of a problem).

Conclusion
Don't use partitions believing that it will tremendously enhance your security: it will, but only ever so slightly. Partitions are generally a pain when you're running out of space, and today we don't really need partitions anymore with filesystems that support very large partitions and all.

You have been warned...