blog.johanv.org (Berichten over beveiliging)

Tax-on-Web, Fedora 15 en Firefox 4

Johan Vervloet — Sat, 25 Jun 2011 20:04:50 GMT

Eind juni, dringend tijd voor de belastingaangifte. En uiteraard liefst via tax on web, dan zijn er al een aantal dingen op voorhand ingevuld. Maar oei, probleem, je hebt een 64-bit installatie van Fedora 15 (met dus ook Firefox 4), en dat wordt niet ondersteund volgens eid.belgium.be.

Is het dan onmogelijk? Verre van. Is het moeilijk? Evenmin. Helaas vind je op internet weinig informatie over hoe je het aan de praat krijgt. Maar daar breng ik nu verandering in :-)

De software om je e-ID te gebruiken met Firefox, vind je bij google code: http://code.google.com/p/eid-mw/downloads/list

Klik daar de juiste rpm aan; in mijn geval was dat eid-mw-4.0.0-0.925.fc15.x86_64.rpm. De pakketinstaller downloadt en installeert automatisch de nodige dependency's. (Mogelijk moet je Firefox herstarten, want er wordt ook een Firefox-add-on geïnstalleerd.)

Dat was al de software-installatie. Nu er nog voor zorgen dat je Tax-on-Web ook kunt gebruiken met Firefox 4, want ze hebben op de Tax-on-Web-site een belachelijk javascriptje gezet, dat aanloggen met deze fijne browser tegen gaat. Hiervoor heb ik user agent switcher add-on geïnstalleerd.

Let op: als je in Firefox 4 de menubar hebt uitgeschakeld, dan ligt het niet direct voor de hand hoe je deze add-on kunt configureren. Door op F10 te drukken, tover je die menubar terug te voorschijn.

Via de menubar klik je door naar ‘Tools’, ‘Default User Agent’, ‘Edit User Agents’. Vervolgens klik je op ‘New‘ en ‘New User Agent’.

Als omschrijving kies je ‘Firefox 3’, en achter ‘User Agent’ vervang je ‘Firefox/4.0.1’ door Firefox/3.8 of iets dergelijks. Klik OK.

Tenslotte moeten we nog iets aanpassen in de Firefoxconfiguratie. Naar verluidt een securityprobleem introduceren. Maar het is blijkbaar nodig om Tax-on-Web te kunnen gebruiken.

Surf naar about:config, (klik de waarschuwing weg) en zoek naar de instelling ‘security.ssl.allow_unrestricted_renego_everywhere__temporarily_available_pref’. Dubbelklik die lijn, om de ‘false’ in ‘true’ te veranderen.

Nu zijn we er. Surf naar http://taxonweb.be, verander je user agent door in de menubar op ‘Tools’, ‘Default User agent’, ‘Firefox ’ te klikken, klik door naar ‘naar mijn aangifte’, en vervolgens kies je om aan te melden met je e-ID. Je krijgt nog een aantal securityvragen waarop je ‘Ja’ moet antwoorden, en tenslotte zul je je pincode moeten ingeven.

Hoera!

Met dank aan Franky Backeljauw en Bert Van De Poel om mee te helpen zoeken, en ook voor een zekere ‘sebva’, want via Google kwam ik op een bugreport van hem terecht, dat mij leidde naar de eid-mw-software.

Arch Linux with encrypted LVM on 2 physical volumes

Johan Vervloet — Fri, 10 Jun 2011 14:28:03 GMT

In this howto, I explain how I installed Arch Linux, with an encrypted LVM setup. The tricky part is that I have 2 physical volumes for my volume group, which required some hacking to get it working.

(I did all this on a virtual machine, as a proof of concept. I want to do something similar on my laptop, which already has an encrypted LVM system, and on which I want to install Arch beside the other installed OS'es.)

disclaimer: I am an Arch newbie. This is the first time a setup Arch, so I might explain things wrong. I've used LVM on other distributions though, and I have used encrypted LVM on Fedora (where the installer did al the work for me, without me completely understanding how it worked.)

Setting up the encrypted LVM system

Boot your machine from the installation iso, and use e.g. cfdisk to create the partitions.

My partitioning scheme looks like this:

  sda1  510 MB ext2 (boot)
  sda5 2048 MB Linux LVM
  sda6 6029 MB Linux LVM

The boot partition cannot be inside LVM, and cannot be encrypted either, because it should be accessable by grub. All other file systems will be on logical LVM volumes, which will be in one volume group. I set this up like this:

  modprobe dm-mod
   
  cryptsetup -y -c aes-xts-plain -s 512 luksFormat /dev/sda5
  cryptsetup -y -c aes-xts-plain -s 512 luksFormat /dev/sda6
   
  cryptsetup luksOpen /dev/sda5 crypt1
  cryptsetup luksOpen /dev/sda6 crypt2
   
  pvcreate /dev/mapper/crypt1
  pvcreate /dev/mapper/crypt2
   
  vgcreate vgroup /dev/mapper/crypt1
  vgextend vgroup /dev/mapper/crypt2
   
  lvcreate -L 1G -n swap vgroup
  lvcreate -L 6G -n root vgroup
  lvcreate -l 100%FREE -n home vgroup

The aes-xts-plain defines the used encryption method. I don't know anything about that, so I just copied something from yet another howto. crypt1 and crypt2 are just arbitrary names, which allow access to the unecrypted partitions on /dev/mapper/crypt1 and /dev/mapper/crypt2.

Reactivating the LVM volumes after reboot

At this point, you can just start the installation procedure. But, if something goes wrong, and you have to reboot, you obviously don't have to recreate your encrypted partitions. This is how you can reactivate them:

  modprobe dm-mod
  cryptsetup luksOpen /dev/sda5 crypt1
  cryptsetup luksOpen /dev/sda5 crypt2
   
  vgchange -ay

(The last line just activates all available logical volumes.)

Setting up arch

To setup arch, just run /arch/setup, as usual. For the step ‘prepare hard drive’, choose option 3: manually configure block devices, file systems, mount points.

Choose the physical partition as boot partition, and the correct logical partitions for root, home, swap, or whatever partitions you created.

In order to use two (or more) encrypted physical volumes, you have to apply a hack to the encrypt hook. You do this when the installer shows you the different configuration files you can edit. At this point, just press CTRL+ALT+F2, log in as root again, and apply the changes in this patch to /mnt/lib/initcpio/hooks/encrypt.

Update: It seems the patch got lost in a migration of my blog 😢. But I obviously didn't invent the patch myself, I just shamelessly stole it from this post on the arch linux forums.

Once you've done that, press CTRL+ALT+F1 again, to switch back to the installer. Edit rc.conf: change USELVM="no" into USELVM="yes".

Edit mkinitcpio.conf: search for HOOKS, and add encrypt lvm2 directly before filesystems. In my case, the HOOKS-line looks like this:

  HOOKS="base udev autodetect pata scsi sata encrypt lvm2 filesystems"

That's all you have to change in the configuration files. Continue the installation until the step you have to configure grub. For the menu entries 'Arch Linux' and 'Arch Linux Fallback' you should make sure that the kernel line looks as follows:

  kernel /vmlinuz27 root=/dev/mapper/vgroup-root cryptdevice=/dev/sda5:crypt1,/dev/sda6:crypt2 ro

Of course you should change vgroup-root to the name of your root volume, and choose the correct partitions after cryptdevice=. I chose the same names for the unencrypted devices (crypt1 and crypt2) as above, but I am not sure this is a requirement.

Adding two partitions after cryptdevice= is non-standard, this is why you had to hack the encrypt hook.

That's all. It should work. During bootup, you will be asked for the passphrases to decrypt your physical LVM partition. After entering these, your system will boot.

Things to be done

Although this setup works, it isn't perfect yet. In my situation, both encrypted partitions can be unlocked with the same password. It would be nice if entering the password one time, would decrypt both partitions at once; this is e.g. the case with Fedora.

I guess I will have to modify the encrypt hook again, such that it would try the first entered password for decrypting all the volumes. Only if this fails, it should ask to enter another password. This should be perfectly doable, but I wasn't able to try this out. Yet. ;-)

References

https://bbs.archlinux.org/viewtopic.php?pid=827495#p828784
https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS#LVM.26dm-crypt_manually_.28short_version.29
http://www.pindarsign.de/webblog/?p=767

Over Google, Windows en veilige besturingssystemen

Johan Vervloet — Thu, 03 Jun 2010 11:38:34 GMT

Misschien heb je het gisteren wel op de radio gehoord: Werknemers van Google mogen geen Windows meer gebruiken zonder expliciete toestemming van een CIO (chief information officer). Tenminste, dat zeggen de geruchten. Windows zou te onveilig zijn, en het incident eerder dit jaar met de Chinese aanval op Gmail zou de beslissing versneld hebben.

Als het al waar is dat Google Windows dumpt, dan geloof ik er niets van dat het beveiligingsargument de grootste reden is. Wat wel speelt, is dat Microsoft een concurrent is van Google: beide bedrijven hebben een zoekmachine, bieden webmail aan, en nu ook een soort van Officetoepassingen op het internet. Als Google nu Windows bant, en de pers pikt dat op, dan is het natuurlijk mooi meegenomen dat de concurrentie op een negatieve manier in het nieuws komt.

Ondertussen heeft het Microsoftkamp ook gereageerd . Volgens de Microsoftfans brengt een overschakeling naar Linux of Mac OS X meestal nog meer beveiligingsproblemen met zich mee. Dat is larie.

Het is natuurlijk zo dat - als je meer computers op Linux of Mac OS X gaat gebruiken -, je ook Windows-beveiligingsexperten zal moeten omscholen tot/vervangen door Linux- of Macbeveiligingsexperten. Ik vermoed sterk dat Google dat ook wel zal doen.

Dat Linux achterloopt wat betreft veiligheid, is ook geweldig onwaar. Het is niet omdat er geen antivirusprogramma's bestaan, dat Linux onveilig is. Voor Linux heb je geen antivirus nodig, en dat heeft alles te maken met de manier waarop je in een Linuxsysteem programma's bij-installeert. Die verschilt wezenlijk met de manier waarop dit onder Windows gebeurt. Maar later meer daarover.

Microsoft lost beveiligingsprobleem op: 'Druk niet op F1'.

Johan Vervloet — Tue, 02 Mar 2010 12:16:03 GMT

Als workaround voor een recent beveiligingsprobleem van Internet Explorer onder Windows XP, adviseert Microsoft zijn gebruikers om niet op F1 te drukken bij het surfen. Dat gaat zeker werken. :-p

De eerlijkheid gebiedt te vermelden dat er in Microsofts advies ook fatsoenlijke workarounds vermeld staan, zoals het uitzetten van het ‘legacy Windows help system’. Maar we hebben toch weer eens goed kunnen lachen :)

Windows mobile gebruikers krijgen inbox van onbekenden te zien

Johan Vervloet — Thu, 18 Feb 2010 20:22:35 GMT

Het zit Microsoft niet mee. Er zijn blijkbaar gevallen gerapporteerd van Windows Mobile gebruikers die de inbox van iemand anders te zien kregen na zich aan te melden bij Hotmail. Spijtig toch.

Rootkit die blauw scherm veroorzaakte is gepatcht

Johan Vervloet — Mon, 15 Feb 2010 12:14:50 GMT

Bij de updates voor Windows XP die op 9 februari vrijgegeven werden, zat er eentje dat je PC onbruikbaar maakte, tenminste als je computer geïnfecteerd was door de TDL3-rootkit (of TDSS, alnaargelang de bron).

Zo'n rootkit verandert je PC in een zogenaamde ‘zombie’, die door criminelen allerhande gebruikt wordt voor louche activiteiten. Zelf zal je er weinig van merken, behalve misschien dat je PC wat traag wordt.

Als je geïnfecteerde PC niet meer start na een Windows update, is dat natuurlijk vervelend voor jou, maar uiteraard ook voor mogelijke ‘users’ van je rootkit. Vandaar dat TDL3 nu blijkbaar overal gepatcht wordt, zodanig dat ze compatibel wordt met de betreffende Update voor Windows.

Als dat geen snelle service is :)

Microsoft raadt aan IE 8 te gebruiken, hoewel ook IE 8 kwetsbaar is

Johan Vervloet — Tue, 19 Jan 2010 10:36:56 GMT

Nu ook Frankrijk het gebruik van Internet Explorer afraadt, raadt Microsoft de gebruikers van Internet Explorer aan om te upgraden naar versie 8. Uit Microsofts eigen rapport over het veelbesproken probleem blijkt echter dat ook Internet Explorer 8 kwetsbaar is.

Duitsland raadt gebruik van Internet Explorer af

Johan Vervloet — Tue, 19 Jan 2010 08:36:06 GMT

Het Duitse ‘Bündesamt für Sicherheit in der Informationstechnologie’ raadt internetters af Internet Explorer te gebruiken. Dit naar aanleiding van de Chinese aanvallen op Google via een lek in Microsofts webbrowser.

iTunes stelt voor autorun opnieuw aan te zetten

Johan Vervloet — Mon, 09 Nov 2009 08:37:17 GMT

‘Autorun’ is een concept dat ervoor zorgt dat Windows bij het inpluggen van een CD of USB-disk automatisch een programma op die CD of stick uitvoert. Op die manier kunnen bijvoorbeeld snel installatieprogramma's gestart worden. Maar ook computervirussen kunnen zich op die manier onopvallend via USB-sticks verspreiden. Vandaar dat Microsoft met de release van Windows 7 (eindelijk) autorun uitschakelde.

Maar blijkbaar stelt iTunes zijn gebruikers voor om autorun opnieuw aan te zetten. Tss.

Windows 7 hotspot functie gevaar voor bedrijven?

Johan Vervloet — Thu, 05 Nov 2009 08:33:24 GMT

Blijkbaar is het mogelijk om met Windows 7 een PC met draadloze netwerkkaart te gebruiken als ‘access point’ voor een draadloos netwerk. Security.nl stelt dat dit een gevaar inhoudt voor bedrijven. Via deze ‘hotspot feature’ kan een werknemer een onbeveiligde draadloze toegang tot het bedrijfsnetwerk opzetten.

Ik ben het er niet mee eens dat dit mogelijk beveiligingsprobleem te wijten is aan Windows 7. Om de hotspotfunctionaliteit te activeren, moet de gebruiker beheerdersrechten hebben op zijn/haar PC. Als je als bedrijf beheerdersrechten geeft aan mensen die een onbeveiligde draadloze toegang tot het bedrijfsnetwerk willen openzetten, dan ben je verkeerd bezig.

En natuurlijk is het mogelijk dat mensen bijv. via een eigen laptop beveiligingsproblemen mee naar binnen nemen in een bedrijf. Maar door features uit één bepaald OS te verwijderen, los je dat probleem niet op. Een kwaadwillig of onwetend iemand kan even goed met een wireless router binnen stappen, en die aan het bedrijfsnetwerk hangen.

Je beveiligt je netwerk niet door features uit een besturingssysteem te verwijderen. Er bestaan betere oplossingen om te vermijden dat een niet-geautoriseerde personen van je netwerk gebruik maken.