![[Inhalt]](../../Grundlagen/Firewall/images/toc.gif){kind=small}
|
|
Online Suche im Handbuch | LITTLE-IDIOT NETWORKING |
Es gibt eine ganze Menge von kleinen Details, die Hersteller von renomierten Firewalls gerne verschweigen. Man trifft auf diese Details dann, wenn man aus den RFC´s sich ein ganz bestimmtes Protokoll heraussucht, und dieses genau analysiert. Im Quellcode von LINUX 2.0 und 2.2 ist im Verzeichnis /usr/src/linux/net/ipv4 der Code der REALAUDIO, CUSEEME und VDOLIVE Videokonferencing Protokolle zu finden.
Eine Besonderheit bei vielen Videokonferencing Protokollen ist, daß diese auf UDP Übertragungen beruhen. Darin enthalten ist das RTP (Real Time Protocol), welches für einen Ausgleich bei Schwankungen der Übertragungsgeschwindigkeit sorgt. Allen Protokollen gemeinsam ist, daß die Übertragung durch ein TCP Paket z.B. auf Port 554 und 7070 (REALAUDIO) initiiert wird. Daraufhin sorgt der PROXY- Mechanismus dafür, daß für eine Zeit von ca. 30 Sekunden die Firewall für UDP Pakete aus dem Internet transparent wird. Das bedeutet, daß ein Surfer hinter der Firewall für Angriffe von dem REALAUDIO Server und von beliebigen anderen Host im Internet, die mit gespooften Adressen arbeiten, verletzlich wird. Diese systematischen Löcher in Firewalls wurden in keinem mir bekannte Falle auch nur erwähnt oder sogar getestet. Dasselbe betrifft auch RPC, also Protokolle, die sich aus TCP und UDP Paketen zusammensetzen. RPC´s werden insbesondere von PDC´s und BDC's unter NT benutzt, also den Primary Domain Controller in Netzwerken mit mehreren NT Servern.
Haben Sie sich noch nicht gefragt, über welchen Port, mit welchen Verschlüsselungsalgorithmen und mit welchen Standard Paßworten sich Windows NT Server untereinander austauschen ? Das Problem wird insbesondere dann interessant, wenn es darum geht, die Security Policy umzusetzen. Angenommen, jede einzelne Abteilung eines Unternehmens wird mit einer eigenen LINUX Firewall ausgestattet und kann selber bestimmen, wer worauf Zugriff haben darf. Das komplexe RPC Protokoll muß dann über die Firewall hinweg übertragen werden. Welche Ports werden von Windows NT geöffnet, welche Protokolle werden wie übertragen, und wann können Ports wieder geschlossen werden. Alle diese Fragen sollten Sie im mitgelieferten Handbuch Ihres Betriebssystems und Ihrer Firewall finden.
Ein weiteres Problem betrifft SQL Datenbanken, welche mit Firewalls gesichert werden müssen. In vielen Fällen ist die Vertraulichkeit der Daten für Unternehmen überlebenswichtig. Leider hat es in der Vergangenheit mit u.a. auch mit ORACLE und MSQL vor kurzem Fälle von Buffer Overflows gegeben, sodaß wichtige Daten des Unternehmens ins Internet verschwunden sind.
Welche Parameterlängen kann der Firewall-Proxy abfangen, um Buffer Overflows zu vermeiden ? Wird die Syntax der SQL Statements auf Zulässigkeit geprüft ? Wie man schon erahnen kann, muß mit kommerziellen Firewalls und Betriebssystemen erheblich kritischer umgegangen werden.
Schauen Sie sich auf der Site http://www.netcraft.com/security/diary.html und achten Sie einmal besonders auf den Markennamen Firewall-1 von Checkpoint.
Kann es denn wirklich möglich sein, daß keine Security Consulting Firma bei der Überprüfung der Firewalls mit Standard Angriffstools bemerkt hat, daß hier Firewall-1 4.0 einfach mit einem UDP Paket auf Port 0 unter SOLARIS 2.6/2.7 lahmgelegt werden kann ?
Ein Beispiel hier aus dem Code von Firewall-1 von Checkpoint:
// INSPECT Security Policy Skript Generated by
// cshenton@LapDancer.it.hq.nasa.gov at 12Mar98 17:20:57
// from Rulebase by FireWall-1 Version 3.0b [VPN] Compiler
// Running under SunOS5.5.1
// Number of Authentication and Encryption rules
#define NAUTHENTICATION 0
#define NENCRYPTION 0
#define NLOGIC 0
#define NLOGICFOLD 0
#define NACCOUNT 0
/////////////////////////////
// Exported Rules Database //
/////////////////////////////
export {
(
:auth ()
:crypt ()
:logic ()
:logicfold ()
:proxy ()
:rules (
: (rule-1
:src (
: Any
)
:dst (
: lapdancer
)
:services (
: H323
: NetMeeting
: NetMeeting-DirSrv
)
:action (
: (accept
:type (accept)
:color ("Dark green")
:macro (RECORD_CONN)
:icon-name (icon-accept)
:text-rid (61463)
:windows-color (green)
)
)
:track (
: Long
)
:install (
: (Gateways
:type (gateways)
:color ("Navy Blue")
:icon-name (icon-gateways)
)
)
:time (
: Any
)
)
: (rule-2
:src (
: Any
)
:dst (
: Any
)
:services (
: Any
)
:action (
: (drop
:type (drop)
:color (Firebrick)
:icon-name (icon-drop)
:text-rid (61465)
:windows-color (green)
)
)
:track ()
:install (
: (Gateways
:type (gateways)
:color ("Navy Blue")
:icon-name (icon-gateways)
)
)
:time (
: Any
)
)
)
:party ()
:conf_params (
: (tcptimeout
:val (900)
:type (int)
)
: (udptimeout
:val (40)
:type (int)
)
: (udpreply
:val (true)
:type (str)
)
: (addresstrans
:val (false)
:type (str)
)
: (skipmaxtime
:val (120)
:type (int)
)
: (skipmaxbytes
:val (10485760)
:type (int)
)
: (icmpcryptver
:val (0)
:type (int)
)
: (fwsynatk_method
:val (0)
:type (int)
)
: (fwsynatk_timeout
:val (10)
:type (int)
)
: (fwsynatk_max
:val (500)
:type (int)
)
: (fwsynatk_ifnum
:val (-1)
:type (int)
)
: (fwsynatk_warning
:val (1)
:type (int)
)
: (disable_ipsec
:val (false)
:type (str)
)
)
)
}.set;
///////////////////////////
// Beginning of Prologue //
///////////////////////////
// Define Log Preferences
#define LOG_TIMEOUT 9
// Define Session Timeouts
#define TCP_TIMEOUT 900
#define UDP_TIMEOUT 40
// List of known TCP services
tcp_services = { 256, 257, 258, 259, 261, 18181, 18182, 6000, 6001, 6002,
6003,\ 6004, 6005, 6006, 6007, 6008, 6009, 6010, 6011, 6012, 6013, 6014,
6015,\ 6016, 6017, 6018, 6019, 6020, 6021, 6022, 6023, 6024, 6025,
6026,\ 6027, 6028, 6029, 6030, 6031, 6032, 6033, 6034, 6035,
6036,\ 6037, 6038, 6039, 6040, 6041, 6042, 6043, 6044, 6045,
6046, 6047, 6048, 6049, 6050, 6051, 6052, 6053, 6054, 6055,
6056, 6057, 6058, 6059, 6060, 6061, 6062, 6063, 2000, 513,
512, 514, 23, 21, 540, 80, 70, 210, 25, 109, 110, 119, 15,
79, 113, 2626, 5510, 1521, 7, 53, 750, 9, 37, 13, 123, 139,
6670, 6680, 1352, 7000, 7070, 1720, 6500, 6499, 1503, 522, 389,
443, 1235, 453, 455, 1720, 22, 5001, 9224, 43, 105, 17003, 17003,
106, 10101, 15632 };
// List of known UDP services
udp_services = { 259, 260, 161, 162, 2049, 69, 520, 1525, 513, 514, 42, 512,
67, 1024, 7, 53, 750, 9, 37, 13, 123, 137, 138, 22555, 1645, 1558, 370,
61801, 61802, 61803, 61804, 61805, 61806, 61807, 61808, 61809, 61810, 61811,
61812, 61813, 61814, 61815, 61816, 61817, 61818, 61819, 61820, 61821, 7648,
7649, 7650, 7651, 7652, 1987 };
// Log macro for IP Options
#define IPOPTNS_LOG LOG(badip_form, LOG_NOALERT, 0)
// Log macro for Established TCP Packets
#define LOG_ESTABLISHED_TCP
// Define flag for Live Connections
#define LIVE_CONNS 1
// Define flag for enabling decryption on accept
#define ACCEPT_DECRYPT_ENABLE 0
#define NO_ENCRYPTION_FEATURES 1
// Address Translation definitions
#define FWXT_EOX 0x0
#define FWXT_TCP_DPORT_STATIC 0xb02
#define FWXT_UDP_DPORT_STATIC 0x1b02
// Include Common Definition File
#include "fwui_head.def"
SRV_tcp(h323, 1720)
SRV_tcp(netmeeting, 1503)
SRV_tcp(netmeeting-dirsrv, 522)
/////////////////////
// End of Prologue //
/////////////////////
///////////////////////////////////////
// Beginning of Security Policy Code //
///////////////////////////////////////
// List of FireWalled Gateways, Hosts and Embedded systems
firewalled_list = { 192.168.0.2, 131.182.8.1, 131.182.5.1, 131.182.5.2,
192.168.1.2,\ 198.116.65.1, 131.182.8.1 };
// List of RADIUS Servers
radius_servers_list = { 0 };
// List of cvp Servers
cvp_servers_list = { 192.168.0.2 };
// List of ufp Servers
ufp_servers_list = { 192.168.0.2 };
// List of Servers, operated by Logical Servers
servers_list = { 0 };
//time lists
MAKE_ALERT(alert_tab, <"![alert]">)
MAKE_ALERT(snmptrap_tab, <"![snmptrap]">)
MAKE_ALERT(mail_tab, <"![mail]">)
MAKE_ALERT(useralert_tab, <"![useralert]">)
MAKE_ALERT(spoofalert_tab, <"![spoofalert]">)
MAKE_ALERT(userauthalert_tab, <"![userauthalert]">)
ADDR_gateway(neuromancer, 192.168.0.2)
ADDR_gateway(wintermute, 131.182.5.2)
ADDR_host(lapdancer, 131.182.119.44)
target_list1 = targets { neuromancer, wintermute };
// Code for First-Bounded Properties
init_code;
ftpdata_code;
rpc_code;
ftppasv_code;
accept_fw1_connections_first;
#define REVERSE_UDP 1
#include "code.def"
accept_fw1_connections;
accept_rip;
accept_domain_udp;
accept_domain_tcp;
enable_radius_queries;
#define load_agent_port 0
#if NLOGIC > 0
enable_load_agent_queries;
#endif
// Rule-Base And Before-Last Properties Code
start_rule_base_code;
inbound all@target_list1
accept start_rule_code(1),
(tcp, h323 or netmeeting or netmeeting-dirsrv),
(ip_dst = lapdancer),
RECORD_CONN(1),
LOG(long, LOG_NOALERT, 1);
inbound all@target_list1
drop start_rule_code(2);
// Code for Last-Bounded Properties
accept_icmp;
accept_outgoing;
/////////////////////////////////
// End of Security Policy Code //
/////////////////////////////////
#include "fwui_trail.def"
Wie man sehen kann, erkennt Firewall-1 zwar die typischen Ports der Netmeeting Verbindung, hat jedoch keine Ahnung von den Inhalten dieser Protokolle. Desweiteren werden Protokolle zugelassen die keiner braucht (RPC) und alle möglichen TCP und UDP Ports nach außen hin geöffnet. Ein lohnender Fall für Cracker also, es mal mit Manipulationen der Protokollinhalte und gespooften Paketen zu versuchen.
Was wäre denn die Aufgabe der Firewall-1 gewesen ? Herr Brian Wheeler von RAPTOR hat sich zu dem Problem Netmeeting genauer geäußert:
"Gut ist derjenige dran, dessen Firewall Netmeeting unterstützt. Leider mit einer kleinen Einschränkung: Port 1501 (T.120) ist dafür verantwortlich, daß Daten von der Festplatte des Clients in das Internet Verschwinden können. Microsoft nett dies einfach "Application Sharing" und betrachtet dieses als Feature, andere nennen es schlichtweg "Leichtsinn".
Siehe hierzu auch das Kapitel Netmeeting. Der Port 1501 im Netmeeting Protokoll sollte sich also immer über einen Button abschalten lassen, andernfalls kann der Verhandlungspartner via Netmeeting alle Daten Ihrer Festplatte einsehen und sogar Programme starten.
Leider wandeln sich Protokolle auch. Wer noch vor einiger Zeit von z.B. den REALAUDIO Server (EINSLIVE, WDR und SWR3) durch den Firewall PROXY keinen Ton auf seiner Arbeitsstation empfangen konnte, der muß heute nur noch den REAL-G2 Player neu installieren, um diese Protokolle über den PORT 80 oder 8080 der Firewall übertragen zu können. Was ist inzwischen geschehen ? Die Hersteller der VIDEO/AUDIO Player haben sich Klagen vieler Kunden anhören müssen, die nur durch den Einsatz von teuren Firewalls mit den entsprechenden PROXY's an den LIVE Übertragungen teilnehmen konnten. Das hat dazu geführt, daß alle Protokolle in den HTTP Datenstrom verpackt wurden. Hierzu gehören die Protokolle LDAP, ULP, IMTC-MCS, H.323 hostcall, MSICCP, H.245 und RTP/RTCP auf den ursprünglichen Ports 389, 522, 1503, 1720, 1731, und UDP auf Port 1024+ . Falls eine Firewall im Netz installiert wurde, die einen speziell für NETMEETING installierten PROXY besitzt, dann wird dieser PROXY neuerdings einfach übergangen, da alle diese Protokolle über den Port 80 abgewickelt werden. Damit entfällt völlig die Kontrolle über die Mechanismen von Netmeeting. Die sicher geglaubte Internetanbindung wird wegen einer Protokolländerung zum Tummelplatz für Cracker.
Weitere Sicherheitslücken in Verbindung mit Firewall-1 von Checkpoint wurden bereits im Internet an zahlreichen Stellen im Internet beschrieben.
REAL-G2 und Netmeeting haben gemeinsam, daß beide Protokolle Punkt-zu-Punkt Verbindungen, bzw. Serverseitig Punkt-zu Multipunkt Verbindungen sind. Wenn zwei Personen ohne Firewall im Internet surfen, dann können beide zueinander finden, wenn diese zuerst eine Verbindung zu den Microsoft ILS-Servern (Internet Locator Server) aufbauen. Die ILS Server sind quasi LDAP Server, nur hat Microsoft sich auch hier nicht an den Standard gehalten. Es erfolgt die Anmeldung über Port 522 (veraltet) und Port 389 (TCP). Es folgt der Aufbau einer H.323 Verbindung über den Port 1720 und gleichzeitig der Aufbau der Audio Verbindung über Port 1731, beide TCP. Danach werden dynamisch viele UDP Ports oberhalb der Ports 1024 für das RTP (Real Time Protocol) Streaming Protokoll geöffnet.
Für eine Firewall zwischen diesen Hosts bedeutet dies, daß nach den Protokollen 522/389 und 1731 und 1720 alle UDP Ports oberhalb von 1024 für den Zugriff aus dem Internet freigeschaltet werden müssen. Es werden inbound/outbound Antwortpakete für aufeinanderfolgende Verbindungen des Realtime Protokolls (RTP) von dem PROXY in der Firewall ausgesandt. Diese enthalten Hinweise auf den nächstfolgenden Port (UDP).
Ein Proxy ohne Spezialwissen kann also diese Hinweise nicht generieren. Wenn beide Surfer hinter einer Firewall sitzen, dann muß die eine Firewall der anderen mitteilen, welche Ports diese nun nach innen außen zu öffnen hat. Jede der Firewalls hat also zu entscheiden, welcher Port nach innen (inbound) geöffnet wird. Danach muß sie die andere Firewall fragen, auf welchen Port sie diese Verbindung auf der Gegenseite legen soll. Die andere Firewall fragt daraufhin den Client, ob er eine Verbindung wünscht, baut ebenfalls eine inbound Verbindung auf und meldet der einen Firewall, daß z.B. auf Port 31234 eine UDP Verbindung geöffnet werden kann. Diese nimmt den Vorschlag entgegen und verbindet ihren Surfer über diesen Port nach außen. Somit ist es möglich, daß ein Cracker von außen bestimmen kann, welche Ports nun nach innen hin geöffnet werden sollen.
Dies widerspricht sämtlichen Grundsätzen der Firewall-Techniken. Man muß sich ernsthaft fragen, ob Firewallhersteller, die Netmeeting Proxy´s anbieten, ernsthaft glauben, daß hier ein Schutz gegeben ist.
|
|
Online Suche im Handbuch | LITTLE-IDIOT NETWORKING |