1. Aktuelles
  2. Dashboard
  3. Forum
    1. Unerledigte Themen
  4. Mitglieder
    1. Letzte Aktivitäten
    2. Benutzer online
  5. Community vs. Enterprise
  • Anmelden
  • Registrieren
  • Suche
Alles
  • Alles
  • Artikel
  • Forum
  • Seiten
  • Erweiterte Suche
  1. efw-forum - Endian Firewall Support Forum
  2. Mitglieder
  3. burnout

Beiträge von burnout

  • DNS Server

    • burnout
    • 22. November 2010 um 07:18

    Ne, man kann da nur, wie beschrieben, einen anderen DNS Server angeben der für eine bestimmte Zone ZUständig ist (Zone kann auch ein Host sein). In diesem Fall wäre das eine Pseudo-Zone der eigentlich ein Host ist (myserver.dyndns.org -> zuständig 192.168.x.x).
    An diesem Server pflegt man dann den DNS für diese Zone.

    Hosts muss man in der Console /etc/hosts pflegen. Wäre natürlich noch cool, wenns im GUI für die Main-CFG Files nen Editor gäbe. Aber man kann ja nicht alles haben.

    Bei meiner Juniper Firewall kann ich zwar auch statische Hosts pflegen im DNS Proxy ("profi-Gerät"), aber wenn man erst mal ein Netz hat wo man sich überlegt so ein Gerät zu kaufen, hat man mit Sicherheit auch lokal einen oder mehrere richtige DNS Server. Auf diesen "Profi-"Geräten wird die Konfiguration ja meist auch nur über die Console gemacht. So nach dem Motto: Je schwieriger zu konfigurieren, je mehr Befehle man auswendig können muss, je dicker der Notizzettel, desto besser ;) Schließlich will man sich das ordentlich bezahlen lassen. Bei GUI lässt sich da nur schwer argumentieren, die wird gleich mal deaktiviert, hehe :)

  • FIREWALL Protokoll

    • burnout
    • 22. November 2010 um 06:39

    Ja genau. Nur ist es doch in der Praxis eher seltener bei Unternehmen, dass man dort simple HTTP Server zu stehen hat die man nur von außen erreichen soll.

    In meinem Fall tangiert mich das grüne Netz eher peripher, da das "echte" grüne Netz hinter einem VPN hängt was selbst noch mal ne Firewall hat. Das grüne Netz an der Endian hingegen hat dort keine Clients.
    Wenn man bedenkt, dass es gängige Praxis ist im SOHO Bereich per Portforwarding nen SBS-Server im Internet zu exponieren (ROT nach GRÜN), ist das Konzept mit dem Auslagern extern erreichbarer Dienste in die DMZ doch etwas besser.

    Dennoch wird man nicht umhin kommen, einzelne Kanäle von der DMZ in irgendein anderes Netz zu öffnen. Ob grün weil das Netz so klein ist, oder BLAU für die periphere Servergroup...
    Diese KAnäle lassen sich zusätzlich absichern durch IPSEC, User-Authentifizierung, ALGs...

    Sonst verlege ich eben die 2 Linie von GRÜN nach Blau, mir eigentlich egal welche Farbe die haben. Brauch nur an der Site eben 2 Zonen.. :)

    Hat sich übrigens nur deshalb ergeben, weil ich bei der Installation der Firewall eine grüne Zone erstellen musste, um die Kiste überhaupt konfigurieren zu können! Sonst guckt man nämlich etwas bescheiden in die Optionen der Console wenn man wie ich das Netz mit Firewall beginnt und danach erst die anderen Rechner aufsetzen will ;)

    Grüße

  • FIREWALL Protokoll

    • burnout
    • 21. November 2010 um 16:10

    Interessant...

    Ja, man kann dem Server in der DMZ noch ein Interface mit Schnittstelle in Grün geben. Problem gelöst. Und dann beten dass niemand die Kiste hackt ;)

    Mir gings konkret um einen Exchange dort mit ein paar externen Postfächern ohne "kritische Inhalte" mit nem Read-Only Domain Controller um nicht so viel Traffic durchs VPN zu schieben. Die Remote-Site ist nur mit 1 MBit Upload angebunden. Die Site mit der Endian aber 100 Mbit.

    Habe jetzt den RODC nach grün verlegt. Der Exchange bleibt in Orange. Dann kann ich den Auth-Traffic per Route ohne NAT von Orange nach Grün per Firewall-Policy erlauben. Außer es geht _überhaupt kein_ Traffic durch diesen Weg.
    Der Exchange braucht ja selbst nicht durchs VPN, er muss nur den RODC erreichen können. Dieser wiederum muss dann durch den VPN Tunnel kommen, was ja kein Problem ist.

    Ob das funktioniert, soweit bin ich gerade noch nicht...
    Aber falls ja, brauch ich garkein Source-Nat mehr... außer über ROT für das grüne LAN.

    Garkein Verkehr Orange/Grün kann ich mir aber nicht als KOnzept vorstellen, sonst müsste man konsequenter Weiser sämtliches Portforwarding erst recht deaktivieren.
    Schließlich gibts dafür ja die Firewall, um zu definieren was darf und was nicht. Sonst kann ich auch nen Switch nehmen und die physikalisch trennen.

  • FIREWALL Protokoll

    • burnout
    • 21. November 2010 um 13:36

    Hm, ne eigentlich net. Deswegen ist es ja Source-NAT, d.h. die Quell-Adresse wird maskiert, nicht der Ziel-Port oder die Ziel-Adresse.
    Die Systemregel macht ja genau dasselbe, Alles was über ROT rausgeht, wird vom roten Interface maskiert. Das funktioniert.

    Mein Anliegen ist es, sämtliche Source-IPs aus dem DMZ die das VPN-Netz als Ziel haben, auf das Firewall-Interface zu maskieren, welches im VPN Netz liegt.
    Was später wirklich auch darf, wird per Firewall geregelt. Bzw. am Ziel-LAN hinter dem VPN steht ja auch ein Security Gateway.

    Zusätzliche Firewall-Regeln hab ich auch, bzw, ich hab mal spontan sämtliche ICMP egal von wo nach egal wohin erlaubt.

    Irgendwie scheint das Problem der Verkehr zwischen dem DMZ Interface -> Grün -> VPN zu sein.
    Deswegen ja auch die Frage nach dem Firewall Log, dass ich mal sehe wo wie was geblockt wird. Dort taucht nix auf :(

    Von der Firewall selbst kann ich locker mit dem grünen Interface das VPN Lan anpingen (vom grünen LAN sowieso, aber das wird ja auch nicht maskiert).

  • DNS Server

    • burnout
    • 21. November 2010 um 13:03

    Hi,

    nichts leichter als das, dnsmasq nutzt dafür die /etc/hosts:

    ssh root@endian

    echo 123.123.123.123 myserver.dyndns.org >> /etc/hosts
    cat /etc/hosts (alles richtig gemacht?)
    /etc/init.d/dnsmasq restart
    nslookup myserver.dyndns.org

    ODER
    Bei mobilen Geräten denke ich sofort an einen Exchange. Ohne DC kein Exchange. Kein DC ohne DNS. Richte im GUI bei DNS Proxy einen Eintrag für myhost.dyndns.org -> DEINDNSSERVER
    Dort dann einen Zone anlegen für myhost.dyndns.org, einen A-Record für "HIER".

  • FIREWALL Protokoll

    • burnout
    • 21. November 2010 um 12:28

    Achsoooooooo.... ja die funktionieren bei mir auch!

    Meinte ja eigentlich die Firewall-Diagramme (/manage/firewall/diagram/)
    Da bekommt man so Vorschaubildchen die auf Klick Bild einfaden sollten (/toscawidgets/resources/http://endian.firewallgui.web/static/diagram_1.jpg).

    Grüße :)

    PS: Hier mal ganz simple meine Source-Nat Einstellung, die nicht mal mit ICMP funktioniert.

    Bilder

    • EFW_DMZ-Source-nat.JPG
      • 60,01 kB
      • 775 × 450
  • FIREWALL Protokoll

    • burnout
    • 21. November 2010 um 12:11

    Hi,

    Danke! Stimmt, FW Logs waren tatsächlich aus. *large trout überreich*. Funktioniert nun.

    Was wird denn da bei den Diagrammen eigentlich angezeigt? Das Vorschaubild nur in groß (Link in neuem Fenster hilft da...)?
    Hatte erst angenommen dass da konfigurationsabhängige Diagramme gezeigt werden. Was ja geil gewesen wäre. Aber irgendwie sind das nur typische Standard-Diagramme.

    Da der Rest ganz toll läuft, werde ich jetzt nicht nochmal die alte installieren.
    Btw. übrigens die einfachst zu konfigurierende Firewall die ich je gesehen habe :) Inkl. IPSEC VPN zu einem entfernten GW, DMZ mit geroutetem public ipv4 Subnetz und Installation ca. 1 Stunde. Einzige was nicht funktioniert ist Source-NAT des DMZ-Subnetzes auf das IPSEC Subnet.

    Was allerdings fehlt sind selbst konfigurierbare Policy-Objekte für Adressen, Subnetze und Dienste. Es ist nämlich etwas nervig jedesmal eine Liste von Ports oder Netzen einzutackern.

  • FIREWALL Protokoll

    • burnout
    • 21. November 2010 um 09:46

    Hi,

    welche Updates der letzten Tage?
    Bin neu bei der EFW, habe gerade mal die 2.41 installiert vor 4 Tagen.

    efw-upgrade bringt mir auch keine updates. Oder muss man hier "bleeding edge" auswählen? ähm...

    Habe manuell die libipt_ kopiert nach /lib/iptables/ (Ordner musste ich erstellen) und ulogd n nachinstalliert.
    Trotzdem zeigen weder Firewalllogs noch Diagramme irgendeinen Inhalt.

    Offtopic:
    Ist es eigentlich Absicht, dass bei der Community-Version die glibc-header weggelassen werden, damit man da nicht selber die vmwaretools installiert?

    Grüße

Unterstützt von

  1. Datenschutzerklärung
  2. Impressum
Community-Software: WoltLab Suite™