Portknocking

[Verwijderd]

Hallo allemaal,

Ik las in de huidige C'T een artikel over portknocking. Portknocking is een nieuwe beveiligingstechniek die uit 2 programma's bestaat: een server progje en een client progje. Die programma's heb je in heel veel verschillende vormen geschreven, namelijk perl, C(++), java, python en bash. Dus je weet eigenlijk wel zeker dat het op jouw server kan.
Het werkt als volgt:
Er staat een programmaatje op de server die luistert naar een bepaalde port* (het liefst boven de 45912, want veel portscanners komen daar niet). Met een clientprogramaatje wat op je eigen PC staat stuur je een bepaald patroon naar de server. Dan zet de server applicatie de port waar je op in wilt loggen (bijv. port 22 voor SSH) open. Dan kan je gewoon met je SSH client inloggen en alles doen wat je wilt. Als je klaar bent sluit je je SSH client af en stuur je weer een bepaald patroon naar de server, weer op die rare port. Het serverprogrammaatje zet dan port 22 weer dicht, en niemand kan dan inloggen op port 22.
Dus alle poorten op je firewall zet je dan dicht, behalve de poorten die altijd open moeten zijn, bijv. port 80 (webserver) of 21 (FTP). Port 22 hoeft niet altijd open te staan, maar alleen als je in wilt loggen. Dus dit is weer een extra veiligheid erbij.
Alle informatie over het portknockinsysteem kan je vinden op http://www.portknocking.org.
Er is alleen 1 maar: Je firewall software moet iptables zijn. Verder zijn er eigenlijk geen beperkingen, want iedere server kan wel of c++ of bash of perl aan.
Ik heb (nog) geen eigen server, maar als ik er (ooit) 1 krijg, dan gaat dit er zeker op.

*: Het server programmaatje luisterd eigenlijk niet naar een port, maar kijkt in de logs van de firewall of er een request is binnen gekomen (en geblokt is) op een bepaalde port.

[Belgar]

Ik zie hier het voordeel niet helemaal van. Of eigenlijk, ik zie de meerwaarde niet echt. Uiteindelijk komt toch de service weer aan internet te hangen. Bovendien is je verhaal een beetje verwarrend. op het ene moment zeg je dat het progje aan een poort hangt en het andere dat de firewall log bekeken wordt.

Beide technieken zijn ook gewoon te realiseren met de standaard windows xp firewall. Je kunt namelijk lokaal een 'rule' aan of uit zetten.

Als laatste zou ik niet de poort weer sluiten met een pakket, maar gewoon als je disconnect van de poort krijgt. Dit kan door de rule weer op 'TCP established only' te zetten nadat de eerste connectie is gevormd. Mischien een leuk idee voor een back-door, maar veel toegepaste veiligheid vind ik het niet.

Dit is mijn persoonlijke analyse overigens. Er zijn vast wel goede redenen te verzinnen wanneer dit gedrag gewenst kan zijn.

[Verwijderd]

Belgar schreef op 08 september 2004 @ 14:45:
Ik zie hier het voordeel niet helemaal van. Of eigenlijk, ik zie de meerwaarde niet echt. Uiteindelijk komt toch de service weer aan internet te hangen.

Ja, de service komt weer aan het internet te hangen. Maar het is wel een veel grotere veiligheid als de port alleen open staat als je hem nodig hebt, of 24/7/365. Dus het is wel veiliger.

Belgar schreef op 08 september 2004 @ 14:45:
Bovendien is je verhaal een beetje verwarrend. op het ene moment zeg je dat het progje aan een poort hangt en het andere dat de firewall log bekeken wordt.

Eerst zei ik dat hij naar een port keek. Dat klopt ook wel, maar hij is niet aan het listenen naar een port, maar hij kijkt naar een port via de firewall logs. In het verhaal zei ik het een beetje kort, om niet van de kern van het verhaal af te wijken. Daarom staat er ook een sterretje bij, om aan te geven hoe het echt werkt.

Belgar schreef op 08 september 2004 @ 14:45:
Beide technieken zijn ook gewoon te realiseren met de standaard windows xp firewall. Je kunt namelijk lokaal een 'rule' aan of uit zetten.

Maar aangezien dit eigenlijk alleen over de firewall iptables gaat, heb je geen windows XP, dus is het wel weer makkelijk .
Kan je de standaard XP firewall zo instellen dat hij naar een hele ander port moet luisteren naar een bepaalde code en dan een port moet open zetten? Denk het niet, lijkt me vrij geavanceerd.

Belgar schreef op 08 september 2004 @ 14:45:
Als laatste zou ik niet de poort weer sluiten met een pakket, maar gewoon als je disconnect van de poort krijgt. Dit kan door de rule weer op 'TCP established only' te zetten nadat de eerste connectie is gevormd. Mischien een leuk idee voor een back-door, maar veel toegepaste veiligheid vind ik het niet.

Das waar, dat je de port weer dicht moet zetten is idd niet echt handig, dat kan beter. Maar aangezien de C++/java/perl/pyton/bash scripts er staan, kan je de boel zo aanpassen dat dat gebeurd. Dus ga je gang

Belgar schreef op 08 september 2004 @ 14:45:
Dit is mijn persoonlijke analyse overigens. Er zijn vast wel goede redenen te verzinnen wanneer dit gedrag gewenst kan zijn.

Dit is heel erg makkelijk als je thuis een server hebt staan, maar je daar niet altijd iedereen op wilt laten. Erg makkelijk. Ook voor een gewone system administrator lijkt het me veilig om te weten dat zijn SSH poort alleen open staat op het moment dat hij hem nodig heeft.

[Belgar]

Verwijderd schreef op 08 september 2004 @ 14:57:

Maar aangezien dit eigenlijk alleen over de firewall iptables gaat, heb je geen windows XP, dus is het wel weer makkelijk .
Kan je de standaard XP firewall zo instellen dat hij naar een hele ander port moet luisteren naar een bepaalde code en dan een port moet open zetten? Denk het niet, lijkt me vrij geavanceerd.

Niets geavanceerds aan hoor. Je kunt gewoon de log uitlezen. Hier staat netjes in dat 'een pakket van xxx bytes is geblocked op poort yyyy'. Zo werkt het ook bij iptables IMO.

Mijn punt is dat een goed gemanagede server dit niet hodig heeft. Als het alleen is om SSH te beveiligen, houdt niemand je tegen SSH op poort 54648 te draaien (of helemaal niet). Ik vind het overigens wel een leuke techniek hoor, maar de uitwerking klinkt zo onprofessioneel. Mischien beter om het topic om te vormen naar een discussietopic over het nut van zulke beveiligingen.

Het XP voorbeeld was overigens alleen om aan te tonen dat de firewall 'an sich' dus geen invloed heeft op de techniek. Zolang de firewall een log genereerd en een mogelijkheid heeft om 'rules' toe te passen is het altijd mogelijk.

[Verwijderd]

Natuurlijk kan je er niet alleen SSH mee beveiligen. Je kan er elke port die wilt mee beveiligen.
Natuurlijk is dat nog een extra beveiliging om SSH op poort 54648 te draaien.
Waar ik het trouwens over heb, is niet zomaar een "rule". Dit gaat echt over het openen en sluiten van poorten vanaf een andere computer, op het moment dat jij het nodig hebt.

De reden dat dit waarschijnlijk alleen bij iptables werkt is de precieze manier van loggen van iptables. Dit weet ik niet zeker, dit is alleen een veronderstelling.

En ik ben wel voor die omvorming , dus bij deze. Ik vind dit soort beveilingen heel nuttig, omdat dan potensieel gevaarlijke poorten alleen maar open staan op het moment dat ze echt open moeten staan en verder niet.

[Reptile209]

Maar ook dit kan je volgens mij prima brute-forcen: gewoon pakketjes naar die PC gaan gooien en (evt met een portsniffer) kijken wat er open gaat. 't Is wel een drempel om eerst de "knock"-poort + pakketgrootte/inhoud te raden en dan bijvoorbeeld de VNC poort + pass, maar het lijkt me niet onmogelijk.
Of je gaat gewoon sniffen naar pakketjes en dan luister je het knock-pakketje af...
Toch alleen maar een middel om het moeilijker - niet onmogelijk - te maken. Een firewall die controleert dat bijvoorbeeld de VNC-client vanaf een bepaald IP komt, lijkt me al een stuk zinvoller dan dit.

[Belgar]

Verwijderd schreef op 08 september 2004 @ 15:19:

Waar ik het trouwens over heb, is niet zomaar een "rule". Dit gaat echt over het openen en sluiten van poorten vanaf een andere computer, op het moment dat jij het nodig hebt.

De reden dat dit waarschijnlijk alleen bij iptables werkt is de precieze manier van loggen van iptables. Dit weet ik niet zeker, dit is alleen een veronderstelling.

Uhm volgens mij begrijp jij het verkeerd. Een quote van de portknocking site:

Before a connection is established, ports are opened using a port knock sequence, which is a series of connection attempts to closed ports. A remote host generates and sends an authentic knock sequence in order to manipulate the server's firewall rules to open one or more specific ports.

Er worden dus inderdaad gewoon rules gemanipuleerd nadat in de logfile een bepaalde serie van foutmeldingen wordt ontdekt. Elke firewall met rules kan dus zo beveiligd worden. Doet niets af aan het concept, maar zou het dus beter zijn een discussie te hebben over het 'concept' portknocking dan deze, in mijn ogen, gelimiteerde implementatie.