Als hij aan deep packet inspection (op layer 7, applicatielaag) doet zou hij kunnen voldoen.
Volgens mij is dit antwoord zowel 100% technisch correct als 100% onduidelijk voor jou
Laat ik het anders schrijven: de meeste firewalls gaan na:
welke source & destination IP's er betrokken zijn.
welke services (poorten) er betrokken zijn
welke actie er gedefinieerd is.
Bijvoorbeeld: van "buiten" naar "jouw pc" op poort 80 (HTTP): denied/drop.
van "jouw pc" naar "buiten" op poort 80 (HTTP): allowed.
Waar wil ik nu toe komen. Je firewall zal wél zien of er aan deze rudimentaire voorwaarden wordt voldaan, maar:
A/ het is niet omdat traffiek naar poort 80 gaat, dat dit effectief HTTP traffiek is.
B/ het is niet omdat het effectief HTTP traffiek is dat er geen exploit code* in zit.
*bug, vuln (vulnerability): security probleem in software.
exploits, exploit code: shellcode + payload
shellcode: de code die de bug triggert zodat de payload wordt uitgevoerd.
payload: kan vanalles zijn; bijvoorbeeld het openen van een nieuwe connectie, het aanmaken van een admin account op de pc, het draaien van nieuwe processen, het bypassen van authenticatie, enz ...
Met een netwerkfirewall ben je dus niets tegen dit soort problemen; je moet eigenlijk een applicatieve FW/content filter/proxy hebben die gaat nagaan:
A/ of de traffiek is wat hij claimt te zijn (is HTTP traffiek weldegelijk HTTP traffiek?)
B/ of de traffiek conform de spelregels is (meeste protocollen volgen RFC's. Zo kan je doorgaans stellen dat "normale" HTTP traffiek nooit binaire code zou moeten bevatten (ik ga het niet met uitzonderingen moeilijker maken dan nodig...)
C/ of er geen exploits, virussen, e.d. aanwezig zijn.
Een "gewone" firewall zet gewoon je hek open of dicht. Als jij bepaalt dat enkele blauwe carrera's binnen mogen, dan gebeurt dat, maar je gaat op die wijze nooit weten of er ook nog 3 Russen met kalashnikovs in zitten.
Er even van uitgaand dat je liever geen Russen met kalashnikovs thuis ontvangt, natuurlijk
