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:

  1. 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.
  2. 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).
  3. 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!)

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;

  1. Zet “allow_url_fopen” op “off” zodat er met PHP via remote files geen ‘vijandige’ code kan binnengehaald worden.
  2. 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.
  3. 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;

  1. Laad enkel die apache-modules die je echt nodig hebt (meestal bv. geen cgi, proxy, include, ..)
  2. Zet default access-rights op ‘DENY FROM ALL’ en voeg per Directory Allow-rules toe.
  3. Zet default AllowOverride-rechten op ‘none’ en voeg -indien nodig- per Directory laksere rechten toe.
  4. 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).
  5. 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? 😉

Iedere god zijn hemel

über kernel hacker (linus torvalds) mengde zich een paar dagen geleden op zijn gekende manier in een debat over usability van gnome (een open source user interface). een veelzeggend citaat:

Gnome seems to be developed by interface nazis, where consistently the excuse for not doign something is not “it’s too complicated to do”, but “it would confuse users”.

nieuwswaardig blijkbaar (want ondertussen is bovenstaand uittreksel al op zowat elke computer-nieuws-site verschenen), grappig ook, maar verder eigenlijk weinig relevant; kernel hackers doen moeilijke dingen die alleen zij begrijpen en die voor de rest gewoon moeten werken (de kernel zorgt ervoor dat je software van je hardware gebruik kan maken). een gewone sterverling wordt immers niet bewust geconfronteerd met hun arbeid (behalve wanneer er iets niet werkt).
met een user interface daarentegen, wordt iedere gebruiker constant geconfronteerd. dat usability een belangrijk aspect is bij het ontwerpen en ontwikkelen van een GUI is dan ook logisch. gnome stelt zich specifiek tot doel voor iedereen (dus ook voor wie geen code junkie of command line ridder is) onmiddelijk bruikbaar te zijn. dat daarvoor features moeten worden opgeofferd is misschien spijtig, maar volstrekt logisch.
linus is god, maar hij moet wel in zijn hemel blijven.
tot u sprak een happy gnome-user 😉
Links: Telenet portaal: Torvalds mengt zich in GNOME vs KDE-debat.

de draadloze lekkende zeef

draadloze netwerken (ook gekend als wifi, wlan, 802.11, ..) zijn op korte tijd enorm populair geworden. iedereen wilt blijkbaar van in de tuin of van boven de dampende wc-pot ongehinderd door kabels het wereldwijde web op. dat die ongekende populariteit ook een paar gevaarlijke kantjes heeft, wordt dikwijls vergeten. of weten de enthousiaste gebruikers gewoon niet..
maar wat zou een onverlaat met zijn laptop in de wagen voor uw deur zoal op uw draadloos netwerk kunnen mispeuteren?
in oplopende volgorde van schadelijkheid:
* gewoon surfen (of mail afhalen) op jouw kosten. who cares, right?
* illegale software of muziek en films downloaden. da’s al iets minder fijn; als je beperkte download-capaciteit hebt (cfr. telenet telemeter) zou je sneller aan die limiet kunnen zitten. en je verbinding wordt eigenlijk gebruikt voor diefstal. politie en de verenigingen van de film- en muziekindustrie zullen er in eerste altijd van uitgaan dat jij -als gebruiker van de verbinding- de schuldige bent.
* illegale software of muziek en films uploaden. het wordt al iets warmer; het zelf aanbieden van mp3’s of divx’en wordt feller bestreden door IFPI en andere belangenorganisaties.
* hacken of spammen: een hacker of spammer wilt voor zijn sportieve of misdadige activiteiten liefst anoniem blijven. wat is er makkelijker dan met de laptop op de schoot in het centrum van een middelgrote stad anoniem andermans internetverbinding te ‘lenen’ om te proberen in te breken op -ik zeg maar wat- de internetsite van hugo coveliers.
onder de indruk? nee? ok, dan gaan we verder:
* zien wat jij op internet doet: met een network-sniffer je doen en laten op internet (alles wat niet geencrypteerd is tenminste) volgen. naar welke sites je gaat, welke paswoorden gebruikt, je binnenkomende en uitgaande mail mail, ..!
* informatie van je computer halen: elke gesharede drive (network-drive) zonder wachtwoord is onmiddelijk en zonder beperking leesbaar voor bezoekers van je draadloos netwerk.
* inbreken op je computer: een beetje zoals voorgaand risico, maar nog meer verregaand. aangezien wireless routers hun draadloze verbindingen als ‘trusted’ beschouwen, wordt het verkeer op die verbinding (meestal) niet door de firewall gestuurd. het is dan ook veel makkelijker om via de draadloze verbinding binnen te breken in een computer dan via het internet. en eenmaal binnen kan je computer gebruikt worden om inloggegevens van je online bank door te sturen, om te spammen, om ..
soit, het komt erop neer dat een open draadloos netwerk een heel groot risico inhoudt. volgende betrekkelijk eenvoudige stappen kunnen dat gevaar buitenshuis houden:
* beveilig je draadloos netwerk met een wachtwoord (WEP of liever nog WPA)
* stel je router zo in dat die de netwerknaam (SSID) niet uitzendt (broadcast)
* laat enkel computers op je netwerk met een gekend MAC-adres (het mac-adres is een voor elke netwerkkaart unieke identificatie-string). je kunt het mac-adres van de netwerkkaart van je computer te weten komen in apparaatbeheer (device manager) of vanuit een ‘dos-venster’ met ‘ipconfig /all’ (zie onder physical address). lijstje invullen in je router onder mac-adres-filtering en klaar is je beter beschermd draadloos netwerk..
en voor de rest: nog veel draadloos genot gewenst!

the joy of port forwarding of waarom ik een linux-geek ben

U houdt het misschien niet voor mogelijk, maar zo af en toe (als ik op het werk aan mijn nieuwe krachtige laptop met Windows XP zit) vergeet ik waarom ik zo graag met linux en andere open source software werk. Tot ik weer iets nieuws ontdek in die wondere geek-wereld. Zo ben ik deze week overdonderd door een mij tot voor kort volkomen onbekend aspect van ssh; tcp port forwarding ofte vpn for the linux-masses ..
Voor wie zo moedig was om van de inleidende paragraaf (op mijn homepage) toch nog door te klikken naar dit artikel, een korte uitleg als ‘fond’:
SSH staat voor secure shell, een ‘protocol’ voor beveiligde communicatie met een linux/unix-server. Met ssh krijg je vanop afstand toegang tot zo een machine in de vorm van een shell (te vergelijken met een dos-venster in windows, maar dan veel krachtiger). De beveiliging bestaat uit zware encryptie van alle data die over en weer gaat tussen de server en het ‘dos-venster’. de meest voorkomende implementatie van ssh op linux/ unix is openssh (gratis en open source).
Enig begrip van wat een ‘port’ (poort) is, kan ook helpen om te snappen waar ik het straks over heb. Een computer die op het internet aangesloten is, heeft een op dat moment uniek ip-adres waarop je die machine kunt bereiken (te vergelijken met een huisnummer). Op die computer worden er typisch echter verschillende diensten aangeboden. Daarom wacht elk van die diensten in principe aan een eigen ‘port’ op aanvragen. Zo een poort zou je kunnen vergelijken met de tientallen huisbellen (met parlofoon) in de hal van een appartementsgebouw. De belangrijkste diensten hebben een vaste poort; zo gaat al het webverkeer over poort 80, mail over 25 (om te versturen en 110 om af te halen) en ssh over 22.
Omdat IT- en security-verantwoordelijken beroepshalve paranoia moeten zijn, wordt zoveel mogelijk verkeer van de boze buitenwereld afgeschermd door de firewall op te dragen verkeer voor bijna alle computers en poorten tegen te houden. Daarom kun je van thuis uit bv. niet aan je computer op je werk. Met VPN kan dat wel en ssh tcp forwarding is daar een heel leuk zelfbouw-alternatief voor (als je ssh-toegang hebt tot een linux/unix server op het werk die niet in een DMZ ofzo staat) 🙂
Tot daar de theorie, dan nu de praktijk! Port forwarding is functionaliteit in ssh die toelaat om, via de beveiligde tunnel die ssh opzet over poort 22, requests naar andere poorten (andere diensten dus) te laten forwarden. Hoe? Wel:
ssh -L 5900:mydesktop.mycompany.be:5900 mylinuxserver
naam en paswoord geven en klaar is frank! alle verkeer voor de normaal van thuis uit onbereikbare mydekstop kan nu vanop mijn thuiscomputer (via localhost op poort 5900 naar mylinuxserver naar mydesktop op poort 5900) bereikt worden. en waarvoor ik dat dan gebruik? wel, 5900 is de vnc-poort. ik kan van thuis uit, op mijn linux-laptop, mijn windowsXP-laptop op het werk overnemen (de vncviewer van tightvnc, ook al gratis en open source, doet dat zelfs al automatisch, met de “-via”-optie). en met
ssh -L 1139:fileserver:139 mylinuxserver
en daarna
smbmount //fileserver/myshare myremoteshare -o ip=127.0.0.1,port=1139
kan ik mijn windows-gesharede homedrive op de fileserver op het werk rechtstreeks op mijn thuiscomputertje mounten (aanspreken). smbmount is overigens onderdeel van samba, een gratis en open source implementatie van SMB, het protocol waarmee windows shares werken.
andere mogelijkheden; je mail op een veilige manier binnenhalen (met pop3 of imap4 wordt je wachtwoord in principe immers ongeencrypteerd verstuurd). of surfen via de proxy van het werk. of met de exchange connecteren. vandaar: met ssh port forwarding kun je zo ongeveer alles wat je via vpn zou willen doen, maar niet durfde vragen aan die autistische coorporate IT’er op je werk. en wedden dat die man geen probleem heeft met incoming connections op port 22? 😉
ik heb nu overigens op mijn usb-key (waarvoor ik eigenlijk nog geen echt nuttig gebruik had gevonden) vncviewer en putty gezet. met putty (een ssh client voor op windows, ook gratis en open source) kun je ook port forwarden. waar ik ook kom, ik hoef mijn usb-key maar in te pluggen, putty op te starten en in te loggen op een unix/linux-machine op het werk en ik kan met vncviewer aan mijn laptop..
en for the record: op die nieuwe blinkende dell latitude d505 komt eerstdaags ook wel linux te draaien. kwestie van geduldig op de nieuwe Ubuntu te wachten, die perfect met de Intel Centrino chipset zou moeten kunnen werken .. en in tussentijd zorgt cygwin voor een vertrouwde shell ;D