SERVER: /var/log/daemon.log

Mar 28 15:38:02 localhost openvpn[31788]: Connection reset, inetd/xinetd exit [-1]

SENSOR: /var/log/daemon.log

Mar 28 15:36:34 Knoppix openvpn[6079]: VERIFY ERROR: depth=1, error=certificate is not yet valid:
Mar 28 15:36:34 Knoppix openvpn[6079]: TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL 
    routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Mar 28 15:36:34 Knoppix openvpn[6079]: TLS Error: TLS object -> incoming plaintext read error
Mar 28 15:36:34 Knoppix openvpn[6079]: TLS Error: TLS handshake failed
Mar 28 15:36:34 Knoppix openvpn[6079]: Fatal TLS error (check_tls_errors_co), restarting

This usually means that the date is not set correctly on the sensor. The date on the sensor is earlier that the current date and this will make the server think the sensor certificate is not yet valid. You will have to manually set the correct date in the BIOS of the sensor machine or use something like ntpdate.

[ crit debug fixme ] Connection to database 'idsserver' failed.
[ crit debug fixme ] FATAL:  IDENT authentication failed for user "nepenthes"

The authentication with postgresql is best set to an md5 check instead of an ident check. Edit the postgresql access configuration file: /etc/postgresql/pg_hba.conf

host    idsserver         nepenthes         127.0.0.1         255.255.255.255  md5
host    idsserver         idslog            127.0.0.1         255.255.255.255  md5

This is how your pg_hba.conf should be looking like. Replace the IP address and netmask accordingly to your setup.

[03042006 14:35:29 crit debug fixme] Connection to database 'idsserver' failed.
[03042006 14:35:29 crit debug fixme] FATAL:  Password authentication failed for user "nepenthes"

This means that the username and password combination you have configured in the log-surfnet.conf file is not correct.

[03042006 14:39:11 crit debug fixme] could not connect to server: 
        Is the server running on host "192.168.1.10" and accepting
        TCP/IP connections on port 5432?
[03042006 14:39:11 crit mgr module] Loading Module lib/nepenthes/logsurfnet.so failed, Module->Init() returned false
[03042006 14:39:11 crit mgr module] ERROR LOADING MODULE lib/nepenthes/logsurfnet.so: SHUTTING DOWN

This means that the server that is configured in the log-surfnet.conf file is not correct or that the server hosting the database does not accept tcp connections to the database. Either check log-surfnet.conf on the tunnel server or postgresql.conf on the database server.

DETAIL:  Key (sensorid)=(-1) is not present in table "sensors".

or

[26012006 15:51:06 crit debug fixme] PGexec() failed #2 ERROR:  insert or update on table "attacks" violates 
    foreign key constraint "foreign_sensor"

This means that there are no sensors present in the sensors table. To fix this, add a sensor to the sensors table with localip, remoteip and tapip the IP address where Nepenthes is listening on. This assumes that you are running a single sensor setup with Nepenthes running on 1 box.

First of all we will need to change to the user that is used to generate the keys. This is the user that is running apache(-ssl).

su www-data

In this example we will use the Debian default apache user. Next we will have to start the key generation.

cd /opt/surfnetids/genkeys/
./generate_certificate.sh randomsensor

This will generate the .key file. The next step is signing the csr file.

./sign_certificate.sh randomsensor

Performing these steps manually is good when debugging the key generation process.

This problem can have many causes. One of them might be a difference in the ca.crt information and the sensor.csr information. Startup the key generation debugging process. When running the sign_certificate.sh script, the following error occurs:

The countryName field needed to be the same in the
CA certificate (Nl) and the request (NL)

This means that the sensor.csr is generated with different values then the ca.crt.

The password that the sensor uses to do it's updates is stored on the sensor in the wgetrc file and on the server in the /opt/surfnetids/updates/.htpasswd file. To change the password you set at the installation, use the following command:

htpasswd -c -m /opt/surfnetids/.htpasswd idssensor

The tunnel server certificate can't be loaded. The following error shows up in the daemon.log.

openvpn[4062]: Cannot load certificate file /opt/surfnetids/serverkeys/tunserver.crt ...

This means that either you have no server certificate or the wrong server certificate is specified in your openvpn server.conf. /etc/surfnetids/server.conf

cert /opt/surfnetids/serverkeys/tunserver.crt
key /opt/surfnetids/serverkeys/tunserver.key

These 2 lines give the location of your tunnel server certificate and key to openvpn. Make sure these files exists or else replace them by the correct values.

Nepenthes is not logging any attacks with a source IP address from the sensor network. This is because Nepenthes finds a source MAC address and tries to enter it into the database. If the src_mac column is not present in the attacks table, this query obviously fails. The following error is generated by Nepenthes:

[12092006 14:02:30 crit debug fixme] PGexec() failed #2 ERROR:  column "src_mac" of relation "attacks" does not exist

or this error:

[ crit module ] Query failure. ...snip... 
Error 'PGRES_FATAL_ERROR' ('ERROR:  column "src_mac" of relation "attacks" does not exist ...snip...

This problem can be fixed by adding the column src_mac to the attacks table. See below SQL query on how to add the column to your database.

ALTER TABLE attacks ADD COLUMN src_mac macaddr

Nepenthes is not logging any attacks. The logs show a failed PGexec().

[12092006 14:02:30 crit debug fixme] PGexec() failed #2 ERROR:  duplicate key violates Unique-Constraint primary_attacks

This is due to a violation of the constraint that expects a unique ID for each attack that's logged. The cause of this is the attack_id_sequence that is somehow reset. Possible reason could be an upgrade from PostgreSQL 7.4 to 8.1. Solution: To fix this problem, check the highest id in the attacks table and reset the attacks_id_sequence to this value. Example: Let's say the highest ID in the attacks table is 32.

SELECT setval('attacks_id_seq', 32);

Nepenthes is shutting down right after starting with the following error messages:

[ crit handler event module ] Could not create sqlhandler for the postgres database connection
[ crit mgr module ] Module instance of "lib/nepenthes/logsurfnet.so" using configuration "etc/nepenthes/log-surfnet.conf" failed to initialize
[ crit mgr module ] ERROR LOADING MODULE lib/nepenthes/logsurfnet.so: SHUTTING DOWN

The cause of this error is a missing module called “sqlhandlerpostgres.so”. This module needs to be loaded before the logsurfnet.so module. To fix this problem edit the nepenthes.conf and add the sqlhandler line.

// SQL handler
    "sqlhandlerpostgres.so",        "",                             ""

// logging
    "logdownload.so",               "log-download.conf",            ""
//  "logirc.so",                    "log-irc.conf",                 ""  // needs configuration
    "logsurfnet.so",                "log-surfnet.conf",             ""  // needs configuration

Add the sqlhandlerpostgres.so module to the nepenthes.conf before loading the logsurfnet.so module.

This error occurs when the database connection settings haven't been configured yet in the SURFids configuration file.
Check out /etc/surfnetids/surfnetids-tn.conf for the database ($pgsql_*) settings.

[ spam module ] <in virtual bool nepenthes::SQLHandlerPostgres::handleTimeout()>
[ spam module ] <in void nepenthes::SQLHandlerPostgres::reconnect()>
[ debug spam fixme ] addDNS: Adding DNS 127.0.0.1 for ()
[ debug spam fixme ] DNS is ip 127.0.0.1 
[ spam module ] <in virtual bool nepenthes::SQLHandlerPostgres::dnsResolved(nepenthes::DNSResult*)>
[ spam module ] domain 127.0.0.1 has ip 127.0.0.1 
[ spam module ] <in virtual int32_t nepenthes::SQLHandlerPostgres::doRecv()>
[ crit module ] ERROR could not send SSL negotiation packet: Broken pipe

[ spam net mgr ] Socket -1 Socket POLL  (connect) 0.0.0.0:0 -> 0.0.0.0:0 is Dead
[ spam net mgr ] Socket -1 Socket POLL  (connect) 0.0.0.0:0 -> 0.0.0.0:0 is Dead

This is most likely due to a wrong postgresql lib dir include in the configuration. When configuring Nepenthes before make/make installing it, make sure you have the –with-postgre-lib switch set correctly. The location on a Debian system is usually /usr/lib/postgresql/ with subdirectories for the specific versions.

--with-postgre-lib=/usr/lib/postgresql/8.3/

Make sure the directory where the rrd databases are stored exists. The default directory is /var/lib/rrd/.

In some cases, port security on your switches might interrupt the correct setup of the VPN tunnels.

[02-06-2009 09:36:23] 24510 tcp-wrapper.pl unknown IP_OVERLOAD Multiple sensors (2) for 192.168.1.10. Refusing connection
[02-06-2009 09:36:23] 24510 tcp-wrapper.pl unknown SCRIPT_END

These log messages will appear in your /var/log/surfids.log (or webinterface syslog) when there are duplicate entries for 1 particular sensor in the sensor_details table. This typically should never happen. If this is the case, remove the duplicate entry and try to start your sensor again.

You can remove the duplicate sensor by either removing him manually from the database (sensor_details table) or by putting the faulty sensor on ignore.

Jun  3 06:23:26 surfids openvpn[23165]: openvpn_execve: external program may not be called due to setting of --script-security level

This log message means you are most likely running OpenVPN 2.1. Currently SURFids does not support OpenVPN 2.1 yet. You will have to downgrade OpenVPN to a 2.0 version.

2009-06-12 05:34:09,851 DEBUG us=850103 VERIFY OK: depth=1, /C=NL/ST=Utrecht/L=Utrecht/O=SURFnet/OU=SURFnet_IDS/CN=server/emailAddress=ids@surfnet.nl
2009-06-12 05:34:09,852 DEBUG us=850329 VERIFY OK: nsCertType=SERVER

2009-06-12 05:34:09,853 DEBUG us=850345 VERIFY X509NAME ERROR: /C=NL/ST=Utrecht/O=SURFnet/OU=SURFnet_IDS/CN=surfids3/emailAddress=ids@surfnet.nl, must be 192.168.2.11

2009-06-12 05:34:09,855 DEBUG us=850414 TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

This means that the tunserver.crt (or whatever name your server certificate has) has a wrong CN name. The CN name of the tunnel server certificate has to be the IP address or FQDN of the tunnel server. This is so that the connecting sensors can use the tls-remote setting of their configuration to verify that they are talking to the right server. If you have this error you will have to create a new tunserver.crt with the correct CN name. For now, the only way to do this is by reinstalling the tunnel server or doing it manually (if you know how).

Jun 16 11:08:43 surfids openvpn[30692]: OpenVPN 2.0.9 i486-pc-linux-gnu [SSL] [LZO] [EPOLL] built on Sep 20 2007
Jun 16 11:08:43 surfids openvpn[30692]: LZO compression initialized
Jun 16 11:08:43 surfids openvpn[30692]: Note: Cannot ioctl TUNSETIFF s5: Device or resource busy (errno=16)
Jun 16 11:08:43 surfids openvpn[30692]: Note: Attempting fallback to kernel 2.2 TUN/TAP interface
Jun 16 11:08:43 surfids openvpn[30692]: Cannot open TUN/TAP dev /dev/s5: No such file or directory (errno=2)
Jun 16 11:08:43 surfids openvpn[30692]: Exiting
Jun 16 11:08:46 surfids openvpn[30170]: Connection reset, inetd/xinetd exit [-1]

Seeing this error message in the syslog on your tunnel server could mean that there's a conflict with the iproute2 routing table names.

cat /etc/iproute2/rt_tables

This will show us the current configuration of your rt_tables file. There are a few values that are reserved and will cause some strange behavior when used for custom routing tables (like we do with the SURFids).

#
# reserved values
#
255     local
254     main
253     default
0       unspec
#
# local
#
#1      inr.ruhep

This is a clean, unused file. The numbers 0, 1, 253, 254 and 255 are reserved values which should not be used. If you have a line in there like this:

1       s1

This will be the cause of your problem. Rename the line to this:

1001    s1

When this message appears in the logs you probably have placed a remote sensor in the same network as the tunnel server. Due to the way we handle routing on incoming connections it is not possible to add a remote sensor in the tunnel server network. To fix this error message, simply put your sensor in a different network.

If you want to monitor the tunnel server network you could add the nepenthes server as a permanent sensor. For more information on how to do this, check out FAQ T28.

The SURFids web interface now supports the addition of so called permanent sensors. These sensors are not connected via the usual way (OpenVPN), but are rather static machines logging to the SURFids database.
You can transform your tunnel server to such a sensor by using the supplied localsensor.pl script. This script is located at:

• /opt/surfnetids/tntools/localsensor.pl
• /opt/surfnetids/logtools/localsensor.pl

#:/opt/surfnetids/tntools# ./localsensor.pl
Usage: ./localsensor.pl -i <interface name> -s <sensor name> -o <organisation name>
Usage: ./localsensor.pl -p <ip address> -m <mac address> -s <sensor name> -o <organisation name>

   -i <interface name>                   Interface that has to be added as a sensor
   -p <ip address>                       IP address of the sensor
   -m <mac address>                      MAC address of the sensor, defaults to 00:00:00:00:00:00
   -s <sensor name>                      Name of the sensor, defaults to Nepenthes
   -o <organisation name>                Organisation name, defaults to LOCAL
   -h                                    This help message

Example: ./localsensor.pl -i eth0 -s mySensor -o SURFnet
Example: ./localsensor.pl -p 192.168.10.12 -m 00:11:22:33:44:55 -s mySensor -o SURFnet

Adding a permanent local sensor is as easy as running the following command on the machine you want to add:

#:/opt/surfnetids/tntools# ./localsensor.pl -i eth0

If you don't want to add any machine which has the localsensor.pl script, you can specifiy which IP address it needs to add:

#:/opt/surfnetids/tntools# ./localsensor.pl -p 192.168.2.22

You can add some informational values that are mostly for cosmetics in the web interface:

• -m - The MAC address paired with the IP address you are adding. Will be shown on the sensor status and sensor details pages.
• -s - The sensor name you want to add, defaults to Nepenthes.
• -o - The domain/organisation this sensor should belong to. Defaults to LOCAL which should do fine.

The tls-remote setting in the OpenVPN configuration file of the sensor (/etc/surfids/openvpn.conf) is an added security setting. This setting checks if the remote server it's talking to is actually the server it says it is.

To configure this properly you will have to make sure the tls-remote setting on the sensor has the same value as the Common Name of your server certificate. To check this we can do the following:

#: openssl x509 -text -in /opt/surfnetids/serverkeys/tunserver.crt | grep Subject | grep CN

This command will output the following line (example):

Subject: C=NL, ST=Utrecht, O=SURFnet, OU=SURFids, CN=publicids.surfnet.nl/emailAddress=root@localhost

The Common Name here is the CN= part (publicids.surfnet.nl).

The symptom are syslog messages like this:

Sep 18 05:01:20 test dhclient: can't create /var/lib/dhcp3/s22.2.leases: Permission denied
Sep 18 05:01:20 test dhclient: execve (/opt/surfnetids/scripts/surfnetids-dhclient, ...): Permission denied
Sep 18 05:01:20 test dhclient: Bind socket to interface: No such device
Sep 18 05:01:20 test kernel: [1212381.467205] type=1503 audit(1253264480.412:22): operation="inode_permission" requested_mask="r::" denied_mask="r::" fsuid=0 name="/etc/surfnetids/dhclient.conf" pid=6694 profile="/sbin/dhclient3"

We think this is caused by something called AppArmor and is most likely the case if you are running Ubuntu (since it ships with Ubuntu). The cause of these messages are still unconfirmed, but we would like you to try turning AppArmor off and test again to see if the errors still appear.

To turn AppArmor off, do the following:

/etc/init.d/apparmor stop

Now test starting up your sensor again and see if you still get the error. Please report back to us if this fixes the problem as we haven't been able to test this ourselves yet.

When cert.php is called and this error appears you are probably still running php4 on the tunnel server. Make sure that Apache2 is running with php5 and restart Apache2.

If you get this line in your dionaea logs it means you need to up the open file limit on your system.

[26092010 16:15:07] util util.c:209-warning: could not open path /opt/surfnetids/binaries (Too many open files)

Open up /etc/security/limits.conf and add the following lines:

root             -       nofile          16000
*                -       nofile          16000

Now restart Dionaea and it should be fine.

This can be fixed by installing the libpq header files:

apt-get install libpq-dev

Symptoms of this will be a failure of the sensor to request a proper certificate and/or a crash of the sensor-manager while first starting the sensor.
A possible cause of this error is a cert.php file on the tunnel server with the wrong permissions. Make sure this file has 0644 permissions:

-rw-r--r-- 1 root root  7341 2011-02-03 14:02 cert.php

There are several reasons why your scripts can't connect to the database, but if you are getting messages about authentication failures, then it's usually the credentials that are wrong.
Some characters can give problems, so if you have a password with the following characters $ or @ you might need to enclose the password between single quotes (') instead of double quotes (”). If that does not work, you might even need to escape said characters.

Symptom (in your syslog/daemon/openvpn logfile):

Wed Oct 12 22:00:11 2011 us=406929 Assertion failed at socket.c:659

This seems to be caused by a bug in OpenVPN. More info here: Bugreport.

For now the solution seems to be to upgrade OpenVPN to 2.1.3-4 or higher.

Warning: pg_connect(): Unable to connect to PostgreSQL server: could not connect to server:  Is the 
server running on host "localhost" and accepting TCP/IP connections on port 5432? in
/opt/surfnetids/webinterface/include/connect.inc.php on line 7

This means that the webinterface cannot connect to the database. Check your Postgresql settings
/etc/postgresql/postgresql.conf

tcpip_socket = true
virtual_host = '192.168.1.10'

Check if the virtualhost address is correct and tcpip_socket is set to true.
/etc/postgresql/pg_hba.conf

host    idsserver         idslog               127.0.0.1         255.255.255.255  md5

Check this conf to allow connections based on md5 auth to localhost or the database host. If you're not running the database on the same server change 127.0.0.1 to the IP of the logging server. Add one for nepenthes too.

Warning: pg_connect(): Unable to connect to PostgreSQL server: FATAL: IDENT authentication failed 
for user "idslog" in /opt/surfnetids/webinterface/include/connect.inc.php on line 2

/etc/surfnetids/surfnetids-log.conf

# User info for the logging user in the postgresql database
$pgsql_pass = "password";
$pgsql_user = "idslog";

Make sure the correct password is set in this configuration file at pgsql_pass.

This means that your Apache is not configured to run on port 8080. The SURFnet IDS webinterface runs default on port 8080.
/etc/apache/httpd.conf

Listen 192.168.1.10:8080

Make sure the Listen directive in your httpd.conf is correctly configured.

This might be the result of some missing dependancies with your php installation. Make sure your php version supports the necessary stuff:

• GD
• FreeType
• PCRE - Perl Compatible Regular Expressions
• PostgreSQL(libpq)

This error occurs when the database connection settings haven't been configured yet in the SURF IDS configuration file.
Check out /etc/surfnetids/surfnetids-log.conf for the database ($pgsql_*) settings.

Warning: pg_connect() [function.pg-connect]: Unable to connect to PostgreSQL server: 
FATAL: no pg_hba.conf entry for host "192.168.10.2", user "idslog", database "idsserver", 
SSL off in /opt/surfnetids/include/connect.inc.php on line 15

Check your /etc/postgresql/8.1/main/pg_hba.conf if it is configured to allow connections from the host 192.168.10.2.

host    idsserver         idslog     192.168.10.2/32     md5
host    idsserver         nepenthes     192.168.10.2/32     md5
host    idsserver         pofuser     192.168.10.2/32     md5

This is usually caused by an alias in the main apache config for the images directory. Check the main config for such alias and comment it out.

    Alias /images/ /usr/share/images/

    <Directory /usr/share/images>
         Options MultiViews
         AllowOverride None
         Order allow,deny
         Allow from all
    </Directory>

Change to:

#    Alias /images/ /usr/share/images/

#    <Directory /usr/share/images>
#         Options MultiViews
#         AllowOverride None
#         Order allow,deny
#         Allow from all
#    </Directory>

Debugging the plotter is in fact done by debugging showplot.php. If your querystring to plotter.php looks like this:

plotter.php?strip_html_escape_tsselect=D&int_org=0&strip_html_escape_tsstart=&strip_html_escape_tsend=&sensorid%5B%5D=0&attack%5B%5D=99&int_interval=3600&int_type=1&submit=Show

Replace plotter.php with showphplot.php (or showopenflash.php) and you get access to the page that's actually generating the graph.
Now you should see some error messages. These should give you some info on what's wrong. If it's a bug, please report it to us in any way possible (see contact page).

To debug the Googlemap, you need to replace googlemap.php with googlemapdata.xml.php in the URL. This will give you access to the XML that is loading the attacks into the map. Any error messages here will give you some more info about what's happening.

Replace

http://logserver.nl/googlemap.php

with

http://logserver.nl/googlemapdata.xml.php

If it's a bug, please report it to us in any way possible (see contact page).

The error log file of apache2 gives the following error:

[Tue Jun 03 19:05:07 2008] [alert] [client 192.168.2.10] /opt/surfnetids/webinterface/.htaccess: Invalid command 'Auth_PG_host', perhaps misspelled or defined by a module not included in the server configuration

This probably means that the auth_pgsql module is not loaded by apache2. Make sure there's a auth_pgsql.load file in the /etc/apache2/mods-enabled/ directory. If this is not the case you can fix it for example with this command (adjust it to your own system specific paths):

cd /etc/apache2/mods-enabled/
a2enmod auth_pgsql
/etc/init.d/apache2 restart

The following error occurs when running the mailreporter.pl script.

class method send must have HOW... arguments
 at ./mailreporter.pl line 1140

This usually means that the sendmail program hasn't been installed (or configured) on the system. Install sendmail or change the method of sending in the mailreporter.pl script. The first method is preferred, the latter unsupported.

To install sendmail:

apt-get install sendmail

If sendmail is installed, then sendmail is most likely not configured correctly.

The mailreporter uses a perl module called Net::Abuse::Utils for looking up ASN info. You will need to install this module to make these reports work. You can do this with the use of CPAN.

cpan Net::Abuse::Utils

After having installed this module you can enable the reports in the logserver configuration file (/etc/surfnetids/surfnetids-log.conf).

# Enable/disable Cymru mails
# If this option is enabled you can create reports in the
# Cymru markup format:
#   <ASN>  | <IP>  | <time> <info> | <ASN description>
#
# Enabling this option requires you to install the following perl package:
#   Net::Abuse::Utils
# See the FAQ L13 for more info.
$c_enable_cymru = 1;

Set the option c_enable_cymru to 1.

NOTE: If you don't want or need the Cymru reports you can disable these in the logserver configuration file.

This usually means the pg_auth module for apache2 cannot connect to the database correctly. Usually this is due to wrong authentication info in the htaccess file.
Open up /opt/surfnetids/webinterface/.htaccess.

Auth_PG_host localhost
Auth_PG_port 5432
Auth_PG_user idslog
Auth_PG_pwd enter_database_pass_here

Change these lines according to the correct database info (this is the same as configured in /etc/surfnetids/surfnetids-log.conf).

[warn] [client 192.168.2.22] [mod_auth_pgsql.c] - missing configuration parameters

This usually means the pg_auth module for apache2 cannot connect to the database correctly. Usually this is due to wrong authentication info in the htaccess file.
Open up /opt/surfnetids/webinterface/.htaccess.

Auth_PG_host localhost
Auth_PG_port 5432
Auth_PG_user idslog
Auth_PG_pwd enter_database_pass_here

Change these lines according to the correct database info (this is the same as configured in /etc/surfnetids/surfnetids-log.conf).

The first and foremost reason would be the interference of SELinux. To check if this is the case, you can do the following:

/usr/sbin/getsebool -a | grep httpd_can_network_connect_db

If that boolean is set to “off” then you need to turn it to “on” by doing the following:

/usr/sbin/setsebool httpd_can_network_connect_db on

You can update the OUI information by running the following script on the tunnel server.

cd /opt/surfnetids/tntools/
./update_oui.pl

You will have to clear the ARP cache in the web interface as it only updates the OUI information when it adds the record to the database.

The mailreporter.pl script might not know where to find it's gpg key store. You can fix this by defining this yourself in the mailreporter.pl script (this will be fixed in the next release). Open the /opt/surfnetids/scripts/mailreporter.pl script and find the following line:

$gpg = new GnuPG();

Change this into:

$gpg = new GnuPG(homedir => '/root/.gnupg/');

Assuming your gpg keystore is located in /root/.gnupg/ ofcourse.

SERVER: /var/log/daemon.log

Mar 28 15:38:02 localhost openvpn[31788]: Connection reset, inetd/xinetd exit [-1]

SENSOR: /var/log/daemon.log

Mar 28 15:36:34 Knoppix openvpn[6079]: VERIFY ERROR: depth=1, error=certificate is not yet valid:
Mar 28 15:36:34 Knoppix openvpn[6079]: TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL 
    routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Mar 28 15:36:34 Knoppix openvpn[6079]: TLS Error: TLS object -> incoming plaintext read error
Mar 28 15:36:34 Knoppix openvpn[6079]: TLS Error: TLS handshake failed
Mar 28 15:36:34 Knoppix openvpn[6079]: Fatal TLS error (check_tls_errors_co), restarting

This usually means that the date is not set correctly on the sensor. The date on the sensor is earlier than the current date and this will make the server think the sensor certificate is not yet valid. You will have to manually set the correct date in the BIOS of the sensor machine or use something like ntpdate.

SERVER: /var/log/daemon.log

Mar 28 15:38:02 localhost openvpn[31788]: Connection reset, inetd/xinetd exit [-1]

SENSOR: /var/log/daemon.log

Mar 28 15:36:34 Knoppix openvpn[6079]: VERIFY ERROR: depth=1, error=certificate verify failed
Mar 28 15:36:34 Knoppix openvpn[6079]: TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL 
    routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Mar 28 15:36:34 Knoppix openvpn[6079]: TLS Error: TLS object -> incoming plaintext read error
Mar 28 15:36:34 Knoppix openvpn[6079]: TLS Error: TLS handshake failed
Mar 28 15:36:34 Knoppix openvpn[6079]: Fatal TLS error (check_tls_errors_co), restarting

This usually means that OpenVPN could not correctly verify the server's certificate according to it's client.conf settings. The tls-remote option in the client.conf needs to be the same as is shown in the tunserver.crt's subject. To check this do the following on the server:

openssl x509 -in /opt/surfnetids/serverkeys/tunserver.crt -text | grep "Subject:"

The result should be something like this:

        Subject: C=NL, ST=Utrecht, O=SURFnet, OU=SURFnet IDS, CN=idsserver.test.nl/emailAddress=ids@test.nl

In this case, the tls-remote option in client.conf on the sensor should be the same as the CN FQDN hostname.domain as shown in the subject of the tunserver.crt (idsserver.test.nl).

We encountered some problems with Layer 2 traffic from the tunnel server itself that reflects back in to the tunnel causing extra traffic. We resolved the problem by putting an iptables rule on the sensors startupscript.

iptables -A OUTPUT -p TCP -m physdev --physdev-out $tap --dport 1194 -j DROP

Where $tap is the tap device (usually tap0).

SERVER: /var/log/daemon.log

Mar 28 15:38:02 localhost openvpn[31788]: Connection reset, inetd/xinetd exit [-1]

SENSOR: /var/log/daemon.log

Aug 17 09:14:27 Knoppix openvpn[11200]: VERIFY ERROR: depth=1, error=self signed certificate in certificate chain: /C=NL/ST=Utrecht/L=Utrecht/O=coolio/OU=SURFnet_IDS/CN=server/emailAddress=foo@bar.com
Aug 17 09:14:27 Knoppix openvpn[11200]: TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Aug 17 09:14:27 Knoppix openvpn[11200]: TLS Error: TLS object -> incoming plaintext read error
Aug 17 09:14:27 Knoppix openvpn[11200]: TLS Error: TLS handshake failed
Aug 17 09:14:27 Knoppix openvpn[11200]: Fatal TLS error (check_tls_errors_co), restarting
Aug 17 09:14:27 Knoppix openvpn[11200]: SIGUSR1[soft,tls-error] received, process restarting

This could be the result of a mismatch in the ca.crt's you are using. The ca.crt on the sensor needs to be the same as the ca.crt on the server. So /usbstick/scripts/ca.crt needs to be the same as /opt/surfnetids/serverkeys/ca.crt.

This happens when the cert.php script cannot connect to the database correctly. Make sure your username, password and other database connection settings are configured correctly in /etc/surfnetids/surfnetids-tn.conf.
Contents of the downloaded certificate:

Not connected :

This problem is caused by VMWARE ESX not allowing interfaces to be put into promiscuous mode by default. Check out this link for more information on how to fix it:
VMWARE ESX support

This usually means the sensor has a problem bringing up the OpenVPN tunnel correctly. The cause of this is usually visible in the tunnel server logfile. So check the logfile on the server to see what the problem is.

This is usually caused by the event.d or inittab starting up multiple instances of the sensor-manager on the same tty. You can usually detect this when the menu is giving you different results than you would have expected when selecting a menu item. The screen will get distorted.

On Debian, check inittab file (/etc/inittab). Look for the following line:

1:2345:respawn:/usr/sbin/sensor-manager </dev/tty1 >/dev/tty1 2>&1 2>&1

Delete any duplicate lines.

On Ubuntu, check the event.d directory.

~# ls -lart /etc/event.d/ | grep tty1
-rw-r--r--   1 root root   306 2008-09-30 01:52 tty1

If you see any file that looks like it's a duplicate of the tty1 file (ie, the same file with a different name) and delete them.
Example files:

• tty1.save
• tty1.backup
• tty1.conf

The OpenVPN configuration file is located in the /etc/surfids/ directory along with the other important configuration files of the SURFids sensor.

To fix this warning you will need to lower your max_size a bit (roughly 15 Mb).

You will need to lower your max_size. Max_size cannot be larger than the size of the USB stick.

The interactive shell during the mkimage process is useful for checking how the eventual USB image will look like. You can browse the filesystem in the interactive shell to check if everything is setup correctly.
To enable to interactive shell you will need to edit /opt/usb_sensor/config/chroot. Find the following line:

LH_INTERACTIVE="disabled"

Change this to:

LH_INTERACTIVE="shell"

This will put you in an interactive shell during the mkimage process. To exit the shell either type “exit” or “logout”. The mkimage process will continue after that.

This warning shows up when the wrong GPG key is added to the chroot_sources directory. Check out /usb_sensor/config/chroot_sources/. For each repository you add, there needs to be a file with the .gpg extension containing the GPG key for that repository. Currently, the contents look like this:

-rw-r--r--  1 root root 1710 2009-01-23 16:10 surfids.chroot.gpg
-rw-r--r--  1 root root 1710 2009-01-23 16:10 surfids.binary.gpg
-rw-r--r--  1 root root   54 2009-09-07 14:14 surfids.binary
-rw-r--r--  1 root root   54 2009-09-07 14:14 surfids.chroot
-rw-r--r--  1 root root 1751 2009-10-26 08:15 live-snapshots.binary.gpg
-rw-r--r--  1 root root 1751 2009-10-26 10:55 live-snapshots.chroot.gpg
-rw-r--r--  1 root root   59 2009-10-27 13:17 live-snapshots.binary
-rw-r--r--  1 root root   59 2009-10-27 13:17 live-snapshots.chroot

You can find the GPG key for the Debian Live repository here.
You can find the GPG key for the SURFids repository here.

A VLAN sensor can currently only work when the machine has 2 physical network interfaces. This is a limitation of VLAN interfaces along with TAP devices. We are in the process of fixing this issue in a future release, but in the meantime you can use a USB network adapter to get around this problem. The only stable USB network adapter we tested with the sensor was the one from Apple found here.

To see what's on the image file of your USB you will need to mount the squashfs file. First put in the USB drive in your laptop and mount the DEBIAN_LIVE partition.

mkdir /mnt/squashfs
mkdir /media/DEBIAN_LIVE
mount /dev/sdb1 /media/DEBIAN_LIVE
mount /media/DEBIAN_LIVE/live/filesystem.squashfs /mnt/squashfs -t squashfs -o loop

Now you can browse your Debian Live image like any other filesystem. Just go to /mnt/squashfs/ and see what's in there. This will be the root of your Debian Live image.

NOTE: If the mount command does not work due to version mismatches, you can also try the following command.

apt-get install squasfs-tools
cp /media/DEBIAN_LIVE/live/filesystem.squashfs /tmp/
cd /tmp/
unsquashfs filesystem.squashfs
cd squasfs-root

To manually verify your certificate, use the following command:

openssl verify -CAfile /etc/surfids/ca.crt /etc/surfids/surfids.crt

This should tell you if any problems exist with your certificate.

 gcc -DHAVE_CONFIG_H -I. -Wall -I../include -I../include -D_GNU_SOURCE -DSYSCONFDIR=\"/opt/dionaea/etc/libnl\" -g -O2 -MT route/cls/cgroup.lo -MD -MP -MF route/cls/.deps/cgroup.Tpo -c route/cls/cgroup.c  -fPIC -DPIC -o route/cls/.libs/cgroup.o
 gcc -DHAVE_CONFIG_H -I. -Wall -I../include -I../include -D_GNU_SOURCE -DSYSCONFDIR=\"/opt/dionaea/etc/libnl\" -g -O2 -MT route/cls/cgroup.lo -MD -MP -MF route/cls/.deps/cgroup.Tpo -c route/cls/cgroup.c -o route/cls/cgroup.o >/dev/null 2>&1
bison -y -d  -o route/cls/ematch_syntax.c route/cls/ematch_syntax.y
route/cls/ematch_syntax.y:31.9-16: syntax error, unexpected identifier, expecting string
make[2]: *** [route/cls/ematch_syntax.c] Error 1
make[2]: Leaving directory `/opt/src/libnl/lib'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/opt/src/libnl/lib'
make: *** [all-recursive] Error 1

This error means you will have to update bison to the version from Debian testing. With the stable version of bison this won't compile properly.

You can pin the bison package by adding this to the /etc/apt/preferences file.

Package: *
Pin: release a=stable
Pin-Priority: 700

Package: bison
Pin: release a=testing
Pin-Priority: 800

In file included from /opt/dionaea/include/netlink/handlers.h:19,
                 from /opt/dionaea/include/netlink/netlink.h:32,
                 from module.c:38:
/opt/dionaea/include/netlink/netlink-kernel.h:9: error: redefinition of ‘struct sockaddr_nl’
/opt/dionaea/include/netlink/netlink-kernel.h:33: error: redefinition of ‘struct nlmsghdr’
/opt/dionaea/include/netlink/netlink-kernel.h:173: error: redefinition of ‘struct nlmsgerr’
/opt/dionaea/include/netlink/netlink-kernel.h:182: error: redefinition of ‘struct nl_pktinfo’
/opt/dionaea/include/netlink/netlink-kernel.h:229: error: redefinition of ‘struct nlattr’
make[3]: *** [module.lo] Error 1
make[3]: Leaving directory `/opt/src/dionaea/modules/nl'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/opt/src/dionaea/modules'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/opt/src/dionaea'
make: *** [all] Error 2

If you have this error you can fix it with the following command:

echo "#include <linux/netlink.h>" > /opt/dionaea/include/netlink/netlink-kernel.h

If you're seeing warnings like this in your Dionaea logfile it's most likely caused by Dionaea not being able to connect to the database.

[03082011 11:47:06] python module.c:999-warning: ClientCannotConnectError at <!repr>
[03082011 11:47:06] python module.c:1024-warning: /opt/dionaea/lib/python3.2/site-packages/postgresql/driver/pq3.py:480 in raise_client_error
[03082011 11:47:06] python module.c:1025-warning:        raise client_error
[03082011 11:47:06] python module.c:1024-warning: /opt/dionaea/lib/python3.2/site-packages/postgresql/driver/pq3.py:2545 in connect
[03082011 11:47:06] python module.c:1025-warning:        self.typio.raise_client_error(could_not_connect, creator = self, cause = exc)
[03082011 11:47:06] python module.c:1024-warning: /opt/dionaea/lib/python3.2/site-packages/postgresql/driver/pq3.py:3024 in connect
[03082011 11:47:06] python module.c:1025-warning:        c.connect()
[03082011 11:47:06] python module.c:1024-warning: /opt/dionaea/lib/python3.2/site-packages/postgresql/driver/__init__.py:14 in connect
[03082011 11:47:06] python module.c:1025-warning:        return default.connect(*args, **kw)
[03082011 11:47:06] python module.c:1024-warning: /opt/dionaea/lib/dionaea/python/dionaea/surfids.py:75 in connect
[03082011 11:47:06] python module.c:1025-warning:        port = g_dionaea.config()['modules']['python']['surfids']['port'])
[03082011 11:47:06] python module.c:1024-warning: /opt/dionaea/lib/dionaea/python/dionaea/surfids.py:66 in __init__
[03082011 11:47:06] python module.c:1025-warning:        self.connect()
[03082011 11:47:06] python module.c:1024-warning: /opt/dionaea/lib/dionaea/python/dionaea/ihandlers.py:91 in new
[03082011 11:47:06] python module.c:1025-warning:        g_handlers.append(dionaea.surfids.surfidshandler('*'))

Check if your database connection settings in the dionaea config file are set correctly.

If you get the following error while making Dionaea.

cc1: warnings being treated as errors
connection.c: In function ‘dtls_create_cookie’:
connection.c:3685: error: implicit declaration of function ‘HMAC’
make[2]: *** [dionaea-connection.o] Error 1
make[2]: Leaving directory `/var/dionaea/build/dionaea/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/var/dionaea/build/dionaea'
make: *** [all] Error 2

Open up dionaea/src/connection.c.

FIND:

        HMAC(EVP_sha1(),
                 (const void*) con->transport.dtls.type.client.parent->transport.dtls.type.server.cookie_secret, DTLS_COOKIE_SECRET_LENGTH,
                 (const unsigned char*) buffer, length,
                 hash, len);

REPLACE WITH:

        /*
        HMAC(EVP_sha1(),
                 (const void*) con->transport.dtls.type.client.parent->transport.dtls.type.server.cookie_secret, DTLS_COOKIE_SECRET_LENGTH,
                 (const unsigned char*) buffer, length,
                 hash, len);
        */

In the dionaea.log the following symptom:

[22122011 17:06:34] python module.c:999-warning: UndefinedFunctionError at postgresql.exceptions.UndefinedFunctionError('function surfids3_type_from_name(unknown) does not exist'

To fix this do the following query in your database:

CREATE FUNCTION surfids3_type_from_name(character varying) RETURNS integer
    AS $_$DECLARE
        p_name ALIAS FOR $1;
        p_type INTEGER;
BEGIN
        SELECT INTO p_type id FROM honeypots WHERE name = p_name;
        return p_type;
END$_$
    LANGUAGE plpgsql;