freebsd.munk.me.uk - Security

Installing Exim, SASLAuthd, ClamAV and SpamAssassin on FreeBSD 6.2

nospam@example.com (munk) — Wed, 17 Jan 2007 20:19:00 +0000

Introduction
This article describes the steps necessary to install and configure Exim on FreeBSD 6.2 with support for the following:

authenticated SMTP (asmtp) using SASLAuthd
spam detection and quarantine using SpamAssassin
malware detection and quarantine using ClamAV

Each of the required 'dependencies' or components will be installed and configured, Exim will be installed and configured and finally we will test to check each component is working as required.

With regards to spam and malware scanning, the system described will quarantine any files/messages that it finds classified as spam or malware. In this way the quarantined files can be checked over by the admin at a later date and various stats gathering can be done if required.

Installing and Configuring SASLAuthd
SASLAuthd is an authentication daemon that can handle authentication requests from 3rd party applications such as Exim - generally for any application that can't directly access a system password database because of permission restrictions. In this case running Exim MTA as 'root' is a potential security risk, so exim runs as the 'mailnull' user on FreeBSD. Unfortunately this means Exim can't easily read the system password database to authenticate users who want to send mail via the server, which is where SASLAuthd comes in. Any requests for authentication with Exim are passed on to the SASLAuthd daemon which will then verify whether the user credentials are valid - if so, the email is delivered, if not, it's rejected.

Install SASLAuthd from the FreeBSD ports tree:

CODE:
root@win /root# cd /usr/ports/security/cyrus-sasl2-saslauthd/
root@win /usr/ports/security/cyrus-sasl2-saslauthd# make install
...
root@win /usr/ports/security/cyrus-sasl2-saslauthd# rehash
Configure SASLAuthd to run at boot.

Edit /etc/rc.conf to include the following:

CODE:
saslauthd_enable="YES"
saslauthd_flags="-a getpwent"

Note:
SASLAuthd will run using the 'getpwent' authentication mechanism with the flag above. This method uses the passwd file directly instead of using other means like kerberos or PAM. If you require another method, check the manpage for saslauthd.
Start the SASLAuthd daemon running:

CODE:
root@win /usr/ports/security/cyrus-sasl2-saslauthd# cd /usr/local/etc/rc.d
root@win /usr/local/etc/rc.d# ./saslauthd start
(Optional) Test the SASLAuthd daemon:

Substitute 'user' and 'pass' for the username and password of a user
account on your system:

CODE:
root@win /usr/local/etc/rc.d# testsaslauthd -u user -p pass
0: OK "Success."

Installing and Configuring SpamAssassin
SpamAssassin (SA) is one solution to the problem of spam. SA can run as a daemon (spamd) in the background and accept requests from an MTA such as Exim to check whether an email message should be classified as spam.

Spamd looks at the message and checks for various factors that make the message more or less likely to be spam and assigns the message a score based on what it finds. Spamd will then reply to the MTA, telling it the spam score that it gave that message. The MTA can then decide - based on that score - whether to accept/reject the message - or in the case of this guide whether to instead quarantine the message.

Install SA from the FreeBSD ports.

Note:
There are various installation options you can choose when installing SA which you should see when you first run 'make install' in the SA port directory. To see the options after already configuring them you can run 'make config'.

In turn, each of SA's dependencies may also have options you can configure at install time.

To write this guide I'm only using the single option 'AS_ROOT' in the SA install configuation and for the other items generally just choose the
defaults.

CODE:
root@win /root# cd /usr/ports/mail/p5-Mail-SpamAssassin/
root@win /usr/ports/mail/p5-Mail-SpamAssassin# make install

Once complete, you should see:

CODE:
*************************************************************************
*           _  _____ _____ _____ _   _ _____ ___ ___  _   _             *
*          / \|_   _|_   _| ____| \ | |_   _|_ _/ _ \| \ | |            *
*         / _ \ | |   | | |  _| |  \| | | |  | | | | |  \| |            *
*        / ___ \| |   | | | |___| |\  | | |  | | |_| | |\  |            *
*       /_/   \_\_|   |_| |_____|_| \_| |_| |___\___/|_| \_|            *
*                                                                       *
*       See /usr/local/share/doc/p5-Mail-SpamAssassin/INSTALL,          *
*       and /usr/local/share/doc/p5-Mail-SpamAssassin/UPGRADE,          *
*       or http://spamassassin.org/dist/INSTALL and                     *
*       http://spamassassin.org/dist/UPGRADE BEFORE enabling            *
*       this version of SpamAssassin for important information          *
*       regarding changes in this version.                              *
*************************************************************************

It's a good idea to read the files listed in the banner above. SA has a large number of options that can be configured; a good place to start configuring options on FreeBSD is in /usr/local/etc/mail/spamassassin/.
Configure SA to run at boot.

Edit /etc/rc.conf to include the following:

CODE:
spamd_enable="YES"
Start SA spamd.

We can now go on to actually start spamd running as a daemon and verify spamd started ok:

CODE:
root@win /root# cd /usr/local/etc/rc.d
root@win /usr/local/etc/rc.d# rehash
root@win /usr/local/etc/rc.d# ./sa
sa-spamd* saslauthd*
root@win /usr/local/etc/rc.d# ./sa-spamd start
Starting spamd.
munk@win /usr/local/etc/rc.d# ./sa-spamd status
spamd is running as pid 754.

This tells us spamd is running ok in the background.

Installing and Configuring ClamAV
ClamAV is an anti-virus suite and includes a daemon clamd (runs in the background to check for requests to test for virii), another daemon freshclam (updates the virus definition database) and a couple of clients to run on the commandline if you need them for local virus scanning.

Exim will send requests to the clamd server in much the same was as spamd does - if clamd classifies a message as containing a virus, Exim will reject delivery of the message and instaed quarantine it.

Install ClamAV from the FreeBSD ports tree:

CODE:
root@win /root# cd /usr/ports/security/clamav
root@win /usr/ports/security/clamav# make install
Configure ClamAV to start at boot time.

Edit /etc/rc.conf to include:

CODE:
clamav_clamd_enable="YES"
clamav_freshclam_enable="YES"
Configure clamd.

Edit /usr/local/etc/clamd.conf to include the following:

CODE:
LogFile /var/log/clamav/clamd.log
PidFile /var/run/clamav/clamd.pid
DatabaseDirectory /var/db/clamav
LocalSocket /var/run/clamav/clamd
FixStaleSocket
User clamav
AllowSupplementaryGroups
ScanMail
ScanArchive
Start clamd and freshclam.

CODE:
root@win /root# cd /usr/local/etc/rc.d
root@win /usr/local/etc/rc.d# ./clamav-clamd start
Starting clamav_clamd.
root@win /usr/local/etc/rc.d# ./clamav-freshclam start
Starting clamav_freshclam.

Note:
You may see the following message on first running clamd:

CODE:
LibClamAV Warning: **************************************************
LibClamAV Warning: *** The virus database is older than 7 days. ***
LibClamAV Warning: *** Please update it IMMEDIATELY! ***
LibClamAV Warning: **************************************************

As long as you're running freshclam, you can safely ignore this message. Freshclam should update your definitions automatically. Be sure to configure freshclam to update the virus definitions regularly.

ClamAV should be configured now and ready to accept request to check for malware from the Exim MTA.

We can now move on finally to install and configure Exim.

Installing and Configuring Exim
Exim configuration can be very complicated. This guide will only deal with the configuration of Exim so it accepts mail on a domain 'mail.example.com', scans the mail for malware/spam - quarantining anything it finds as malware/spam and accepts authentication requests correctly.

Important:
Ensure your mail server's DNS is configured correctly and preferably has a reverse DNS record (rDNS) set up. Many mail servers will not deliver mail correctly to/from your mail server without rDNS.

Install Exim from the FreeBSD ports tree:

CODE:
[12:10:57] root@win /root# cd /usr/ports/mail/exim
[12:12:30] root@win /usr/ports/mail/exim# make -DWITH_CONTENT_SCAN -DWITH_SASLAUTHD install
Stop the Sendmail daemon if it's already running:

CODE:
root@win /root# cd /etc/rc.d
root@win /etc/rc.d# ./sendmail stop
Configure Exim to run at boot time.

Edit /etc/rc.conf to include:

CODE:
sendmail_enable="NO"
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"
exim_enable="YES"

This has the effect of disabling sendmail at boot time - the default FreeBSD MTA - and running Exim instead.
Configure mailer.conf to use Exim as the default MTA.

Edit /etc/mail/mailer.conf to read:

CODE:
sendmail          /usr/local/sbin/exim
send-mail         /usr/local/sbin/exim
mailq             /usr/local/sbin/exim -bp
newaliases        /usr/bin/true

This will allow any FreeBSD base system mail related commands to use Exim instead of Sendmail.

Configuring Exim
We now move on to configuring Exim.

Set the primary hostname.

Edit /usr/local/etc/exim/configure.

Find and edit the 'primary_hostname' line for your domain:

CODE:
primary_hostname = example.com

This configures Exim to accept mail primarily for the 'example.com' domain - ie foobar@example.com.
Find and edit the following lines to read:

CODE:
av_scanner = clamd:/var/run/clamav/clamd
spamd_address = 127.0.0.1 783
Configure the malware and spam Access Control Lists (ACLs).

How malware/spam checking works in this system:
We add a check in the acl_check_data ACL for spam and malware. Exim will request each email is checked for spam/malware by the relevant daemon - spamd for spam, clamd for malware. If the message is classified as spam/malware by the relevant daemons, Exim will add a header to the message 'X-Quarantine-Me-Spam' (similar for malware).

Later on when it comes to actually delivering (termed 'routing' in Exim terminology), we add two routers to test for the existence of the headers that are added in the acl_check_data ACL if a message is found to be spam/malware. If the headers are found by the malware/spam routers, the message is not delivered but instead copied to a quarantine location on disk.

This quarantine location can then be checked later by an admin to check if anything is amiss - ie regular non spam/malware mail that should really have been delivered.

Once you're satisfied the configuration is working as it should - ie after a few months of operation - and not finding false positives, you can change the malware/spam acl checks to just deny instead of adding the quarantine headers. Having said that, I still opt to just quarantine malware/spam and remove it at a later date.

On to configuring the data ACL:

Modify the acl_check_data ACL to read/include:

CODE:
acl_check_data:

  # Deny if the message contains a virus. Before enabling this check, you
  # must install a virus scanner and set the av_scanner option above.
  #
  # defer_ok - pass this message if scanner is down etc:
  warn  message         = X-Quarantine-Me-Malware: $malware_name
        log_message     = malware: $malware_name
        demime          = *
        malware         = */defer_ok

  # Add headers to a message if it is judged to be spam. Before enabling this,
  # you must install SpamAssassin. You may also need to set the spamd_address
  # option above.
  #
  warn    message       = X-Quarantine-Me-Spam: SA score $spam_score\n\
                          X-SA-Report: $spam_report
          log_message   = Spam score $spam_score > 5
          spam          = spamd/defer_ok
          condition     = ${if >{$spam_score_int}{50}{1}{0}}

  # Accept the message.

  accept

At the top of the routers section, modify to read/include:

CODE:
begin routers

check_malware:
  driver                = redirect
  condition             = ${if def:h_X-Quarantine-Me-Malware: {1}{0}}
  headers_add           = X-Quarantined-Malware: $h_X-Quarantine-Me-Malware:
  headers_remove        = X-Quarantine-Me-Malware
  data                  = /var/quarantine/malware/malware.$tod_logfile
  file_transport        = address_file

check_spam:
  driver                = redirect
  condition             = ${if def:h_X-Quarantine-Me-Spam: {1}{0}}
  headers_add           = X-Quarantined-Spam: $h_X-Quarantine-Me-Spam:
  headers_remove        = X-Quarantine-Me-Spam
  data                  = /var/quarantine/spam/spam.$tod_logfile
  file_transport        = address_file

no_more

Modify the authenticators section to read:

CODE:
begin authenticators
plain:
driver = plaintext
public_name = PLAIN
server_condition = ${if saslauthd{{$2}{$3}}{1}{0}}

login:
driver = plaintext
public_name = LOGIN
server_prompts = "Username:: : Password::"
server_condition = ${if saslauthd{{$1}{$2}}{1}{0}}

Save the /usr/local/etc/exim/configuration file.
Create the quarantine directories and change ownership to mailnull:mail:

CODE:
root@win /root# mkdir -p /var/quarantine/{malware,spam}
root@win /root# chown mailnull:mail /var/quarantine/{malware,spam}
Restart Exim to suck in the new config options:

CODE:
root@win /root# /usr/local/etc/rc.d/exim restart
Stopping exim.
Starting exim.

Exim should now be set to check for malware/spam and to authenticate users.

Testing Exim configuration
Finally we can move on to test that our config works correctly for spam/malware checking and for authenticating users.

Testing Exim's malware/spam scanning.

The easiest option is to send an email to your mailserver with specially crafted malware/spam signatures included in the body of the message. When spamd/clamd see these signature strings in the body of the messages, they should classify the message as spam/malware and Exim in turn will quarantine the messages.

The official EICAR malware/virus testing signature is as follows:

CODE:
X5O%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILEspamcH+H*

See here for the official string:

http://www.eicar.org/anti_virus_test_file.htm

The official GTUBE spam testing signature is as follows:

CODE:
XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X

See here for the official string:

http://spamassassin.apache.org/gtube/

Note:
Another option for testing spam/malware scanning is to run exim from the commandline using the command 'exim -bh 127.0.0.1'. This will run an SMTP session from the commandline (think telnet) and allow you to inject your own specially crafted message using the signatures above. This requires you enter a valid SMTP session, something like:

CODE:
HELO example.com
MAIL FROM:foo@example.com
RCPT TO:foo@example.com
DATA
X5O%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILEspamcH+H*
.

This would simulate the injection of a mail message with a virus in it and in 'exim -bh' mode you can see a lot of useful debugging info to verify everything works ok.
Testing Exim's Authentication configuration.

We can now test that ASMTP is working. For this you can either run exim in one of it's many excellent debugging modes or you can simply configure a remote email client to use ASMTP. This guide will use the commandline to test ASMTP.

Important:
Before attempting this method please read the exim documentation on how ASMTP works. The following assumes you have read and understood that text.

First create a simple perl script called 'encode' in /usr/local/etc/exim/ and make sure it is executable:

CODE:
root@win /usr/local/etc/exim# cat encode
#!/usr/bin/perl
use MIME::Base64;
printf ("%s", encode_base64(eval ""$ARGV[0]""));
root@darkstar /usr/local/etc/exim# chmod +x encode
root@darkstar /usr/local/etc/exim# ls -al encode
-rwxr-xr-x  1 root  wheel  85 Apr 23 12:25 encode

Now decide which user account on your server you wish to test ASMTP with. It must be an account you know the password for obviously. I created an account called 'dummy' and set the password to 'dummy' as well - if you do this remember to remove the account or disable it as soon as you've finished testing.

Encode the user:password pair into base64 MIME using the 'encode' script we created above:

CODE:
root@darkstar /usr/local/etc/exim# ./encode "\0dummy\0dummy"
AGR1bW15AGR1bW15

Now enter into Exim's fake SMTP session command-line mode and just for good measure do it in authentication debug mode as well:

CODE:
root@win /root#  exim -d+auth -bh 127.0.0.1
Exim version 4.66 (FreeBSD 6.1) uid=0 gid=0 pid=3056 D=fbb95cfd
Probably Berkeley DB version 1.8x (native mode)
Support for: crypteq iconv() IPv6 use_setclassresources PAM Perl OpenSSL Content_Scanning Old_Demime
Lookups: lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmnz dnsdb dsearch nis nis0 passwd
Authenticators: cram_md5 plaintext spa
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
Fixed never_users: 0
Size of off_t: 8
changed uid/gid: forcing real = effective
  uid=0 gid=0 pid=3056
  auxiliary group list: 0
seeking password data for user "mailnull": using cached result
getpwnam() succeeded uid=26 gid=26
seeking password data for user "root": cache not available
getpwnam() succeeded uid=0 gid=0
configuration file is /usr/local/etc/exim/configure
log selectors = 00000ffc 00089001
trusted user
admin user
changed uid/gid: privilege not needed
  uid=26 gid=6 pid=3056
  auxiliary group list: 6 6
seeking password data for user "mailnull": cache not available
getpwnam() succeeded uid=26 gid=26
originator: uid=0 gid=0 login=root name=Charlie Root
sender address = root@win.munk.me.uk
sender_fullhost = [127.0.0.1]
sender_rcvhost = [127.0.0.1]

**** SMTP testing session as if from host 127.0.0.1
**** but without any ident (RFC 1413) callback.
**** This is not for real!

host in hosts_connection_nolog? no (option unset)
LOG: smtp_connection MAIN
  SMTP connection from [127.0.0.1]
host in host_lookup? yes (matched "*")
looking up host name for 127.0.0.1
DNS lookup of 1.0.0.127.in-addr.arpa (PTR) succeeded
IP address lookup yielded localhost.munk.me.uk
gethostbyname2 looked up these IP addresses:
  name=localhost.munk.me.uk address=::1
  name=localhost.munk.me.uk address=127.0.0.1
checking addresses for localhost.munk.me.uk
  ::1
  127.0.0.1 OK
sender_fullhost = localhost.munk.me.uk [127.0.0.1]
sender_rcvhost = localhost.munk.me.uk ([127.0.0.1])
set_process_info:  3056 handling incoming connection from localhost.munk.me.uk [127.0.0.1]
host in host_reject_connection? no (option unset)
host in sender_unqualified_hosts? no (option unset)
host in recipient_unqualified_hosts? no (option unset)
host in helo_verify_hosts? no (option unset)
host in helo_try_verify_hosts? no (option unset)
host in helo_accept_junk_hosts? no (option unset)
SMTP>> 220 win.munk.me.uk ESMTP Exim 4.66 Wed, 17 Jan 2007 19:24:22 +0000
220 win.munk.me.uk ESMTP Exim 4.66 Wed, 17 Jan 2007 19:24:22 +0000
smtp_setup_msg entered

When you get to this point you are ready to start an SMTP 'conversation' with Exim. First introduce yourself to Exim using the SMTP 'EHLO localhost' command:

CODE:
EHLO localhost
SMTP<< EHLO localhost
sender_fullhost = localhost.munk.me.uk (localhost) [127.0.0.1]
sender_rcvhost = localhost.munk.me.uk ([127.0.0.1] helo=localhost)
set_process_info:  3103 handling incoming connection from localhost.munk.me.uk (localhost) [127.0.0.1]
host in pipelining_advertise_hosts? yes (matched "*")
host in auth_advertise_hosts? yes (matched "*")
host in tls_advertise_hosts? no (option unset)
250-win.munk.me.uk Hello localhost.munk.me.uk [127.0.0.1]
250-SIZE 52428800
250-PIPELINING
250-AUTH PLAIN LOGIN
250 HELP
SMTP>> 250-win.munk.me.uk Hello localhost.munk.me.uk [127.0.0.1]
250-SIZE 52428800
250-PIPELINING
250-AUTH PLAIN LOGIN
250 HELP

In response to your 'EHLO localhost' command, Exim returns more debug information but most importantly for us it also indicates what authentication options it offers in this line:

CODE:
250-AUTH PLAIN LOGIN

This indicates that currently acceptable AUTH methods are PLAIN and LOGIN.

We can then test the PLAIN login method using the "\0dummy\0dummy" user:password pair we encoded above:

CODE:
AUTH PLAIN AGR1bW15AGR1bW15
SMTP<< AUTH PLAIN AGR1bW15AGR1bW15
Running pwcheck authentication for user "dummy"
pwcheck: success (NULL)
plain authenticator:
  $1 =
  $2 = dummy
  $3 = dummy
expanded string: 1
SMTP>> 235 Authentication succeeded
235 Authentication succeeded

This indicates that authentication for 'dummy:dummy' would succeed and mail would be relayed (pending further conditional checks by Exim).

So we now have a working Exim with support for spam/malware checking and authentication over SMTP.

Block Brute Force Attacks Against sshd and proftpd Using blockhosts

nospam@example.com (munk) — Sat, 30 Dec 2006 11:52:15 +0000

For a long time now I've had a lot of problems with brute force attacks against sshd and proftpd - attacks where a host will attempt to login with a dictionary of common usernames and passwords, trying each one until they find a combination that works. Apart from being a security issue, this uses up a lot of bandwidth so it's worth taking some measures to block these kind of attacks.

Both sshd and ftpd services have their own individual means for blocking individual connections, but unfortunately neither have an inbuilt method for detecting brute force attacks - counting how many failed login attempts are made from each individual IP address and then blocking that IP address if the number of failed login attempts is more than a certain number. This is where a 3rd party utility is required.

There are a few utilities that can mitigate brute force attacks on services. For a while now I've used DenyHosts successfully to block sshd brute force attacks. DenyHosts works by constantly monitoring sshd logfiles and keeping track of how many failed logins have occured per IP address over time. If the number of failed logins reaches a certain threshold, DenyHosts adds an entry in /etc/hosts.allow that effectively blocks the IP address, stopping that host from connecting to the sshd service any more.

DenyHosts is great, but unfortunately it's aimed only at blocking sshd brute force attacks and I need to protect the ftpd service as well as just sshd - and in future maybe adapt to block other services. With this in mind I decided to move to using a very similar script called BlockHosts (the documentation for BlockHosts actually mentions that it was inspired by DenyHosts). BlockHosts can scan a list of service logfiles in one go instead of just a single logfile as with DenyHosts, so is ideal for monitoring a number of different services for brute force attacks.

The following describes how to install and configure BlockHosts on FreeBSD so it's executed every time the sshd or proftpd services are accessed using TCP_WRAPPERS - ie modifying /etc/hosts.allow so the blockhosts script is run each time sshd or proftpd are accessed. The BlockHosts script will then check if this current connection attempt is part of a brute force attack and if so, add a blocking rule to /etc/hosts.allow to deny further access.

Installation of BlockHosts

Download blockhosts from the download page, extract the distribution (note please check the download link for the latest version, the version below was latest at time of writing):

CODE:
root@users /home/munk/bin/python/blockhosts# wget http://www.aczoom.com/tools/blockhosts/BlockHosts-1.0.5.tar.gz
root@users /home/munk/bin/python/blockhosts# tar zxvf BlockHosts-1.0.5.tar.gz
BlockHosts-1.0.5/
BlockHosts-1.0.5/Makefile
...
Change to BlockHosts directory:

CODE:
root@users /home/munk/bin/python/blockhosts# cd BlockHosts-1.0.5
Edit and save blockhosts.py to read:

CODE:
CONFIG_FILE = "/usr/local/etc/blockhosts.cfg"
...
"LOGFILES": ( "/var/log/auth.log", ),

Note: may seem a bit odd editing the blockhosts.py script before it's installed - the reason for this is that the installation locations used by setup.py below are taken from blockhosts.py, so by modifying blockhosts.py like this we get the config file installed into /usr/local/etc/ (FreeBSD default for 3rd party software) instead of into /etc (default for linux 3rd party software).
Install blockhosts:

CODE:
root@users /home/munk/bin/python/blockhosts/BlockHosts-1.0.5# python setup.py -v install
running install
running build
running build_scripts
creating build
creating build/scripts-2.4
copying and adjusting blockhosts.py -> build/scripts-2.4
changing mode of build/scripts-2.4/blockhosts.py from 644 to 755
running install_scripts
copying build/scripts-2.4/blockhosts.py -> /usr/local/bin
changing mode of /usr/local/bin/blockhosts.py to 755
running install_data
copying blockhosts.cfg -> /usr/local/etc

This installs the blockhosts.py script into /usr/local/bin and the config file blockhosts.cfg into /usr/local/etc. Make sure to run 'rehash' to reread the binary paths again so blockhosts.py will run from anywhere:

CODE:
root@users /home/munk/bin/python/blockhosts/BlockHosts-1.0.5# rehash
Edit and save the /usr/local/etc/blockhosts.cfg file so it reads:

CODE:
LOGFILES = [ "/var/log/auth.log", "/var/log/ftp.log" ]

Important:
Add the logfiles you want blockhosts to monitor for brute force attacks here. /var/log/auth.log is standard for sshd, /var/log/ftp.log is maybe not standard for all ftpd, this is just what I have setup here.

At this point it's best to read through the documentation for blockhosts completely - the README, INSTALL and the blockhosts.py script itself. The following section is pretty much copy/pasted from what's mentioned in there.
Edit and save /etc/hosts.allow to include the section that blockhosts.py will modify. Make sure you allow your own IP blocks first and any trusted IPs so they don't get blocked accidentally:

GOTCHA LOOKOUT!
One gotcha to watch out for in this is the line:

CODE:
ALL : ALL : allow

You MUST remove this line - replace it with your IP block instead so you don't get locked out from your own address range. If this line isn't removed/commented out, anything below it just isn't read/executed and blockhosts won't work.

This is how my /etc/hosts.allow looks:

CODE:
#######################################################################
# blockhosts
#######################################################################
# ----
# see "man 5 hosts_access" for details of the format of IP addresses,
#services, allow/deny options. Also see "man hosts_options"
#order of lines in this file is important, first matched IP address line
#is rule applied by hosts_access
#
# permanent whitelist addresses - these should always be allowed access

ALL : 213.152.51.192/255.255.255.248 : allow
# ALL: 127.0.0.1  : allow
# ALL: 192.168.0. : allow

# permanent blacklist addresses - these should always be denied access

# ALL: 10.  : deny
# ALL: 192. : deny
# ALL: 172. : deny

# ----------------------------------------
# next section is the blockhosts section - it will add/delete entries in
# between the two marker lines (#---- BlockHosts Additions)

#---- BlockHosts Additions
#---- BlockHosts Additions

# ----------------------------------------
# finally, the command to execute the blockhosts script, based on
# connection to particular service or services, for example, for
# sshd and proftpd - if using vsftpd, pure-ftpd, be sure to use those
# words instead:

sshd, proftpd: ALL: spawn (/usr/local/bin/blockhosts.py --verbose --echo "%c-%s" >> /var/log/blockhosts.log 2>&1 )& : allow

# remove:   >> /var/log/blockhosts.log 2>&1     if logging to
# blockhosts.log is not needed - it will still log to syslog (minimally)
# see examples below
# --
# See "man hosts.allow" for info on %c and %s identifiers
#----
# for non-verbose, with identification, to syslog only (/var/log/messages):
#sshd, proftpd, in.proftpd: ALL: spawn /usr/bin/blockhosts.py --echo "%c-%s" & : allow
#----
# minimal logging, to syslog (usually goes to /var/log/messages):
#sshd, proftpd, in.proftpd: ALL: spawn /usr/bin/blockhosts.py & : allow
#----
# To test hosts.allow, and to find out exact names of SSH/FTP services,
# add this line to the beginning of hosts.allow, use ssh/ftp to connect
# to your server, and then look at the log (/var/log/messages or
# blockhosts.log) to see the name of the invoked service.
# IMPORTANT: after your test is done, remove this line from hosts.allow!
# Otherwise everyone will always have access.
#ALL : ALL: spawn (/usr/bin/blockhosts.py --verbose --echo "%c-%s" >> /var/log/blockhosts.log 2>&1 )& : allow
#######################################################################
# blockhosts
#######################################################################

Important Note for ProFTPD users:
The following sections describes the configuration needed when using proftpd via inetd. If you are using ProFTPD in standalone mode, you need to use the proftpd mod_wrap/mod_wrap_file functionality to have proftpd read and honour the TCP_WRAPPERS//etc/hosts.allow file(s) when denying/allowing hosts. Additionally you need to specifiy the configure flag --enable-wrapper-options when building proftpd. For a heavily used server, this might be worth doing but personally I don't get that many connections that I need to worry about inetd being overloaded so I can just go down the (easier to configure for blockhosts) inetd path.
Ensure proftpd is configured to run correctly via inetd.

Edit and save /usr/local/etc/proftpd.conf to read:

CODE:
ServerType inetd

Important: remember to delete or rename /usr/local/etc/rc.d/proftpd.sh so it's not run at boot time - the proftpd daemon doesn't need to be started at boot if you're using inetd, inetd handles all the proftpd connections, see below:

Edit and save /etc/inetd.conf to read:

CODE:
ftp stream tcp nowait root /usr/local/sbin/in.proftpd proftpd

then restart inetd:

CODE:
root@users /usr/local/etc# kill -HUP `cat /var/run/inetd.pid `

This forces inetd to restart, rereading the config file changes made to /etc/inetd.conf. ftp connections will now be handled by proftpd via inetd.

We're now ready to run blockhosts.py for the first time. BlockHosts will parse each logfile mentioned in blockhosts.cfg and check for any brute force attacks and if it finds any, blocks will be added to the /etc/hosts.allow file.

Note: This initial check does not take into account the period over which failed logins took place, so any IP that has more than the default 7 failed login entries will look like a brute force attacker. However, the ban BlockHosts adds will only last for the default 12 hours so this shouldn't cause a huge issue - just be aware of this and check the IPs that are added on the first run.

For the very first time it's a good idea to try a 'dry run' just to see what blockhosts finds and what it'd do, without actually doing anything to the /etc/hosts.allow file. To do this, run blockhosts with the '--dry-run' flag:

CODE:

root@users /usr/local/etc# /usr/local/bin/blockhosts.py --verbose --dry-run
blockhosts 1.0.5 started: 2006-12-30 14:15:30
... will discard all host entries older than  2006-12-30 02:15
... load blockfile: /etc/hosts.allow
... found both markers, count of hosts being watched: 0
  Warning: no offset found, will read from beginning in logfile: /var/log/auth.log
... securelog, loading file, offset: /var/log/auth.log 0
  Warning: no offset found, will read from beginning in logfile: /var/log/ftp.log
... securelog, loading file, offset: /var/log/ftp.log 0
... updates: counts: hosts to block: 9; hosts being watched: 21
#---- BlockHosts Additions
ALL:  203.88.192.225 : deny
ALL:    200.71.192.7 : deny
ALL:  212.227.81.146 : deny
ALL:    218.25.62.75 : deny
ALL:  200.46.108.164 : deny
ALL:    201.57.163.2 : deny
ALL:  205.129.191.11 : deny
ALL:    200.68.51.91 : deny
ALL:    82.38.68.217 : deny

#bh: ip:   85.184.10.200 :   1 : 2006-12-30-14-15
#bh: ip:  84.158.231.209 :   1 : 2006-12-30-14-15
#bh: ip:    82.38.68.217 :  11 : 2006-12-30-14-15
#bh: ip:    82.153.28.16 :   2 : 2006-12-30-14-15
#bh: ip:   67.113.225.66 :   1 : 2006-12-30-14-15
#bh: ip:   59.108.34.228 :   2 : 2006-12-30-14-15
#bh: ip:  222.68.192.132 :   2 : 2006-12-30-14-15
#bh: ip:    218.25.62.75 :  20 : 2006-12-30-14-15
#bh: ip:  217.83.162.157 :   1 : 2006-12-30-14-15
#bh: ip:  212.227.81.146 : 29499 : 2006-12-30-14-15
#bh: ip:   210.1.132.178 :   4 : 2006-12-30-14-15
#bh: ip:  205.129.191.11 :  20 : 2006-12-30-14-15
#bh: ip:   204.141.87.14 :   3 : 2006-12-30-14-15
#bh: ip:  203.88.192.225 : 448 : 2006-12-30-14-15
#bh: ip:  202.108.40.109 :   1 : 2006-12-30-14-15
#bh: ip:    201.57.163.2 : 2867 : 2006-12-30-14-15
#bh: ip:    200.71.192.7 : 761 : 2006-12-30-14-15
#bh: ip:    200.68.51.91 :  10 : 2006-12-30-14-15
#bh: ip:  200.46.108.164 : 170 : 2006-12-30-14-15
#bh: ip:  200.105.255.90 :   7 : 2006-12-30-14-15
#bh: ip:  152.104.125.14 :   3 : 2006-12-30-14-15

From this you can see nicely what blockhosts makes of the service logfiles and the addresses that have tried to connect unsuccessfully. On my host, as you can see above, there are a few that are obviously dodgy (I would only expect a max of maybe 8 connections per ip per month, so clearly 29,499 connections is just wrong!).

Once you're happy that the output is correct, run blockhosts again without the '--dry-run' flag and the /etc/hosts.allow file will be modified. Also from now on the logfiles will only be read from the last recorded offset which saves a lot of time if your logfiles are very big.

Big thanks to the BlockHosts author Avinash Chopde !

FreeBSD 6.2 To Include Security Event Auditing

nospam@example.com (munk) — Tue, 14 Nov 2006 16:38:39 +0000

Just read an interesting article about the addition of 'Security Event Auditing' in FreeBSD 6.2. Until now FreeBSD hasn't had any really useful security auditing other than using 'accounting' to log all syscalls which at best was confusing when it came to working out who did what when and how.

At one time I installed a kernel module lrexec to log all system exec calls, but this was also quite a handful to configure scripts so they reported only on certain users. Hopefully this new security auditing daemon will make security auditing a lot easier on FreeBSD.

Read the article for more info on what's new:
Security Event Auditing in FreeBSD 6.2

Also of interest is the new addition to the FreeBSD handbook on security auditing:
FreeBSD Handbook: Security Event Auditing

Modsecurity 2.0 Released

nospam@example.com (munk) — Fri, 20 Oct 2006 14:24:52 +0000

A new version of mod_security has just been released - 2.0 - complete with a total rewrite that includes a number of new features. El reg is running an article on the new release which includes an interview with ModSecurity's author Ivan Ristic.

mod_security is an apache module for monitoring requests made to a web server and acting on those requests according to rules - useful for blocking malicious bots, stopping web spammers and so on. I've been using it for a few years now and it handles blocking of weblog spammers and trojan worms/bots very well, though it has to be said the configuration isn't the simplest of all time.

Hopefully this configuration issue might be made easier with the also newly released modsecurity console, although reading through that page it doesn't seem to mention anything about using it to configure mod_security... Will have a look at it later and see what's what.

A list of the new features or improved features in ModSecurity 2.0 - taken from the article above:

Five processing phases (where there were only two in 1.9.x). These are: request headers, request body, response headers, response body, and logging. Those users who wanted to do things at the earliest possible moment can do them now.

Per-rule transformation options (previously normalisation was implicit and hard-coded). Many new transformation functions were added.

Transaction variables. This can be used to store pieces of data, create a transaction anomaly score, and so on.

Data persistence (can be configured any way you want although most people will want to use this feature to track IP addresses, application sessions, and application users).

Support for anomaly scoring and basic event correlation (counters can be automatically decreased over time; variables can be expired).

Support for web applications and session IDs.

Regular Expression back-references (allows one to create custom variables using transaction content).

There are now many functions that can be applied to the variables (where previously one could only use regular expressions).

XML support (parsing, validation, XPath).

The article is well worth reading if you already use ModSecurity - particularly if you're interested in moving from just simple blocking and logging of requests as in mod_security 1.0 to a more sophisticated web application firewalling system - mod_security 2.0. 2.0 includes a pseudo web app firewalling programming language making it easy to manipulate and process HTTP in a stateful manner - tracking HTTP sessions per IP in real time for example or perhaps watching for anomalous web activity and then flagging any IP that transgresses behaviour deemed as acceptable and watching for that IP in the future.

Password generation using a base rule

nospam@example.com (munk) — Sun, 01 Oct 2006 21:11:57 +0000

Just stumbled across this article on lifehacker about choosing and remembering great passwords. The gist of it is you choose a base 'rule' and then tack on a password that's unique to the system that you're using.

For example if your mother's maiden name was Cameron Jane Diaz, you might use cjd5 as the 'base'. Then you'd create a password based on the system you're using - so for amazon you might make tack on 1m1zon - making the passwd cjd51m1zon. Not a bad password in and of itself.

One downside to the 'base rule' system as someone pointed out in the comments to that article - it's a bit like having just one password with lots of variations on the theme. Someone finds out the 'base' password rule and it'd be a lot easier cracking the rest of the passwords. I'd disagree that that's a bad thing though; as long as you keep the end bit of the password unique and long enough, the passwords are still hardened enough to resist an attack even if someone does find out the 'base rule' - for example cracking '1m1zon' wouldn't be trivial.

Worth reading the article though if you tend to use a single password for almost everything:

Choose and remember great passwords (Lifehacker)

Solving permission problems with parsepath.pl

nospam@example.com (munk) — Mon, 04 Sep 2006 22:41:00 +0000

parsepath.pl is a brilliant perl script for fixing permissions problems on Unix based platforms by Jeremy Mates. Probably the most common type of permission problem from a sysadmin/webmaster's viewpoint is uploading a file to a directory in a website's document root folder and then trying to access the file or script in a web browser only to get the dreaded 403 error message:

Forbidden
You don't have permission to access /foo/bar/test.php on this server.

Most time the solution is very simple, just change the permissions on 'test.php' to make sure the user the webserver runs as can read the file correctly - the simplest and most common method being to change the mode of the file to '755':

CODE:

chmod 755 test.php

Unfortunately sometimes it's not that easy and many times you see users asking 'I'm getting 'access denied' errors even though I've changed the perms to 755'. The problem is that one of the subdirectories that the 'test.php' file lives in has permissions set so that the webserver can't read the file properly. Now that's where the headache comes in :)

However, parsepath.pl can take the headache out of fixing permissions problems.

Say you have a website document root directory tree /usr/local/www/web/www.munk.me.uk/foo/bar and you upload a web script 'test.php' into that directory. You try and access the file in a webbrowser but get the 403 permission denied error above. First off you check the permissions on the file itself:

CODE:

[23:58:17] root@users /usr/local/www/web/www.munk.me.uk/foo/bar# ; ls -l
total 0
-rwxr-xr-x 1 www www 0 Sep 4 23:39 test.php

That looks ok, with permissions 755 and the owner/group set to 'www' the webserver user 'www' should be able to read the file ok. So in this case the problem must be with the permissions on one of the parent subdirectories. The old method of working out the perms would be either to trawl one by one through each directory checking the perms on each subdirectory or to change the permissions recursively on the document root folder so all subfolders have the read bit set for the webserver user/group.

With parsepath.pl things are a lot simpler though - just run the following command:

CODE:

[0:03:21] root@users /usr/local/www/web/www.munk.me.uk/foo/bar# parsepath.pl user=www +r test.php
! group=www +rx fails: d 0700 root:www /usr/local/www/web/www.munk.me.uk/foo
! unix-other +rx fails: d 0750 root:wheel /usr/local/www/web/www.munk.me.uk/foo/bar

With this command parsepath.pl recurses through each subdirectory below the file/path you feed it on the commandline and tells you the permissions problems - if any - for the user 'www' (the user=www argument) to read (the +r argument) the file 'test.php'.

In the output, we're told that permissions to read the test.php by the user www fails on two counts:

CODE:

# the group bit on the folder 'foo' doesn't have the +rx flag set:
! group=www +rx fails: d 0700 root:www /usr/local/www/web/www.munk.me.uk/foo

# the other bit on the folder 'bar' doesn't have the +rx flag set:
! unix-other +rx fails: d 0750 root:wheel /usr/local/www/web/www.munk.me.uk/foo/bar

With this information it's easy enough to go in and make the changes necessary to fix the problem using 'chmod g+rx foo foo/bar'.

There are other ways of invoking parsepath.pl though. Running it just with a file/path as an argument it'll tell you the permissions on each subdirectory under it:

CODE:

[0:10:33] root@users /usr/local/www/web/www.munk.me.uk/foo/bar#
> parsepath.pl /usr/local/www/web/www.munk.me.uk/foo/bar/test.php
% /usr/local/www/web/www.munk.me.uk/foo/bar/test.php
d 0755 root:wheel /
d 0755 root:wheel /usr
d 0755 root:wheel /usr/local
d 0755 root:wheel /usr/local/www
d 0770 www:wheel /usr/local/www/web
d 0750 www:www /usr/local/www/web/www.munk.me.uk
d 0700 root:www /usr/local/www/web/www.munk.me.uk/foo
d 0750 root:wheel /usr/local/www/web/www.munk.me.uk/foo/bar
f 0755 root:www /usr/local/www/web/www.munk.me.uk/foo/bar/test.php

which can is better to see a whole tree in one go.

No permissions were harmed in the making of this article!

I'll include the parsepath.pl script in the extended article just in case the original ever gets lost - big credit of course goes to the author of the script, Jeremy Mates. His site is actually very interesting from a sysadmin's point of view containing lots of interesting admin scripts and thoughts on system administration in general - spent quite a while grazing through his stuff there - cheers Jeremy.

Continue reading "Solving permission problems with parsepath.pl"

Snort upgrade to 2.6.0 fails in make build on FreeBSD 4.11

nospam@example.com (munk) — Sat, 02 Sep 2006 18:12:54 +0000

UPDATE:
Yay this is now fixed, seemed to be a fairly simple solution too. All good!

http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/102922

A few days ago I went to upgrade snort to the latest version (from 2.4.5 to 2.6.0) and it failed at the 'make build' stage. I've just had a chance to look into the problem and it appears to be to do with the build of the dynamic rule processing functionality. A temporary workaround is to build snort with the '-DWITHOUT_DYNAMIC' flag on FreeBSD:

CODE:

cd /usr/ports/security/snort
make -DWITHOUT_DYNAMIC clean install

Hopefully a full fix will be found in the next few weeks. I'm about to submit a problem report (PR) once the maintainer's had a chance to look it over, I'll cc it to the snort-users mailing list as well in the hope someone there will have a better idea what the problem is.

The PR is included in the extended article.

Continue reading "Snort upgrade to 2.6.0 fails in make build on FreeBSD 4.11"

Apachectl Leaks Sensitive in phpinfo() PHP Calls

nospam@example.com (munk) — Sat, 15 Jan 2005 10:27:36 +0000

Quite a while ago I posted a question to the freebsd-isp mailing list about a minor modification that could be added to the apachectl apache startup shell script to stop it from displaying a lot of sensitive information when PHP and other CGI applications display apache's environment information to users. A bit mouthful - the gist of it is that when you use apachectl to start/stop apache from a shell, the environment variables of the shell user that invokes the apachectl script become available to CGI applications by default.

For example in my case the following types of sensitive environmental information is available by default when someone runs phpinfo.php on my server:

CODE:

_ENV["USER"] root
_ENV["MAIL"] /var/mail/root
_ENV["qbertconf"] /home/munk/eggdrop/bots/qbert/qbert.conf
_ENV["webcpdevcvs"] /home/munk/cvs/ver2
_ENV["alllog"] /var/log/all.log
_ENV["apacheerrlog"] /var/log/httpd-error.log
_ENV["SHLVL"] 2
_ENV["VENDOR"] intel
_ENV["snortruledir"] /usr/local/share/snort
_ENV["PHP4_OPTFILE"] /root/php4_options
_ENV["IRCNICK"] munk
_ENV["HOME"] /root

and so on along with all the other environment variables I have set in my default root shell - not really what I want displayed to all and sundry :P To see this yourself on your own server, try running phpinfo() from a php script:

CODE:

<?php phpinfo(); ?>

Anyway the solution I found is to 'sanitize' the environment when the apachectl script starts up the apache httpd process by using the following simple line in apachectl:

CODE:

HTTPD=`echo /usr/bin/env -i $HTTPD`

A problem report I was considering sending to the FreeBSD ports team is included in the extended article below - I didn't bother sending it in the end because it's not really a FreeBSD issue. Not sure why I didn't send it to the Apache mailing list though, I thought I did but I can't find it now. Ho hum.

Continue reading "Apachectl Leaks Sensitive in phpinfo() PHP Calls"

FreeBSD Security Advisory - Overflow error in fetch

nospam@example.com (munk) — Thu, 18 Nov 2004 14:58:26 +0000

CODE:

=============================================================================
FreeBSD-SA-04:16.fetch                                      Security Advisory
                                                         The FreeBSD Project

Topic:          Overflow error in fetch

Category:       core
Module:         fetch
Announced:      2004-11-18
Credits:        Colin Percival
Affects:        All FreeBSD versions.
Corrected:      2004-11-18 12:02:13 UTC (RELENG_5, 5.3-STABLE)
               2004-11-18 12:03:05 UTC (RELENG_5_3, 5.3-RELEASE-p1)
               2004-11-18 12:04:29 UTC (RELENG_5_2, 5.2.1-RELEASE-p12)
               2004-11-18 12:05:36 UTC (RELENG_5_1, 5.1-RELEASE-p18)
               2004-11-18 12:05:50 UTC (RELENG_5_0, 5.0-RELEASE-p22)
               2004-11-18 12:02:29 UTC (RELENG_4, 4.10-STABLE)
               2004-11-18 12:06:06 UTC (RELENG_4_10, 4.10-RELEASE-p4)
               2004-11-18 12:06:22 UTC (RELENG_4_9, 4.9-RELEASE-p13)
               2004-11-18 12:06:36 UTC (RELENG_4_8, 4.8-RELEASE-p26)
               2004-11-18 12:06:52 UTC (RELENG_4_7, 4.7-RELEASE-p28)
FreeBSD only:   YES

For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit
<URL:http://www.freebsd.org/security/>.

I.   Background

The fetch(1) utility is a tool for fetching files via FTP, HTTP, and HTTPS.

II.  Problem Description

An integer overflow condition in the processing of HTTP headers can result
in a buffer overflow.

III. Impact

A malicious server or CGI script can respond to an HTTP or HTTPS request in
such a manner as to cause arbitrary portions of the client's memory to be
overwritten, allowing for arbitrary code execution.

IV.  Workaround

There is no known workaround for the affected application, although
the ftp(1) application in the FreeBSD base system, and several
applications in the FreeBSD Ports collection provide similar
functionality and could be used in place of fetch(1).

V.   Solution

Perform one of the following:

1) Upgrade your vulnerable system to 4-STABLE or 5-STABLE, or to the
RELENG_5_3, RELENG_5_2, RELENG_4_10, or RELENG_4_8 security branch dated
after the correction date.

2) To patch your present system:

The following patches have been verified to apply to FreeBSD 4.8, 4.10,
5.2, and 5.3 systems.

a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.

# ftp ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:16/fetch.patch
# ftp ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:16/fetch.patch.asc

b) Execute the following commands as root:

# cd /usr/src
# patch < /path/to/patch
# cd /usr/src/usr.bin/fetch
# make obj && make depend && make && make install

3) IMPORTANT NOTE to users of FreeBSD Update:

FreeBSD Update (security/freebsd-update in the FreeBSD Ports collection)
is a binary security update system for the FreeBSD base system.  It is
not supported or endorsed by the FreeBSD Security team, but its author
has requested that the following note be included in this advisory:

FreeBSD Update uses the fetch(1) utility for downloading security
updates to the FreeBSD base system.  While these updates are
cryptographically signed, and FreeBSD Update is therefore immune from
most attacks, it is exposed to this vulnerability since the files
must be fetched before their integrity can be verified.

As a workaround, FreeBSD Update can be made to use the ftp(1) utility
for downloading updates as follows:

# sed -i.bak -e 's/fetch -qo/ftp -o/' /usr/local/sbin/freebsd-update
# freebsd-update fetch
# mv /usr/local/sbin/freebsd-update.bak /usr/local/sbin/freebsd-update
# freebsd-update install

VI.  Correction details

The following list contains the revision numbers of each file that was
corrected in FreeBSD.

Branch                                                           Revision
Path
- -------------------------------------------------------------------------
RELENG_4
src/usr.bin/fetch/fetch.c                                     1.10.2.28
RELENG_4_10
src/UPDATING                                              1.73.2.90.2.5
src/sys/conf/newvers.sh                                   1.44.2.34.2.6
src/usr.bin/fetch/fetch.c                                 1.10.2.23.2.1
RELENG_4_9
src/UPDATING                                             1.73.2.89.2.14
src/sys/conf/newvers.sh                                  1.44.2.32.2.14
src/usr.bin/fetch/fetch.c                                 1.10.2.21.2.1
RELENG_4_8
src/UPDATING                                             1.73.2.80.2.29
src/sys/conf/newvers.sh                                  1.44.2.29.2.27
src/usr.bin/fetch/fetch.c                                 1.10.2.20.2.1
RELENG_4_7
src/UPDATING                                             1.73.2.74.2.32
src/sys/conf/newvers.sh                                  1.44.2.26.2.30
src/usr.bin/fetch/fetch.c                                 1.10.2.18.2.1
RELENG_5
src/usr.bin/fetch/fetch.c                                      1.72.2.2
RELENG_5_3
src/UPDATING                                             1.342.2.13.2.4
src/sys/conf/newvers.sh                                   1.62.2.15.2.6
src/usr.bin/fetch/fetch.c                                  1.72.2.1.2.1
RELENG_5_2
src/UPDATING                                                 1.282.2.20
src/sys/conf/newvers.sh                                       1.56.2.19
src/usr.bin/fetch/fetch.c                                      1.62.4.1
RELENG_5_1
src/UPDATING                                                 1.251.2.20
src/sys/conf/newvers.sh                                       1.50.2.20
src/usr.bin/fetch/fetch.c                                      1.62.2.1
RELENG_5_0
src/UPDATING                                                 1.229.2.28
src/sys/conf/newvers.sh                                       1.48.2.23
src/usr.bin/fetch/fetch.c                                      1.58.2.1
- -------------------------------------------------------------------------

VII. References

<other info on vulnerability>

FreeBSD Security Advisory - Boundary checking errors in syscons

nospam@example.com (munk) — Tue, 05 Oct 2004 00:18:07 +0000

Another freebsd related sec advisory, only applicable to admins who have users who login to FreeBSD systems locally - ie on ttyv* local consoles.

CODE:

=============================================================================
FreeBSD-SA-04:15.syscons                                    Security Advisory
                                                         The FreeBSD Project

Topic:          Boundary checking errors in syscons

Category:       core
Module:         sys_dev_syscons
Announced:      2004-10-04
Credits:        Christer Oberg
Affects:        FreeBSD 5.x releases
Corrected:      2004-09-30 17:49:15 UTC (RELENG_5, 5.3-BETA6)
               2004-10-04 17:04:25 UTC (RELENG_5_2, 5.2.1-RELEASE-p11)
CVE Name:       CAN-2004-0919
FreeBSD only:   YES

For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit
<URL:http://www.freebsd.org/security/>.

I.   Background

syscons(4) is the default console driver for FreeBSD.  Using the
physical keyboard and screen, it provides multiple virtual terminals
which appear as if they were separate terminals.  One virtual terminal
is considered current and exclusively occupies the screen and the
keyboard; the other virtual terminals are placed in the background.

II.  Problem Description

The syscons CONS_SCRSHOT ioctl(2) does insufficient validation of
its input arguments.  In particular, negative coordinates or large
coordinates may cause unexpected behavior.

III. Impact

It may be possible to cause the CONS_SCRSHOT ioctl to return portions of
kernel memory.  Such memory might contain sensitive information, such as
portions of the file cache or terminal buffers.  This information might
be directly useful, or it might be leveraged to obtain elevated
privileges in some way.  For example, a terminal buffer might include a
user-entered password.

IV.  Workaround

There is no known workaround.  However, this bug is only exploitable
by users who have access to the physical console or can otherwise open
a /dev/ttyv* device node.

V.   Solution

Perform one of the following:

1) Upgrade your vulnerable system to the RELENG_5_2 security branch
dated after the correction date.

2) To patch your present system:

The following patches have been verified to apply to FreeBSD 5.2
systems.

a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.

# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:15/syscons.patch
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:15/syscons.patch.asc

b) Apply the patch.

# cd /usr/src
# patch < /path/to/patch

c) Recompile your kernel as described in
<URL:http://www.freebsd.org/handbook/kernelconfig.html> and reboot the
system.

VI.  Correction details

The following list contains the revision numbers of each file that was
corrected in FreeBSD.

Branch                                                           Revision
Path
- -------------------------------------------------------------------------
RELENG_5_2
src/UPDATING                                                 1.282.2.19
src/sys/conf/newvers.sh                                       1.56.2.18
src/sys/dev/syscons/syscons.c                                 1.409.2.1
- -------------------------------------------------------------------------

VII. References

<URL:http://cvsweb.freebsd.org/src/sys/dev/syscons/syscons.c.diff?r1=1.428&r2=1.429>

FreeBSD Security Advisory - Various CVS Server Related Vulnerabilities

nospam@example.com (munk) — Mon, 20 Sep 2004 16:19:31 +0000

I. Background

The Concurrent Versions System (CVS) is a version control system. It
may be used to access a repository locally, or to access a `remote
repository' using a number of different methods. When accessing a
remote repository, the target machine runs the CVS server to fulfill
client requests.

II. Problem Description

A number of vulnerabilities were discovered in CVS by Stefan Esser,
Sebastian Krahmer, and Derek Price.

. Insufficient input validation while processing "Entry" lines.
(CAN-2004-0414)

. A double-free resulting from erroneous state handling while
processing "Argumentx" commands. (CAN-2004-0416)

. Integer overflow while processing "Max-dotdot" commands.
(CAN-2004-0417)

. Erroneous handling of empty entries handled while processing
"Notify" commands. (CAN-2004-0418)

. A format string bug while processing CVS wrappers.

. Single-byte buffer underflows while processing configuration files
from CVSROOT.

. Various other integer overflows.

Additionally, iDEFENSE reports an undocumented command-line flag used
in debugging does not perform input validation on the given path
names.

III. Impact

CVS servers ("cvs server" or :pserver: modes) are affected by these
vulnerabilities. They vary in impact but include information disclosure
(the iDEFENSE-reported bug), denial-of-service (CAN-2004-0414,
CAN-2004-0416, CAN-2004-0417 and other bugs), or possibly arbitrary code
execution (CAN-2004-0418). In very special situations where the
attacker may somehow influence the contents of CVS configuration files
in CVSROOT, additional attacks may be possible.

See the extended article for the complete advisory.

Continue reading "FreeBSD Security Advisory - Various CVS Server Related Vulnerabilities"

Using mod_security to Block Serendipity Weblog / Blog Comment Spam

nospam@example.com (munk) — Fri, 03 Sep 2004 06:53:17 +0000

Have been seeing quite a bit of comment spam recently on this weblog, mainly pimping online pharmacies. Needless to say this is not wanted.

After the fourth lot of spam in not that many days I've added a few lines to the mod_security section in my httpd.conf file to stop apache from allowing access if the POST payload contains certain keywords:

CODE:

SecFilterSelective POST_PAYLOAD "BLOCKED KEYWORDS GO HERE!!!"

You get the gist, adding the keywords would freeze me out so won't bother with that :P

Before I considered mod_security though I was wondering how a spamassassin plugin might work with Serendipity - a plugin that would forward comments to a spamd daemon for spam checking before accepting the comment. Not too sure how spamd handles data that doesn't contain mail headers, I guess it should still parse it ok and return a score. No doubt this won't get pursued any further seeing as this mod_security fix should do the trick.

Attempts To Exploit My_ eGallery Vulnerability Target Random Sites

nospam@example.com (munk) — Thu, 26 Aug 2004 06:21:27 +0000

This is by no means a new attempt to exploit a vulnerability in a PHP web application, but since I started using snort as a full time intrusion detection system I've picked up countless attempts to exploit a vulnerability in an online PHP photo gallery called My_ eGallery. The annoying thing about this is that I've never had this gallery system installed on any of the sites I maintain - particularly the one that keeps getting hit - but they continue to try their exploits. Read on for more...
Continue reading "Attempts To Exploit My_ eGallery Vulnerability Target Random Sites"

Script Kiddies Redirected to NSA Kiddies site

nospam@example.com (munk) — Thu, 26 Aug 2004 06:04:02 +0000

Ok, I'm really bored now. Some morons have been trying to exploit a hole in an online PHP gallery system called E_Gallery for weeks now. The thing is I don't have and never have had E_Gallery on my system - at least not in the location they're trying to 'exploit'.

This really pisses me off, why can't people bother to check whether the thing they're trying to exploit actually exists on the system they're trying to exploit before wasting bandwidth trying to exploit it??? Bloody idiot script kiddies.

Enough's enough, I've just set up this .htaccess file now to redirect them to the NSA kiddies page, let them try and crack something worth cracking:

CODE:

RewriteEngine On
RewriteRule ^modules/my_ egallery/public/displayCategory.php \
http://www.nsa.gov/kids/intro.htm

I'll write something up about the actual exploit attempts in a separate article.

UPDATE:
Ok this was not a good idea, I'm redirecting hits to the URI to somewhere more interesting (like the location of the backdoor servers they're trying to install in the first place :P).

Microsoft Slow To Release Security Fixes

nospam@example.com (munk) — Thu, 12 Feb 2004 10:26:41 +0000

Microsoft has yet again been savaged for dragging it's heels in fixing critical security issues with it's OS. In particular the security group Eeye has a list of several pending security fixes which it has made known to Microsft a long time ago, but as yet have not been addressed with relevant patches.

The list is very scary for Microsoft users with most of the critical security issues submitted by Eeye being around 6 months old! Appalling given that people actually *pay* M$ for this software.

</M$ bashing>