Op Groenlicht, een betrekkelijk jonge leuke groepsblog (och, was ik ook maar jong en leuk), vergeilen ze zich aan porno-liefhebberijen op bedrijfscomputers. Niet dat ik een expert in het omzeilen van filters ben, maar als het op het veilig bewaren van data neerkomt, kunnen we wel iets forceren.
Om te vermijden dat je corporate IT-vrienden bij de wekelijkse scan iets onoorbaars vinden, zou je al die mooie dames (en heren, als u dat meer zegt) in een zip-file-met-wachtwoord kunnen opsluiten. Niet moeilijk, maar vooral niet bulletproof: de lijst van files in een beveiligde zipfile is sowieso zonder wachtwoord te bekijken en de encryptie-algoritmes die standaard in zip-software gebruikt worden zijn veel te makkelijk te kraken (pdf).
Waarmee we bij een serieuzer oplossing komen; TrueCrypt! Met TrueCrypt (gratis en open source!) kun je virtuele filesystemen met zeer sterke encryptie aanmaken. Die Truecrypt-filesystemen kun je, mits correct wachtwoord natuurlijk, dan als extra hard disk ‘mounten’. Net zoals bij een usb memory stick, kun je die schijf dan in je Windows Verkenner zien en er al je geheime documenten en andere opwindende bestanden op bewaren. Na gebruik die schijf dismounten en niemand kan er ook maar iets mee doen.
En als de IT-nazi’s je komen vragen wat er in dat geëncrypteerd bestand zit? Makkelijk; je kunt in een TrueCrypt-volume een andere verborgen schijf aanmaken (TrueCrypt in TrueCrypt dus). Op de zichtbare schijf bewaar je dan enkele professionele documenten (“Om te voorkomen dat laptop-dieven bedrijfsgeheimen zouden kunnen inkijken, Mijnheer.”) en je eigen geheime pleziertjes staan dan vol ongeduld op jou te wachten op je verborgen schijf. En klaar is Kees! Zakdoekje jongen?
Technology
Blogposts on blog.futtta.be about internet, web developement, browsers, security, linux, …
19 april: Ubuntu Feisty Feestje!
Morgen (19 april) wordt de nieuwste Ubuntu 7.04, ook gekend onder codenaam “Feisty Fawn”, op de wereld losgelaten. Ik ga er zeker mee aan de slag; mijn Dell Latitude D620 met dualcore processor en 1Gb memory, schreeuwt om -met behulp van een bootable usb-stick- verlost te worden van die archaïsch geconfigureerde Window XP (dank aan onze corporate IT). Wie de stap ook wilt zetten maar wat hulp nodig heeft; laat gerust iets weten, ik probeer je er wel door te loodsen!
MS Outlook 2007 verkloot html-mail?
Blijkbaar heeft MS voor Outlook 2007 beslist om de HTML-rendering engine van Word 2007 te gebruiken ipv die van Internet Explorer 7. Het resultaat: heel wat nieuwsbrieven zien er plots niet uit, want Word-html ondersteund bv. geen background image, geen padding of float, … Meer op http://www.campaignmonitor.com/blog/archi… en op Microsofts MSDN.
Slimmer dan je proxy(-admins)!
Proxies zijn vreemde dingen met een olifantengeheugen en bezorgen je soms een oude versie van een file die je van internet wilt plukken. Dat willen we niet en gelukkig is daar een simpele oplossing voor, een eenvoudige “bookmarklet” (stukje javascript-code dat vanuit de bookmarks wordt opgeroepen) zal die proxy wel even voor U temmen.
Een voorbeeld: om de meest recente versie van het fantastische Gilles Peterson’s Worldwide van de StuBru servers te plukken, zonder dat de bedrijfsproxy me de versie van bv. vorige week of afgelopen maand geeft, heb ik ipv dit:
“http://download.streampower.be/vrt/stubru/41_41gpwo-hi.mp3“
het volgende in mijn bookmarks:
“javascript:(function(){rnd=Math.floor(Math.random()*1000000);url = ‘http://download.streampower.be/vrt/stubru/41_41gpwo-hi.mp3?n=’ + rnd;location.href=url;})()“
Deze bookmarklet zal elke keer opnieuw een willekeurig cijfer generen en dat aan de URL plakken (die wordt dan bv. http://download.streampower.be/vrt/stubru/41_41gpwo-hi.mp3?n=234219). Omdat proxies bestanden in cache bijhouden aan de hand van de volledige URL, zal de proxy die file (inclusief random number) niet in zijn geheugen kunnen terugvinden en wordt er speciaal voor jou een nieuwe versie van dat bestand afgehaald. Veel luistergenot!
Cache header magic (or how I learned to love http response headers)
Is your site dead slow? Does it use excessive bandwidth? Let me take you on a short journey to the place where you can lessen your worries: the http-response-headers, where some wee small lines of text can define how your site is loaded in cached.
So you’re interested and you are going to read on? In that case let me skip the foolishness (I’m too tired already) and move on to the real stuff. There are 3 types of caching-directives that can be put in the http response: permission-, expiry- and validation-related headers:
- Permission-related http response headers tell the caching algorithm if an object can be kept in cache at all. The primary way to do this (in HTTP/1.1-land) is by using cache-control:public, cache-control:private or cache-control:nocache. Nocache should be obvious, private indicates individual browser caches can keep a copy but shared caches (mainly proxies) cannot and public allows all caches to keep the object. Pre-http/1.1 this is mainly done by issuing a Last-Modified-date (Last-Modified; although that in theory is a validation-related cache directive) which is set in the future.
- The aim of expiry-related directives is to tell the caching mechanism (in a browser or e.g. a proxy) that upon reload the object can be reused without reconnecting to the originating server. These directives can thus help you avoid network roundtrips while your page is being reloaded. The following expiry-related directives exist: expires, cache-control:max-age, and cache-control:s-maxage. Expires sets a date/time (in GMT) at which the object in cache expires and will have to be revalidated. Cache-control:Max-age and Cache-control:s-maxage (both of which which take precedence if used in conjunction with expires) define how old an object may get in cache (using either the ‘age’ http response header or calculating the age using (Expires – Current date/time). s-maxage is to be used by shared caches (and takes precedence over max-age there), whereas max-age is used by all caches (you could use this to e.g. allow a browser to cache a personalised page, but prohibit a proxy from doing so). If neither expires, cache-control:max-age or cache-control:s-maxage are defined, the caching mechanism will be allowed to make an estimate (this is called “heuristic expiration“) of the time an object can remain in cache, based on the Last-Modified-header (the true workhorse of caching in http/1.0).
- Validation-related directives give the browser (or caching proxy) a means by which an object can be (re-)validated, allowing for conditional requests to be made to the server and thus limiting bandwith usage. Response-headers used in this respect are principally Last-Modified (date/timestamp the object was … indeed modified the last time) and ETag (which should be a unique string for each object, only changing if the object got changed).
And there you have it, those are the basics. So what should you do next? Perform a small functional analysis of how you want your site (html, images, css, js, …) to be cached at proxy or browser-level. Based on that tweak settings of your webserver (for static files served from the filesystem, mostly images, css, js) to allow for caching. The application that spits out html should include the correct headers for your pages so these can be cached as well (if you want this to happen, off course). And always keep in mind that no matter how good you analyze your caching-needs and how well you set everything up, it all depends on the http-standards (be it HTTP/1.0 or 1.1) the caching applications follows (so you probably want to include directives for both HTTP/1.0 and 1.1) and how well they adhere to those standards … Happy caching!
Sources/ read on:
(Disclaimer: there might well be some errors in here, feel free to correct me if I missed something!)
Nieuw: de Webwerkers blog
“Gedeelde kennis is vermenigvuldigde kennis”, en daarom start ik met een paar (ex-)collega’s een groepsblog over website-ontwikkeling (in brede zin van het woord). Meer op http://webwerkers.wordpress.com.
Migratie-migraine
Met het opdoeken van de gratis typepad-gehoste telenetblogs moest ik op zoek naar een nieuwe blogwoonst. Alhoewel ik over een serverke op internet beschik, had ik weinig goesting om me met installatie en configuratie en onderhoud van de software bezig te houden. En zo kwam ik algauw bij de gratis wordpress.com-blogs uit. Bleef dan de kwestie van het importeren van mijn oude blogposts. De Typepad-blogs konden geëxporteerd worden, importeren was ‘a piece of cake’ (enkele html-tag-problemen daargelaten).
Waar net iets meer werk in kroop, was het importeren van mijn nog oudere posts uit een antieke nucleus 2-installatie. Niet eenvoudig (want in de nucleus-rss ontbrak heel wat en in de hosted wordpress kun je geen rss importeren). Maar volgende stappen hebben me uiteindelijk het verhoopte resultaat opgeleverd:
- aanpassen nucleus-code om in de rss zowel ‘body’ en ‘more’ (samen) te tonen in de description-tag
- aanpassen nucleus-code om in de rss de maximum lengte van de string in de description-tag te vergroten
- opvragen en bewaren van de rss, de al via typepad geëxporteerde posts handmatig verwijderen
- installeren en configureren van wordpress op mijn serverke (toch ja ..)
- php.ini op mijn serverke aanpassen om file-uploads mogelijk te maken
- aanpassen van rechten op filesysteem zodat wordpress zelf upload-directory kan aanmaken
- de rss-import op mijn tijdelijke blog gebruiken om de nucleus-rss te importeren
- de wordpress export-functie op mijn tijdelijke blog gebruiken om te exporteren
- de wordpress-export gebruiken om in mijn wordpress.com-blog te importeren
- en dan de tijdelijke blog op mijn serverke verwijderen en -nu ik er aan denk- de wijzigingen in php.ini ongedaan maken …
Maar we zijn er, al mijn blogposts staan nu proper op 1 plaats en ik voel me dus al een beetje thuis. Nu nog gelezen worden 😉
Doe open die proxy!
Omdat het op het werk niet altijd eenvoudig surfen is naar porno- of hacker-sites, heeft een mens al eens alternatieven voor de almachtige coorporate proxy nodig.
Dat je met firefox + putty + openssh-op-je-linux-serverken al veel kunt bereiken, is ongetwijfeld al gekend. Samengevat: de ‘dynamic port forwarding‘ optie in putty (en andere ssh-clients) opent een socks proxy op je eigen computer. Firefox kan via die socks proxy dan over de ssh-tunnel requests voor de meest ongepaste wwwebpagina’s de wereld insturen, zonder dat de bigcompany-proxy daar weet van heeft. En met de Firefox Switchproxy-extensie kun makkelijk switchen tussen bedrijfs- en je persoonlijke proxy.
Eén probleem rest er ons nog; de dns-requests gebeuren in bovenstaand scenario wel nog op het bedrijfsnetwerk. Als je in Firefox een URL intikt, zal die eerst moeten worden omgezet in een ip-adres. Die “vertaling” gebeurt door de DNS-servers van je werkgever en zo laat je de coorporate wwwatchdogs toch weer weten dat je de duistere kant van het net op wilt.
De oplossing daarvoor zit verborgen in de kelders van je Firefox-preferences; in about:config vind je de setting network.proxy.socks_remote_dns. De waarde van die instelling staat standaard op “false” maar wanneer die op “true” staat, wordt de vertaling van URL naar IP-adres effectief in alle privacy via je socks-proxy aan de andere kant van de ssh-tunnel afgehandeld. Nu alleen nog zorgen dat die collega die achter je zit, die blote schoon madammen op je scherm niet ziet … 😉
PHP kan uw gezondheid ernstige schade berokkenen
PHP is krachtig gereedschap. Net als met een goeie cirkelzaag of een stevige voorhamer kun je met PHP veel goeds, maar ook veel slechts doen. Volgende eenvoudige wijzigingen in php.ini zouden je installatie veel veiliger moeten kunnen maken;
- Zet “allow_url_fopen” op “off” zodat er met PHP via remote files geen ‘vijandige’ code kan binnengehaald worden.
- Maak een aantal functies (vnl. die waarmee commando’s van het OS kunnen uitgevoerd worden, bv. shell_exec, passthru, exec, system, proc_get_status, proc_nice, proc_open, proc_terminate, proc_close) ontoegankelijk met “disable_functions” zodat het vanuit PHP niet mogelijk is om bv. met wget (zoek maar eens in je apache logfiles naar de string ‘wget’) files af te halen (bv. een udp-flooder in perl), naar de /tmp folder te downloaden en daar uit te voeren.
- Overweeg “safe_mode” aan te zetten (veel van de vorige beperkingen worden dan automatisch afgedwongen).
Ook op Apache-niveau kun je -in apache.conf of httpd.conf- een en ander dichtspijkeren;
- Laad enkel die apache-modules die je echt nodig hebt (meestal bv. geen cgi, proxy, include, ..)
- Zet default access-rights op ‘DENY FROM ALL’ en voeg per Directory Allow-rules toe.
- Zet default AllowOverride-rechten op ‘none’ en voeg -indien nodig- per Directory laksere rechten toe.
- Zet “ServerTokens” op “PROD” en “ServerSignature” op “Off” (zodat het niet onmiddelijk zichtbaar is als je op een oudere versie-met-security-problemen van Apache werkt).
- Overweeg de implementatie van mod_security (soort software applicatie-firewall).
Toegang tot krachtige administratieve webapplicaties als phpmyadmin kun je best extra afschermen door in httpd.conf te specifieeren dat toegang standaard verboden is (DENY FROM ALL) en toegestaan vanaf ‘vertrouwde’ internet-adressen (bv. ip-range van bedrijf waar je werkt).
Probeer tenslotte zo weinig mogelijk applicaties te installeren; elke applicatie vermindert de veiligheid van het hele systeem weer een klein beetje ..
how google stole my video
zsazu, zo wilde ik het geesteskind noemen waarmee ik de wereld ging veroveren. de toekomst van nternetvideo, mee op de golf van web 2.0: cross-platform flash-gebaseerde video publishing als een service! tot google video met elke nieuwe release meer van mijn ideeen bleek te valideren en daarmee zsazu naar het mindmap-kerkhof verwees, waar menig concept om middernacht jammerend met de kettingen rammelt .. gooogle! gooooooooogle!!
met zsazu (of zou het toch zazu geworden zijn?) zou ik video-publishers (AV-media en gelieerde bedrijven in eerste instantie, portaal- en webbouwers in tweede instantie) de mogelijkheid bieden om op eenvoudige wijze cross-platform video-bestanden te publiceren.
ik brainstormde elke avond met mezelf (mindmapping for dummies), mailde met macromedia en kleine would-be concurrenten, deed testen met software-componenten en werkte zelfs al aan een prototype.
het idee was krachtig én eenvoudig: de originele file laten uploaden via een web-interface, op de server zou die file verwerkt en geconverteerd worden naar een flv-bestand en de eigenaar zou dan per mail een klein blokje html of javascript ontvangen waarmee de flash video in de eigen site gepublished kon worden. dat stukje javascript zou een geavanceerde flash applicatie oproepen die de eigenlijke video-file (flv) zou ophalen (met een security-laag errond waardoor een gebruiker nooit aan de eigenlijke flv-file zou kunnen) en (eventueel na betaling, want dat moest ook mogelijk zijn) afspelen. daar zou tenslotte nog een laag logging en reporting-functies rond geschreven worden om de eigenaar alle nodige inzicht in consumptie van zijn of haar online video-materiaal te geven.
dat alles zou met een paar bestaande en bewezen componenten (beginnen met 1 linux webserver met apache webserver, php voor administratie en flv-wrapper-functies, mysql database voor sessiebeheer en 1 linux server voor videoconversie met ffmpeg, aangestuurd door shellscripts of in extremis perl, python of php-cli-scripts) en een keigoeie flash applicatie op betrekkelijk korte tijd (ik dacht aan pakweg 3 maand) in test op te zetten zijn.
en dan, met een goeie demo als breekijzer, dan was het een kwestie van een paar vissen aan de haak te slaan die met mij in zee wilden (paar investeerders, paar klanten die vroeg aan boord zouden springen) en we zouden op weg geweest zijn om een leuk web 2.0-bedrijfje uit te bouwen. tot pakweg vorige week.
want vorige week las ik dat google begin q4 van 2005 voor hun video-project -dat al een tijdje ontwikkeld wordt- beslist had om de switch te maken van een eigen ontwikkelde client-applicatie (een stand-alone google videoplayer) naar publishing in flash video. en naarmate de google video hype groter werd (naar aanleiding van de aankondiging van het feit dat google ook video van oa broadcasters ging verkopen) en er dagelijks functionaliteit bij gereleaset werd, bleek dat zsuza ook bestond in de knappe koppen van de verlichte zoekdespoten. google was me voor en deed het beter dan ik het ooit gedaan zou kunnen hebben. een pracht van een applicatie, op alle vlakken!
en zsazu, .. die naam hou ik in mijn achterhoofd voor het volgende lumineuze idee. want ooit moet ik alle nitwits ter wereld toch voor kunnen zijn. toch? 😉