IPFire funktioniert/arbeitet ABER kein Zugriff mehr auf Konfiguration (via Webinterface ODER SSH)...

Post Reply
SomeITguy
Posts: 2
Joined: February 8th, 2019, 12:11 pm

IPFire funktioniert/arbeitet ABER kein Zugriff mehr auf Konfiguration (via Webinterface ODER SSH)...

Post by SomeITguy » March 14th, 2019, 9:45 am

Hallo,

ich habe ein etwas obskures Problem und hoffe dass mir irgendjemand vlt. noch einen Tipp geben kann... :(

Und zwar kann ich seit kurzem nicht mehr via Webinterface oder SSH auf ein IPFire-System zugreifen - Ihren "Dienst" tut die IPFire aber nach wie vor. Wichtig ist noch dass die IPFire insbesondere auch Traffic von innen/Green filtern sollte, so dass nur gezielt freigegebene Dienste & Websites (Red) verwendet/besucht werden können (Entwicklernetzwerk, bis vor kurzem komplett offline). Blue gibt es nicht.

1. Version ist ipfire-2.19, Squid-Webprox ist aktiv (transparent), erst vor 2-3 Wochen aufgesetzt.

2. Die IPFire tut ihren Dienst noch insofern dass sowohl ein Remotezugang via Portforwarding von Red -> Green als auch der Zugriff auf die wenigen bislang freigegebenen Websites (Green -> Red) nach wie vor funktioniert.

3. Das letzte was bewusst geändert wurde ist die zus. Freigabe einer weiteren Website (klappt), die Standardmäßig von der IPFire selbst verwendeten Ports 81, 444 und für SSH 22 bzw. 222 wurden alle def. NICHT für eine Weiterleitung oder dgl. eingetragen (genaugenommen wurden diese wenn dann immer NUR als Ausnahmen z.B. für Proxy eingetragen).

4. Aufruf-/Anmeldeversuche via IP und Port 81 o. 444 im Firefox, 22 o. 222 SSH aus der Bash -> Seit kurzem immer nur Timeout.
(Bin mir nicht 100% sicher ob die Option im Webinterface die zwischen 22 und 222 umschaltet zuletzt aktiviert war oder nicht, darum versuch ich aktuell ggf. immer beides, sicherheitshalber.)

5. Da ich mich nur noch direkt am System anmelden und via Terminal arbeiten kann, hab ich versucht in den Konfigurationsdateien vorerst Ausnahmen für alle genannten Ports & das komplette Subnet (Green) einzutragen*, damit def. weder transparenter Proxy noch Firewall meinen Zugriff auf Webinterface o. SSH irgendwie behindern - Hat aber leider alles nichts genützt (natürlich inzwischen schon diverse male neu gestartet).

( *Mit Hilfe von: https://wiki.ipfire.org/configuration/n ... /conf_edit und viewtopic.php?t=3813 sowie viewtopic.php?t=18667&start=15 )

Das sind z.B. die Firewall-Ausnahmen die ich jetzt nachträglich noch manuell in die /etc/sysconfig/firewall.local eingetragen habe (eine /etc/sysconfig/firewall.rules wie im verlinkten Post beschrieben gibt es hier nicht (evtl. eine überholte Info?), der Aufbau ("## add your 'start' rules here" usw.) der vorhandenen /etc/sysconfig/firewall.local war aber identisch und dort hab ich also meine Ausnahmen eingetragen):

Code: Select all

# See how we were called.
case "$1" in
  start)
        ## add your 'start' rules here
    	sudo iptables -A INPUT -p tcp -s 192.168.110.0/24 --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
    	sudo iptables -A OUTPUT -p tcp --sport 22 -m conntrack --ctstate ESTABLISHED -j ACCEPT
    	sudo iptables -A INPUT -p tcp -s 192.168.110.0/24 --dport 222 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
    	sudo iptables -A OUTPUT -p tcp --sport 222 -m conntrack --ctstate ESTABLISHED -j ACCEPT
    	sudo iptables -A INPUT -p tcp -s 192.168.110.0/24 --dport 81,444 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
    	sudo iptables -A OUTPUT -p tcp --sport 81,444 -m conntrack --ctstate ESTABLISHED -j ACCEPT
        ;;
  stop)
        ## add your 'stop' rules here
    	sudo iptables -D INPUT -p tcp -s 192.168.110.0/24 --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
    	sudo iptables -D OUTPUT -p tcp --sport 22 -m conntrack --ctstate ESTABLISHED -j ACCEPT
    	sudo iptables -D INPUT -p tcp -s 192.168.110.0/24 --dport 222 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
    	sudo iptables -D OUTPUT -p tcp --sport 222 -m conntrack --ctstate ESTABLISHED -j ACCEPT
    	sudo iptables -D INPUT -p tcp -s 192.168.110.0/24 --dport 81,444 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
    	sudo iptables -D OUTPUT -p tcp --sport 81,444 -m conntrack --ctstate ESTABLISHED -j ACCEPT
        ;;
In die /var/ipfire/proxy/advanced/acls/include.acl hab ich wie gesagt auch Ausnahmen eingetragen.


Wie auch immer, ich Trottel muss mich wohl durch irgendeine frühere Änderung selbst ausgerrt haben(?), auch wenn sich mir absolut nicht erschließt welche das gewesen sein sollte (die ganzen allgemeinen Beschränkungen waren alle schon längst eingestellt und haben - auch nach Reboots - tagelang keine Probleme verursacht)... ein Bug ist aber wohl eher unwahrscheinlich(?)...


Hat irgendjemand noch - irgendeinen - Tipp, was ich evtl. noch versuchen könnte, welche Konfiguration ich ggf. noch manuell anpassen könnte oder dergleichen? :( :( :(


Wäre für jeden Tipp dankbar (das komplette Ding neu aufzusetzen wäre nicht nur lästig, sondern der erwähnte Remote-Zugriff wird momentan auch locker 10 Stunden täglich aktiv von einem externen Entwickler verwendet... und ohne die IPFire hat der Kollege dann temp. ein Problem)...


Vielen Dank fürs Lesen!!

Grüße,
SomeITGuy

teejay
Posts: 19
Joined: August 19th, 2016, 5:52 pm

Re: IPFire funktioniert/arbeitet ABER kein Zugriff mehr auf Konfiguration (via Webinterface ODER SSH)...

Post by teejay » March 15th, 2019, 10:44 am

Neuinstallation außerhalb der Arbeitszeiten...

fredym
Posts: 477
Joined: November 14th, 2016, 2:45 pm

Re: IPFire funktioniert/arbeitet ABER kein Zugriff mehr auf Konfiguration (via Webinterface ODER SSH)...

Post by fredym » March 15th, 2019, 11:39 am

SomeITguy wrote:
March 14th, 2019, 9:45 am
Wichtig ist noch dass die IPFire insbesondere auch Traffic von innen/Green filtern sollte, so dass nur gezielt freigegebene Dienste & Websites (Red) verwendet/besucht werden können (Entwicklernetzwerk, bis vor kurzem komplett offline).
"intelligente Aussperrung" ... aber wer kommt auf solche (blöde??) Idee GREEN ohne Not zu filtern!

Outgoing haben wir früher am Ausgang gemacht ;-)
Also FORWARD (und wenns dann extra noch sein muß) OUTPUT - GREEN nur für "spezielle Freunde" die das Ding umkonfigurien wollen - also "namentlich per IP ".

Lösung (IMHO) alle GREEN Regeln löschen! Kannst das Regelwerk vorher noch irgendwohin (tmp ?) sichern und dann per Editor alle Regel rauswerfen in denen das GREEN-Device vorkommt; Firewall neu starten (/etc/init...).

Na ja.. oder eben ALLE Regeln löschen und alles neu aufbauen - neu installieren tät ich nicht

- Alternativ im eingeloggten Zustand Regeln löschen (mit iptables command, -F ? )
- Nicht am Proxy basteln... iptables Rules setzen für regulären Zugriff... Rest später !
- setzt voraus daß du dich auskennst (auch Squid konfigurieren...), aber dann hättest du hier auch nicht gefragt :-)

Na ja... oder händisch eine Regel dazumachen (iptables kommandozeile) auf Position 1 (!!) die dir (IP) den Zugriff gestattet und dann reparieren

Es gibt eben mehrere Varianten... auch ein serieller Zugriff reicht zum reparieren :-)

Und... mein Gott ... wer wurstelt denn in der INPUT/OUTPUT... feste dauerhafte Regeln maximal in CUSTOM... der GUI Kram steht (aus gutem Grund) noch weiter hinten!

Fred

PS: wenn du eine Regel Portforward via ROT hast, kannst per Editor auch eine für die GUI dazubasteln, mußt eben nur die Zeile kopieren und Ports ändern und iptables neu starten (reload), für Reparaturen kann man das schon mal machen.

Post Reply