DMCZ: De-militarized Client Zone
På 90-talet var brandväggar ovanliga, såväl servrar som persondatorer var tillgängliga över Internet. Det fanns fortfarande inget behov av NAT, koppel var verkligen end-to-end. Detta blev efter några år ett problem. Säkerhetshål utnyttjades och information från känsliga servrar riskerade stjälas. Vi började filtrera paket, vi började skilja de servrar som skulle ta emot främmande besökare från de som var känsliga. Vi placerade de publika servrarna i DMZ-nätverk. Nätverk varifrån man, om man tog sig in där, skulle ha begränsade möjligheter att ta sig vidare in i de interna nätverken.
En anledning till detta var att buffer overflows var ett monumentalt problem som lurade i varenda servermjukvara som fanns; mailservrar, webbservrar, namnservrar, FTP, you name it. Hackers byggde brohuvuden i DMZ och letade sig därifrån vidare in på det smaskigare, interna nätverket. Det är en metod som beskrivs i mer eller mindre alla "hackerböcker" (Hacking Exposed och motsvarande).
Det var då.
Intrång fungerar inte bara så längre. IIS, Apache, SQL Server, BIND, vsftpd, OpenSSH och annat som företag traditionellt har öppet mot nätet har inte haft pre-auth-privileged-arbitrary-code-execution-sårbarheter på åratal. (De enda undantagen verkar vara webbapplikationer...)
Det finns hundratals kända och sannolikt tusentals gånger fler okända exempel på att brohuvudet inte skapas på servern i DMZ:at. Brohuvudet skapas på en klientdator, någon anställds laptop eller motsvarande: de tre mest omtalade de senaste åren kan vara GhostNet samt intrången hos Google och RSA. F-Secure har regelbundet bloggposter som beskriver den senaste batchen med "malicious <insert-file-type>".
Jag har aldrig varit hos en kund som inte har ett DMZ. Däremot är antalet som har särskilda nät för klienter synnerligen lätträknade.
Varför har vi inte hängt med där? Borde vi inte börja prata om de-militarized client zones (DMCZ) i alla våra dokument om best-practice? Jag funderar på om inte DMCZ nästan borde anses som viktigare än vårt konventionella DMZ nuförtiden.
...eller dödade NAC/NAP den diskussionen?
--
Stefan Pettersson
En anledning till detta var att buffer overflows var ett monumentalt problem som lurade i varenda servermjukvara som fanns; mailservrar, webbservrar, namnservrar, FTP, you name it. Hackers byggde brohuvuden i DMZ och letade sig därifrån vidare in på det smaskigare, interna nätverket. Det är en metod som beskrivs i mer eller mindre alla "hackerböcker" (Hacking Exposed och motsvarande).
Det var då.
Intrång fungerar inte bara så längre. IIS, Apache, SQL Server, BIND, vsftpd, OpenSSH och annat som företag traditionellt har öppet mot nätet har inte haft pre-auth-privileged-arbitrary-code-execution-sårbarheter på åratal. (De enda undantagen verkar vara webbapplikationer...)
Det finns hundratals kända och sannolikt tusentals gånger fler okända exempel på att brohuvudet inte skapas på servern i DMZ:at. Brohuvudet skapas på en klientdator, någon anställds laptop eller motsvarande: de tre mest omtalade de senaste åren kan vara GhostNet samt intrången hos Google och RSA. F-Secure har regelbundet bloggposter som beskriver den senaste batchen med "malicious <insert-file-type>".
Jag har aldrig varit hos en kund som inte har ett DMZ. Däremot är antalet som har särskilda nät för klienter synnerligen lätträknade.
Varför har vi inte hängt med där? Borde vi inte börja prata om de-militarized client zones (DMCZ) i alla våra dokument om best-practice? Jag funderar på om inte DMCZ nästan borde anses som viktigare än vårt konventionella DMZ nuförtiden.
...eller dödade NAC/NAP den diskussionen?
--
Stefan Pettersson
Kommentarer
Trackback
