Category Archives: Security

T-COM: DNS-Umstellung ohne Ankündigung

Die deutsche Telekom oder T-Com oder T-Online oder T-DSL Business
Irgend ein T-* hat für Ihre Kunden heute nachmittag mal eben schnell die DNS-Server gewechselt – selbstverständlich ohne jemanden vorher zu informieren..

Besonders aufgefallen ist dies bei div. T-DSL Business Kunden. Auf einmal war kein surfen mehr möglich, Mails konnten nicht mehr (über DNS) zugestellt werden, etc.. Stattdessen erhielt man folgende Meldung:

Hinweis zur Abschaltung von DNS-Servern
Wie alle Systeme im Internet müssen auch Server ständig aktualisiert und den Erfordernissen angepasst werden. Der von Ihnen genutzte DNS-Server wird durch leistungsfähigere Systeme ersetzt und steht deshalb nicht mehr zur Verfügung. Normalerweise werden Ihrem Computer / Router die DNS-Server automatisch zugewiesen, so dass die Abschaltung alter DNS-Server keine Auswirkung für Ihr System hat.
....
Überprüfen Sie bitte, ob im Router ein DNS-Server fest eingetragen
wurde. Entfernen Sie ggf. den Eintrag.


Wirklich informativ für Systeme, die den DNS-Server nicht dynamisch beziehen können. Fast lustig ist, dass dies eben hauptsächlich “Business-Kunden” betraf, von denen viele den DNS-Server fest im System hinterlegt haben…

Vielen Dank an atelier89.de/users/dirk – hier wurde man schliesslich doch noch fündig, nachdem die Hotline ausschliesslich auf google verweisen konnte: “suchen Sie mal bei google – da werden Sie das schon finden”.
Wow – das war mal wieder Service .. Danke T-Com :-/

PS:
Die DNS-Server werden anscheinend nach Standort zugewiesen, z.B.:
217.237.148.102 / n-lb-a01.isp.t-ipnet.de – Nuernberg
217.237.151.115 / m-lb-a01.isp.t-ipnet.de – Muenchen


PPS:
Die Server sind nur aus den T-Netzen erreichbar; Anfragen aus anderen IP-Bereichen werden abgelehnt.

German government forbids security tools

Maybe only interesting for german readers and security specialists.
The german government accepted a law that forbids the usage of programs that can be used by hackers and crackers in illegal activities. What they obviously forgot is the simple fact, that you have to use some of these programs to prevent your system from being hijacked. Or what is more probably:
People without any technical knowledge decided once again what is good for us.
Thank you b**ches!

What the CCC thinks about that (german)
heise Security (german)

xt:Commerce & suPHP

After installing suPHP a few days ago, I had the first problem with a xt:Commerce installation. That’s what happened on a SuSE 10.0 system:

When trying to access the pages, it stayed blank and there were some wierd errors in the apache logfile:
[Mon Apr 02 16:44:48 2007] [error] [client x.x.x.x] PHP Fatal error: %v%v() [<a href='function.require'>function.require</a>]: Failed opening required 'DIR_WS_INCLUDESfilenames.php' (include_path='/usr/share/php5') in /path/to/user/html/includes/application_top.php on line 57

Reason was found quite quick:
The include path only had the default path and didn’t include the webroots any longer : (

Solution: change config in /etc/php5/cli/php.ini .
From:
include_path = "/usr/share/php5"
To:
include_path = ".:/usr/share/php5"

. = Homedir of webroot
: = next path

Installation of suPHP using Apache2 & PHP5

suPHP is a nice tool for executing PHP scripts with the permissions of their owners. It’s comparable to suexec (which is for perl scripts). When using this tool, you don’t need SafeMode any longer, etc…

Tested on: SuSE 10.0, openSuSE 10.1
Prerequisites: php5-fastcgi, autoconf, gcc

in openSuSE 10.1, I had to (soft)link some files:
ln -s /usr/include/apr-1/* /usr/include/apache2

configure in openSuSE 10.1:
./configure --with-apxs=/usr/sbin/apxs2 --with-php=/usr/bin/php5 \
--with-logfile=/var/log/apache2/suphp.log --with-min-uid=30 \
--with-min-gid=30 --with-apache-user=wwwrun \
--with-apr=/usr/bin/apr-1-config --with-setid-mode=owner \
--prefix=/usr --sysconfdir=/etc


configure in SuSE 10.0:
./configure --with-apxs=/usr/sbin/apxs2 --with-php=/usr/bin/php5 \
--with-logfile=/var/log/apache2/suphp.log --with-min-uid=30 \
--with-min -gid=30 --with-apache-user=wwwrun \
--with-apr=/usr/bin/apr-config --with-setid-mode=owner \
--prefix=/usr --sysconfdir=/etc


After that, usual way:
make; make install

Check your configuration at /etc/suphp.conf. For me, it looks someway like this:
[global]
logfile=/var/log/apache2/suphp.log
loglevel=info
webserver_user=wwwrun
docroot=/srv/www/htdocs
allow_file_group_writeable=false
allow_file_others_writeable=false
allow_directory_group_writeable=false
allow_directory_others_writeable=false
check_vhost_docroot=false
errors_to_browser=false
env_path=/bin:/usr/bin
umask=0022
min_uid=30
min_gid=30
;
[handlers]
;Handler for php-scripts
x-httpd-php=php:/srv/www/cgi-bin/php5
;Handler for CGI-scripts
x-suphp-cgi=execute:!self


Add suPHP module to your apache config (/etc/sysconfig/apache2):
APACHE_MODULES="access .... php5 suphp"

Create a new file to tell apache to use suPHP:
/etc/apache2/httpd.conf.local
<Directory "/srv/www/htdocs">
php_admin_value engine off
suPHP_Engine on
AddHandler x-httpd-php .php .php3 .php4 .php5
suPHP_AddHandler x-httpd-php
</Directory>


Include that in your apache configuration (/etc/sysconfig/apache2):
APACHE_CONF_INCLUDE_FILES="httpd.conf.local"

After restarting apache, it should be done ; )

exim / implementing greylisting without db

I had greylisting running for a while with a little perl script, that only worked with ip-addresses. As spam is growing an growing, I wanted to use the whole triplet (ip/sender/recipient) for the filter.

As I did not want to use a database backend, the decision led to greylistd – an easy configurable daemon. I needed the packages for (open)SuSE, that can be found in openSuSE’s software repository.

After installing it and checking the basics at /etc/greylistd/config, you have to add a little code to your acls in exim.conf, i.e.:

defer message = greylisted $sender_host_address. please try again later
condition = ${readsocket{/var/run/greylistd/socket}\
{--grey $sender_host_address $sender_address $local_part@$domain} {5s}{}{false}}


That was all I had to do to get it working. It’s advisable to add some hosts, that are known for problems with greylisting, not to be checked. Therefor you have to extend your acl:

defer message = greylisted $sender_host_address. please try again later
!hosts = : ${if exists {/etc/greylistd/whitelist-hosts}\
{/etc/greylistd/whitelist-hosts}{}} : \
${if exists {/var/lib/greylistd/whitelist-hosts}\
{/var/lib/greylistd/whitelist-hosts}{}}
condition = ${readsocket{/var/run/greylistd/socket}\
{--grey $sender_host_address $sender_address $local_part@$domain} {5s}{}{false}}


Many thanks for the documentations from Arne Schirmacher and Ben Charlton.

PAM-Authentication & MySQL (v5) / b1gMail

Enviroment:

  • SuSE Linux 10.1
    • pam-0.99.3.0-29.3, pam-modules-10.1-7
    • postfix-2.2.9-10
    • mysql-5.0.18-20.8, mysql-client-5.0.18-16

I was trying to implement SASL-authentication via PAM (which is using a mysql-backend) in a postfix installation.
Output from maillog:

postfix/smtpd: warning: SASL authentication failure: Password verification failed
postfix/smtpd: warning: [x.x.x.x]: SASL PLAIN authentication failed


Checking the syslog:

saslauthd: pam_b1gmail: cannot connect to mysql database
(Access denied for user 'xx'@'localhost' (using password: YES))
saslauthd: DEBUG: auth_pam: pam_authenticate failed: Permission denied
saslauthd: do_auth : auth failure: [user=xx] [service=smtp]
[realm=domain.tld] [mech=pam] [reason=PAM auth error]


Reason:
The PAM module is using a deprecated way to connect to the MySQL-DB.

Solution:
Set the MySQL-Password to OLD_PASSWORD:

SET PASSWORD FOR user'@'localhost' = OLD_PASSWORD('password');

Pimp my spamassassin / FuzzyOCR

Today I’ve implemented a new tool in our anti-spam system:
FuzzyOCR (Dec 13, 2007: URL contains ads only now)

It’s an OCR software used as a plugin for SpamAssassin.
OCR means “optical character recognition” and describes the procedure to recognize characters and words from images. It’s quite useful when you try to catch so-called “Image Spam”, which uses normal text where the real message is hidden in images (inline gifs, etc.)

The results are quite good and I’m confident : )

Additionally to the packages described on the homepage of FuzzyOCR you’ll need another piece of software (at least with openSuSE 10.0): giflib-progs-4.1.3-7.i586.rpm
Continue reading Pimp my spamassassin / FuzzyOCR

Nagios 2.x Plugin check_mrtgtraf buggy?

affected:

nagios plugins 1.4.3
nagios plugins 1.4.5
nagios plugins 1.4.6 (Feb, 05 – 2007)

I was trying to implement the check_mrtgtraf plugin for nagios.
A test run in bash using the command
./check_mrtgtraf -F /my/mrtg/log/server.log -w "196608,196608" -c "235929,235929"
resulted in the following “error”:
Traffic UNKNOWN – Avg. In = 2.3 KB/s, Avg. Out = 2.3 KB/s ..

In my constellation the result should be “Traffic OK”, because the limit of 0,19 MByte/s (1,5 MBit) has not been reached. On http://archive.netbsd.se I found a hint from Israel Brewster that fixed it:

From: Israel Brewster
Date: 2007-01-26 17:54:06

I’m pretty sure this is a bug. I ran into the same thing, but was able to fix it easily enough in the source code. Looking at the original code for this plugin, you can find the section where it sets the output state, something like:

if (incoming_rate > incoming_critical_threshold
|| outgoing_rate >
outgoing_critical_threshold) {
result = STATE_CRITICAL;
}
else if (incoming_rate > incoming_warning_threshold
|| outgoing_rate >
outgoing_warning_threshold) {
result = STATE_WARNING;
}

This may not be exact, as I have modified the code somewhat, but I think it is pretty close, if not. At any rate, what you’ll notice is that while the result is set to STATE_CRITICAL or STATE_WARNING, depending on the circumstances, it is never set to STATE_OK (as you mentioned in your original message), which means that it remains in its STATE_UNKNOWN default state if the traffic is OK, to fix it, all you need to do is add the two lines:

else
result = STATE_OK;

Immediately following the closing bracket on the code block above, and recompile. At least, that fixed it for me. I have plugins version 1.4.3, I don’t know if this issue has been fixed in a newer version of the plugins or not (current is 1.4.5)

That workaround did it for me, too.
You can download my patched version of the c source right here: check_mrtgtraf.c – fixed version