Monitoring intrusion attempts is almost always a waste of time; secure the server instead.
Set up the server in a secure way, with many layers of defense. Any applications that accept data from the internet should be very robust. After that, add mitigating stuff like SQL permissions, a chroot jail for the web server, running as a totally unprivileged user (i.e. not nobody), and so on and so forth. Pick a secure kernel, too, and make sure that your software is compiled with exploit mitigation techniques (e.g. ASLR, W^X). Throw out anything that needs patching more often than once a year (once every ten years is a better goal). Don't pick a weak password and leave SSH password logins enabled.
If you are interested in detecting intrusions, a first layer may be a list of checksums of crucial files. This is built-in to my favourite OS, OpenBSD, but others can use Tripwire, AIDE or any of the other programs. Note that an attacker with root privileges can typically bypass this.
EDIT: Look at mod_security, too, if you use Apache and cannot trust the web developer (which may be you). Just accept that it will, in the end, not save you.
EDIT2: And don't store passwords in plain text. Or MD5.
There are no currently known cryptographic weaknesses in this application of MD5, and using salts is adequate protection against rainbow tables. But a weakish password can still be guessed far too quickly.
Using a proper key derivation function like OpenBSD's pessimised Blowfish (with a suitable numbers of rounds), John the Ripper tries about 60 passwords per second on my hardware. Against salted MD5, 3000. (Also see PBKDF2, which is also a good solution.)
SHA1 isn't really that much better here, sadly - the problem is not cryptographic weaknesses, it's weak passwords and a function that can be evaluated too quickly.
Set up the server in a secure way, with many layers of defense. Any applications that accept data from the internet should be very robust. After that, add mitigating stuff like SQL permissions, a chroot jail for the web server, running as a totally unprivileged user (i.e. not nobody), and so on and so forth. Pick a secure kernel, too, and make sure that your software is compiled with exploit mitigation techniques (e.g. ASLR, W^X). Throw out anything that needs patching more often than once a year (once every ten years is a better goal). Don't pick a weak password and leave SSH password logins enabled.
If you are interested in detecting intrusions, a first layer may be a list of checksums of crucial files. This is built-in to my favourite OS, OpenBSD, but others can use Tripwire, AIDE or any of the other programs. Note that an attacker with root privileges can typically bypass this.
EDIT: Look at mod_security, too, if you use Apache and cannot trust the web developer (which may be you). Just accept that it will, in the end, not save you.
EDIT2: And don't store passwords in plain text. Or MD5.