"Over 10 jaar gaat alles over poort 80"
Over tien jaar gaat alles over poort 80, waardoor de huidige generatie firewalls niet meer in staat is om het netwerk te beveiligen. Filterden firewalls eerst nog poorten, gevolgd door protocollen, nu is het applicaties dat de klok slaat, waarbij er op hogere snelheden geïnspecteerd en geblokkeerd moet worden. De nieuwe generatie firewalls zal niet alleen over intrusion prevention beschikken, maar ook op applicatie type kunnen filteren.
"Het wordt steeds duidelijker dat over 10 jaar bijna alles over poort 80 gaat, wat betekent dat 90 procent van de regels in de hedendaagse firewalls niet meer relevant zijn", zegt Thomas Ptacek van Matasano Security.
De meeste firewall aanbieders gaan voor de "alle-poorten/alle protocollen" aanpak, maar alleen het herkennen van protocollen is niet de oplossing van het poort 80 probleem. "Het poort 80 probleem is dat zowel PeopleSoft als Digg hetzelfde HTTP protocol gebruiken, hoe maak je dan onderscheid?" Firewalls moeten daarom een stap verder gaan. "Als Digg en PeopleSoft hetzelfde protocol gebruiken, is het duidelijk niet genoeg om te weten welk protocol het is. Het probleem is dat er vele duizenden applicaties zijn."
Christofer Hoff van Unisys laat weten dat het aanpassen van de firewall zodat die applicatie protocollen herkent niet voldoende is. "Het probleem is dat applicaties slechts een geleider zijn. Data is het echte probleem." In de toekomst verwachten experts dan ook dat firewalls niet het hele netwerk en alleen aan de buitenkant beschermen, maar juist per afdeling worden ingezet, gekoppeld met oplossingen zoals Data Leakage Prevention.
gaan ontwikkelen en niet eerst netjes een RFC daarvoor
opstellen, het een puinhoop is geworden.
Voorheen had je duidelijkheid over welke applicatie over
welke poort ging, wat het protocol inhield en kon je vragen
naar suggesties voor verbetering.
Het is wel zo, dat veel webapplicaties gewoon port 80
gebruiken omdat het HTTP is. Logisch. Maar het is jammer dat
men te pas en te onpas HTTP gebruikt voor alles wat los en
vast zit. Heel vaak gaat het niet eens om Hypertext, maar om
POST en GET URL's die puur data pompen. Zelfs SOAP wordt op
deze manier gehanteerd. Nou, daar is niets Hypertext aan.
Het is zelfs niet eens efficient om HTTP maar te gebruiken
omdat het zo makkelijk is. Het is ook vaak genoeg bewezen
dat daardoor veel lekken ontstaan.
Mijn idee is, terug naar de RFC-tekentafel en stel
duidelijke protocollen op. Daar zouden we in zo'n 10 jaar
toch wel wat aan moeten hebben?
- Unomi -
Office/CRM pakketten verwacht ik dat bedrijfsfirewalls het steeds moeilijker
gaan krijgen. Ik verwacht zeker dat Data Leakage Prevention in de
toekomst steeds vaker ingezet zal worden.
Als software engineer maak ik vaak de beslissing om datatransfer via http
of https te laten lopen om problemen met firewals te voorkomen.
Greetingz,
Jacco
Poort 80, ofwel volgens definitie onbeveiligd HTTP-verkeer,
mag wat mij betreft absoluut niet meer gebruikt worden,
omdat alles niet alleen eenvoudig te filteren is, maar ook
te onderscheppen. Ik hoop over 10 jaar: alles over poort
443, encrypted.
En als dat toch onleesbaar is gemaakt en per definitie de
proxies niet als 'man in the middle' mogen fungeren, kunnen
kwaadaardige XML pakketjes daar netjes over worden
getunneld. Het beste beveiligingsmiddel dan? Encrypted tot
aan de applicatie (of nog verder) en totale semantische
invoercontrole van de gegevens.
Meer realistisch is echter dat ik vermoed dat een aantal
bedrijven veiligheid voor privacy kiezen en dat er
HTTPS-proxies worden ingezet om toch de applicatiedata te
kunnen filteren en controleren, waardoor alles helaas net zo
goed direct over poort 80 kan worden verstuurd, unencrypted
en netjes leesbaar gemaakt omdat alle applicaties via XML
gaan werken.
Terzijde vermoed ik dat we het voor elkaar krijgen om zelfs
streaming video over XML te sturen, gezien dat zo goed
gefilterd kan worden en netjes door dergelijke proxies kan
stromen. Dat dit een onwaarschijnlijke hoeveelheid
bandbreedte vereist, wordt echter niet meer onderwijzen op
de gemiddelde ICT opleiding, maar dat is een andere discussie.
Gr
ing.D. Dubbelhuis
Terzijde vermoed ik dat we het voor elkaar krijgen om zelfs
streaming video over XML te sturen, ...
XML is een taal, geen protocol ...
poort 443 dan poort 80. Zo kan je direct een socket openen
naar je SSH server wanneer deze op poort 443 draait.
Je stuurt alleen een HTTP CONNECT naar de proxy en je krijgt
direct een tcp-socket. Ook al gebruik je het niet voor
encryptie, de firewall zal de boel links laten liggen omdat
het niet eens de moeite wil doen.
Leuke is dat je hier te maken hebt met een kip-ei probleem.
Wanneer de firewall SSL inspectie zou gaan doen is een mitm
aanval nodig. Maar je bent dan ook meteen onzeker of deze
aanval nu door de firewall of door iets anders wordt uitgevoerd.
Een service die het bijvoorbeeld al ondersteund is Google
talk. Ipv poort 2223 kan je 443 gebruiken. Heel weinig
firewalls die daar over zullen klagen.
die het verkeer kan herkennen laat staan tegenhouden.
waarbij de firewall met applicatie inteligentie steeds populairder worden.
Het SSL inspectie probleem is wel een lastig probleem hoe kunnen we
ervoor zorgen dat ook in deze datastroom een controle kan plaatsvinden.
Voor een virusmaker is het een kleine moeite om een virus via HTTPS
naar de client te versturen.
Zijn er anderen die hier oplossingen voor weten, inline of proxy varianten?
netwerkbeheer wordt neergelegd.
Ik weet nog goed hoe verbijsterd ik was toen ik hoorde wat onwikkelaars en
consultants vertelde over de de belangrijkste motivatie voor webservices:
dan hoeven we in de applicaties en de ontwikkeling daarvan geen rekening
te houden met de firewall.
Zuhct, alsof security een zaak van het netwerk alleen is.
huidige generatie firewalls niet meer in staat is om het
netwerk te beveiligen. Filterden firewalls eerst nog
poorten, gevolgd door protocollen, nu is het applicaties dat
de klok slaat, waarbij er op hogere snelheden geïnspecteerd
en geblokkeerd moet worden.
kan zelfstandig applicaties installeren op zijn werkstation?
Een organisatie dat uitsluitend op een firewall leunt doet
geheel niet aan beveiliging.
werkstation?"
Volgens mij gaat deze discussie helemaal niet specifiek over niet-
geautoriseerde applicaties. Ook voor geautoriseerde applicaties is access
control nodig, en daarnaast gaat hem ook om externe applicaties
waarmee men wellicht door de perimeter van je netwerk zou kunnen
komen, en waarover je geen controle uit kunt voeren, dus ik snap niet
helemaal welk punt je hiermee wilt maken.
mag wat mij betreft absoluut niet meer gebruikt worden,
omdat alles niet alleen eenvoudig te filteren is, maar ook
te onderscheppen. Ik hoop over 10 jaar: alles over poort
443, encrypted. "
Zo zou je eveneens andere applicaties via port 443 kunnen laten lopen. In
dat geval zal je dus eveneens network based application recognition of
andersoortige technieken moeten gebruiken om onderscheid te kunnen
maken tussen diverse soorten applicaties.
Port 80 is een voorbeeldje, maar dit verhaal geldt natuurlijk simpelweg
voor iedere willekeurige port. Ook zegt het al dan niet gebruiken van
encryptie weinig over de content van het verkeer, waardoor
bovenstaande argumenten ook gewoon nog steeds geldig blijven.
gaan de akamai machines een poortscan uitvoeren .....
waar zou dat nu voor zijn.........ff via een andere he...:)
genoemd maar is nog veel 'transparanter') dan wordt het hoog
tijd dat we http applicatieproxies maar eens nieuw leven
moeten gaan inblazen. En dan maar regeltjes maken a-la snort
om te beslissen wat mag en wat niet.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
