image

"Over 10 jaar gaat alles over poort 80"

donderdag 29 november 2007, 11:29 door Redactie, 17 reacties

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.

Reacties (17)
29-11-2007, 11:51 door [Account Verwijderd]
[Verwijderd]
29-11-2007, 11:57 door awesselius
Het is gewoon dat, sinds men als een wilde protocollen zijn
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 -
29-11-2007, 12:14 door _Maarten_
Doordat er in de toekomst steeds meer gewerkt gaat worden met online
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.
29-11-2007, 12:17 door Anoniem
De firewall is de oorzaak van het steeds vaken gebruiken van poort 80.
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
29-11-2007, 12:37 door Anoniem
Ik hoop dat de auteur van dit bericht het geheel onjuist heeft.

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
29-11-2007, 13:24 door Anoniem
Volgens mij heeft de NSA de oplossing in handen.
29-11-2007, 13:50 door Anoniem
Door Anoniem
Terzijde vermoed ik dat we het voor elkaar krijgen om zelfs
streaming video over XML te sturen, ...

XML is een taal, geen protocol ...
29-11-2007, 13:59 door Anoniem
Normale proxies/firewalls laten vaak nog veel meer toe via
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.
29-11-2007, 15:28 door Anoniem
Ik laat elke applicatie over welke poort dan ook communiceren. Geen filter
die het verkeer kan herkennen laat staan tegenhouden.
29-11-2007, 20:50 door Anoniem
Je ziet op dit moment een verschuiving van interesse in de firewall markt
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?
30-11-2007, 00:46 door Anoniem
Dat komt ervan als de verantwoordelijkheid voor security alleen bij
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.
30-11-2007, 11:36 door Anoniem
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.
Welke werknemer mag en
kan zelfstandig applicaties installeren op zijn werkstation?
Een organisatie dat uitsluitend op een firewall leunt doet
geheel niet aan beveiliging.
30-11-2007, 12:48 door Anoniem
"Welke werknemer mag en kan zelfstandig applicaties installeren op zijn
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.
30-11-2007, 12:51 door Anoniem
"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. "

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.
30-11-2007, 14:30 door Anoniem
Als je in Win update doet en de standaard poort is niet open
gaan de akamai machines een poortscan uitvoeren .....
waar zou dat nu voor zijn.........ff via een andere he...:)
30-11-2007, 15:19 door Anoniem
Als ik zo bezie dat alles via poort 80 (443 wordt niet
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.
17-03-2008, 13:43 door Anoniem
Mooi was die implementatie van het OSI netwerk tussen
Digital en IBM die we op de hannover messe hebben laten
zien...in 1987.
Geen poorten geklooi....maar ja.........kost wat maar dan
hedde ook wat.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.