Clemens Wohld <c.wohld@ndh.net> wrote:
* On Tue, Aug 15, 2000 at 01:57:54PM +0200, Joerg Henner wrote:
On Die, 15 Aug 2000, Clemens Wohld wrote:
hat hier jemand eine clevere Lösung trotz "Netmeeting" eine firewall aufzuziehen? [...] das problem ist ganz einfach das H.323 (netmeeting) dynamische UDP-Ports verwendet
Nicht nur UDP-Ports. Das Call-Signalling laeuft zwar in der Regel ueber einen festgelegten TCP-Port (1720), aber da kommen auch noch andere TCP-Verbindungen (fuer H.245) ins Spiel, die nicht mit festen Ports arbeiten.
- und sorry, dabei kann man beim besten willen nimmer von firewall reden ... ganz egal welches produkt man dann einsetzt.
Betroffen ist wahrscheinlich nur ein bestimmter Bereich von Ports, die fuer dynamische Vergabe verwendet werden (kann man bei Windows eigentlich von >1024 ausgehen?), was einen Schutz der uebrigen Ports, immer noch moeglich macht. Aber in dem betreffenden Bereich ist natuerlich nicht viel zu machen -- fuer unkontrollierbare Uebertragungen reicht das.
Mein denken 2.!! Volles ACK. Da kann man anscheinend die fw weglassen weil man's niemmer firewall nennen dürfte.
Na ja, ganz weglassen waere auch keine gute Idee. Immerhin lassen sich auch dann noch eine Reihe von Angriffen blockieren, wenn man nur einen Teil der Ports sperren kann. Der Schutz ist "nur" nicht mehr vollstaendig.
So wie ich das seh sind ja anscheinend fast ALLE unpreveligierten ports mal dann wann zu öffnen.
Das grosse Problem ist, dass (nicht nur) H.323 die Sprachuebertragung per RTP vorsieht, und das basiert nun einmal auf UDP. Daran laesst sich auch wenig aendern, da TCP sich nicht fuer die Uebertragung von Medienstroemen in Echtzeit eignet. Waehrend man bei TCP noch unterscheiden kann, ob eine Verbindung von innen oder von aussen initiiert wird, und somit gezielt eine Richtung verbieten kann, hat man es bei UDP einfach nur mit einzelnen Paketen zu tun -- da sieht eines wie das andere aus und es gibt keine festen Verbindungen, denen man sie zuordnen koennte. Man muesste schon die gesamte Aushandlung der Parameter zwischen den beteiligten Endpunkten mitlesen, um dynamisch nur die gerade benoetigten Ports freischalten zu koennen. Das duerfte ein ziemlicher Aufwand sein...
Zumindest so was ich bislang an Infos habe. Die M$ler kommen aber auch immer wieder auf Klopper ..tststs
Ausnahmsweise mal kein MS-spezifisches Problem :( Eilert -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Eilert Brinkmann -- Universitaet Bremen -- FB 3, Informatik eilert@informatik.uni-bremen.de - eilert@tzi.org - eilert@linuxfreak.com http://www.informatik.uni-bremen.de/~eilert/ --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Am Don, 17 Aug 2000 schrieb Eilert Brinkmann:
das problem ist ganz einfach das H.323 (netmeeting) dynamische UDP-Ports verwendet
Nicht nur UDP-Ports. Das Call-Signalling laeuft zwar in der Regel ueber einen festgelegten TCP-Port (1720), aber da kommen auch noch andere TCP-Verbindungen (fuer H.245) ins Spiel, die nicht mit festen Ports arbeiten.
Laut der Firewall-Anleitung von Little-Idiots sinde es folgende Ports für Netmeeting: PORT TCP/UDP STATIC/DYN. PROTOCOL NETMEETING 389 TCP statisch LDAP Internet Locator Server (ILS) 522 TCP statisch ULP User Location Service 1503 TCP statisch imtc-mcs T.120 1720 TCP statisch h323hostcall H.323 Anruf 1731 TCP statisch msiccp Audio Anruf 1024+ TCP dynamisch H.245 H.323 Anrufkontrolle 1024+ UDP dynamisch RTP/RTCP H.323 streaming (RTP) Man sollte sich aber in jedem Fall die Hinweise dazu durchlesen und sich dann mindestens zweimal überlegen, ob man das wirklich will... -- Machs gut | http://www.iiv.de/schwinde/buerger/tremmel/ | http://www.knightsoft.de Manfred | http://www.knightsoft-net.de -> Bundesliga-Tipprunde! --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* On Fri, Aug 18, 2000 at 08:42:46PM +0200, Manfred Tremmel wrote:
Am Don, 17 Aug 2000 schrieb Eilert Brinkmann:
das problem ist ganz einfach das H.323 (netmeeting) dynamische UDP-Ports verwendet
Nicht nur UDP-Ports. Das Call-Signalling laeuft zwar in der Regel ueber einen festgelegten TCP-Port (1720), aber da kommen auch noch andere TCP-Verbindungen (fuer H.245) ins Spiel, die nicht mit festen Ports arbeiten.
Laut der Firewall-Anleitung von Little-Idiots sinde es folgende Ports für Netmeeting:
Ups,...nicht gesehen als ich meins postete ;) ...können wir mal vergleichen ;)
PORT TCP/UDP STATIC/DYN. PROTOCOL NETMEETING 389 TCP statisch LDAP Internet Locator Server (ILS) 522 TCP statisch ULP User Location Service 1503 TCP statisch imtc-mcs T.120 1720 TCP statisch h323hostcall H.323 Anruf 1731 TCP statisch msiccp Audio Anruf 1024+ TCP dynamisch H.245 H.323 Anrufkontrolle 1024+ UDP dynamisch RTP/RTCP H.323 streaming (RTP)
Man sollte sich aber in jedem Fall die Hinweise dazu durchlesen und sich dann mindestens zweimal überlegen, ob man das wirklich will...
Mache müßen es aus versch. Gründen. Die Industrie hat uns leider alle nicht gefragt als die "lizenzen" vergeben würden :( ...obwohl ICH streng der Meinug bin; Der Kunde hat es wohl gewollt. Wäre es sonst alles so verbreitet? Einen Netzwerkadmin/Sicherheitsexperte sträuben sich naklar die Haare wenn er solche Maschinen zu verantworten hat. Aber er wird auch einen Kompromiss finden / müßen. Gruß Clemens -- sig_23 kopieren mit dd: (zB. auf Floppy) [Info: man dd] $ dd if=<zu_kopierendes> of=/dev/fd0 [X-Page:http://www.ndh.net/home/wohld/index.html] -------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* On Thu, Aug 17, 2000 at 11:36:16PM +0200, Eilert Brinkmann wrote:
Clemens Wohld <c.wohld@ndh.net> wrote:
* On Tue, Aug 15, 2000 at 01:57:54PM +0200, Joerg Henner wrote:
On Die, 15 Aug 2000, Clemens Wohld wrote:
hat hier jemand eine clevere Lösung trotz "Netmeeting" eine firewall aufzuziehen? [...] das problem ist ganz einfach das H.323 (netmeeting) dynamische UDP-Ports verwendet
Nicht nur UDP-Ports. Das Call-Signalling laeuft zwar in der Regel ueber einen festgelegten TCP-Port (1720), aber da kommen auch noch andere TCP-Verbindungen (fuer H.245) ins Spiel, die nicht mit festen Ports arbeiten.
Nicht nur,.... Da wären dann noch Dienst protocoll port CosmoCalling register-Port (tcp) 2324 www (tcp) 80 H.323 ports: ILS (tcp) 389 ULS (tcp) 522 T.120 (tcp) 1503 H.323 callsetup (tcp) 1720 Audio call contr. (tcp) 1731 H.323 call contr. (tcp) dynamic H.323 stream (rtp over udp) dynamic M$ Exchanche: (gehört nunmal dazu) RPC Communic. (tcp) 135 Directory services (tcp) stat. assigned Inform. services (tcp) stat. assigned Das ist dann schon beinahe gewesen......ohhh help. Ich kann mich mit sowas garnicht anfreunden. Mag sein das ich den "Stuss" den M$ so vabriziert nicht nachfolziehen kann. *sorry* ..iss so ,)
- und sorry, dabei kann man beim besten willen nimmer von firewall reden ... ganz egal welches produkt man dann einsetzt.
Betroffen ist wahrscheinlich nur ein bestimmter Bereich von Ports, die fuer dynamische Vergabe verwendet werden (kann man bei Windows eigentlich von >1024 ausgehen?),
Neee, das wäre ja schon ein Stückweit normaler....
was einen Schutz der uebrigen Ports, immer noch moeglich macht. Aber in dem betreffenden Bereich ist natuerlich nicht viel zu machen -- fuer unkontrollierbare Uebertragungen reicht das.
Ich sag nur; schnell die DMZ aufstellen ;) Dort die Nettmeetingmaschinen und ExChange-server rein. Wenn DNS-server vorhanden den auch noch. Nur das blöde,.....es ist ein DHCP-system :(
Mein denken 2.!! Volles ACK. Da kann man anscheinend die fw weglassen weil man's niemmer firewall nennen dürfte.
Na ja, ganz weglassen waere auch keine gute Idee. Immerhin lassen sich auch dann noch eine Reihe von Angriffen blockieren, wenn man nur einen Teil der Ports sperren kann. Der Schutz ist "nur" nicht mehr vollstaendig.
Klar. Auch die Pflege einer firewall fördert immer wieder neue rules (wenn man logfiles liest ;). Abuse gibts doch auch noch. Oder?
So wie ich das seh sind ja anscheinend fast ALLE unpreveligierten ports mal dann wann zu öffnen.
Das grosse Problem ist, dass (nicht nur) H.323 die Sprachuebertragung per RTP vorsieht, und das basiert nun einmal auf UDP. Daran laesst sich auch wenig aendern, da TCP sich nicht fuer die Uebertragung von Medienstroemen in Echtzeit eignet.
ACK
Waehrend man bei TCP noch unterscheiden kann, ob eine Verbindung von innen oder von aussen initiiert wird, und somit gezielt eine Richtung verbieten kann, hat man es bei UDP einfach nur mit einzelnen Paketen zu tun -- da sieht eines wie das andere aus und es gibt keine festen Verbindungen, denen man sie zuordnen koennte. Man muesste schon die gesamte Aushandlung der Parameter zwischen den beteiligten Endpunkten mitlesen, um dynamisch nur die gerade benoetigten Ports freischalten zu koennen. Das duerfte ein ziemlicher Aufwand sein...
Das ist der springende Punkt,....diese dynamic-Geschichten.
Zumindest so was ich bislang an Infos habe. Die M$ler kommen aber auch immer wieder auf Klopper ..tststs
Ausnahmsweise mal kein MS-spezifisches Problem :(
Was? Wo kommt Netmeeting und M$ Exchange denn her?? Oder meinst du weil es so verbreitet ist und nunmal von vielen anderen OS' verwaltet werden will? Gruß Clemens -- sig_47 -*-grepen in rc-files-*- [Info: man grep] $ grep -v ^# /etc/ppp/options | grep -v ^$ $ grep -v ^# /etc/rc.config | grep -v ^$ ------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Clemens Wohld schrieb am 19.08.2000 um 01:27:18 +0200: Hallo Clemens,
* On Thu, Aug 17, 2000 at 11:36:16PM +0200, Eilert Brinkmann wrote:
Ausnahmsweise mal kein MS-spezifisches Problem :(
Was? Wo kommt Netmeeting und M$ Exchange denn her?? Oder meinst du weil es so verbreitet ist und nunmal von vielen anderen OS' verwaltet werden will?
nein, darum geht es nicht. Netmeeting baut auf H.323 auf. H.323 ist eine Empfehlung der ITU (Internationale Fernmeldeunion) und beschreibt den Transport von Multimediadaten über IP-basierte Netzwerke die keine QoS haben. Es besteht aus Terminals, Gateways, Gatekeeper und Multiple Control Units. Terminals sind wie man sich denken kann die Endpunkte der Kommunikation. Es werden zwischen diesen Audio/Videodaten, Datenpakete und Steuersignale übertragen. Für jede Datenart gibt es wiederum eigene Codecs, abhängig von den verwendeten Resourcen, genormt sind z.B. H.245 und Q.931 In den Gateways erfolgt die Umsetzung von einer Übertragungsart in eine andere und die damit verbundene Umsetung der Übertragungsformate (Codecs). Gatekeeper haben die Aufgabe beim Verbindungsaufbau die Zugangsberechtigung der Benutzer zu überprüfen, Adressumsetzungen durchzuführen und die Bandbreite zu verwalten. Multiple Control Units werden bei Konferenzschaltungen zwischen 3 oder mehreren Terminals benötigt. Das hat überhaupt nichts mit Microsoft zu tun. Man sollte MS nicht für alles verantwortlich machen. Währe es Dir lieber MS hätte für Netmeeting wieder sein eigenes Süppchen gekocht und ein Protokoll erfunden das zu rein garnichts kompatibel ist, vielleicht sogar noch nicht einmal zu sich selber? Bis denne, Michael -- This video needs like more explosions and close-ups of butts. (Butthead) --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Clemens Wohld <c.wohld@ndh.net> wrote:
* On Thu, Aug 17, 2000 at 11:36:16PM +0200, Eilert Brinkmann wrote:
Das ist der springende Punkt,....diese dynamic-Geschichten.
Und die werden sich fuer solche Dienste leider nur schwer vermeiden lassen :(
Ausnahmsweise mal kein MS-spezifisches Problem :(
Was? Wo kommt Netmeeting und M$ Exchange denn her??
Die *Implementierung* stammt von MS, basiert aber (ausnahmsweise) auf einem Standard, naemlich der ITU-Empfehlung H.323 (die wiederum auf etliche andere Standards Bezug nimmt). Daran haben zwar AFAIK auch MS-Leute mitgearbeitet, aber z.B. auch ein Mensch aus dem Buero nebenan (der arbeitet nicht fuer MS) und eine Menge anderer Leute. Zugegeben, dieser Standard hat auch seine unschoenen Seiten, vor allem, wenn man Teile davon implementieren muss... Aber in mancher Hinsicht, z.B. was die Nutzung dynamischer Ports fuer die Sprachuebertragung etc. angeht, duerfte es schwierig werden, sinnvolle Alternativen zu finden. Eilert -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Eilert Brinkmann -- Universitaet Bremen -- FB 3, Informatik eilert@informatik.uni-bremen.de - eilert@tzi.org - eilert@linuxfreak.com http://www.informatik.uni-bremen.de/~eilert/ --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Das ist der springende Punkt,....diese dynamic-Geschichten.
Die *Implementierung* stammt von MS, basiert aber (ausnahmsweise) auf einem Standard, naemlich der ITU-Empfehlung H.323 (die wiederum auf etliche andere Standards Bezug nimmt). Daran haben zwar AFAIK auch MS-Leute mitgearbeitet, aber z.B. auch ein Mensch aus dem Buero nebenan (der arbeitet nicht fuer MS) und eine Menge anderer Leute. Zugegeben, dieser Standard hat auch seine unschoenen Seiten, vor allem, wenn man Teile davon implementieren muss... Aber in mancher Hinsicht, z.B. was die Nutzung dynamischer Ports fuer die Sprachuebertragung etc. angeht, duerfte es schwierig werden, sinnvolle Alternativen zu finden.
Der Masquerading Proxy für LINUX 2.2.16 ist fast fertig. Er hat nur noch ein kleines Problem: Wenn man zu mehreren gleichzeitig eine Verbindung in das Internet aufbauen möchte, dann kommt es zu Verwechselungen. Wenn man aber nacheinander die Verbindungen aufbaut, ist er stabil. In ca. 1 Woche lege ich ihn unter http://www.little-idiot.de/firewall/ ins Netz. Masquerading läuft auch fein. Installiert wird er nach einem Kernelpatch mit insmod bzw. genauso, wie alle anderen Kernel Module. Ich denke, daß SuSE 7.0 den auch schon integriert hat. Bin ja mal gespannt. Gru/3, Guido Stepken
Eilert -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Eilert Brinkmann -- Universitaet Bremen -- FB 3, Informatik eilert@informatik.uni-bremen.de - eilert@tzi.org - eilert@linuxfreak.com http://www.informatik.uni-bremen.de/~eilert/
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
participants (5)
-
c.wohld＠ndh.net -
eilert＠Informatik.Uni-Bremen.DE -
Manfred.Tremmel＠iiv.de -
micha28＠gmx.de -
suse＠little-idiot.de