On interesting stuff
Posts tagged Howto’s
Putty als proxy!
Nov 20th
Putty is veel meer dan een SSH-client, het is bijvoorbeeld ook mogelijk om bepaalde poorten via Putty te tunnelen en dat kan erg nuttig zijn. In dit voorbeeld gaan we Putty inzetten als HTTP proxy, op die manier is het mogelijk om vanaf een onveilig netwerk een beveiligde verbinding op te zetten met een SSH-server en al je HTTP verkeer over die tunnel te sturen. De toepassingen hiervan;
- bedrijfsproxies met mogelijke filtering/logging omzijlen (denk aan monitoring/blokkeren van streaming etc)
- vanaf een onveilig wifi netwerk verantwoord je bankzaken regelen
- de web-console van je thuis-router benaderen vanaf je lokale browser
Om een tunnel aan te maken moet je binnen Putty een normale SSH-connectie configureren, voor je op Open klikt moet je echter ook nog in het linkermenu naar Connection -> SSH -> Tunnels gaan en het als volgt configureren;
Putty tunnel aanmaken
Je moet in het veld ‘Source port’ 8080 invullen en het type is ‘Dynamic’, ‘Auto’, nadat je dat hebt ingesteld klik je op ‘Add’ en komt ie in het lijstje er bij te staan (zoals hierboven al het geval). Klik vervolgens op ‘Open’ en log in op de SSH-server. Je tunnel is nu actief zolang je Putty open laat staan, je kunt deze gewoon minimalizeren. Om gebruik te maken van de proxy kun je het best Firefox gebruiken, op die manier kun je namelijk ook je DNS-requests over de proxy heen tunnelen (zo kun je voorkomen dat bedrijfsproxies kunnen zien welke DNS-requests je maakt).
Binnen Firefox ga je naar Tools -> Settings en dan;
Firefox proxy config
In het blauw aangegeven vakje kun je je lokale netwerken zetten, op deze manier kun je als een VPN-verbinding down is toch op de routers aan beide kanten werken (de lokale zonder proxy, de remote router via de SSH-proxy via een server in het remote netwerk). Erg handig!
Om je DNS-requests te verbergen moet je in de Firefox adres-balk ‘about:config’ intypen, dit is een speciaal adres waarmee je naar een soort registry van Firefox gaat. Type vervolgens ‘Proxy’ in als Filter-text en pas de rood aangegeven zaken aan door er op te dubbelklikken:
Firefox about:config - DNS requests tunnelen
Je bent nu klaar met het configureren van een volledig beveiligde proxy! Het verkeer wordt nu vanaf je eigen pc tot aan de SSH server encrypted verstuurd, let op dat het vanaf de SSH server natuurlijk wel onbeveiligd naar de website in kwestie gaat tenzij je een HTTPS-website benaderd. Mocht je een hele strenge firewall hebben bij het bedrijf waar je werkt dan kun je je SSH-server thuis op poort 443 hosten, op die manier ziet het verzoek er voor de firewall uit alsof je een HTTPS-website benaderd en zal het dus bijna altijd doorgelaten worden.
Edit: kwam de volgende pagina tegen met SSH-tips, best interessant: http://souptonuts.sourceforge.net/sshtips.htm
Authorative DNS lookups
Nov 19th
Een authorative DNS-lookup is een lookup naar een hostname bij de primaire DNS-server voor dat domein. Wat de primaire DNS-servers voor een domein zijn kun je opvragen door het NS-record van dat domein op te vragen. Hieronder een screenshot waarin je kunt zien hoe we eerst het A-record opvragen bij de default DNS-server van mijn machine (opendns) en vervolgens het NS-record opvragen, de server instellen op een authorative DNS-server en daarna dus ook een authorative antwoord krijgen (dit is alleen te zien doordat er NIET ‘Non-authorative’ bij de output staat).
DNS authorative lookups
DNS wijzigingen
Alle DNS-records hebben een bepaalde levensduur die aangeeft hoe lang een DNS server het record in cache mag houden. Een DNS-record met een levensduur van 24 uur zal dus tot 24 uur na het wijzigen van het DNS-record in bepaalde delen van de wereld nog naar het oude adres resolven. Bij het plannen van een MX-wijziging is het dan ook belangrijk enkele dagen voor de wijziging de levensduur te veranderen naar een zo laag mogelijke waarde, bijvoorbeeld 5 minuten. Op die manier kun je in het geval er iets mis gaat snel het DNS-record weer aanpassen en is de eventuele downtime door verkeerde veranderingen slechts 5 minuten.
Als je wil weten of het aan de cache van je eigen DNS-server ligt dat een bepaalde DNS-wijziging voor jou nog niet zichtbaar is kun je door middel van het ‘server <IP authorative nameserver van het domein in kwestie>’ een DNS-query rechtstreeks bij de authorative nameserver uitvoeren.
DNS record types
Nov 19th
Door middel van nslookup is het mogelijk de verschillende DNS-records van een domeinnaam op te vragen:
DNS nslookup voorbeeld
Het NS-record kan gebruikt worden om de authorative nameservers van het domain op te vragen;
NS record lookup
Als je een DNS wijziging voor marno.org zou willen doorgeven moet je dus contact opnemen met transip.net. Het spreekt voor zich dat dit alleen kan gebeuren door geauthoriseerde personen, vaak moet dit door middel van een FAX zelfs nog bevestigd worden.
Hoe email werkt
Nov 19th
Om email-problemen goed op te kunnen lossen is het belangrijk om te snappen wat mailservers precies uitvoeren om een mailtje van A naar B te krijgen. In dit voorbeeld gaan we een mailtje volgen van gmail.com naar acknowledge.nl en gaan we er van uit dat gmail.com de mail zonder smarthost verstuurd.
1. De gebruiker klikt op verzenden, het mailtje komt in de uitgaande mail-queue van een mailserver van gmail.com.
2. De mailserver van gmail.com ziet dat het een mailtje voor ‘acknowledge.nl’ is en gaat het bijbehorende MX-record opvragen. Als inkomende mail voor Acknowledge.nl niet zou werken zou een goede eerste test zijn om te kijken of de MX-records wel kloppen. Dit kun je gemakkelijk zelf testen met behulp van ‘nslookup’:
MX record troubleshooten
Wat gebeurt er en wat is er te zien;
- Start een command prompt en start ‘nslookup‘
- Na het starten van nslookup, een tool om DNS records op te vragen, geven we aan dat we een record van het type ‘MX’ willen hebben. MX staat voor Mail Exchange: ‘set type=mx‘
- Vervolgens typen we de domeinnaam in kwestie in, in dit geval acknowledge.nl.
- In de output zien we een aantal belangrijke gegevens;
- MX preference: de mailserver met de laagste preference wordt als eerste geprobeerd, in dit geval zal gmail.com dus in eerste instantie proberen de mail op mail.acknowledge.nl af te leveren.
- De mail exchanger; dit zijn de domeinnamen waar naar gmail.com een SMTP-connectie op zal zetten. Het IP-adres dat hier bij hoort zou je op kunnen vragen door ‘set type=a‘ te gebruiken en dan ‘mail.acknowledge.nl’ in te type
3. De mailserver bij gmail.com weet nu dat hij de mail voor acknowledge.nl op mail.acknowledge.nl moet afleveren, mocht dat niet lukken dan zal de mail worden afgeleverd bij mailbackup1.kpn.net. Als mail.acknowledge.nl de mail van gmail.com accepteerd is het verhaal voor wat betreft gmail.com hiermee klaar.
- Om te testen of mail.acknowledge.nl verbindingen accepteert kun je een telnet sessie opzetten naar mail.acknowledge.nl op poort 25. Let op dat dit vaak niet kan vanaf werkstations, poort 25 wordt uitgaand vaak alleen open gezet vanaf de mailserver om de impact van spam-virussen op werkstations te minimalizeren. Dit is ook bij Acknowledge het geval.
- Voer dit dus bij voorkeur vanaf thuis of een mailserver van een klant zonder mailproblemen uit
- Start vanuit een command prompt een telnet sessie naar mail.acknowledge.nl om te kijken of de mailserver een mailtje voor gmail.com accepteert;
SMTP test voorbeeld
- Als je bij de mail from/rcpt to foutmeldingen krijgt probeer het dan eenst met een < en een > teken om het email-adres heen: mail from: <marno.vandermolengmail.com> bijvoorbeeld.
- Druk Ctrl + ] om de connectie te verbreken. Type vervolgens quit of exit (verschilt tussen Linux/Windows) om telnet af te sluiten.
- Let hierbij op de return-codes die je terug krijgt: 250 is altijd goed, 354 geeft aan dat je mag beginnen met je mailtje.
- Bij het verzenden van een mailtje voert een mailserver zelf exact dezelfde stappen uit zoals hierboven weergegeven, het is dus erg nuttig om dit zelf ‘live’ te kunnen testen.
4. In het geval dat mail.acknowledge.nl niet te benaderen is zal gmail.com proberen de mail bij mailbackup1.kpn.net af te leveren, het idee is dat KPN de mailtjes bewaard tot onze omgeving weer online is. De mailserver bij KPN zal om de zoveel tijd blijven proberen of het zijn mailtjes bij de acknowledge mailserver kan afleveren.
Notes:
Als een domein geen fallbackserver heeft en de mailserver is offline dan zullen de mensen die naar dat domein mailen een mailtje krijgen dat het mailtje niet kon worden afgeleverd, meestal probeerd de verzendende mailserver het zo’n 24 uur voor het besluit het mailtje als ‘onverzendbaar’ te beschouwen en het weg gooit. Op zo’n moment is het bedrijf in kwestie dus niet per email te bereiken wat vaak een grote impact heeft, hopelijk lukt het met deze korte handleiding mail-issues sneller op te lossen.
Als de primaire server van een domein een tijdje offline is dan kan het zo zijn dat de mail die in de tussentijd naar dat domein is verzonden nog een tijdje blijft staan bij de fallback-server, je kunt op zo’n moment het beste contact opnemen met de host van je fallback mailserver (bij acknowledge.nl zou dat dus KPN zijn) en vragen of ze onze mail-queue kunnen legen. Mocht je een technisch iemand aan de lijn krijgen; hij moet de mailserver met onze mailqueue een ETRN-command geven, in sommige gevallen kan dit ook zelf door via telnet op de fallback mailserver in te loggen, door middel van HELO ‘domeinnaam’ aan te geven voor welk domein je een ETRN wil triggeren en vervolgens zal de fallback mailserver de mail opnieuw proberen af te leveren bij de mailserver.