Firewall für kleines Unternehmen

[IThome 10]

Nur als Beispiel:

Check Point FW-1 kann das. Der FTP Server ist in diesem Fall die Firewall, die widerum FTP Kommandos auf einen Server ausführt (transparent), und auch nur die Verzeichnisse und Kommandos die man dafür definiert hat (z.B. get, put, dir, etc.), und das ist nicht alles, was die kann....

Ein Hoch auf Application Layer Firewalls mit Application Proxys, die Watchguard Firebox X-Serie kann sowas auch ...

[Otaku19 33]

Eine Firewall muss nicht natten um ihren Zweck zu erfüllen.

NAT ist kein Sicherheitsfeature

wie ITHome sagt, da gibts Content Filter

 

"Umständliches" umschreiben ist doch auch Quatsch, die heutige Hardware macht das mit links

 

Es gibt immer Lösungen um draussen-Firewall-drinnen (+eben noch ne DMZ) aufzustellen. So und nicht anders gehört es sich.

 

und eben daher hab ich ja geschrieben, der Threadersteller muss sich genau im Klaren sein was er braucht, sonst wird das nix.

[nerd 28]

Ok, wir kommen etwas vom ursprünglichen thread ab. Da hier jedoch einige Aussagen stehen die man so nicht stehen lassen kann antworte ich dennoch.

 

Denial of Service... ja und? ...gegenmassnahmen kannst du auf dem System selbst, auf dem beispielsweise ein mailsystem läuft, auch ergreifen...

das fängt nicht zuletzt damit an, das du security patches durchführst, sie aufmerksam verfolgst und so die schwachstellen und lücken die DoS verursachen schliesst.

sehr komischer Ansatz. Eine Firewall und die drauf installierte Software ist dafür ausgelegt eine geringe Menge von Aufgaben möglichst effektiv durchzuführen. Daher ist es um einiges schwerer eine dedizierte FW mit einer DOS Attacke in die Knie zu bekommen als ein Mailserver der nebenbei noch Firewall spielt.

 

@Patchen: Das hat im allgemeinen keinen direkten Zusammenhang mit DoS Attaken diese können auch einfach darauf aus sein das System durch die pure Menge an Anfragen zu überlasten. Es gibt natürlich auch Schwachstellen die einen solchen Angriff vereinfachen da hast du natürlich recht.

 

@Patch generell: Eine Firewall ist kein Freibrief für schlechtes Patching! Grundsätzlcih sollten alle installierten Dienste auf einer Maschine gepatched oder deinstalliert werden.

 

d.h. wenn man auf einem mailsystem lediglich den port 25 offen hält, von mir aus auch noch 465, ...dann muss man NUR den maildienst vor DoS Attacken schützen (security patches für den MTA ! ) und ggf. die firewall, die auch abstürzen könnte bzw. im zweifelsfall blockiert. (schutz also auf application ebene, kenn keine firewall die die pakete checkt, also deren inhalt... )

saubere administration, intrusiondetection und sorgfältiges logging... was kann man mehr dazu sagen.

sieh Punkte weiter oben. Ach ja, es gibt FW's die jedes Paket auf machen und rein schauen!

 

eine dedizierte firewall für ein mailsystem heisst:

man betreibt nicht weniger aufwendiges, PRE-Routing (stichwort NAT -- SNAT, DNAT ) ...schreibt an der firewall umständlich quell-adressen um... um sie letztenendes doch zu dem "eigentlichen mail-system" zu leiten... der port 25 wäre auch auf der dedizierten firewall offen... oder?

 

ein einbruch auf der dedizierten firewall verschafft nur zeit, jedoch keine zusätzliche sicherheit.

ok, du bist nicht in der Securty Branche tätig ;) Natürlich hat man zusätzlichen Schutz. Bringt jemand die FW down kommt er nicht an das Mailsystem mit meinen u. U. Geschäftskritischen Informationen. Ich kann in ruhe ne Backupleitung hoch fahren die FW neu booten und Gegemaßnahmen einleiten...

ist die dedizierte firewall down... ist das mailsystem auch nicht mehr erreichbar...

wenn kein Backupsystem da ist ja - die FW sollte diesen Angriffen aber weitaus länger stand halten und vorab infos an den Admin geben um Gegenschritte einleiten zu können.

angriffe auf systeme mit dem fuss ins internet sorgen dafür das diese systeme entweder nicht mehr erreichbar sind oder root zugriffe möglich sind.

 

nehmen wir an, es gelingt mir auf der dedizierten firewall einzubrechen... was hindert mich daran im nächsten schritt das dahinterliegende mailsystem anzugreifen ...AUF DEM JA KEINE FIREWALLinstalliert ist...

hoffentlich der Admin der zwischenzeitlich mitbekommen hat, dass seine FW down ist. Zudem sollte er über das Monitoring der DMZ mitbekommen, dass jemand versucht seinen mailserver zu hacken...

 

...aber wir können da gerne weiterphilosophieren.

das szenario möchte ich sehen, wo das was ihr machen wollt auch sinn macht

jedes Szenario in dem man Systeme von Internet aus erreichbar haben muss

 

[nerd 28]

all auf die bereits kommentierten Aussagen folgenden Aussagen sind leider vollständig falsch - bitte informiere dich mal genau was Firewalls alles können... Nur weil es deine Desktop FW nicht kann heißt das noch lange nicht, dass eine dedizerte FW dafür keine Lösung bietet. Die Aufgabenstellungen sind allerdings eher Enterprise Systeme (zwei Mailsysteme) daher kosten solche Lösungen auch etwas mehr...

[Velius 10]

NAT ist kein Sicherheitsfeature

 

Ist zwar an sich nicht so gedacht, bietet aber klar Sicherheit. Ein Rechner der durch ein hide Nat/PAT/NAPT in's Internet geht ist von diesem nicht angreiffbar!:wink2:

[Velius 10]

BTW: Bezüglich DoS

 

Firewalls, oder zumidest bessere, trennen Verbindungen wenn mehr connections pro Zeiteinheit geöffnet werden als erlaubt oder konfiguriert. Ein Server wo der Dienst drauf läuft macht das in aller Regel nicht.

[Otaku19 33]

Ist zwar an sich nicht so gedacht, bietet aber klar Sicherheit. Ein Rechner der durch ein hide Nat/PAT/NAPT in's Internet geht ist von diesem nicht angreiffbar!:wink2:

 

afaik ist er das doch. Deswegen gibts ja firewalls. Das NAT an sich kann nicht entscheiden ob ein paket "gut" oder "Böse" ist wenn es eben dieses an den Client drinnen weiterleitet.

[Velius 10]

afaik ist er das doch. Deswegen gibts ja firewalls. Das NAT an sich kann nicht entscheiden ob ein paket "gut" oder "Böse" ist wenn es eben dieses an den Client drinnen weiterleitet.

 

Deine Annahme ist falsch, denn es ist bei einem hide NAT schlicht weg nicht möglich, von ausserhalb des Gerätes das NAT macht erreicht zu werden! Das liegt nicht daran, ob ein Paket 'gut oder 'böse' sein soll, dass kann auch eine 'normale' Firewall nicht beurteilen. Sie folgt nur gewissen mustern (z.B. ist der three-way-handshake abgeschlossen, sonst könnte es eine Syn-Attacke sein).

 

Der Grund dafür ist einfach:

 

http://www.mcseboard.de/windows-forum-lan-wan-32/one-to-one-nat-91375.html?highlight=hide+nat#post555711

 

Die NAT-Gerät führt eine Tabelle, welche IP und welcher Quell-Port übersetzt werden muss, und kann aufgrund dieser Tabelle auch wieder Rückschlüsse machen, welches Packet wohin soll. Wenn man diese Richtung nun umdreht, also der Verkehr wird von Aussen iniziert, dann fehlt dem NAT-Geräte jegliche Zuordnung => Es kann und wird keine Verbindung stattfinden, ausser es wäre ein statisches NAT konfiguriert, aber dann ginge es auch nur auf eine IP oder pro Port der übersetzt wird eine IP.

 

Also, es ist schon technisch gesehen völlig unmöglich bei einem hide NAT.;)

[Otaku19 33]

ich beziehe mich da auf:

Lutz Donnerhacke: de.comp.security.firewall FAQ

 

 

Ist NAT ein ausreichender Schutz für Surfer?

Adressumsetzung (NAT) wurde entwickelt, um Kommunikation zwischen Anwendungen auch dann zu ermöglichen, wenn die Adressen der Gegenstellen nicht direkt gegenseitig erreichbar sind.

Die meisten Anwendungen verwenden nicht allein eine Verbindung, die von dem Surfersystem zum jeweiligen Server aufgebaut wird, sondern eine Vielzahl von unterstützenden Diensten und damit auch unterschiedlichen Protokollen. Die Richtung dieser unterstützenden Verbindungen ist dabei oft auch vom Server zum Client(Surfer).

 

Erreicht einen NAT-Router ein Paket für eine umgesetze Adresse, so wird er versuchen, irgendwie den eigentlichen Empfänger zu erraten und das Paket zuzustellen. Das gilt insbesondere dann, wenn der NAT-Router keine intime Protokollkenntnis der Anwendung hat. Oft besteht keine Chance für den NAT-Router, selbst bei Kenntnis des Protokolls, den Empfänger sicher zu ermitteln. Dann wird mittels einer Heuristik der Empfänger erraten. Dies gilt insbesondere bei verschlüsselten Verbindungen und verbindungslosen Protokollen.

 

Ein NAT-Router ist deswegen keine Sicherheitskomponente.

 

 

 

Denn mal ganz logisch nachgedacht, wäre NAT ein Schutzsystem, wären Firewalls nicht so gefragt

[Velius 10]

@Otaku19

 

Sorry, aber das ist Schwachfug! Ich habe noch nie so eine NAT Implemetierung gesehen, und kann das aus meiner Praxis beurteilen.

 

Ausserdem sind wie erwähnt Firewalls nicht blos Port-Filter heutzutage, sondern meist auch Router (soweiso) NAT-Gerät, möglicherweise auch VPN-fähig und zudem meist, wenn häufig auch in begrenztem Umfang, Application Layer Firewalls. Und wie bereits erwähnt zieht der Schutz nur bei einem hide NAT, nicht aber bei einem statischen NAT, da der Rechner direkt vom Internet angesprochen werden kann und auch muss.

 

 

 

Denn mal ganz logisch nachgedacht, wäre NAT ein Schutzsystem, wären Firewalls nicht so gefragt

 

Das ist eine blose Annahme und kein technischer Beweis für deine von dir zitierte Quelle.

[Lucyyyyyy 10]

...;) mag das thema extrem strapazieren und entfremden, aber im Forum LAN WAN wohl mit eine der interessantesten dinge...

 

UND !! ...ich bin nicht hier um stunk zu machen, ...ich lese aufmerksam und bekomme INPUT ...und das ist gut. ...dazu gehört natürlich auch, das ich mich eines besseren belehren lasse.

 

Eine Firewall muss nicht natten um ihren Zweck zu erfüllen.

NAT ist kein Sicherheitsfeature

wie ITHome sagt, da gibts Content Filter

 

lohnt eigentlich nicht weiter zu diskutieren ^^

stichwort INPUT, FORWARD und OUTPUT regelwerk, ich möchte jetzt nicht sagen das NAT /SNAT DNAT nicht dazu gehören, aber gehören zumindest zum guten ton.

das desktop firewalls das nicht können müssen, da hast du recht, hab auch nur eine netzwerkkarte in meinem rechner, da reichen INPUT und OUTPUT regeln.

 

Adress-/Port-umschreibungen sollten firewalls dennoch können und tun dies auch, PREROUTING und POSTROUTING gehören für mich daher genauso zum firewallregelwerk, mag sein das andere das als feature sehen... dann gönn mir an dieser stelle ein lächeln.

 

NAT ist kein Sicherheitsfeature

für mich schon, durch masquerading lassen sich immerhin Netzwerke im LAN verstecken, nur wo fängt sicherheit an? ;) ...sicherheit für mich nicht nur durch das öffnen und schliessen von ports.

 

Firewalls, oder zumidest bessere, trennen Verbindungen wenn mehr connections pro Zeiteinheit geöffnet werden als erlaubt oder konfiguriert. Ein Server wo der Dienst drauf läuft macht das in aller Regel nicht.

ich betreibe einen sendmail, ...es läuft iptables (die firewall) ...intrusiondetection, was hindert mich daran gleiches zu tun? die firewall lässt den traffic auf port 25 zu oder eben nicht, den rest macht der detection dienst und fügt als gegenmassnahme regeln in das bestehende regelwerk ein, schreibt in den syslog ..und und und...

nichts anderes ist das, was "bessere firewalls" tun (intrusion-detection dienste)

"angriffs-" verhalten analysieren und entsprechende massnahmen ergreifen --> z.B. portblockade, angreiferIP sperren ...egal was auch immer und in das firewallregelwerk eingreifen. in diesem sinne trennt nicht die firewall, sondern ein weiteres feature die verbindung.

gegenteiliges erreichst du beispielsweise mit portknocking ...dieser dienst veranlasst z.b. die firewall nach einer bestimmten combo von paketen das öffnen bestimmter ports... hat nichts mit firewall an und für sich zu tun.

 

----------

 

Nur als Beispiel:

Check Point FW-1 kann das. Der FTP Server ist in diesem Fall die Firewall

jaaa, dann ist die checkpoint auch schoneinwenig mehr als eine einfache firewall ...

..wir reden hier jedoch von implemetierungen ...ein gutes Virenprogramm erkennt auch nicht "NUR Viren" sondern kann von mir aus darüber hinaus auch noch SPAM erkennen...

aber es ist sehr gut, das es derartige und vorallem SINNVOLLE lösungen gibt, ...ALL in ONE produkte.

 

---------

 

sieh Punkte weiter oben. Ach ja, es gibt FW's die jedes Paket auf machen und rein schauen!

...Angst ...dann sollte ich wohl keine Transaktionen via https mit meiner bank tätigen :cool: ...oder wie weit schaun die in die pakete ;)

noch viel schlimmer, wenn sone "doofe" firewall meine signiert, verschlüsselten liebes e-mails an meine "weggehfreundin" lesen kann...

 

---------

 

ok, du bist nicht in der Securty Branche tätig Natürlich hat man zusätzlichen Schutz. Bringt jemand die FW down kommt er nicht an das Mailsystem mit meinen u. U. Geschäftskritischen Informationen. Ich kann in ruhe ne Backupleitung hoch fahren die FW neu booten und Gegemaßnahmen einleiten...

...security branche? ...was heisst das? ...hacker, cracker? ...oder nur netzwerkadmin? ;)

wie kommst du dadrauf? ;) ...weil ich andere ansichten habe, anders philosophiere?

P.S: wer sagt das die postofficeboxen auch auf diesem system liegen? ...welche Geschäftskritischen infos meinst du also ? ;)

[Lucyyyyyy 10]

was ich unter szenario verstehe:

 

dedizierte firewall 1 ...

LAN schnittstelle1 - die öffentliche IP 212.87.34.14

LAN schnittstelle2 - die DMZ - IP 192.168.1.6

geht zum

mailsystem1 in der DMZ - IP 192.168.1.5 (denn das soll ja keinesfalls mit einer öffentlichen IP versehen sein)

 

d.h. source nat auf den port 25 der IP: 192.168.1.5

ist also die firewall down, ...ist das mailsystem natürlich von draussen nicht mehr erreichbar...ABER sehr wohl doch im DMZ netz !

 

frage:

wenn deine monitoring tools in der DMZ agieren, wie soll dann jemals erkannt werden, das das mailsystem von draussen nicht mehr erreichbar ist ? (...denn es ist ja erreichbar)

wie soll dann ein backupsystem anspringen (das ja auf monitoring reagiert)

muss es ja eigentlich nicht, weil mailsystem1 ja eigentlich noch funktioniert nur die dedizierte firewall nicht mehr, die keinen traffic mehr erlaubt.

Zu monitoren wären also in jedem fall beide Netzwerkschnittstellen der dedizierten firewall...

 

Zitat:

ist die dedizierte firewall down... ist das mailsystem auch nicht mehr erreichbar...

 

wenn kein Backupsystem da ist ja - die FW sollte diesen Angriffen aber weitaus länger stand halten und vorab infos an den Admin geben um Gegenschritte einleiten zu können.

 

P.S. dafür gibt es firewall policys ...die z.b. auf DROP gesetzt ist, wer auch immer das ding abschiesst, ....da geht dann garnix mehr... werder durch, rein oder raus...

wer es allerdings schafft, die sauber herunterzufahren... zieh ich meinen hut ^^ aber nicht mit ner DoS

 

...nur dann schweifen wir von meiner ursprünglichen aussage, denn nur darum ging es mir:

von daher ---> bei rechensystemen mit direktem anschluss an das internet, Webservern, FTP- / Mai / DNS - systemen hast du direkt auf dem laufenden system eine firewall am laufen, das macht sinn... (meine meinung)

alles andere ist unnützer, zusätzlicher, administartiver aufwand... , schafft zusätzliche flaschenhälse (meine meinung)

 

iptables auf einem mailsystem, mit stateful filtering, implementierungen die fehlerhafte und ungültige pakete erkennen und verwerfen tut nicht weniger schlecht seinen dienst wie eine checkpoint...

 

...und nun sind wir schon bei backupsystemen ^^ ...einer abgeschmierten, dedizierten firewall und und und.

 

und nun geb ich mal vorsichtig zurück... was für ein komischer ansatz das ist:

sehr komischer Ansatz. Eine Firewall und die drauf installierte Software ist dafür ausgelegt eine geringe Menge von Aufgaben möglichst effektiv durchzuführen.

 

was bitte schön hat eine firewall auf einem mailsystem grossartiges zu tun, wenn sie nur den port 25 offen hält und den rest an ungewollten paketen verwirft / droppt.

im übrigen habe ich auch noch nichts davon gehört, das man mit DoS eine sorgfältig konfigurierte firewall bezwingt, ich bin bisher nur davon ausgegangen das Denial of Services dienste lahm legen.

 

Daher ist es um einiges schwerer eine dedizierte FW mit einer DOS Attacke in die Knie zu bekommen als ein Mailserver der nebenbei noch Firewall spielt

...das spielt keine rolle mehr, wenn das erste system versagt.

 

DoS auf den mailserver legt den mailserver lahm nicht die FW ...

angriffe auf die firewall legt die firewall lahm, nicht den mailserver.

 

naja wie auch immer...

[Velius 10]

Ok, ich denke damit sind nun alle Aspekte des Themas abgehandelt. Weitere Fragen....?:D

[Lucyyyyyy 10]

...hehe Velius :D ...ich nich ...aber so gesehn interessiert mich das schon ^^ ...man muss ja nicht nur immer helfen wollen in sonem forum ...nen meinungsaustausch ist auch was feines = INPUT ^^

[woiza 10]

was ich unter szenario verstehe:

 

....

mailsystem1 in der DMZ - IP 192.168.1.5 (denn das soll ja keinesfalls mit einer öffentlichen IP versehen sein)

Warum nicht? Unsere Mailrelays haben sehr wohl öffentliche IPs, um genau zu sein, die IPs die auch als MX-Records eingetragen sind. Durch die vorgeschaltete Firewall sind sie nur über 25 zu erreichen, die nachgeschaltete erlaubt auch nur 25. Ob jetzt ein Angreifer den Server via NAT auf 25 anspricht oder auf der echten IP ist doch wurst.

 

frage:

wenn deine monitoring tools in der DMZ agieren, wie soll dann jemals erkannt werden, das das mailsystem von draussen nicht mehr erreichbar ist ? (...denn es ist ja erreichbar)

wie soll dann ein backupsystem anspringen (das ja auf monitoring reagiert)

muss es ja eigentlich nicht, weil mailsystem1 ja eigentlich noch funktioniert nur die dedizierte firewall nicht mehr, die keinen traffic mehr erlaubt.

Zu monitoren wären also in jedem fall beide Netzwerkschnittstellen der dedizierten firewall...

Ich kann z.B. alle 5 Minuten eine Mail an Echo@TU-Berlin.DE schicken und auswerten, ob die Rückantwort ankommt. Zu monitoren wären prinzipiell alle beteiligten Systeme.

 

von daher ---> bei rechensystemen mit direktem anschluss an das internet, Webservern, FTP- / Mai / DNS - systemen hast du direkt auf dem laufenden system eine firewall am laufen, das macht sinn... (meine meinung)

alles andere ist unnützer, zusätzlicher, administartiver aufwand... , schafft zusätzliche flaschenhälse (meine meinung)

Nö, deine Lösung ist zusätzlicher administrativer Aufwand. Angenommen ich habe 4 oder 8 Smarthosts in der DMZ, dann ist es doch wohl weniger Aufwand eine vorgeschaltete Checkpoint zu administrieren und konfigurieren, als jeweils eine Firewall auf den Mailsystemen.

Worauf ich hinaus will ist, dass bei umfangreichen DMZs durchaus auf Firewalls auf den einzelnen Systemen verzichtet werden kann und dafür eine mehrstufige Lösung, optimalerweise von verschiedenen Herstellern vorgeschaltet wird. Die Einzelsysteme werden dann eben gepatcht, die (Web-)anwendungen sollten auf sichere Programmierung abgeklopft werden, aber das sind alles Punkte, bei denen mir eine weitere Firewall auf dem Einzelsystem keine zusätzliche Sicherheit bringt.

 

iptables auf einem mailsystem, mit stateful filtering, implementierungen die fehlerhafte und ungültige pakete erkennen und verwerfen tut nicht weniger schlecht seinen dienst wie eine checkpoint...

Kann denn IPTables mittlerweile in die Pakete schauen? Checkpoint kann es, ISA, z.B. auch.

Die Checkpoint, bzw. die eigenständige Lösung hat aber einen Riesenvorteil. Sollte ein Angreifer auf dem offenen Dienst, z.B. auf 80 es schaffen, eine Sicherheitslücke auszunutzen und damit den Server in die Gewalt bekommen, könnte er die auf dem Server laufende Firewall aushebeln.

Die Checkpoint wird ihm weiterhin nur 80 anbieten.

 

was bitte schön hat eine firewall auf einem mailsystem grossartiges zu tun, wenn sie nur den port 25 offen hält und den rest an ungewollten paketen verwirft / droppt.

im übrigen habe ich auch noch nichts davon gehört, das man mit DoS eine sorgfältig konfigurierte firewall bezwingt, ich bin bisher nur davon ausgegangen das Denial of Services dienste lahm legen.

Nun, es sind ja auch Szenarien, wie Exchange Frontend denkbar, bei denen ich ein paar mehr Ports brauche.