Konfigutation mit öffentlichem IP-Subnetz



  • Hallo zusammen,

    zuerst möchte ich mitteilen, dass ich mich grade frisch in pfSense und Firewalls einarbeiten muss. Wir haben von unserem Provider ein /27-er IP-Subnetz bekommen und möchten jetzt eine Firewall dahinter hängen. Wir haben uns nach viel lesen und vergleichen für pfSense entschieden. Ich denke hier haben wir eine gute Entscheidung getroffen.

    Mein Problem ist es jetzt, das ganze einzurichten. Leider scheiter ich bereits daran von draußen eine IP Adresse, die auf eine interne weitergeleitet werden soll, zu erreichen. Ich habe vieles versucht. Firewall Aliasse angelegt, NAT, Rules, … Ich erreiche den internen PC einfach nicht. Ich denke hier habe ich schon an der Grundkonfiguration versagt.

    Angeschlossen ist es wie folgt:
    ISP --> Planet Modem --> Cisco Router (GW) --> interner Router (derzeit uraltes ClearOS / soll pfSense werden) WAN an das GW und LAN an einen HP Switch zu unserem Netz.

    Ziel ist, alle Server behalten ihre interne 192.168.0.x IP und die pfSense soll die öffentlichen IPs zu dem entsprechenden internen NATten. Ist das so machbar und sicher genug? Problem ist hier, es handelt sich fast ausschließlich um MS Hyper-V VMs die erreicht werden müssen. Und die Idee dahinter, dass alle Server die interne IP behalten ist, wenn hier mal Internet ausfällt, erreichen wir wenigstens noch unsere Systeme intern (CRM, Exchange, File-Server etc.)

    Ich hoffe ich habe es halbwegs verständlich beschrieben und hoffe auf eure Hilfe. Danke im Voraus für eure Mühe...

    Vielen Grüße aus Dortmund

    Marc


  • Moderator

    Hi Marc,

    Ich denke hier habe ich schon an der Grundkonfiguration versagt.

    Wenn du uns diese mal grob darlegst, können wir dir da sicher helfen.

    ISP –> Planet Modem --> Cisco Router (GW) --> interner Router (derzeit uraltes ClearOS / soll pfSense werden) WAN an das GW und LAN an einen HP Switch zu unserem Netz.

    Muss der Cisco als GW da drin bleiben? Wie sieht die Konfig bei dem aus, ist dort das /27er Netz überhaupt schon bekannt/aufgelegt oder gehört der noch zum Provider und routet euch das nur zu?
    Wie ist auch generell das /27er überlassen worden? Hat der Provider hier selbst eine IP aus diesem Netz als dein Gateway definiert oder bekommt ihr das via Transfernetz aufgelegt?

    Ziel ist, alle Server behalten ihre interne 192.168.0.x IP und die pfSense soll die öffentlichen IPs zu dem entsprechenden internen NATten. Ist das so machbar und sicher genug?

    Machbar ist das, natürlich. Sicherheit ist relativ, wird aber sicher nicht (allein) durch routing vs NATting bestimmt. Es gibt einfach dann diverse Netzkonstrukte die du bei solch einem Szenario nicht nutzen kannst, aber das was du möchtest ist definitiv möglich. Allerdings wäre es "sicherer", wenn trotz Zuweisung von Public auf Interne IP die Server alle in einer extra Zone + Netzbereich und/oder VLAN stehen würden (DMZ) damit einfach kein Zugriff auf euer internes Netz möglich ist, sollte man eine der Kisten gehackt werden.

    Problem ist hier, es handelt sich fast ausschließlich um MS Hyper-V VMs die erreicht werden müssen.

    Warum ist das ein Problem?

    Und die Idee dahinter, dass alle Server die interne IP behalten ist, wenn hier mal Internet ausfällt, erreichen wir wenigstens noch unsere Systeme intern (CRM, Exchange, File-Server etc.)

    Das wäre ja kein Problem des Internetausfalls. Selbst wenn die Systeme Public IPs hätten und in einer extra DMZ stünden, dann wäre es trotzdem noch von euch erreichbar, wenn euer Internet ausfiele, denn das Default GW wäre dann ja die pfSense und die kennt dann die Public IPs der DMZ und kann die nach wie vor routen. Das ist also kein Argument pro/contra public IPs. Das ist Sache der Netzplanung :)

    Ich hoffe ich habe es halbwegs verständlich beschrieben und hoffe auf eure Hilfe. Danke im Voraus für eure Mühe...

    Jap :) Allerdings wäre es da vielleicht besser, wenn du das noch ein wenig umplanen/umbauen könntest, um das ganze Konstrukt besser abzusichern.

    Viele Grüße
    Jens



  • Hi Jens,

    vielen Dank erst mal für die schnelle Antwort. Freut mich sehr!

    Mit dem "versagen an der Grundkonfiguration" wollte ich sagen, dass ich jetzt nicht mal mehr mit einem angeschlossenen Notebook ins Internet komme und ich nicht weiß woran das liegt. Ich habe dem LAN if im Moment noch die IP 192.168.0.55 verpasst und ebenfalls als sein default GW. An der 0.1 hängt aktuell noch unsere alte ClearOS Kiste, damit der Rest hier weiter arbeiten kann. Aber auch die 0.1 als LAN if default GW geht nicht. Das WAN if hat die erste public IP nach dem GW. Das GW ist die xx.65 und das WAS if hat die .66.

    Der Cisco muss da nicht zwingend bleiben, den habe wir vom Provider bekommen und ich für uns unantastbar. Ich kann aber auch die PPPoE Einwahldaten vom ISP bekommen, dann kann der Cisco weg, sagten die jedenfalls. Das Netz gehort dem ISP, ich denke die routen das direkt hier her. Kann man das irgendwie sehen? Ich kann dir per PN gerne das Netz schicken. Sieht man das an einer RIPE Suche? Den Link dahin hast du schon kommentarlos in deiner Mailbox hier.

    Grundsätzlich ist es kein Problem noch umzubauen, wie du vorschlägst. Allerdings schaffe ich es dann noch weniger alles einzurichten denke ich, weil da noch mehr dazu kommt. Werde ich dann aber durch müssen… Habe auch nichts gegen Remotegesteuerte Hilfe, Unterstützung, vormachen und zeigen ;-)

    Wie genau muss ich es denn dann umstellen?

    Gruß, Marc.


  • Moderator

    Der Cisco muss da nicht zwingend bleiben, den habe wir vom Provider bekommen und ich für uns unantastbar.

    Nope, wenn der vom Provider da steht, kann der normaerweise gerade nicht weg.

    Ich kann aber auch die PPPoE Einwahldaten vom ISP bekommen, dann kann der Cisco weg, sagten die jedenfalls.

    Zweifelhaft, denn per Einwahl (PPPoE) kann ich eigentlich kein IP Netz geroutet bekommen. Es sei denn ich habe definiert immer eine fixe IP und die routen das /27er darauf. Da du aber was schreibst von wegen der Cisco hätte jetzt .65 und das WAN der ClearOS Kiste .66 (hab ich das so korrekt verstanden?), kann das nicht so ohne weiteres sein. Oder es ist kein PPPoE.

    Sieht man das an einer RIPE Suche?

    Nein, im Normalfall siehst du da nur technische Ansprechpartner und allerhöchstens noch den AS, der dir das Netz bringt, das Routing bestimmt aber der Anbieter.

    Wie genau muss ich es denn dann umstellen?

    Kann man so pauschal nicht sagen, denn sollte bspw. der Cisco bleiben (müssen), ist es wieder ein ganz anderes Setup als ohne, wenn du bspw. das Netz via Transfernetz beziehen könntest. Das sind dann ganz unterschiedliche Arten, wie die pfSense das WAN konfiguriert bekommt und wie sie IPs annehmen kann (oder eben nicht).

    Mit dem "versagen an der Grundkonfiguration" wollte ich sagen, dass ich jetzt nicht mal mehr mit einem angeschlossenen Notebook ins Internet komme und ich nicht weiß woran das liegt.

    Abgehende NAT nicht konfiguriert? Keine allow Regeln von LAN -> WAN? WAN nicht richtig konfiguriert? Es könnten vielfältige Probleme sein. Da ich nicht weiß wie die ClearOS Büchse arbeitet und wie die IPs ankommen, könnte es sein, dass die pfSense parallel dazu überhaupt keine IP abbekommt, weil die alte Kiste nebendran alle IPs hat.

    Aber auch die 0.1 als LAN if default GW geht nicht.

    Naja die alte Kiste muss ja funktionieren, sonst würden deine Leute ja schon die Heugabeln auspacken ;)
    Also ist irgendwas an deinem Testsetup mit dem Laptop madig!?

    Das WAN if hat die erste public IP nach dem GW. Das GW ist die xx.65 und das WAS if hat die .66.
    Das ist noch nicht ganz klar: welches Gerät hat was für eine IP wo und warum?

    Grüße



  • Nein, das ist nicht ganz richtig. Es hängt ja noch das VDSL Modem vor dem Cisco… Aktuelles Setup (siehe Anhang).
    Der ClearOS Router hat die IP Adressen 192.168.1.1 und 192.168.0.1. Die public .66 hat die WAN Karte der pfSense.

    Die Konfig auf dem Cisco sieht so aus:

    interface FastEthernet0/1 
    description LAN 
    ip address 192.168.1.1 255.255.255.0 secondary 
    ip address 85.22.69.65 255.255.255.224 
    
    ip nat inside source list NAT_INTERNET interface Dialer1 overload 
    ip nat inside source static tcp 192.168.1.32 4430 interface Dialer1 4430 
    ip nat inside source static udp 192.168.1.52 2022 interface Dialer1 2022 
    ip nat inside source static tcp 192.168.1.52 2022 interface Dialer1 2022 
    ip nat inside source static tcp 192.168.1.32 8080 interface Dialer1 8080 
    ip nat inside source static tcp 192.168.1.32 2081 interface Dialer1 2081 
    ip nat inside source static tcp 192.168.1.32 2443 interface Dialer1 2443 
    ip nat inside source static tcp 192.168.1.32 2080 interface Dialer1 2080 
    ip nat inside source static tcp 192.168.1.32 23560 interface Dialer1 23560 
    ip nat inside source static tcp 192.168.1.32 587 interface Dialer1 587 
    ip nat inside source static tcp 192.168.1.32 995 interface Dialer1 995 
    ip nat inside source static tcp 192.168.1.32 993 interface Dialer1 993 
    ip nat inside source static udp 192.168.1.32 1194 interface Dialer1 1194 
    ip nat inside source static tcp 192.168.1.32 443 interface Dialer1 443 
    ip nat inside source static tcp 192.168.1.32 3033 interface Dialer1 3033 
    ip nat inside source static tcp 192.168.1.32 1195 interface Dialer1 1195 
    ip nat inside source static tcp 192.168.1.32 80 interface Dialer1 80 
    ! 
    ip access-list extended NAT_INTERNET 
    permit ip 192.168.1.0 0.0.0.255 any
    

    Wir haben hier erst mal nur einen 1:1 Tausch gemacht, als wir das bekommen haben. Die Fritzbox raus, das Modem und den Cisco rein. Alles andere hat der ISP gemacht. An der Router Konfig des Cisco können wir gar nichts machen. Kommen auf die Kiste nicht mal drauf.

    Der ISP sagte, der Cisco kann weg wenn wir das wollen oder anders machen können. Müsste ich noch mal genau nachfragen.

    Das Internet raus geht jetzt mit dem Laptop. Ich habe vergessen bei der Vergabe der IP unsere internen DNS Server einzutragen. Die pfSense übernimmt kein DHCP und kein DNS. Dafür haben wir Windows DCs.


  • Moderator

    Die Konfiguration auf dem Cisco sieht aber so aus, als würde ER die externen Adressen tragen, nicht die ClearOS Kiste hintenan.



  • Richtig.
    Die ClearOS Kiste macht nichts. Die ist nur ein interner Router und der openVPN Zugang. Der soll ja durch die pfSense ersetzt werden mit zusätzlicher FW. Das ClearOS kennt nicht mal eine der public IPs.

    Vorher war es so:

    ISP –> Fritzbox mit einer festen IP und intern 192.168.1.0/24
                              |
                              | --> LAN 1 ein Fileserver der extern erreichbar sein musste.
                              |
                              | --> LAN 2 Der ClearOS Router
                              |                          |
                              |                          | --> unser interes Netz (192.168.0.0/24)
                              |                          |
                              |                          |
                              |                          |

    Sorry ich habe im letzten Post die aktuelle Setup vergessen anzuhängen. Die hängt hier dran. So sieht es genau jetzt aus.



  • Moderator

    Die ClearOS Kiste macht nichts. Die ist nur ein interner Router und der openVPN Zugang.

    Wofür wird sie dann konkret genutzt? Und warum hängt nicht einfach alles hinter dem Cisco (der ja auch filtern kann)?

    Ich verstehe momentan das Konzept nicht, dass da umgesetzt werden soll, das sieht mir alles nach Daisy-Chaining hintereinander aus, aber ohne dass es für mich jetzt konkreten Sinn ergibt ;)



  • Der hat das Routing gemacht. Wir wollten damals ein abgesichertes Büro-LAN das nicht groß erreichbar ist. Den Cisco und das IP-Subnetz haben wir erst seit einer Woche und ist noch nicht live.

    Ich habe grade mit dem ISP telefoniert. Es ist wirklich so wie ich eingangs sagte. Der Cisco kann weg, die pfSense macht die PPPoE Einwahl und das xx.xx.xx.64/27-er Netz wird dann auf die pfSense geroutet. Die pfSense wird dann Gateway mit der .65, wenn sie das kann?

    Dann kann ich die IP Adressen und Ports durch NATten auf die bestehenden internen 0.x Adressen.

    =====

    Ein Konzept gibt es so gar nicht. Ich bin erst seit einem Jahr in dem Unternehmen tätig. Der Wunsch war es, einige Server (Exchange, MS Dynamics CRM, Atlassian Jira und Confluence etc.) extern verfügbar zu machen. Da wir nur eine public IP hatten damals die auf der Fritzbox was und mehrere Dienste die selben Ports benötigen, was der Aufwand mit einem NGINX Webserver dahinter zu groß. Wir hatten eine Subdomain web.firma.de (die firma.de liegt bei Strato) auf unsere feste IP geleitet und alles mit web.firma.de/jira, /crm, /owa etc. gemacht. Problem an der Sache ist, wir haben einen Geschäftsführer in HH sitzen und einige MAs die viel unterwegs sind. Die immer zu zwingen VPN zu nutzen, damit Outlook geht, war keine Lösung. Die Handys haben das ordentlich gemacht, die gehen ja auch über ActiveSync…

    Also musste eine Lösung her. Das Netz hat uns jetzt einmalig 100 Euro gekostet und ist lebenslang kostenlos. Da war die Lösung klar - das muss her! Jetzt haben wir es und ich muss es zum laufen gekommen.

    =====

    Ich habe es nun irgendwie geschafft die public IP .67 zu NATten auf die interne 0.80 und siehe da, XAMPP ist da. War der Test mit dem Laptop. Hoffe das ich das so alles richtig mache... Ein Problem habe ich allerdings, die public IP .90 kommt der Web-Admin der pfSense.



  • ISP –> Planet Modem --> Cisco Router (GW) --> interner Router (derzeit uraltes ClearOS / soll pfSense werden) WAN an das GW und LAN an einen HP Switch zu unserem Netz.

    ISP = ok
    Modem = ok
    Cisco Router = erste mal NAT
    ClearOS = zweites mal NAT

    Und wo genau ist nun die pfSense?

    Sicherlich kann man einen Cisco Router benutzen und dahinter eine pfSense Firewall, nur dann müssten bzw. sollten
    die zu erreichenden PCs, Server und was weiß ich nicht noch alles hinter dem Cisco Router, also in der DMZ aufgestellt
    werden und nicht hinter der pfSense.

    Noch schlimmer kommt es dann wenn drei mal NAT gemacht wird, dann kann man das ganze gleich vergessen.
    Ich weiß auch nicht warum ein PC eine öffentliche IP Adresse bekommen sollte?

    Also ich bin jetzt mal ganz ehrlich das ClearOS macht höchst wahrscheinlich so etwas wie NAT + Squid + ClamAV
    für Euch und dann noch die pfSense dazu ist nicht so der Bringer in meinen Augen.

    Ich würde das ganz einfach wie alle anderen auch machen wollen, hinter den Cisco Router alles was aus dem
    Internet erreicht werden soll in die DMZ und dann dahinter einfach nur die pfSense um das LAN abzusichern.
    Fertig. Dann kann man von dem LAN auf die DMZ zugreifen aber nicht umgekehrt, aber die Ports vorne am WAN
    Interface sind offen für die Server.

    Man kann auch nur das Modem benutzen und dann dahinter die pfSense mit Squid und SquidGuard & ClamAV und
    legt dort eine DMZ an der pfSense an, das geht auch dann ist OWA nicht gleich nackt im Internet zu sehen sondern
    hinter einem Squid Proxy.



  • Hallo Frank,

    wie du schon zitiert hast […]–> interner Router (derzeit uraltes ClearOS / soll pfSense werden)[…] wird der ClearOS RT durch die pfSense ersetzt. Der Cisco hat NOCH ein NATting, weil es bislang nur ein 1:1 HW Tausch war und noch nichts an dem neuen Netz passiert ist. Damit die Mitarbeiter weiter arbeiten können und die Kunden entsprechende Systeme noch erreichen, haben wir mit der Umstellung erst mal gewartet. Steht alles im Verlauf des Threads.

    Der Cisco RT kann bleiben, muss er aber nicht. Da der nur eine Schnittstelle rein und eine raus hat, macht es keinen Sinn da eine DMZ aufzubauen. Denn da muss ich noch nen Switch kaufen. Und auch kann der Cisco nicht von innen nach außen nach innen NATten, wie eine FW. Das wäre viel zu viel Aufwand.

    Also entweder Cisco stehen lassen und NAT anpassen lassen, oder Cisco raus und Lösung wie mein letzter Post. Sprich pfSense wird das Netz routen und wird gleichzeitig Gateway. Wenn sie das denn kann?



  • Der Cisco RT kann bleiben, muss er aber nicht. Da der nur eine Schnittstelle rein und eine raus hat, macht es keinen Sinn da eine DMZ aufzubauen.

    Der Bereich zwischen dem Cisco und der pfSense ist die DMZ, die musst Du nicht erst neu bauen.



  • Der Bereich zwischen dem Cisco und der pfSense ist die DMZ, die musst Du nicht erst neu bauen.

    Das macht ja keinen Sinn, die Server sind ja dann nicht abgesichert und 100% öffentlich. Dann würde ich der pfSense lieber ein drittes Interface einbauen und hier die DMZ einsetzen, oder verstehe ich hier grade was falsch?

    Der ISP würde das Netz auf die pfSense routen und die pfSense würde die PPPoE Einwahl machen.
    Kann die pfSense das Gateway sein auf der WAN Seite und die LAN Seite geht über das WAN_GW?



  • Was für ein Cisco Router ist das denn genau?
    Modell, Nummer?

    Das macht ja keinen Sinn, die Server sind ja dann nicht abgesichert und 100% öffentlich.

    Wenn man schon eine DMZ baut dann auch richtig und nicht unnütz.
    In Eurer ersten DMZ (ersten Zeichnung) ist der Cisco Router zu sehen und dahinter ein Fileserver
    und dann ein ClearOS Server der entweder NAT oder NAT und Squid oder NAT, Squid und Snort
    realisiert. Und dort ist der Fileserver genau an der richtigen Stelle! Aus dem Internet zu erreichen
    und aus dem LAN zu erreichen. Und warum soolte der Filserver dann 100% ungeschützt im Internet
    stehen? Ob ich nun am Cisco Router oder an der pfSense Ports öffne, diese "forwarde" und die Server
    in der DMZ darüber zu erreichen sind ist doch fast egal, sie sind zu erreichen. Und völlig nackt und
    zu 100% erreichbar ist wenn man vorne am WAN Interface alles auf Durchzug stellt, was natürlich
    nicht anzuraten ist.

    Dann würde ich der pfSense lieber ein drittes Interface einbauen und hier die DMZ einsetzen,
    oder verstehe ich hier grade was falsch?

    Man stellt in der Regel die ganzen Server und Geräte die aus dem Internet zu erreichen sein sollen
    eigentlich immer hinter das erste WAN Gerät (SPI/NAT/Firewall) und wenn man nicht eine extra DMZ
    anlegt ist das dort, der gesamte Bereich der DMZ Bereich! Man spricht dann auch oft von dem "Border"
    Gateway, Router oder Firewall und die zweite Instance dahinter die muss nicht, aber kann noch einmal
    SPI/NAT oder eben nur Firewall bzw. IDS/IPS machen. Nur dann noch einmal eine dritte Instance dahinter
    würde ich nicht machen wollen. Wofür NAT machen wenn ich dann alles nur wieder aufbohren muss?

    Der ISP würde das Netz auf die pfSense routen und die pfSense würde die PPPoE Einwahl machen.
    Kann die pfSense das Gateway sein auf der WAN Seite und die LAN Seite geht über das WAN_GW?

    Ja das geht alles. Die Zeichnung ist etwas groß geworden daher würde ich empfehlen sie zu speichern und
    dann zu betrachten!




  • Hallo Frank,

    danke für deine ausführliche Antwort und die Zeichnung. Hat geholfen! Es ist ein Cisco 1840.

    Die finale Entscheidung ist nun gefallen, wir lassen den Cisco erst mal stehen und der macht lediglich die Einwahl. Das NAT wird vom ISP wieder entfernt. Hinter den Cisco kommt dann unsere pfSense. Die bekommt auf dem WAN IF (welche in den Cisco geht) eine öffentliche IP .66 und auf dem LAN IF die 192.168.0.1. Die LAN Seite geht in unseren großen HP Switch und da kommt alles mit internen IP Adressen dran.

    In der pfSense werden viruelle IPs angelegt und diese dann per NAT auf die internen Dienste verteilt. Das wird sicher nicht die Lösung für immer sein, aber hauptsache es läuft langsam mal was.

    Eine Frage habe ich noch:
    Der ISP wird mir bei der Einrichtung behilflich sein. Dafür würde ich gerne das Webinterface über die Haupt IP (WAN .66) erreichbar machen. Das scheint nicht zu funktionieren. Wie kann ich das einrichten?
    Unter FW –> Rules --> WAN habe ich eine Regel angelegt die sagt, dass rein über WAN IF und TCP from any to IP .66 auf HTTPS erlaubt. Das klappt aber nicht.


  • Moderator

    Der Wunsch war es, einige Server (Exchange, MS Dynamics CRM, Atlassian Jira und Confluence etc.) extern verfügbar zu machen.

    DAS ist gruselig. Die Dinger hängt man nicht nackt ans Netz. Empfiehlt dir niemand. Dafür gibts Reverse Proxies, die das verfügbar machen und nebenbei dafür Sorgen, dass eben zuverlässigere Komponenten am Netz hängen als das was da so normalerweise drauf läuft.

    Das macht ja keinen Sinn, die Server sind ja dann nicht abgesichert und 100% öffentlich. Dann würde ich der pfSense lieber ein drittes Interface einbauen und hier die DMZ einsetzen, oder verstehe ich hier grade was falsch?

    Wie Frank schon schreibt ist das nicht richtig, nur wenn die Server nackt am Netz hingen und der Cisco macht(e) ja NAT und kann sicher auch Regeln (auch wenn ich die nicht nehmen würde, er kanns wahrscheinlich).

    Ich bin zwar normalerweise gegen so eine durchgeschleuste DMZ, aber tatsächlich besser als nix.

    Die finale Entscheidung ist nun gefallen, wir lassen den Cisco erst mal stehen und der macht lediglich die Einwahl. Das NAT wird vom ISP wieder entfernt. Hinter den Cisco kommt dann unsere pfSense.

    Bekommt der Cisco dann die .65 und das Netz geroutet? Wie routet der dann das Netz weiter? an die .66 die du auf die pfSense knoten willst? Macht kein Sinn, denn das Netz liegt dann ja schon auf. Verstehe also nicht ganz wie ihr das dann klöppeln wollt.

    Die LAN Seite geht in unseren großen HP Switch und da kommt alles mit internen IP Adressen dran.

    Und warum zum Geier nehmt ihr dann nicht - wenn es eh alles so billig war - ne neue APU Kiste, die erstens mehr Bumms hat und zweitens noch ein drittes Interface? Dann kann man auch ne ordentliche DMZ konfigurieren? Alternativ, wenn euer HP das hintendran kann - 2 getrennte VLANs machen und die Server die man Live stellen möchte da rein packen (oder deren Proxies). Das wirkt alles einfach sehr gebastelt und wenn man dann doch eh am Aufräumen ist, warum nicht richtig? :)
    Die Möglichkeiten von Frank mögen valide sein (kein Affront dagegen :)) aber gruseln mich alle. Warum kein sauberes 3-Bein Setup implementieren?

    Grüße



  • Ich bin hier nur der ausführende Befehlsempfänger. Entscheidungen treffen andere Stellen. Ich kann immer nur mit meinen Ideen und euren Vorschlägen dahin wandern und das vorschlagen. Das macht mir langsam keinen Spaß mehr. Ich würde das so machen, wie ihr es sagt, auch wenn ich dafür neue Netzwerkkarten kaufen müsste. 2x 10 GBit Karte und fertig ist der Laden! Aber leider ist dem nicht so…

    Ja, so wie es aussieht wird dem Cisco das NAT entzogen und der macht nur noch die Einwahl und routet das Netz auf die pfSense. Die hat am WAN IF bereits die public IP 66. Per SSH komme ich von draußen drau, per HTTPS aber nicht... Why? Wie mache ich das Webinterface vorübergehend per HTTPS von draußen aus erreichbar?



  • Also wenn ich mir das hier so alles anschaue dann würde ich einfach zwei neue Geräte anschaffen wollen.
    Zum Einen eine fette Lösung für die Front und eine weniger gute aber dennoch schnelle Appliance dahinter.

    Also einfach den Cisco Router gegen eine flotte pfSense Lösung austauschen und dann neue Hardware
    für die ClearOS Lösung dahinter. Kann ja weiterhin bleiben und Ihren Dienst verrichten soll aber auch
    nicht der Flaschenhals sein.

    Irgend wann haben eben irgedn welche Leute zusammen mit den Leuten vom SANS Institute
    die drei Hauptarten einer DMZ festgelegt, sicherlich gibt es dazu noch hunderte wenn nicht
    sogar tausende Sublösungen gibt.

    • "Exposed Host" - pseudo DMZ
    • DMZ Port in Hardware oder Software realisiert = true & dirty DMZ
    • Dual homed oder "bastion host" Variante mit zwei Routern oder Firewalls = true & clean DMZ
      Wird oft auch als Router oder Firewallkaskade bezeichnet.

    Was jeder für sich nimmt und benutzt muss ernatürlich selber wissen und umsetzen
    klar da scheiden sich die Geister immer und wenn die ClearOS "Kiste" hinter der pfSense Firewall,
    so wie das netzwerk jetzt aufgebaut ist, laufen würde und das noch transparent als Snort und/oder
    Squid Proxy wäre das auch noch vertretbar, aber so wie das jetzt geplant ist würde ich das nicht realisieren
    wollen, und wozu auch? Cisco Router Ports auf und Route auf die pfSense dahinter die hat dann auch gleich
    erst mal das NAT aufgebohrt und dann erst die Server freigeben? Die stehen doch im LAN und das soll doch
    der geschützte Bereich sein der nicht?

    ISP –- Internet --- Modem --- Router/Firewall --- LAN

    So und wenn nun einige Server Kontakt zum Internet brauchen hat der Admin doch ein Problem
    oder nicht? Er muss die Server an das Internet anbinden und möchte keinen Kontakt zum Internet
    seitens seines LANs haben. Man kann nun eine DMZ Software seitig oder mittels Hardware DMZ Port
    aufsetzen oder aber zwei Geräte hintereinander setzen und dazwischen ist dann die DMZ und natürlich
    auch die Server.

    • Sollte das OS am WAN interface einen Bug haben, steht dahinter noch ein anderes gerät mit einem
      anderen OS drauf was am besten unterschiedlich ist.
    • Hat man sich verkonfiguriert sind nur die Server mit Internetkontakt davon betroffen aber nicht die LAN
      Server und Arbeitsstationen.
    • Vorne terminiert man das VPN und realisiert den HTTP-Proxy zur DMZ hin und am zweiten Gerät weiter
      hinten setzt man ISD/IPS ein.

    Das wird sicher nicht die Lösung für immer sein, aber hauptsache es läuft langsam mal was.

    und das nenne ich dann eben nur noch "blinden Aktionismus" ist nicht böse gemeint aber später will da
    so oder so niemand noch einmal bei gehen!

    Aus dem pfSense Shop C2758 mit pfSense für den Cisco Router
    XG-1540 oder einem kleinen Intel E3-12xxv3 mit 32 GB ECC RAM mit ClearOS dahinter und gut ist es.
    alternativ kann man auch ein Supermicro C2758 und D-1540 Board dazu nehmen und gut ist es.
    Die Server mittels eines Layer2 Switches und 10 GBit/s in der DMZ anbinden und die ClearOS
    Lösung kann dann ja auch transparent laufen, also ohne NAT nur mittels Firewall und Snort.



  • Du hast völlig Recht, ich würde mich da auch direkt so entscheiden, dass es die nächsten Jahre läuft wie es ist. Ich kann nur das ausführen, was ich genehmigt bekomme und das ist nun mal das was ich grade gesagt habe…

    Sollte ich doch noch wiedererwartend eine andere Sache dürfen, wie genau ist die vorgehensweise wenn alle Server (auch die die nicht dreigegeben werden sollen) VMs auf zwei Windows Hyper-V Servern sind?
    Dann müssten die Hyper-V Server beide in die DMZ und dann ist auch das frei was nicht raus soll, oder?

    Noch mal die wichtige Frage: Wie kann ich die pf-Sense Web-Gui extern erreichbar machen mit der WAN IP?



  • Noch mal die wichtige Frage: Wie kann ich die pf-Sense Web-Gui extern erreichbar machen mit der WAN IP?

    Am besten gar nicht, sondern nur Einwahl via VPN und dann am besten nur wenn auf Deinem Gerät ein Radius
    Zertifikat installiert ist, als zusätzliche Absicherung. Sollte einmal eine Bug auftauchen sei es nun in pfSense
    oder SSH, oder irgendwo anders hast Du wenigstens kein Problem.

    LAN seitig würde ich VLAN1 als Admin VLAN benutzen und auch mittels Radius Zertifikat abgesichert.
    WAN seitig nur via VPN und mit Radius Zertifikat abgesichert



  • Es geht nur um die Hilfe des ISP, damit alles sicher ist. Das ist nur vorrübergehend und wir nur von Source (deren Firewall) erlaubt und ist HTTPS mit unserem Wildcard-Cert. Aber kurzzeitig offen muss sein.


  • Moderator

    @Kobold: Ich sehe den Sinn für diesen ganzen ClearOS Quatsch nicht. Entweder ich schaffe alte Zöpfe ab, dann auch richtig, oder eben nicht. Warum soll ich - wenn man jetzt schon den Cisco rauswirft - auch noch irgendein altes anderes RouterOS da rumgammeln lassen. Das erschließt sich nicht.

    Und über irgendwelche theoretischen SANS oder sonstwelche DMZ Niederschriebe schreibe ich eigentlich nicht. Das ist schön wenn sich da mal jemand hingesetzt und das entworfen hat. Wir haben aber 2015 und die Situation ist eine andere, wie sich jemand mal überlegt hat das zu benennen. Als das festgelegt wurde (ich habe noch Firewall und Security Lektüre aus der Zeit) wurde im DMZ Segment auch noch von echten gerouteten Adressen ausgegangen. Das ist heute nicht mehr so, weil oftmals 1:1 NAT oder sonstiges zum Einsatz kommt und Kunden nur noch kleinere - wenn überhaupt - Netze bekommen. Die dann noch extra zu segmentieren oder aufzulegen verschwendet dann Adressen. Theorie ist da schön, in der Praxis seh ich das eben anders :) Und nach meiner Erinnerung hat keiner der sich auch nur im Entferntesten Security Guy schimpft, jemals "Exposed Host" und "DMZ" im gleichen Satz in den Mund genommen. Das ist schlicht eine Verunglimpfung eines Ausdrucks, denn billig-SOHO-Router Hersteller irgendwann mal eingeführt haben, um das als tolles Feature mit einem Security Ausdruck zu bewerfen. Aber mit dem Prinzip DMZ hat das nicht mal Ansatzweise zu tun (denn DMZ impliziert einen begrenzteren/abgegrenzten Security Level der kleiner als Vollzugriff/Internet aber größer als abgeschottetes LAN ist).

    Aus dem Grund sehe ich auch nicht ein, warum ich mit extra Kisten alles kompliziert machen sollte:

    
          WAN / Internet
                :
                : DialUp-/PPPoE-/Cable-/whatever-Provider
                :
          .-----+-----.
          |  Gateway  |  (or Router, Modem, whatever)
          '-----+-----'
                |
            WAN | PPPoE / Ethernet
                |
          .-----+-----.  priv. DMZ  .------------.
          |  pfSense  +-------------+ DMZ-Server |
          '-----+-----' 172.16.16.1 '------------'
                |
            LAN | 10.0.0.1/24
                |
          .-----+------.
          | LAN-Switch |
          '-----+------'
                |
        ...-----+------... (Clients/Servers)
    
    

    Klassisches Dreibein mit DMZ Achse. Läuft. Und man muss nicht an 2-3 Kisten suchen, warum zum Geier irgendwas nicht läuft.

    @Marc

    2x 10Gbit/s…

    Wozu? Ich sehe nirgends Anwendungsbereiche, wo du irgendwas mit 10GE bräuchtest. Finde ich dann doch recht unnötig.

    Sollte ich doch noch wiedererwartend eine andere Sache dürfen, wie genau ist die vorgehensweise wenn alle Server (auch die die nicht dreigegeben werden sollen) VMs auf zwei Windows Hyper-V Servern sind?
    Dann müssten die Hyper-V Server beide in die DMZ und dann ist auch das frei was nicht raus soll, oder?

    Nein, deshalb wären gerade Switche gut, die eben VLANs können. Ich würde sowieso die Server NIE direkt ans Netz hängen, auch nicht via 1:1 NAT, denn das fügt keinerlei Sicherheit hinzu. Gerade Exchange (OWA) hängt dann nackt am Netz und sollte mal wieder nen Patch Day versaut sein, hast du hinterher noch Streß weil der Mailserver tot ist.

    Deshalb kann man - bspw. in eine DMZ oder zum Teil auch direkt via pfSense - diverse Dienste einfach mit (reverse) Proxy betreiben. Für OWA/Exchange geht das m.W. unter anderem mit Squid und/oder HAProxy, die dann einfach die Daten initial annehmen und an Exchange weiterreichen. Wenn aber von außen jemand lustige Probes fährt um irgendwelche IIS Lücken zu finden, wird er am HAProxy oder Squid eben nicht weit kommen. Dito für deine anderen Atlassian Kisten. Da schreibt Atlassian ja sogar selbst, dass man Jira/Confluence und Co. am Besten nochmal mit einem Apache/NGinx vornedran Proxy'en sollte. Schon allein, weil du dann nicht auf krumme Ports zugreifen musst, aber auch um ggf. Caching und Security noch mit reinzubringen (und ggf. TLS hinzuzufügen bzw. Offloaden zu können).

    Darum sehe ich auch keinerlei Traffic WAN<->DMZ, DMZ<->LAN oder WAN<->LAN, der jetzt >1GBit/s wäre und da ich bezweifle, dass ihr 10GBE Dark Fiber angebunden seid ;) sehe ich da nirgends einen Grund für eine pfSense mit 10G Interface.

    VLANs würden sich positiv bemerkbar machen, denn du könntest damit ggf. Maschinen auf dem HyperV hochfahren und deren Interface an einem extra VLAN betreiben, das auf der pfSense eben wie eine DMZ aufliegt. Damit wäre der Hypervisor selbst nicht exponiert, und nur die VM würde dann ggf. mit einer anderen Maschine im normalen LAN reden. Diese Kommunikationsbeziehungen am Besten festhalten (aufschreiben, Netzplan) und dann die Regel genauso festzurren. Dann ist auch nicht mehr erlaubt als es sein muss und damit alles OK -> mehr Filtern geht dann nur auf Applikationsebene und das ist immer ne andere Baustelle.

    Von der bisherigen Erzählung würde ich aber Frank zustimmen: ein C2758er Atom Server mit 8 Kerner Atom und 8GB RAM sollte da DICKE reichen. Wir haben auch 2 solche Kisten vor unserem Office (CARP Cluster wegen Ausfallsicherheit), sind 1HE Supermicro Superserver und funktionieren super und sind wirklich sehr fix und für den Job durchaus ausreichend,

    Grüße

    Grüße