IPv6 talk at BNC 2011

A couple of weeks ago I was at the Belnet Network Conference 2011 and there were a couple of interesting talks but I want to write in particular about some advise that was given during the talk of Andy Davidson about implementing IPv6.

This was his advise:

1. Buy only IPv6 enabled hardware and software. Since quite a number of people had to do this a kind of template called the Ripe501 template http://www.ripe.net/ripe/docs/ripe-501
came into existence.

I personally think that the remark of paying attention to software too is quite correct. Thinking about hardware is very normal, but one has too take into account you have to manage the hardware.

2. Make sure you have connectivity.
This is pretty obvious, if you want to have a connection to the Internet, you need connectivity.

3. Make sure you train your staff.
It seems normal to the outside world that IT people have knowledge about IT stuff so you have to train them.

4. Do trails
Ok, it seems dumb to put a car on the market before doing crash tests but the same thing applies to you IT infrastructure. If you don't make sure you have done your tests you will regret it.

5. Take it to the users
Once you've done your tests, take it to your users. Some trouble might come up but it should be minimal.

6. Dual stack some of your services.

7. Dual stack all of your services.

Privacy is not an option

Yesterday there was an ISSA-BE event about IT and privacy. Marc Vael gave a very good presentation on what privacy is and what laws do apply.

The first thing to know is that the European directive, 1995/46/EC, is according to Marc one of the better ones on this planet. Each European country made it part of its law but some countries like Germany and Italy are more severe than others. Another interesting fact is that the directive applies to the EEA, the European Economic Area.

I asked Marc the question how to handle these differences as an organization. The best way to handle this is creating a baseline valid for all members of the EEA and make sure that you add the specific requirements for the more severe states.

An interesting fact is that if you for instance visit a website in South-Africa, it is the South-African law that applies to the personal data. The reasoning is that the law applies where the company owning the website is located. This creates very interesting situations, Google is a global company with sites all over the EEA but if you log in over their web servers in the USA, it would be the American law that applies.

One of the nice remarks that the presentor made was that personal information and sensitive data are not the same thing.

Since we were talking about dealing with international privacy we discussed the US safe harbor frameworks.

Mounting XFS

Somebody I know recently had troubles with his NAS and needed to turn in the NAS device but wanted to recover his data. According to the information he was able to gather it was an XFS file system.

He had little to no linux knowledge but to recover he made a Ubuntu machine and asked my help to mount his drive. I didn't have any previous experience with XFS so here is how we did it:

The device showed up in the system as sdb3.

1. sudo mkdir /media/nadisk
2. sudo mount -o inode64 -t xfs /dev/sdb3 /media/nadisk

After this he was able to get his data back and bring his NAS device back to the store :)

Symantec Endpoint Protection 11.0.6 MR2 and the internal database

I had the case where I did an implementation of SEP 11.0.6 MR2 and the internal database grew too big. Thanks to my pervious life as a DBA I was able to interprete the logs and discovered a couple of problems:



1. The cache size for the database was set to 65536K as well for the lower as upper limit.

The cache size for a database varies on the size, but there is no direct parameter where you can influence this.



2. No unique index or primary key for table "a_table_in_the_database" in database "sem5".



3. Performance warning: Database file "...\Program Files\Symantec\Symantec Endpoint Protection Manager\db\sem5.db" consists of 9468 disk fragments.



Just for info, the internal database of Symantec is a Sybase database, so it is very similar to MS SQL 2000.


I openend a case at Symantec Support and after the classic "gather the logs" round we finally concentrated on the database.


Step zero was of course run dbvalidator.cmd ("...\Program Files\Symantec\Symantec Endpoint Protection Manager\Tools") and this showed that the database was still ok to use.


The first step was making a backup with the "Backup and Restore" tool that comes with the installation. The next step was to open "services.msc" and stop the Symantec Endpoint protection Manager services and stop/start the Symantec database service. The database backup was written as a zip file to "...\Program Files\Symantec\Symantec Endpoint Protection Manager\data\backup\"


To shrink the database I needed to execute the following command:

'...\Program Files\Symantec\Symantec Endpoint Protection Manager\ASA\Win32\dbunload -c "uid=dba;pwd=your_install_db_pwd" -ar '. The -c specifies the connection parameters and the -ar means rebuild and replace.


I asked the engineer if the shrink tool is possible to use on the MS SQL database but according to the engineer this was not the case.

The database was back to a normal size and the server disk was happy again.

Error 404 ... we are watching you.

The other day I helped out with the coding of a php page for error 404 handling in a Joomla framework. The idea was that when a 404 is generated the event would be logged for analysis.

The results where pretty boring, GoogleBot who scanned the website for pages that didn't exist anymore ... so nothing special to report until I got this one:

Page:/[a path on the server]/index.php
Browser:Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de;rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 Request Method: GET Request
Request URI: /en/components/com_oziogallery2/imagin/scripts_ralcr/filesystem/writeToFile.php

The remote IP addresses where 188.61.137.55 and 195.191.54.46. A lookup on MaxMind Geoip shows us that 188.61.137.55 is an IP address in Aarau, Switzerland (ISP: Bluewin) and 195.191.54.46 is an IP in Latvia (ISP:Sia Venditore).

It was clear that this scan was part of some scanner but why the website on which my code is running is targetted is still unclear to me. The ozio gallery2 was never installed on this joomla installation.

A google search for the websites with a url containing the string "/en/components/com_oziogallery2" gave me a list of 13.500 possible exploitable sites. A look at exploit db gave us immediately an insight what the attacker was up to.

So my lessons learned from this is :

1. Modify the error 404 page in any framework so you can find interesting data.

2. I have proof that any website is scanned and there has not to be any particular reason. This was an eye opener to the person who asked me to code the page.

Educating the public ... but don't tell them the wrong info

The Belgian media is covering the Wikileaks story like in every other country. One of the things on our national television news website that caught my attention was the spectacular title "IT Security Expert: Cyber war is actually very simple".

You can't hear the question to the IT security specialist but what he basically explains is a DDoS attack. What he explains is correct but I am quite disappointed in the journalist. I personally think that it is a good thing to make the public aware of what is happening in the world and how attacks are carried out but choosing this title was over the top.

Fun with SSL

I am working on a project where mutual authentication with SSL has to be done between a Apache mod_proxy and some proxy server at a third party.

I personally did not designed or built the system and after doing an upgrade of httpd one of the instances did not restart when I told it to. It went down and said SSL is already loaded ... fail.

The idea of this server is to listen to tcp/443 and based on the URI redirect to a virtual host running on a specific port. These virtual hosts do some mod_rewrite magic and inject the SSL certificate and then connect to the third party. According to the project manager this can only be done with mod_proxy and no other proxy would allow you to do this.

I tried to restart the other virtual hosts and they went down and up without any problems. So it was just the httpd listening on port 443 that was not coming up.

Since Google is your friend when you got an error message that basically just tells you "sorry, SSL is already in use". I looked at a couple of forum posts and it was pretty clear immediately that it had something to do with the http.conf file.

In the httpd.conf file there was an include directive to load all .conf files from a conf.d directory. So analyzing them one by one I figured out that one of them contained the instructions to load the mod_ssl.so and of course there was the mod_ssl configuration file which loads mod_ssl.so as well.

Once I commented out the lines in the other file everything was back up and running.