[Gelöst] [be ip plus] Firewall konfigurieren

[weißnix_]

Mich nerven z.Zt. sich häufende Angriffe auf den VoIP-Server. Grundsätzlich ist bei mir Registrierung nur in priv. Netzwerken aktiv. Der VoIP-Server weist die Angriffsversuche auch korrekt ab. Was mich stört: Eigentlich steht der Angreifer schon hinter der Firewall am angegriffenen System.

Also hab ich eine Regel für einen definiert, die aber ignoriert wird. Es scheint also eine höchstpriorisierte FW-Regel zu geben für Port 5060. Wäre das nichtmal nachdenkenswert für eine Änderung?

 

[weißnix_]

Ich denke, ich habe die interne FW-Regelkette gefunden. Im SNMP-Browser unter IP-->ipSifExpectTable

Edit: Ich werde da mal probieren, die Regeln zu verbiegen. Da es sich hier aber um einen sensiblen Bereich mit etwas schwer zu überschauenden Abhängigkeiten handelt würde ich mir etwas mehr Komfort wünschen.

konkret: Könnte bintec es nicht möglich machen, in der GUI zu spezifizieren, das benutzerdefinierte Regeln vor den integrierten Regeln eingefügt werden können.
Möglicherweise kann das @Kalle2006 oder jmd. anders an bintec herantragen.

 

[weißnix_]

Offensichtlich muss ich hier noch Abhängigkeiten finden. Es ist mir nicht gelungen eine beliebeige Testregel einzufügen. Ganz zu schweigen von der Beeinflussung der Regelabfolge...

 

[weißnix_]

Stand der Ermittlungen:
Die sif*-Einträge werden anscheinend automatisch aus den NAT-Regeln generiert. Bekanntlich gibt es da ja zwangsläufig die Regeln für 5060 UDP/TCP.
2 Ansätze:
1. die störenden Adressbereiche per NAT-Regel in's Nirvana schicken (wird scheitern, weil ich keine NAT-Regel davor hinkriege
2. Die verursachenden NAT-Regeln modifizieren und auf den Adressbereich meines Providers beschränken

Nummer 2 wird auch nicht gehen, da die automatisch generierten Einträge sich nicht bearbeiten lassen

 

[weißnix_]

Neuer Ansatz: Accessregeln

Im ersten Versuch hab ich es schon geschafft, mich komplett auszusperren
Schon blöd, wenn man Remote drauf ist (war) und keiner vor Ort, der mal eben den Steckerreset durchführen kann

Mal sehen, ob ich damit klarkomme...
Zumindest geht das wieder komplett via GUI und ich muss nicht im SNMP-Browser rumstochern.

 

[weißnix_]

Also dieser von mir wenig beachtete Punkt Netzwerk-->Zugriffsregeln macht (bisher), was ich will.
Die Zugriffe landen im Nirvana (Refuse-Schnittstelle) und gut is.

Es kann manchmal so einfach sein....
Auf den Punkt war ich gekommen, weil laut SNMP-Browser die Zugriffsregeln als erstes abgearbeitet werden.

 

[Tom7320]

Freut mich, auch wenn ich nicht helfen konnte...
Werden die Zugriffsregeln vor der SIF aktiv? Auf welchem Betriebssystem läuft eigentlich die be.ip? Irgendwas unixoides wird's schon sein, oder?

Schönes Wochenende!

 

[weißnix_]

bintec sagt: Eigens entwickelt. Heisst für mich: unixbasiert.

Die Zugriffsregeln stehen in der sif anscheinend ganz oben. Vorsicht, hier kann man sich leicht aussperren. Regelketten werden mit Schnittstellenzuweisung aktiv. Für den Start also vorsichtshalber eine allow-all-Regel ans Ende der Kette stellen (bei Verbotsketten). Die kann ja wenn's läuft entfernt werden.

 

[weißnix_]

@Kalle2006
ich muss dich jetzt mal explizit benennen

Wer "meinen Kampf" bis hierhin mit einem Schmunzeln verfolgt hat weiß ja worum es geht:
Wie blocke ich Netzwerkzugriffe auf meine be.ip, welche eigentlich von impliziten Regeln erlaubt werden. Hier also Zugriffe auf UDP 5060.

Bis jetzt habe ich ganz gute Erfolge erzielt: Ich habe unerwünschte Zugriffe identifiziert und die entsprechenden Netzwerke als Regel in der Zugriffskontrolle via GUI eingefügt.
Diese Regeln hab ich als Regelkette gruppiert und an eine Schnittstelle zugewiesen.

Dabei fiel mir auf, das IP's aus Netzwerken, die eigentlich zu einer Verbotsregel (später eingefügt) gehören trotzdem durchkamen. Jetzt habe ich das ganze Regelwerk vereinfacht und neu aufgebaut.
Der Effekt blieb der gleiche.

Also hab ich wieder den SNMP-Browser aufgemacht und mir mal die Regelkette unter ip-->ipRuleTable angesehen. Da es sich um eine Regelkette handelt, beinhaltet jeder Eintrag einen Verweis auf den Folgeeintrag.
Oh Wunder: Die angezeigte Reihenfolge in der GUI stimmt nicht mit der Abarbeitungsreihenfolge überein. Die Abarbeitungsreihenfolge sieht man in der GUI, wenn man einen Eintrag zu verschieben versucht. Dann wird vor jeder Regel die Abbarbeitungnummer angezeigt. Nachdem ich die Kette jetzt nach dieser Nummer sortiert habe, funzt es wie gewünscht.


Kern meiner Beschwerde: Die angezeigte Reihenfolge in Netzwerk-->Zugriffsregeln-->Regelketten stimmt jedenfalls nicht mit der Realität überein.
Ich muss mal sehen, inwieweit das für die anderen Ketten (Firewall, QoS) auch so nachvollziehbar ist.

Edit: Hab mal Screens zur Veranschaulichung eingefügt. Im Screen 2 haben die Regeln Nummern. Damit das Konstrukt wie gewünscht funktioniert müssen die Regeln 17,18 und 19 in dieser Reihenfolghe als letztes abgearbeitet werden. Den Anschein hat es aber nicht, wenn man sich nur das Abbild in der GUI ansieht...

 

[weißnix_]

Anekdote am Rande:
192.129.8.3 tauchte immer wieder im Log auf. Whois sagt "Regierungsnetz Niedersachsen".
Ich war schon dem Verschwörungstheoretikerwahn fast erlegen, als mir einfiel, das das der heise Netzwerkscan ist....

OMG

Egal: Ziel war das hier bei funktionierender Telefonie:(heise Netzwerkscan auf 5060-5062)