Backdoor via 'QoS'

[Koppelfeld]

Hallo zusammen,
bislang hat es für mich ausgereicht, zu QoS-Zwecken einfach nur UDP zu priorisieren.
Denn 'zeitunkritische' und nutzbringende Anwendungen sind typischerweise statusbehaftet und auf Basis TCP. X11 über ssh, mehr brauchen Terminal-Benutzer eigentlich nicht in Niederlassungen.

Jetzt aber möchte ein Kunde idiotischerweise "PCs" installieren mit "Microsoft Skype for Business" und noch andere Dinge wie "WebRTC". Beides hört sich so scheußlich an, daß es gar nix taugen kann und übermäßigen Datendurchsatz garantiert.
Offenbar mißbrauchen diese Abartigkeiten auch UDP, denn jetzt sind Keine Faxe und auch keine ungestörten Telephonate mehr möglich.

Naja, unsere TK-Anlagen setzen typischerweise ja sowieso den DiffService-Typ 'EF' und wir konfigurieren auch die von uns verwalteten Endgeräte qua Autoprovisioning passend.

Nun habe ich den Artikel von Forumsmitglied Joe Loser noch in Erinnerung, er schreibt ja immer sehr unterhaltsam. Unter anderem referenziert er Hinweise aus der 'Lancom Knowledge Base' und die üblichen Verdächtigen Jirka und Dr. Einstein.

Und jetzt hoffe ich, einem kapitalen Irrtum aufzusitzen:

Joe empfiehlt, auch mit Bezug auf die KB, eine hoch priorisierte Regel 'ACCEPT_EF' zu definieren, die als Aktion ein ziemlich aufwendiges QoS-Konstrukt, aber auch einen 'ACCEPT' beinhaltet.
Und zwar von 'ANY' zu 'ANY'.

Das heißt doch jetzt nix anderes, als daß jedes mit 'EF' getaggte Paket durch die Firewall rutscht ???????? Also, schön ist das nicht. Bitte sage mir jemand, ich sei auf dem falschen Dampfer.

[backslash]

hi Koppelfeld,

Bitte sage mir jemand, ich sei auf dem falschen Dampfer.

kann ich leider nicht, denn es bedeutet genau das...

Sicherheit bietet eigentlich nur das SIP-ALG (oder besser noch der VCM), denn der öffnet nur im SIP ausgehandelten die RTP-Ports und versieht sie gleich mit der nötigen Bandbreite...

Wenn du das SIP-ALG hingegen nicht nutzen willst, solltest du Allow-Regeln nur für die jeweiligen Telefone (Telefone -> ANY) oder wenn du eine eigene TK-Anlage hast, die auch die RTP-Ströme terminiert (Media-Proxy), nur für die TK-Anlage (TK-Anlage -> ANY) erstellen. Und wenn dein SIP-Provider auch noch einen Media-Proxy unterhält, dann kannst du das noch weiter einschränken (TK-Anlage -> Provider-Media-Proxy) - nur mit der Abhörsichertheit hast du dann ein Problem...

Gruß
Backslash

[Dr.Einstein]

Hallo Koppelfeld,

mach doch die QoS Regel mit Any / Any und sag dieser Regel "weitere Regeln beachten". Und danach kommt ganz normal dein Allow/Deny-All Regelwerk.

Gruß Dr.Einstein

[Koppelfeld]

Hallo,

Sicherheit bietet eigentlich nur das SIP-ALG (oder besser noch der VCM), denn der öffnet nur im SIP ausgehandelten die RTP-Ports und versieht sie gleich mit der nötigen Bandbreite...

... den nehme ich auch sehr gerne als "Luxus-ALG" her und das funktioniert auch ganz hervorragend, sogar mit Telekom-Anschlüssen. Außerdem ist der VCM die einzige Möglichkeit, einen bestimmten SIP-Account einem bestimmten Provider zuzuordnen.

Wenn du das SIP-ALG hingegen nicht nutzen willst, solltest du Allow-Regeln nur für die jeweiligen Telefone (Telefone -> ANY) oder wenn du eine eigene TK-Anlage hast, die auch die RTP-Ströme terminiert (Media-Proxy), nur für die TK-Anlage (TK-Anlage -> ANY) erstellen. Und wenn dein SIP-Provider auch noch einen Media-Proxy unterhält, dann kannst du das noch weiter einschränken (TK-Anlage -> Provider-Media-Proxy)

Ja, so werde ich es dann machen. Allerdings überlege ich auch, die störenden PCs auf 7,5KBit/s herunterzushapen - es stehen doch alle so auch ISDN.

Aber ein Hinweis in der Knowledge Base ("Achtung, potentielle Gefährdung") wäre nicht verfehlt.

[Koppelfeld]

mach doch die QoS Regel mit Any / Any und sag dieser Regel "weitere Regeln beachten". Und danach kommt ganz normal dein Allow/Deny-All Regelwerk.

Ah, Danke. Das ist deutlich besser als die QoS-Regel zu "überladen".

[Koppelfeld]

Hallo Dr. Einstein,

mach doch die QoS Regel mit Any / Any und sag dieser Regel "weitere Regeln beachten". Und danach kommt ganz normal dein Allow/Deny-All Regelwerk.

Gesagt, getan.
Und nun:
Von etwa 30 RTP-Verbindungen sieht man unter LCOS/Status/Verbindungen typischerweise zwei bis drei, für die die (richtig definierte) Regel NICHT greift. Wohlgemerkt, bei gleichen Quell- und Zielhosts, gleichen Protokollen etc. pp..
Auffällig: Diese "Ausreißer" haben in der "Flags" - Spalte ausnahmlos eine '8' vorneweg, die richtig zugeordneten Verbindungen dagegen eine '1'.

Weiß jemand etwas dazu ?

[backslash]

Hi Koppelfeld,

eine "8" im höchstwertigen Nibble besagt, daß die Regel eine reine Accept-Regel ist, d.h. ohne QoS, Limiter, Bedingungen etc... Das heißt letztendlich, daß die Regel mit der Mindestbandbreite nicht gegriffen hat und stattdessen die nächste reine Accept-Regel. Hier mußt du ggf. mit dem Firewall-Trace schauen, warum die QoS-Regel nicht greift...

Verwendest du policy based routing? Da haben sich in der 9.10 ein paar Probleme eingeschlichen, die aber in der aktuellen 9.20 gefixt sind. Also ggf. mal mit der aktuellen 9.20 (auch wenn sie noch Beta ist) versuchen...

Gruß
Backslash

[Koppelfeld]

Hallo Backslash,

Hi Koppelfeld,
Verwendest du policy based routing? Da haben sich in der 9.10 ein paar Probleme eingeschlichen, die aber in der aktuellen 9.20 gefixt sind. Also ggf. mal mit der aktuellen 9.20 (auch wenn sie noch Beta ist) versuchen...

Super, prima, klasse - DANKE!
Jetzt laufen laut Verbindungsliste alle Verbindungen der TK-Anlage ordentlich über die vorgesehenen Regeln.
Ein Phänomen bleibt:

Aktion "ACCEPT_EF": '%Lcds0 @dEF %A'
Aktion "QOS_RTP": '%Ft576 @dEF %Fpt576 @dEF %Qctds110 @dEF'

Bei Kundenrouter A sehe ich nur unter Status/IP-Router/TX-Bevorzugt ein Mehrfaches von 110 entsprechend der Anzahl der RTP/RTCP-Verbindungen ausschließlich in der Spalte 'TX-bevorzugt'.

Beim identisch konfigurierten Kundenrouter B, mit der Ausnahme, daß kein 'policy based routing' involviert ist, sehe ich dieses Mehrfache von 110 in den Spalten 'RX-Reserviert' und 'TX-Reserviert', nicht aber in 'TX-Bevorzugt'.

QoS funktioniert bei beiden Systemen, der Maximaldurchsatz ist auf allen DSL-Interfaces richtig konfiguriert.

[backslash]

Hi Koppelfeld,

Aktion "ACCEPT_EF": '%Lcds0 @dEF %A'
Aktion "QOS_RTP": '%Ft576 @dEF %Fpt576 @dEF %Qctds110 @dEF'

Bei Kundenrouter A sehe ich nur unter Status/IP-Router/TX-Bevorzugt ein Mehrfaches von 110 entsprechend der Anzahl der RTP/RTCP-Verbindungen ausschließlich in der Spalte 'TX-bevorzugt'.

Beim identisch konfigurierten Kundenrouter B, mit der Ausnahme, daß kein 'policy based routing' involviert ist, sehe ich dieses Mehrfache von 110 in den Spalten 'RX-Reserviert' und 'TX-Reserviert', nicht aber in 'TX-Bevorzugt'.

Bist du sicher, daß das gleich konfiguriert ist? Das klingt so, als ob im Router B %Qcfds110 statt %Qctds110 steht... (f für "force" statt t für "nur Tx")

Gruß
Backslash

[Koppelfeld]

Beim identisch konfigurierten Kundenrouter B, mit der Ausnahme, daß kein 'policy based routing' involviert ist, sehe ich dieses Mehrfache von 110 in den Spalten 'RX-Reserviert' und 'TX-Reserviert', nicht aber in 'TX-Bevorzugt'.

Bist du sicher, daß das gleich konfiguriert ist? Das klingt so, als ob im Router B %Qcfds110 statt %Qctds110 steht... (f für "force" statt t für "nur Tx")[/quote]
Ja, soeben nochmal geprüft.

ABER:
Es existiert ein kompletter Regelsatz, in dem ich mit %Qcfds110 experimentiert hatte. Der ist jedoch seit längerer Zeit abgeschaltet. Werde diese alten Regeln probehalber einmal ganz entfernen. Oder zumindest den Router neu starten.

[Koppelfeld]

Moinsen,

Hi Koppelfeld,
Verwendest du policy based routing? Da haben sich in der 9.10 ein paar Probleme eingeschlichen, die aber in der aktuellen 9.20 gefixt sind. Also ggf. mal mit der aktuellen 9.20 (auch wenn sie noch Beta ist) versuchen...

Sah gestern alles sehr gut aus mit der 9.20RC2.

Sprich: Es werden mit der 9.20 die "passenden" Regeln gefunden, während bei der 9.10 manchmal falsche Regeln verwendet werden, natürlich welche, die niedriger priorisiert sind.

Aber heute Morgen konzertierter Userangriff: "Wir können keine Mails schicken ..."
Die richtige Regel für Outbound-SMTP wird gefunden, die Regel setzt Tag 5, der (einzige!!!) Routing - Eintrag für Tag 5 in der Routingtabelle verweist auf Provider B, geroutet wird aber nach Provider A.

Habe das Problem mit einer passenden Hostroute zwar umgehen können, aber ich habe jetzt schon Bauchschmerzen, was noch alles nicht funktionieren könnte ....

[Bernie137]

Verwendest du policy based routing? Da haben sich in der 9.10 ein paar Probleme eingeschlichen, die aber in der aktuellen 9.20 gefixt sind. Also ggf. mal mit der aktuellen 9.20 (auch wenn sie noch Beta ist) versuchen...

Hi, kannst Du die Probleme konkreter schildern?

Gruß Bernie

[Koppelfeld]

Verwendest du policy based routing? Da haben sich in der 9.10 ein paar Probleme eingeschlichen, die aber in der aktuellen 9.20 gefixt sind. Also ggf. mal mit der aktuellen 9.20 (auch wenn sie noch Beta ist) versuchen...

Hi, kannst Du die Probleme konkreter schildern?

Moin! Ich kann die Probleme nur zu gut schildern:
Wenn Routing Tags verwendet werden, dann gerät entweder die effektive Reihenfolge der FW-Regeln durcheinander oder aber es werden Regeln manchmal quasizufällig überlesen.
Hieß in meinem Fall, daß QoS - Regeln manchmal griffen und manchmal nicht. Reproduzierbar auf drei unterschiedlichen und unterschiedlich konfigurierten Routern.

Mit der 9.20RC2 war das Problem dann in allen drei Fällen behoben,
freilich wurde nun ein in der FW-Sektion zugewiesenes Routing-Tag in der Routing-Tabelle nicht mehr ausgewertet.
Das war nicht fatal, denn ein dedizierter Hostrouten-Eintrag konnte dieses Einzelphänomen umgehen. Das ist bloß nicht gerade Sinn der Sache.

Ich habe jetzt, überspitzt ausgedrückt, die Wahl:
- Funktionierendes Routing mit 9.10 oder
- funktionierende Firewall mit 9.20

Es wird nicht einfacher dadurch, daß mit 9.20 der VCM beim Anlegen eines SIP - Users abstürzt und der Router neu startet.

Wenn dann noch ein dringend benötigter Mobilrouter nach 4 bis sechs Stunden reproduzierbar abstürzt, mit unterschiedlichen FW-Ständen, dann hat man schonmal Spaß. Im letzteren Fall könnte 'cpuprofi' mit einem Neugerät am Pfingstsonntag aushelfen.

Aber insgesamt habe ich mir Pfingsten anders vorgestellt.