Hardware vs Software Firewalls
Sven Mandel
gegenüber einer Software Firewall bevorzugt werden sollte ? Und wenn man
schon dabei ist, welche Hardware Firewalls sind im moment mit die Besten auf
dem Markt (bitte Preis/Leistungs verhältnis beachten !!!) Firewalls für
mehrere 100TDM kommen nicht in Frage !
Frank Fiene
Ich krieg die Krise. Was ist denn jetzt der Unterschied? Oder besser
gefragt, was ist die Definition für Hardware-/Software-Firewall.
Eine Firewall ist eine Kombination aus Hardware (aktive und passive
Komponenten) und Software (Kernel-mode und User-Mode).
Oder habe ich da etwas falsch verstanden?
ff
--
Frank Fiene, SYNTAGS GmbH, Im Defdahl 5-10, D-44141 Dortmund, Germany
Security, Cryptography, Networks, Software Development
http://www.syntags.de mailto:Frank...@syntags.de
Bernd Eckenfels
> Kann mir jemand GUTE gr?nde nennen warum eine Hardware Firewall immer
> gegen?ber einer Software Firewall bevorzugt werden sollte ?
Immer richtige gute Gründe gibt es nicht. Das kommt von Fall zu Fall drauf an.
Generell gibt es keinen großen Preisunterschied zwischen Firewall Appliances
und Firewall software auf commodity(sp?) Hardware.
> Und wenn man
> schon dabei ist, welche Hardware Firewalls sind im moment mit die Besten auf
> dem Markt (bitte Preis/Leistungs verh?ltnis beachten !!!) Firewalls f?r
> mehrere 100TDM kommen nicht in Frage !
MHO bewegen sich die wenigsten Firewalls in dem Bereich. Mit $20k biste sicher
gut Dabei (inkl. Lizensen für ein grosses Netz).
Gruss
Bernd
Ulrich Eckhardt
>
> Kann mir jemand GUTE gründe nennen warum eine Hardware Firewall immer
> gegenüber einer Software Firewall bevorzugt werden sollte ?
Hi,
die Unterscheidung Hardware/Software Firewall ist eigentlich quatsch.
Ein Firewall ist zuerst einmal ein Sicherheitskonzept. Dieses wird
dann unter Zuhilfenahme von geeigneter Soft und Hardware realisiert.
Was manchmal als "Hardware Firewall" bezeichnet wird, ist eine
properitäre Packetfilter Software die auf eigener Hardware läuft,
wärend der "Software Firewall" eine Packetfilter Software ist,
die auf gebräuchlicher Hardware z.B. PC's läuft.
>Und wenn man
> schon dabei ist, welche Hardware Firewalls sind im moment mit die Besten auf
> dem Markt (bitte Preis/Leistungs verhältnis beachten !!!) Firewalls für
> mehrere 100TDM kommen nicht in Frage !
Die besten Firewalls sind die, die von geschultem Personal
eingerichtet und dauerhaft gewartet werden. Die eigentlichen
Software/Hardware kosten sagen nicht viel über die Qualität.
Ein schlecht designter und gewarteter "Firewall" einer namhaften
Firma kann wesentlich schlechter sein als ein billiger z.B.
auf Linux basierender, der von jemand designed und gewartet
wird, der sich damit auskennt.
Uli
--
Ulrich Eckhardt Tr@nscom
http://www.uli-eckhardt.de http://www.transcom.de
Lagerstraße 11-15 A8
64807 Dieburg Germany
Gaby Hornik
> Sven Mandel wrote:
>>Und wenn man
>> schon dabei ist, welche Hardware Firewalls sind im moment mit die Besten auf
>> dem Markt (bitte Preis/Leistungs verhältnis beachten !!!) Firewalls für
>> mehrere 100TDM kommen nicht in Frage !
> Die besten Firewalls sind die, die von geschultem Personal
> eingerichtet und dauerhaft gewartet werden. Die eigentlichen
> Software/Hardware kosten sagen nicht viel über die Qualität.
Ich wuerde "geschultes Personal" durch "informiertes Personal mit
ausgepraegtem Sicherheitsbewusstsein" ersetzen, das
ist nicht immer dasselbe und das Sicherheitsbewusstsein
in vielen Firmen ist einfach grausam. Bequemlichkeit wird
immer noch vorgezogen.
> Ein schlecht designter und gewarteter "Firewall" einer namhaften
> Firma kann wesentlich schlechter sein als ein billiger z.B.
> auf Linux basierender, der von jemand designed und gewartet
> wird, der sich damit auskennt.
Volle Zustimmung. Ich habe die Konstellation Redhat/Checkpoint
laufen. Kosten ca. 20TDM. :-) Ich finde allerdings, dass es das
wert war.
Die Rulebase muss man allerdings sorgfaeltig ausarbeiten,
sonst bringt das alles nichts.
Mfg, Gaby
--
mailto:ga...@gabyhornik.de
ICQ: 105106979
Ulrich Eckhardt
>
> Ich wuerde "geschultes Personal" durch "informiertes Personal mit
> ausgepraegtem Sicherheitsbewusstsein" ersetzen, das
> ist nicht immer dasselbe und das Sicherheitsbewusstsein
> in vielen Firmen ist einfach grausam. Bequemlichkeit wird
> immer noch vorgezogen.
Full Ack :-)
> Volle Zustimmung. Ich habe die Konstellation Redhat/Checkpoint
> laufen. Kosten ca. 20TDM. :-) Ich finde allerdings, dass es das
> wert war.
Warum man allerdings noch [1] Checkpoint braucht, wo der Kernel 2.4
iptables mit stateful inspection und diversen möglichen und
unmöglichen Erweiterungen als Open Source und für 0 TDM
bietet weiss ich allerdings nicht.
Grüße
Uli
[1] bitte das "noch" beachten, wenn der Firewall vor Kernel 2.4
eingeführt wurde, mag Checkpoint seine Berechtigung gehabt
haben und jetzt immer noch zur Beruhigung des Managements
dienen.
Juergen Nieveler
>Warum man allerdings noch [1] Checkpoint braucht, wo der Kernel 2.4
>iptables mit stateful inspection und diversen möglichen und
>unmöglichen Erweiterungen als Open Source und für 0 TDM
>bietet weiss ich allerdings nicht.
CVP? Authentisierung? VPN?
--
Juergen Nieveler
Support the ban of Dihydrogen Monoxide: http://www.dhmo.org/
"The people united can never be ignited!"- Sgt. Colon, Ankh-Morpork Watch
PGP-Key available under www.netcologne.de/~nc-nievelju/
T-Online
1. Eine Softwarefirewall kontroliert und blocked nur alle eingehende
signale die ankommen . Da es nur software ist kann man das teil aber ganz
leicht übergehen indem man es zuerst überlädt .
Das kann bei einer Hardware - firewall nicht so leicht passieren da es
ein kompletter PC mit OS ist wo man erstmal die ports zum nächsten
rechner suchen muß .
Bei den sogenannten igmp und icmp wo man ohne server attackieren kann
indem man den Computer überlädt und ihm einen Bluescreen zufügt , kann
man nicht mehr getroffen werde da wenn man genuked wird die H Firewall
abschmiert!!!!
Frank Fiene schrieb:
Ulrich Eckhardt
>
> Ulrich Eckhardt <ulrich....@transcom.de> wrote:
>
> >Warum man allerdings noch [1] Checkpoint braucht, wo der Kernel 2.4
> >iptables mit stateful inspection und diversen möglichen und
> >unmöglichen Erweiterungen als Open Source und für 0 TDM
> >bietet weiss ich allerdings nicht.
>
> CVP? Authentisierung? VPN?
CVP = Content Vectoring Protocol API ?
So was ähnliches stellt iptables ebenfalls zur Verfügung :
http://www.netcologne.de/~meberg/netfilter/Netfilter-Hacking-HOWTO.txt
speziell hier die libipq .
Authentisierung ?
Kommt daruf an, was authentifiziert werden soll
VPN ?
Skip http://www.skip.org/
Uli
Ulrich Eckhardt
>
> Hallo Ulrich,
>
> * Ulrich Eckhardt <ulrich....@transcom.de> wrote:
> [...]
> > [1] bitte das "noch" beachten, wenn der Firewall vor Kernel 2.4
> > eingeführt wurde, mag Checkpoint seine Berechtigung gehabt
> > haben und jetzt immer noch zur Beruhigung des Managements
> > dienen.
>
> vorher nicht?
Checkpoint kann Stateful Inspection, was erst mit iptables
in Kernel 2.4 eingeführt wurde. Wobei ich stateful nicht unbedingt
als Killerargument bezeichnen würde, aber es macht das Leben
leichter und ich habe es mittlerweile recht lieb gewonnen :-)
Uli
Ulrich Eckhardt
Ich versuche trotzdem mal drauf zu antworten
>
> Ich kann dir einen gute Grund nennen :
> 1. Eine Softwarefirewall kontroliert und blocked nur alle eingehende
> signale die ankommen . Da es nur software ist kann man das teil aber ganz
> leicht übergehen indem man es zuerst überlädt .
Großer Quatsch und absolut unzusammenhängen. Software kann man nicht
überladen. Lediglich Hardware überlasten.
> Das kann bei einer Hardware - firewall nicht so leicht passieren da es
> ein kompletter PC mit OS ist wo man erstmal die ports zum nächsten
> rechner suchen muß .
Noch größerer Quatsch, auch auf einer "Hardware Firewall" läuft
eine Software.
> Bei den sogenannten igmp und icmp wo man ohne server attackieren kann
> indem man den Computer überlädt und ihm einen Bluescreen zufügt , kann
Hat mit dem Thema nichts zu tun und Bluescreen gibts nur unter NT.
[ab hier beginnt der halbwegs ordentlich gequotete Teil]
> Frank Fiene schrieb:
> >
> > Ich krieg die Krise. Was ist denn jetzt der Unterschied? Oder besser
> > gefragt, was ist die Definition für Hardware-/Software-Firewall.
Die Begriffe Software und Hardware Firewall sind lediglich
Worthülsen diverser Markting Fuzzies und sagen nichts über
die Funktion aus.
> > Eine Firewall ist eine Kombination aus Hardware (aktive und passive
> > Komponenten) und Software (Kernel-mode und User-Mode).
> > Oder habe ich da etwas falsch verstanden?
Das eine Hardware eine Komination aus Hardware und Software
ist, ist korrekt. Software ohne Hardware ist einleuchtender
weise Sinnfrei. Theoretisch könnte man einen Filtering Router
komplett in Hardware bauen, tut das aber wegen des Unflexiblen
Designs nicht. In jedem Router befindet sich ein Prozessor
nebst Softwar, auch wenn in den Prospekten "Hardware Firewall"
steht.
Ob die Software jetzt im Kernel Mode oder User Mode läuft ist
unerheblich und hängt auch von der verwendeten Hardware ab.
Lutz Donnerhacke
Bitte nur einzeln eintreten.
>Bei den sogenannten igmp und icmp wo man ohne server attackieren kann
Eine IGMP Attacke interessiert mich. Wie macht man das?
Juergen Nieveler
>CVP = Content Vectoring Protocol API ?
>So was ähnliches stellt iptables ebenfalls zur Verfügung :
>http://www.netcologne.de/~meberg/netfilter/Netfilter-Hacking-HOWTO.txt
>speziell hier die libipq .
Und das wird auch von genauso vielen Drittanbietern unterstützt?
>Authentisierung ?
>Kommt daruf an, was authentifiziert werden soll
User. Mittels Radius, LDAP, TACACS, etc.
>VPN ?
>Skip http://www.skip.org/
Oder Free S/Wan... aber Checkpoint liefert das alles aus einer Hand, mit
Support (na ja, etwas Support) und Garantie.
Was ich noch vergessen hatte... Checkpoints ganzer Stolz: INSPECT. Mehr als
nur Stateful Inspection, da werden die Paket_inhalte_ geprüft.
Frank Fiene
Danke für die Bestätigung, Ulrich.
Die Frage war auch nur rein rhetorisch gemeint, aber die Antwort von
"T-Online" habe ich leider hier auch erwartet. Plonk.
Frank Fiene
> Ich kann dir einen gute Grund nennen :
> 1. Eine Softwarefirewall kontroliert und blocked nur alle eingehende
> signale die ankommen . Da es nur software ist kann man das teil aber
> ganz leicht übergehen indem man es zuerst überlädt .
Schwachsinn!
> Das kann bei einer Hardware - firewall nicht so leicht passieren da
> es ein kompletter PC mit OS ist wo man erstmal die ports zum
> nächsten rechner suchen muß .
Schwachsinn, Beispiel: ist ein OS keine Software?
> Bei den sogenannten igmp und icmp wo man ohne server attackieren
> kann indem man den Computer überlädt und ihm einen Bluescreen zufügt
> , kann man nicht mehr getroffen werde da wenn man genuked wird die H
> Firewall abschmiert!!!!
Wie überlädt man einen Computer? Stellt man ein Gewicht drauf?
Da sage ich jetzt nichts mehr zu. Vielleicht verstehe ich den Satz
aber auch nicht.
Plonk
Felix von Leitner
> >Bei den sogenannten igmp und icmp wo man ohne server attackieren kann
> Eine IGMP Attacke interessiert mich. Wie macht man das?
Na man schickt so viele davon, daß die Leitung saturiert wird *bg*
Fefe
Joerg Wendland
Guido Hennecke <g.hen...@t-online.de> wrote:
>Und wozu _muss_ man das haben?
schoenes feature: man muss sich z.B. nicht mehr mit FTP herumaergern.
Macht IMHO Sinn fuer ein Firewall, hinter dem nur Clients haengen.
>> Wobei ich stateful nicht unbedingt
>> als Killerargument bezeichnen würde,
>
>Doch und zwar auch im woertlichen Sinne.
Und das ist halt der Nachteil dran... Fuer eine DMZ ist Stateful
filtering gefaehrlich.
Gruss, Joerg
--
Freier Platz fuer Bearbeitungsvermerke, bitte nicht beschriften.
Joerg Wendland
Juergen Nieveler <juergen....@web.de> wrote:
>Was ich noch vergessen hatte... Checkpoints ganzer Stolz: INSPECT. Mehr als
>nur Stateful Inspection, da werden die Paket_inhalte_ geprüft.
Naja, kann der netfilter schon auch, siehe den STRING-match. Aber Du hast
schon recht, Checkpoint ist ziemlich gut gemacht. Besonders die GUI macht
die Administration sehr uebersichtlich (Linux: fwbuilder). Das einzige
Problem das ich persoenlich mit Checkpoint hab, ist ein Vertrauensproblem.
Checkpoint ist proprietaer. Aber das ist wiederum Philosophie :))
Daniel Schmidt
> > eingerichtet und dauerhaft gewartet werden. Die eigentlichen
> > Software/Hardware kosten sagen nicht viel über die Qualität.
>
> Ich wuerde "geschultes Personal" durch "informiertes Personal mit
> ausgepraegtem Sicherheitsbewusstsein" ersetzen, das
> ist nicht immer dasselbe und das Sicherheitsbewusstsein
> in vielen Firmen ist einfach grausam. Bequemlichkeit wird
> immer noch vorgezogen.
So in der Art von "es gibt jemanden in der Firma mit Sicherheits- und
Verantwortungsbewußtsein, der sich ständig auf dem laufenden
hält und den Dienstleister die Arbeit der Filterkonfiguration
überläßt"?
> > Ein schlecht designter und gewarteter "Firewall" einer namhaften
> > Firma kann wesentlich schlechter sein als ein billiger z.B.
> > auf Linux basierender, der von jemand designed und gewartet
> > wird, der sich damit auskennt.
>
> Volle Zustimmung. Ich habe die Konstellation Redhat/Checkpoint
> laufen. Kosten ca. 20TDM. :-) Ich finde allerdings, dass es das
> wert war.
Das ist interessant. Wir haben die Konstellation Redhat/Ipchains mit
Option auf Checkpoint laufen. Da ich die Gelegenheit hatte, bei der
Installation und Anpassungsarbeiten dabei zu sein, hat das bei mir ein
recht gutes Gefühl hinterlassen, eine Open-Source-Firewall zu haben.
Die Option, Checkpoint FW-1 einzusetzen, schien mir fast schon
überflüssig zu sein; dann kam es zu einem Meeting, in dem die
weitere Vorgehensweise _nach_ der Installation besprochen worden ist.
Da ich als DV-Mitarbeiter in einem Mittelstandsunternehmen in vielen
verschiedenen Bereichen zu tun habe, und eine Wartung der Firewall
meinerseits aufgrund von Zeitmangel nicht in Frage kommt, habe ich die
Frage nach einer sinnvollen Wartung unserer Firewall-Lösung gestellt
- und schwupps wurde zum Einsatz einer kommerziellen Firewallsoftware
(in unserem Fall natürlich die FW-1) geraten, weil: Support vom
Hersteller, es ist ein "Produkt", die Wartung wäre einfacher und als
Dienstleister hätten sie (unser Dienstleister) nicht die notwendigen
Personal-Kapazitäten; außerdem wären sogenannte
"Open-Source-Paketfilter-Firewalls" immer speziell angepasste
Lösungen - fällt der einrichtende Mitarbeiter aus bzw. kündigt
er, hat sein Nachfolger wohl größte Schwierigkeiten, sich
einzuarbeiten. Wartungsverträge für so eine Lösung sind damit
wirtschaftlich (für einen Dienstleister) nicht kalkulierbar...
Es würde mich freuen hier ein paar Meinungen dazu zu lesen, welche
Lösung vom Wartungsaspekt her für Unternehmen zu bevorzugen ist.
Also, Dokumentierte Open-Source-Firewall auf Basis von ipchains vs.
Einsatz eines kommerziellen Produkts wie z.B. Checkpoint FW-1.
Ist es tatsächlich so schwer für einen Dienstleister, für
ipchains Wartungsdienstleistung zu erbringen, bzw. sich in die Skripte
anderer Dienstleister einzuarbeiten, wenn es eine Dokumentation gibt?
Irgendwie gehe ich davon aus, daß Dienstleister in dem Bereich, vor
Allem, wenn sie schon eine Lösung _verkaufen_, aus den gleichen
Büchern abschreiben und die Umsetzungen sich doch ziemlich ähnlich
sehen müssten. Korrigiert mein Weltbild bitte, wenn dies in der
Praxis nicht so ist.
> Die Rulebase muss man allerdings sorgfaeltig ausarbeiten,
> sonst bringt das alles nichts.
Gut, das sehe ich auch so. Genau das sollte ja im FW-Konzept schriftlich
festgehalten sein, zusammen mit der prinzipiellen Umsetzung. Ist dies
gegeben, kann die Umsetzung nur noch eine Frage der Techniker sein.
mfg.,
-ds-
Martin 'Funny' Heise
>
> Hardware Firewall immer gegenüber einer Software Firewall
ich darf mich zitieren?
> > Was ist ein "Hardware-Firewall"?
>
> Funny schrieb darauf in <3A9C6C89...@L13.de>:
> Eine Un*x-Kiste (heutzutage zumeist sogar Linux), die in ein
> 19"-Gehäuse geschraubt wurde und wo vorne ein klingender
> mainstream-Firmenname draufsteht, damit die Management-Ebene in dem
> Glauben ist, "etwas Professionelles" gekauft zu haben.
Funny
--
"User? Wo? *erschrecktumschau*" [Sebastian Posner in d.a.s.r.]
Ernest Niedermann
Sven Mandel wrote:
NEIN!
Abgesehen von den anderen *guten* Gründen in diesem Thread, ich bevorzuge
intellegente SW-FWs allein wegen des Reporting!
Ciao - Ernest
Lutz Donnerhacke
>On 1 Mar 2001 17:48:20 GMT,
> Guido Hennecke <g.hen...@t-online.de> wrote:
>>Und wozu _muss_ man das haben?
>
>schoenes feature: man muss sich z.B. nicht mehr mit FTP herumaergern.
>Macht IMHO Sinn fuer ein Firewall, hinter dem nur Clients haengen.
Nein. Stateful braucht man, um Null-Scans abzublocken.
Lutz Donnerhacke
Wie bekommst man ein IGMP Paket über einen Router hinweg? IGMP ist ja nicht
routbar.
Mich interessiert _Deine_ Lösung, ich kenne keine die nicht auf Kooperation
des Routers hinausläuft.
Lutz Donnerhacke
>Es würde mich freuen hier ein paar Meinungen dazu zu lesen, welche
>Lösung vom Wartungsaspekt her für Unternehmen zu bevorzugen ist.
>Also, Dokumentierte Open-Source-Firewall auf Basis von ipchains vs.
>Einsatz eines kommerziellen Produkts wie z.B. Checkpoint FW-1.
>Ist es tatsächlich so schwer für einen Dienstleister, für
>ipchains Wartungsdienstleistung zu erbringen, bzw. sich in die Skripte
>anderer Dienstleister einzuarbeiten, wenn es eine Dokumentation gibt?
Einem Dienstleister, der undokumentierte ipchains Scripte verfaßt, würde ich
genauso wenig trauen, wie einem Dienstleister, der deswegen ein
kommerzielles Produkt verkauft, weil er seine Leute im Notfall auf Schulung
schicken kann.
>Irgendwie gehe ich davon aus, daß Dienstleister in dem Bereich, vor
>Allem, wenn sie schon eine Lösung _verkaufen_, aus den gleichen
>Büchern abschreiben und die Umsetzungen sich doch ziemlich ähnlich
>sehen müssten. Korrigiert mein Weltbild bitte, wenn dies in der
>Praxis nicht so ist.
Die Lösungen sind firmenspezifisch und nicht abgeschrieben. Abgeschriebenen
Lösungen würde ich nicht trauen.
>Gut, das sehe ich auch so. Genau das sollte ja im FW-Konzept schriftlich
>festgehalten sein, zusammen mit der prinzipiellen Umsetzung. Ist dies
>gegeben, kann die Umsetzung nur noch eine Frage der Techniker sein.
Fordere verständliche Dokumentation zur ipchains Konfiguration (nimm sie
nicht ab, solange Du sie nicht verstehst) und Du hast etwas, womit Du im
Zweifel auch im Haus ein Problem lösen lassen kannst.
Joerg Wendland
Daniel Schmidt <dsm...@gmx.net> wrote:
>So in der Art von "es gibt jemanden in der Firma mit Sicherheits- und
>Verantwortungsbewußtsein, der sich ständig auf dem laufenden
>hält und den Dienstleister die Arbeit der Filterkonfiguration
>überläßt"?
Vielleicht so: "es gibt jemanden in der Firma, der genuegend Wissen hat,
um eine Sicherheitsrichtlinie zu verfassen. Aufgrund dieser Richtlinie
hat der Dienstleister den Firewall zu warten." Damit ist "die" Rulebase
auf Papier festgehalten und somit mehr oder weniger zwischen unter-
schiedlichen Firewall-Loesungen "portierbar".
>- und schwupps wurde zum Einsatz einer kommerziellen Firewallsoftware
>(in unserem Fall natürlich die FW-1) geraten, weil: Support vom
>Hersteller, es ist ein "Produkt", die Wartung wäre einfacher und als
>Dienstleister hätten sie (unser Dienstleister) nicht die notwendigen
>Personal-Kapazitäten; außerdem wären sogenannte
>"Open-Source-Paketfilter-Firewalls" immer speziell angepasste
>Lösungen - fällt der einrichtende Mitarbeiter aus bzw. kündigt
>er, hat sein Nachfolger wohl größte Schwierigkeiten, sich
>einzuarbeiten. Wartungsverträge für so eine Lösung sind damit
>wirtschaftlich (für einen Dienstleister) nicht kalkulierbar...
Doch.
<Beispiel>
Wir vertreiben eine Firewall-Loesung auf Debian/iptables-
Basis. Das komplette System bootet von CD, dadurch hat man keinen
Installationsaufwand. Die komplette Konfiguration ist auf einer
Diskette gespeichert, die von geschultem Personal von Hand bzw. vom
Kunden mittels einer Kilcki-Bunti-GUI a la Checkpoint erstellt werden
kann. Das laesst wunderbar in Produkt und Dienstleistung aufteilen
um dadurch sehr gut kalkulieren.
</Beispiel>
>Also, Dokumentierte Open-Source-Firewall auf Basis von ipchains vs.
>Einsatz eines kommerziellen Produkts wie z.B. Checkpoint FW-1.
Auch eine Checkpoint-/Rapto-/PIX-Installation sollte gut dokumentiert
sein.
>Ist es tatsächlich so schwer für einen Dienstleister, für
>ipchains Wartungsdienstleistung zu erbringen, bzw. sich in die Skripte
>anderer Dienstleister einzuarbeiten, wenn es eine Dokumentation gibt?
Ich sehe da keinen Unterschied zu einer proprietaeren Software. Wenn
ich mir einen Haufen PIX-Regeln anseh, die ich nicht selber geschrieben
habe, stehe ich genauso da, wie wenn ich mir ein Shellskript anseh, in
dem hunderte ipchains-Aufrufe durchgefuehrt werden.
>> Die Rulebase muss man allerdings sorgfaeltig ausarbeiten,
>> sonst bringt das alles nichts.
>
>Gut, das sehe ich auch so. Genau das sollte ja im FW-Konzept schriftlich
>festgehalten sein, zusammen mit der prinzipiellen Umsetzung. Ist dies
>gegeben, kann die Umsetzung nur noch eine Frage der Techniker sein.
ACK, siehe oben.
Ulrich Eckhardt
> >> Und warum ist das deiner Meinung nach erst seit Kernel 2.4 der Fall und
> >> vorher nicht?
> > Checkpoint kann Stateful Inspection, was erst mit iptables
> > in Kernel 2.4 eingeführt wurde.
>
Hi,
ich sagte nicht dass man das haben muss.
> > Wobei ich stateful nicht unbedingt
> > als Killerargument bezeichnen würde,
>
> Doch und zwar auch im woertlichen Sinne.
iptables verhält sich reht robust gegen DOS attacken. Ich habe
erfolglos versucht unseren Firewall [1] durch diverse DOS attacken
im internen Netz (10MB) in die Knie zu zwingen. Unsers 128KB
ISDN Standleitung überlebt das Teil deshalb problemlos. Irgendwelche
Attacken gegen unseren Webserver oder E-mail sind da bei weitem
gefährlicher. Ausserdem haben wir noch eine Cisco mit normalem
Packet filter welcher ohnehin schon den meistem Müll entsorgt.
Es kommt halt drauf an, wo man das für was einsetzt. Abgesehen davon
kann man bei iptables normales packet filtern mit stateful
sehr schon mischen.
> > aber es macht das Leben
> > leichter und ich habe es mittlerweile recht lieb gewonnen :-)
>
> Wozu? Was bringt mir das?
Wesentlich vereinfachte Filterregeln, ordentlich funktionierendes
ftp, keine offenen "hohen" ports, Schutz gegen stealth scans
und diverse ICMP scans.
Uli
[1] Pentim 166 mit 94MB Speicher
Mario 'BitKoenig' Holbe
|> iptables verhält sich reht robust gegen DOS attacken. Ich habe
|> erfolglos versucht unseren Firewall [1] durch diverse DOS attacken
|> im internen Netz (10MB) in die Knie zu zwingen. Unsers 128KB
|> ISDN Standleitung überlebt das Teil deshalb problemlos. Irgendwelche
Sorry, aber zu behaupten, ein wie auch immer gearteter Packet Filter
schuetze vor DoS-Attacken ist gelinde gesagt grober Unfug.
Ein System ist so stark, wie sein schwaechster Punkt und Deine
128KB (Kb?) ISDN Standleitung ist ein derart schwacher Punkt, dass
er analog einer Sicherung jegliches dahinter liegende Equipment
zuverlaessig gegen traffic based DoS-Attacken schuetzt - egal
ob Packet Filter oder nicht.
Eine system based DoS-Attack (z.B. lustige 100% CPU for service
blafasel Attacken) kannst Du mit einem Packet Filter ebenfalls kaum
verhindern, es sei denn, Du kennst sie bereits.
|> Wesentlich vereinfachte Filterregeln, ordentlich funktionierendes
|> ftp, keine offenen "hohen" ports, Schutz gegen stealth scans
|> und diverse ICMP scans.
Gesundheit.
regards,
Mario
--
42 Mario 'BitKoenig' Holbe <Mario...@RZ.TU-Ilmenau.DE>
dup http://www.tu-ilmenau.de/~holbe/
*
. Uebrigens... Wer frueher stirbt ist laenger tot!
Ulrich Eckhardt
>
> Gaby Hornik <ga...@gabyhornik.de> wrote:
> > Ich wuerde "geschultes Personal" durch "informiertes Personal mit
> > ausgepraegtem Sicherheitsbewusstsein" ersetzen, das
> > ist nicht immer dasselbe und das Sicherheitsbewusstsein
> > in vielen Firmen ist einfach grausam. Bequemlichkeit wird
> > immer noch vorgezogen.
>
> So in der Art von "es gibt jemanden in der Firma mit Sicherheits- und
> Verantwortungsbewußtsein, der sich ständig auf dem laufenden
> hält und den Dienstleister die Arbeit der Filterkonfiguration
> überläßt"?
Der Dienstleister, der die Filterkonfiguration macht, sollte
auch der sein, der sich ständig auf dem Laufenden hält und das
Sicherheits und Verantwortungsbewusstsein hat [1], wobei jemand
in der Firma mit Sicherheits- und Verantwortungsbewußtsein,
der betreffem Dienstleister über die Schulter schaut sicher nicht
verkehrt ist. Jedoch sollte betreffender Mitarbeiter gute Kentnisse
mit Netzwerken und deren Grundlagen haben.
> > Volle Zustimmung. Ich habe die Konstellation Redhat/Checkpoint
> > laufen. Kosten ca. 20TDM. :-) Ich finde allerdings, dass es das
> > wert war.
>
> Das ist interessant. Wir haben die Konstellation Redhat/Ipchains mit
> Option auf Checkpoint laufen. Da ich die Gelegenheit hatte, bei der
> Installation und Anpassungsarbeiten dabei zu sein, hat das bei mir ein
> recht gutes Gefühl hinterlassen, eine Open-Source-Firewall zu haben.
Es kommt hier auf die Komplexität an, was zu schützen ist und wie
die Infrasturkur aussieht. Hat man z.B. nur ein Netzwerk mit
privatem Ip address-raum und geht mittels Masquerading raus
und es gibt keine sonstigen Spezialitäten, so leistet
Ipcahins gute Dienste und Checkpoint kann da wirklich schon
overkill sein. Es kommt halt auf die näheren Umstände an.
> Die Option, Checkpoint FW-1 einzusetzen, schien mir fast schon
> überflüssig zu sein; dann kam es zu einem Meeting, in dem die
> weitere Vorgehensweise _nach_ der Installation besprochen worden ist.
[..]
> - und schwupps wurde zum Einsatz einer kommerziellen Firewallsoftware
> (in unserem Fall natürlich die FW-1) geraten, weil: Support vom
> Hersteller, es ist ein "Produkt", die Wartung wäre einfacher und als
> Dienstleister hätten sie (unser Dienstleister) nicht die notwendigen
> Personal-Kapazitäten; außerdem wären sogenannte
> "Open-Source-Paketfilter-Firewalls" immer speziell angepasste
> Lösungen - fällt der einrichtende Mitarbeiter aus bzw. kündigt
> er, hat sein Nachfolger wohl größte Schwierigkeiten, sich
> einzuarbeiten. Wartungsverträge für so eine Lösung sind damit
> wirtschaftlich (für einen Dienstleister) nicht kalkulierbar...
Support vom Hersteller kann gelegentlich auch grottenschlecht sein.
Ich habe mit "Support vom Hersteller" schon wirklich schlechte
Erfahrungen gemacht. Bei open source war der Support bisher recht
gut (Spizenreiter ist derzeit der Maintainer der Informix Unterstützung
für php, der einen Bug 30 Minuten nach Report gefixt hatte).
Gelegentlich kommt eventuall zwar auch mal ein RTFM, das ist
aber in der Regel ein Zeichen dafür dass man Tomaten auf den Augen
hat.
Das mit dem Wartungsaspekt kommt auf die Komplexität und die
Dokumentation an. Da kann man keine pauschalen Aussagen
Treffen.
> Ist es tatsächlich so schwer für einen Dienstleister, für
> ipchains Wartungsdienstleistung zu erbringen, bzw. sich in die Skripte
> anderer Dienstleister einzuarbeiten, wenn es eine Dokumentation gibt?
> Irgendwie gehe ich davon aus, daß Dienstleister in dem Bereich, vor
> Allem, wenn sie schon eine Lösung _verkaufen_, aus den gleichen
> Büchern abschreiben und die Umsetzungen sich doch ziemlich ähnlich
> sehen müssten. Korrigiert mein Weltbild bitte, wenn dies in der
> Praxis nicht so ist.
Hier sind kleinere Korrekturen des Weltbildes angebracht.
Eine Firewall ist oftmals eine speziell auf die Sicherheits-
bedürfnisse und die Infrastruktur der Firma angepasste
Lösung. Das kommt halt ganz auf die Größe und Komplexität
der geforderten Lösungen an.
Uli
[1] Ich bin nicht sehr gut im Formulieren juristisch korrekter
Sätze.
[2] Ich weiss,der Satz ist lange, siehe [1]
Ulrich Eckhardt
>
> Ulrich Eckhardt <ulrich....@transcom.de> wrote:
> |> iptables verhält sich reht robust gegen DOS attacken. Ich habe
> |> erfolglos versucht unseren Firewall [1] durch diverse DOS attacken
> |> im internen Netz (10MB) in die Knie zu zwingen. Unsers 128KB
> |> ISDN Standleitung überlebt das Teil deshalb problemlos. Irgendwelche
>
> Sorry, aber zu behaupten, ein wie auch immer gearteter Packet Filter
> schuetze vor DoS-Attacken ist gelinde gesagt grober Unfug.
Hi,
das habe ich auch nicht behauptet. Bitte Ursprungsposting noch
mal genau durchlesen.
> Ein System ist so stark, wie sein schwaechster Punkt und Deine
> 128KB (Kb?) ISDN Standleitung ist ein derart schwacher Punkt, dass
> er analog einer Sicherung jegliches dahinter liegende Equipment
> zuverlaessig gegen traffic based DoS-Attacken schuetzt - egal
> ob Packet Filter oder nicht.
Genau das habe ich gesagt. Bitte Ursprungsposting noch mal
genau durchlesen.
> Eine system based DoS-Attack (z.B. lustige 100% CPU for service
> blafasel Attacken) kannst Du mit einem Packet Filter ebenfalls kaum
> verhindern, es sei denn, Du kennst sie bereits.
Das war nicht Gegenstand der Diskusion. Bitte Ursprungsposting noch mal
genau durchlesen.
> |> Wesentlich vereinfachte Filterregeln, ordentlich funktionierendes
> |> ftp, keine offenen "hohen" ports, Schutz gegen stealth scans
> |> und diverse ICMP scans.
>
> Gesundheit.
Danke
Uli
Mario 'BitKoenig' Holbe
|>> Ulrich Eckhardt <ulrich....@transcom.de> wrote:
|>> |> iptables verhält sich reht robust gegen DOS attacken. Ich habe
|>> |> erfolglos versucht unseren Firewall [1] durch diverse DOS attacken
|>> |> im internen Netz (10MB) in die Knie zu zwingen. Unsers 128KB
|>> |> ISDN Standleitung überlebt das Teil deshalb problemlos. Irgendwelche
|>> Sorry, aber zu behaupten, ein wie auch immer gearteter Packet Filter
|>> schuetze vor DoS-Attacken ist gelinde gesagt grober Unfug.
|> mal genau durchlesen.
Das habe ich getan und die wesentlichen Stellen unterstrichen.
Du stellst einen Zusammenhang her zwischen iptables und der
Tatsache, dass Dein System bei einer DoS Attacke nicht in die
Knie gegangen ist.
Dieser Zusammenhang existiert jedoch nicht.
De facto existiert lediglich ein Zusammenhang zwischen Deiner
schmalbandigen Anbindung (in diesem Fall 10 MBit) und der Tatsache,
dass Dein System nicht in die Knie gegangen ist. iptables hat damit
nix zu tun.
regards,
Andreas Spengler
> On 1 Mar 2001 17:48:20 GMT,
> Guido Hennecke <g.hen...@t-online.de> wrote:
>>Und wozu _muss_ man das haben?
>
> schoenes feature: man muss sich z.B. nicht mehr mit FTP herumaergern.
Kernel 2.2.x: insmod ip_masq_ftp...
Wo ist das Problem...?
Andreas
--
Microsoft's Product Strategy: "It compiles, let's ship it!"
Mario 'BitKoenig' Holbe
|>> schoenes feature: man muss sich z.B. nicht mehr mit FTP herumaergern.
|> Kernel 2.2.x: insmod ip_masq_ftp...
|> Wo ist das Problem...?
Wir reden von firewalling bzw. packet filtering und nicht von
network address translation.
Marc Haber
>Fuer eine DMZ ist Stateful filtering gefaehrlich.
Magst Du diese Aussage etwas näher erläutern?
Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Ulrich Eckhardt
>
> Ulrich Eckhardt <ulrich....@transcom.de> wrote:
>
> Das habe ich getan und die wesentlichen Stellen unterstrichen.
>
> Du stellst einen Zusammenhang her zwischen iptables und der
> Tatsache, dass Dein System bei einer DoS Attacke nicht in die
> Knie gegangen ist.
Ja, und wo ist da das Problem ? Ich sagte, dass sich iptables
bei einer 10 MB Anbindung auf einem P166 mit 96 MB recht
robust verhält. Nicht mehr und nicht weniger. Bitte den
Kontext des gesammten Threads beachten !
> Dieser Zusammenhang existiert jedoch nicht.
> De facto existiert lediglich ein Zusammenhang zwischen Deiner
> schmalbandigen Anbindung (in diesem Fall 10 MBit) und der Tatsache,
> dass Dein System nicht in die Knie gegangen ist. iptables hat damit
> nix zu tun.
Bitte den ganzen Thread noch mal von vorne lesen, und meine
Aussagen nicht aus dem Zusammenhang reisen ! Ich gebe keine
Allgültigen unter jedem Aspekt gültigen Aussagen von mir. Meine
Aussagen gelten immer nur im Rahmen und zusammenhang des Threads.
Ulrich Eckhardt
>
> On Thu, 1 Mar 2001 21:17:20 +0100,
> Vielleicht so: "es gibt jemanden in der Firma, der genuegend Wissen hat,
> um eine Sicherheitsrichtlinie zu verfassen.
Dieser Satz ist OK.
> Aufgrund dieser Richtlinie
> hat der Dienstleister den Firewall zu warten."
Dieser Auch.
> Damit ist "die" Rulebase
> auf Papier festgehalten und somit mehr oder weniger zwischen unter-
> schiedlichen Firewall-Loesungen "portierbar".
Dieser nicht, da es verschiedene Lösungsansätze für das selbe
Problem geben kann, die das gleiche bewirken.
> >einzuarbeiten. Wartungsverträge für so eine Lösung sind damit
> >wirtschaftlich (für einen Dienstleister) nicht kalkulierbar...
>
> Doch.
> <Beispiel>
> Wir vertreiben eine Firewall-Loesung auf Debian/iptables-
> Basis. Das komplette System bootet von CD, dadurch hat man keinen
> Installationsaufwand. Die komplette Konfiguration ist auf einer
> Diskette gespeichert, die von geschultem Personal von Hand bzw. vom
> Kunden mittels einer Kilcki-Bunti-GUI a la Checkpoint erstellt werden
> kann. Das laesst wunderbar in Produkt und Dienstleistung aufteilen
> um dadurch sehr gut kalkulieren.
> </Beispiel>
Bis auf die Risiken dieses Beispiels, die sind Unkalkulierbar.
Um einen Firewall zu warten und korrekt zu implementieren ist
ordentliches solides Wissen über die Grundlagen von TCP/IP
notwendig. Wenn jemandem die Abkürzungen [1] FIN/ACK/SYN, rfc791
rfc792,rfc793 nichts sagen bitte Finger weg von Firewalls.
Wenn jemand __unbedingt__ eine GUI braucht ist das ein gutes
Zeichen mangelnder Kompetenz. Jemand der seinen Job versteht
kommt auch ohne GUI aus und ist in der Lage Doku zu lesen.
Uli
[1] kein Anspruch auf Vollständigkeit und Aussagekraft
Andreas Spengler
^^^^^^^^^
> Andreas Spengler <and...@spengler-netz.de> wrote:
> |>> schoenes feature: man muss sich z.B. nicht mehr mit FTP herumaergern.
> |> Kernel 2.2.x: insmod ip_masq_ftp...
> |> Wo ist das Problem...?
>
> Wir reden von firewalling bzw. packet filtering und nicht von
> network address translation.
Plurale Majestatis? Wer ist wir? Siehe <97nudh$qts$1...@debian.dyndns.org> ...
MfG,
Andreas
[1] Der Unterschied ist mir wohl bekannt...
Ulrich Eckhardt
>
> Hallo Ulrich,
>
> * Ulrich Eckhardt <ulrich....@transcom.de> wrote:
> > Guido Hennecke wrote:
> >> Wozu? Was bringt mir das?
> > Wesentlich vereinfachte Filterregeln,
>
> auseinander setzen muss, findest Du vereinfacht?
Hi,
du must dich eben nicht mit dem State auseinander setzen, das macht
eben iptables :-)
> Nach dem was ich gesehen habe, ist das lediglich eine zusaetzliche
> Fehlerquelle.
Schau dir mal iptables genauer an :-) und siehe auch weiter unten.
Iptables vermeidet definitv Fehler.
> Was sind denn bitte "offene hohe Ports"?
>
> Was laesst Du denn durch? TCP Pakete ohne gesetztes Sysnbit auf >1024.
> Wo hast Du damit ein Problem?
Genau damit. Ich brauch bei nicht stateful eine zusätzliche
Regel. Diese Erlaubt dann auch noch allen Packeten die kein
Syn bit gesetzt haben zu passieren.
Zudem muss ich auch noch auf zugehörige ICMP packete achten,
z.B. network/host unrechable
Als Beispiel, ich will nur HTTP traffic zulassen.
Unter iptables sieht das folgendermassen aus :
iptables --policy FORWARD REJECT
iptables -p tcp --destination-port 80 -m state --state NEW -j ACCEPT
--syn
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
Standard policy für forward ist reject, alles nach port 80 darf
passieren.
Der benötigte destination port und eventuelle icmp packete nur für diese
Verbindung darf passieren.
Erweitert man diese Regeln noch um ein
insmod "ftp_conntrack_ftp"
und iptables -p tcp --destination-port 21 -m state --state NEW -j ACCEPT
--syn
dann funktioniert auch aktives und passives ftp.
> Was macht denn $IPSTACK mit einem solchen Paket, wenn es dazu keine
> Verbindung gibt?
>
> Dein IPSTACK _ist_ eine Stateful Maschine.
Exakt, das Verhalten ist wohl definiert und kann deshalb für
scans misbraucht werden.
> > Schutz gegen stealth scans
> > und diverse ICMP scans.
>
> Bitte beschreib mal ein Szenario, wo definitiv die Sicherheit durch
> stateful Paketfilter erhoeht wird.
Überall wo komplexe filterregeln von nöten sind und sich zudem noch
services auf ports > 1024 tummeln. Dabei kann es bei stateless
filtern zu Nebeneffekten kommen.
Uli
Gaby Hornik
Ich habe mitgelesen und ich finde auch das meiste richtig,
was geschrieben wurde, auch wenn manchmal die absolute
Ablehnung kommerzieller Software zum Ausdruck kam. :-)
Das Topic trifft fuer mich nicht zu, denn mir geht es
eindeutig nicht um "Wartung durch einen Dienstleister",
sondern um Eigenverwaltung.
Ich moechte eigentlich nur noch schnell eins kommentieren:
Ulrich Eckhardt <ulrich....@transcom.de> wrote:
> Wenn jemand __unbedingt__ eine GUI braucht ist das ein gutes
> Zeichen mangelnder Kompetenz. Jemand der seinen Job versteht
> kommt auch ohne GUI aus und ist in der Lage Doku zu lesen.
Das halte ich fuer ein bissel naiv. Natuerlich kommen die
meisten ohne GUI aus und koennen Doku lesen.
Aber muss man das immer? Doku lesen, klar, aber GUI-Verzicht
um jeden Preis? Kann man sich doch nicht etwas
die Arbeit vereinfachen, ohne immer im Code rumkramen zu
muessen?
Logischerweise habe ich mir ipchains angeschaut. Aber ich
habe mich dann doch fuer Checkpoint entschieden. :-) Es
war natuerlich Bequemlichkeit, aber ich hatte innerhalb
von 2 Wochen ein ganzes Netzwerk fuer eine Startup-Firma
zu entwerfen und zu installieren. Es mag ja nett sein, wenn
man _nur_ Firewalladministrator ist oder externer Berater
fuer Sicherheit. Aber ich hab auch noch andere Sachen zu
tun.
Aber ich muss mich ja nicht dafuer entschuldigen, dass ich
Checkpoint verwende, oder? ;-)
Mfg, Gaby
--
mailto:ga...@gabyhornik.de
ICQ: 105106979
Gerd Knorr
> > dem hunderte ipchains-Aufrufe durchgefuehrt werden.
>
> "ipchains-save" die Rules in einem Format ausgeben (oder speichern),
> welches immer gleich ist.
... und alle Kommentare sind weg (falls vorhanden). Mir ist da ein
kommentiertes shellscript mit ipchains/iptables Aufrufen lieber als
eine von ipchains-save ausgeworfene Rule base.
Gerd
--
document.write('<noscript> ... </noscript>');
-- gefunden in einem pixelpark flash banner
Ulrich Eckhardt
>
> Hallo Ulrich,
> > Als Beispiel, ich will nur HTTP traffic zulassen.
> >
> > Unter iptables sieht das folgendermassen aus :
> >
> > iptables --policy FORWARD REJECT
> > iptables -p tcp --destination-port 80 -m state --state NEW -j ACCEPT
> > --syn
> > iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
>
> ipchains -A input -p tcp -s 0/0 1024: -d 0/0 80 -j ACCEPT
> ipchains -A output -p tcp -s 0/0 80 -d 0/0 1024: -j ACCEPT
> ipchains -A forward -b -p tcp -s 0/0 1024: -d 0/0 80 -j ACCEPT
>
> > Standard policy für forward ist reject, alles nach port 80 darf
> > passieren.
>
> Dito.
Ist zwar Haarspalterrei, aber diese Regel fehlt bei dir.
> > Der benötigte destination port und eventuelle icmp packete nur für diese
> > Verbindung darf passieren.
>
> ICMP Traffic regel ich ohnehin. Warum soll ich fuer evtl. ICMP Pakete
> diesbezueglich extra Regeln haben?
In deinem Beispiel wird kein ICMP gefilter, dazu sind extra Regeln
notwendig. Bei meinem Beispiel ist alles drin inklucive ICMP.
Statless regeln für ICMP erlauben z.B. dann wieder diverse ICMP
scanning Techniken.
> > Erweitert man diese Regeln noch um ein
> > insmod "ftp_conntrack_ftp"
> > und iptables -p tcp --destination-port 21 -m state --state NEW -j ACCEPT
> > --syn
> > dann funktioniert auch aktives und passives ftp.
>
> Wozu?
Na zum Beispiel wenn ich was von einem FTP server ziehen will ohne
dass ich irgend einen <broken>ftp client zu passiv connections
überreden muss.
> >> Was macht denn $IPSTACK mit einem solchen Paket, wenn es dazu keine
> >> Verbindung gibt?
> >> Dein IPSTACK _ist_ eine Stateful Maschine.
> > Exakt, das Verhalten ist wohl definiert und kann deshalb für
> > scans misbraucht werden.
>
> Und das Verhalten von iptables ist demnach _nicht_ wohldefiniert und
> kann deshalb nicht fuer Scans missbraucht werden?
>
> Interessant!
Das Verhalten von iptables ist ebenfalls wohl definiert. Obigen 3
iptables Regeln erlauben es nur Packeten (inclusive ICMP) zu
passieren, die zu einer bestehenden Verbindung gehören.
>
> Quatsch. Ich lasse nur tcp Pakete _ohne_ syn durch. Habe ich Dienste auf
> Ports >1024 (tcp) laufen, habe ich ohnehin (auch bei iptables) eine
> Regel dafuer, die das erlaubt.
>
> Wo ist der Vorteil?
Das auch tcp Packete ohne syn, die aber zu keiner bestehenden
Verbindung gehören, ihr Ziel nicht erreichen und ich mir keine
Gedanken eben über diese Regel für Ports > 1024 und ICMMP
machen muss.
Bevor wir hier jetzt endlos weiter diskutieren, lies dir mal die
Doku zu iptables auf http://netfilter.samba.org/ durch und
beschäftige dich mal näher mit stateful filtering.
Ulrich Eckhardt
>
> Hallo!
>
> Ich habe mitgelesen und ich finde auch das meiste richtig,
> was geschrieben wurde, auch wenn manchmal die absolute
> Ablehnung kommerzieller Software zum Ausdruck kam. :-)
Hi,
so schlimm wurde hier die kommerzielle Software nicht abgelehnt.
> Ulrich Eckhardt <ulrich....@transcom.de> wrote:
> > Wenn jemand __unbedingt__ eine GUI braucht ist das ein gutes
> > Zeichen mangelnder Kompetenz. Jemand der seinen Job versteht
> > kommt auch ohne GUI aus und ist in der Lage Doku zu lesen.
>
> Das halte ich fuer ein bissel naiv. Natuerlich kommen die
Bitte das Wort __unbedingt__ beachten, ich kann das mangels
HTML/Flash hier halt so schlecht in großen feurigen Buchstaben
blinkend und mit Sound untermalt darstellen ;-)
Uli
Gerd Knorr
> > > Verbindung darf passieren.
> >
> > ICMP Traffic regel ich ohnehin. Warum soll ich fuer evtl. ICMP Pakete
> > diesbezueglich extra Regeln haben?
>
> In deinem Beispiel wird kein ICMP gefilter, dazu sind extra Regeln
> notwendig. Bei meinem Beispiel ist alles drin inklucive ICMP.
Ebenfalls sehr praktisch ist es für rausgehende Verbindungen. Replies
für vom Rechner initiierte Verbindungen/Anfragen sind mit einem
einzelnen
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
abgegessen, _egal_ was es ist (DNS, http, icmp, whatever).
Gaby Hornik
> Bitte das Wort __unbedingt__ beachten, ich kann das mangels
> HTML/Flash hier halt so schlecht in großen feurigen Buchstaben
> blinkend und mit Sound untermalt darstellen ;-)
Aber ich brauche __unbedingt__ meine GUI, damit ich
viele, viele Terminals aufmachen kann, um auf 10 Servern
gleichzeitig arbeiten zu koennen!
SCNR, Gaby
Gerd Knorr
> Ulrich Eckhardt <ulrich....@transcom.de> wrote:
> > Bitte das Wort __unbedingt__ beachten, ich kann das mangels
> > HTML/Flash hier halt so schlecht in großen feurigen Buchstaben
> > blinkend und mit Sound untermalt darstellen ;-)
>
> Aber ich brauche __unbedingt__ meine GUI, damit ich
> viele, viele Terminals aufmachen kann, um auf 10 Servern
> gleichzeitig arbeiten zu koennen!
Antrag abgelehnt. man screen.
Felix von Leitner
> > Guido Hennecke <g.hen...@t-online.de> wrote:
> >>Und wozu _muss_ man das haben?
> >schoenes feature: man muss sich z.B. nicht mehr mit FTP herumaergern.
> >Macht IMHO Sinn fuer ein Firewall, hinter dem nur Clients haengen.
> Nein. Stateful braucht man, um Null-Scans abzublocken.
Eher: "Stateful Filtering braucht man, wenn man bestimmte Arten von
Stealth-Scans verhindern will".
Es ist wichtig zu verstehen, daß man eben nur den Scan verhindert.
Gegen den eigentlichen Angriff sind beide Filterarten gleich sicher.
Stateful Filtering erhöht aber die Komplexität der sicherheitsrelevanten
Elemente und damit nicht grundsätzlich zu begrüßen.
Man kann das vergleichen mit einer Autobremse, die bei bestimmte
Bremsmanöver automatisch und ungefragt durchführt. Klar, wenn das
funktioniert ist das möglicherweise keine schlechte Sache, aber ich habe
lieber eine vollmechanische Bremse in meinem Auto. Man bedenke, daß in
der Autoindustrie bei Fehlfunktion mit massiven Klagen zu rechnen ist,
in der IT-Industrie zahlt der Kunde dann auch noch für das Update.
Felix
Felix von Leitner
> >> >Bei den sogenannten igmp und icmp wo man ohne server attackieren kann
> >> Eine IGMP Attacke interessiert mich. Wie macht man das?
> >Na man schickt so viele davon, daß die Leitung saturiert wird *bg*
> Wie bekommst man ein IGMP Paket über einen Router hinweg? IGMP ist ja nicht
> routbar.
Gar nicht.
Fragen wir doch am besten unseren Uberhax0r, wie seine Attacke
funktioniert. Vielleicht kann er ja tunneln und so IGMP zum richtigen
Router bringen? Wer weiß?
Felix
Ulrich Eckhardt
>
> Hallo Ulrich,
>
> >> diesbezueglich extra Regeln haben?
> > In deinem Beispiel wird kein ICMP gefilter, dazu sind extra Regeln
> > notwendig. Bei meinem Beispiel ist alles drin inklucive ICMP.
>
> Antworten auf tcp Anfragen.
Hi,
diese Regeln für ICMP brauche ich eben nicht ! Mein iptables 3 Zeiler
funktioniert in allen Lebenslagen, wenn der Webserver nicht erreichbar
ist und ein Host unreachable zurückkommt, so wird das korrekt
geforwarded.
> > Statless regeln für ICMP erlauben z.B. dann wieder diverse ICMP
> > scanning Techniken.
>
> Und?
Es ist halt möglich.
> >> Interessant!
> > Das Verhalten von iptables ist ebenfalls wohl definiert. Obigen 3
> > iptables Regeln erlauben es nur Packeten (inclusive ICMP) zu
> > passieren, die zu einer bestehenden Verbindung gehören.
>
> Und das bringt mir was bzw. birgt welche Gefahren, wenn ich das nicht
> habe?
Das kommt auf den Anwendungfall an. In der Regel ist das zwar harmlos
aber wenn ichs unterbinden kann.
> > Das auch tcp Packete ohne syn, die aber zu keiner bestehenden
> > Verbindung gehören, ihr Ziel nicht erreichen und ich mir keine
> > Gedanken eben über diese Regel für Ports > 1024 und ICMMP
> > machen muss.
>
> Ein Ack oder Fin Paket, zu dem keine Verbindung gehoert, wird vom IP
> Stack beantwortet. Es kommt nicht zur Anwendung. Wo ist das Problem
> damit?
Das der TCP Stack das eventuell mit einem RST beantwortet
-> Stealth Scan. Das ist zwar in der Regel nicht weiter schlimm,
aber wenn mans verhindern kann.
> > Bevor wir hier jetzt endlos weiter diskutieren, lies dir mal die
> > Doku zu iptables auf http://netfilter.samba.org/ durch und
> > beschäftige dich mal näher mit stateful filtering.
>
> Bitte? Es geht um den angeblichen Sicherheitsgewinn durch stateful
> Paketfilter. Mir ist die Technik durchaus bekannt. Ich sehe nur den
> Sicherheitsgewinn nicht.
Der größte Gewinn liegt meiner Meinung nach schlicht und einfach
in einfacheren Filterregeln.
Mike Gerber
> Warum man allerdings noch [1] Checkpoint braucht, wo der Kernel 2.4
> iptables mit stateful inspection und diversen möglichen und
> unmöglichen Erweiterungen als Open Source und für 0 TDM
> bietet weiss ich allerdings nicht.
Gründe:
- Unkompliziertes Management
- Distributed Firewalls
- Unkomplizierte VPNs, insbesondere für mobile Clients (SecuRemote)
- Div. Möglichkeiten zur Authentication
In einigen Punkten ist Linux/iptables da sicher gewachsen, für einige
komplexe Installationen würde ich jedoch immernoch Checkpoint vorziehen.
Allerdings muss da dann meist der Geldbeutel recht locker sitzen.
--
mike gerber - the route is out there!
Mike Gerber
> Checkpoint kann Stateful Inspection, was erst mit iptables
> als Killerargument bezeichnen würde, aber es macht das Leben
Naja, schonmal sauber(!) FTP in Deinen ipchains aufgesetzt? Aktiv und passiv?
Ich nicht. So gesehen ist "stateful" für mich schon ein Killerargument.
Gerd Knorr
> > für vom Rechner initiierte Verbindungen/Anfragen sind mit einem
> > einzelnen
> > iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>
> alle Protokolle zulassen?
Ich hatte jetzt 'nen einzelnen Rechner im Auge, aber meinetwegen auch
das. Man kann bei 'nem Router/Firewall auch alle über das externe
Interface reinkommenden Pakete durch diese Regel schicken. Funkioniert
ganz genauso. Replies für von innen initierte Verbindungen sind erlaubt.
> Bei UDP und icmp sieht es da nuerlich anders aus.
Eben. Das ist bei iptables auch mit der einen Regel da abgefackelt.
> Aber wenn Du keine udp Dienste anbieten willst, warum bietet dann
> dein Rechner welche an?
Vielleicht weil ich intern UDP benutzte (NFS z.B.)? Ich das aber
logischerweise nicht nach außen anbieten will? Und pauschal alles
UDP nach außen zumachen geht auch nicht weil ich DNS brauche?
Das Durchlassen der Replies auf meine DNS-Anfragen ist mit der einen
Zeile da oben schon fix und fertig erledigt. Den Rest kann ich dann
je nach belieben ganz blocken oder von bestimmten Hosts erlauben oder
was auch immer ich gerade brauche.
Mike Gerber
>> schoenes feature: man muss sich z.B. nicht mehr mit FTP herumaergern.
> Kernel 2.2.x: insmod ip_masq_ftp...
> Wo ist das Problem...?
Dads das Dir bei der Deiner NAT-Box hilft, sonst aber nicht?
Mike Gerber
>> schoenes feature: man muss sich z.B. nicht mehr mit FTP herumaergern.
Aufgabe 1: Sie haben einen FTP-Server in einer DMZ.
Geben Sie FTP "vom Internet" ("Any"/"0.0.0.0/0"/whatever) auf diesen
frei, und zwar sowohl im aktiven als auch im passiven Modus.
Zeige mir Dein ipchains-Skript, dass dies sauber erledigt, und auch wirklich
ausschliesslich FTP freischaltet.
Mike Gerber
> * Ulrich Eckhardt <ulrich....@transcom.de> wrote:
>> Wesentlich vereinfachte Filterregeln,
> Das ich mich in der Syntax der Filterregeln nun auch noch mit dem State
> auseinander setzen muss, findest Du vereinfacht?
Natürlich. Du erlaubst das erste Paket zum Aufbau der Verbindung.
iptables-speak: Der Rest ist ESTABLISHED (Teil einer bestehenden Verbindung)
oder RELATED (Zusatz zu einer bestehenden Verbindung, z.B. FTP Data-Session).
> Nach dem was ich gesehen habe, ist das lediglich eine zusaetzliche
> Fehlerquelle.
Ich kann keine Fehlerquelle entdecken.
> Was laesst Du denn durch? TCP Pakete ohne gesetztes Sysnbit auf >1024.
> Wo hast Du damit ein Problem?
Z.B. bei einer FTP Data-Session.
Joerg Wendland
Ulrich Eckhardt <ulrich....@transcom.de> wrote:
>Wenn jemand __unbedingt__ eine GUI braucht ist das ein gutes
>Zeichen mangelnder Kompetenz. Jemand der seinen Job versteht
>kommt auch ohne GUI aus und ist in der Lage Doku zu lesen.
Schon klar, aber erzaehl das mal einem Manager, der entscheiden muss,
was gekauft wird. Eine Bash wird der nicht akzeptieren :(
Gruss, Joerg
--
Freier Platz fuer Bearbeitungsvermerke, bitte nicht beschriften.
Daniel Schmidt
>
> Einem Dienstleister, der undokumentierte ipchains Scripte verfaßt,
> würde ich genauso wenig trauen, wie einem Dienstleister, der deswegen
> ein kommerzielles Produkt verkauft, weil er seine Leute im Notfall auf
> Schulung schicken kann.
Die ipchains-Skripte dieses Dienstleisters _sind_ ja dokumentiert -
ziemlich gut sogar, soweit ich das beurteilen kann. Daß vom
Projektleiter des Dienstleisters im Rahmen der Wartung nun FW-1
vorgeschlagen wird, hat mich nicht wenig verwundert. Ich habe mich dann
so überumpelt gefühlt, daß ich den Rest der Besprechung nur
noch geschwiegen habe.
> >Irgendwie gehe ich davon aus, daß Dienstleister in dem Bereich, vor
> >Allem, wenn sie schon eine Lösung _verkaufen_, aus den gleichen
> >Büchern abschreiben und die Umsetzungen sich doch ziemlich ähnlich
> >sehen müssten. Korrigiert mein Weltbild bitte, wenn dies in der
> >Praxis nicht so ist.
>
> Die Lösungen sind firmenspezifisch und nicht abgeschrieben. Abgeschriebenen
> Lösungen würde ich nicht trauen.
Ja, dem stimme ich auch zu. Klar, daß jedes FW-Konzept eine
Speziallösung für die jeweilige Firma ist. Ich meinte eigentlich,
daß das Konfigurieren eines Dienstes (z.B. http-Freigabe) vom Prinzip
her immer gleich abläuft.
> Fordere verständliche Dokumentation zur ipchains Konfiguration (nimm sie
> nicht ab, solange Du sie nicht verstehst) und Du hast etwas, womit Du im
> Zweifel auch im Haus ein Problem lösen lassen kannst.
Die Dokumentation ist, wie oben gesagt, ja vorhanden. Ich denke schon,
daß ich in der Lage bin, aufgrund der Unterlagen selbst Änderungen
vorzunehmen - es ist aber nicht in meiner Verantwortung dies zu tun. Die
Abteilungsleitung wünscht genau *das* (Änderungen & Wartungen
durchführen) vom Dienstleister; das kommt mir natürlich schon
entgegen ;-)
Es war mir halt wichtig, ein paar Meinungen zu hören zum Thema
kommerzielles Produkt (FW-1) vs. OpenSource (Ipchains).
Von meiner Sichtweise sprach halt bisher nichts gegen ipchains,
allerdings auch nichts gegen FW-1. Wie es technisch realisiert wird, ist
mir im Prinzip auch egal - ich fand die höhren Kosten für FW-1
einfach nicht gerechtfertigt.
Vielen Dank euch Allen!
mfg.,
-ds-
Joerg Wendland
Marc Haber <usene...@marc-haber.de> wrote:
>jo...@joergland.wohnheim.uni-ulm.de (Joerg Wendland) wrote:
>>Fuer eine DMZ ist Stateful filtering gefaehrlich.
>
>Magst Du diese Aussage etwas näher erläutern?
Vielleicht war ich ein bisschen ungenau. Nicht direkt gefaehrlich fuer die
DMZ, aber fuer den Firewall, der diese schuetzen soll. Wenn ich es schaffe,
die interne Tabelle, in der die aktiven Connections gespeichert werden, zum
Ueberlaufen zu bringen, kann eine DoS-Attacke fahren.
Mike Gerber
> * Mike Gerber <blue...@gmx.net> wrote:
>> Aufgabe 1: Sie haben einen FTP-Server in einer DMZ.
>> Geben Sie FTP "vom Internet" ("Any"/"0.0.0.0/0"/whatever) auf diesen
>> frei, und zwar sowohl im aktiven als auch im passiven Modus.
> erlaubst Du. Der FTP Server bietet FTP an. Sonst nichts. Wo ist das
> Problem, wenn auf diesen Syn Pakete kommen, die auf einen Port
> einschlagen, auf dem kein Dienst horcht.
Du weichst aus. Das war nicht die Frage. Ich will FTP auf diesen Server
freischalten, egal welche Services dort sonst noch laufen.
> man bastion Host (Btw)
[kerouac:mg:~]man bastian Host (Btw)
bash: syntax error near unexpected token `(B'
Aber für Dich: "man Realität": Realität ist, dass ein Server div. Services
anbietet.
Mike Gerber
>>> Fehlerquelle.
>> Ich kann keine Fehlerquelle entdecken.
> ipchains.
Wir sprachen vorher noch von Konfiguration, jetzt plötzlich von Code?
>>> Was laesst Du denn durch? TCP Pakete ohne gesetztes Sysnbit auf >1024.
>>> Wo hast Du damit ein Problem?
>> Z.B. bei einer FTP Data-Session.
> Client oder Server?
> Ich kann keines sehen.
Dein FTP-Server wird eine Session zu Dir aufmachen.
Mike Gerber
> Aber auch die Konfiguration ist nicht zwangslaeufig einfacher, wenn man
> stateful filter verwendet. Die Konfiguration von iptables magst Du
> _subjektiv_ als leichter empfinden als die von ipchains. Aber das ist
> eben nur subjectiv.
Sie ist objektiv einfacher. Wir sehen uns einmal an, was wir definieren
müssen:
Stateful: Der Verbindungsaufbau korrekter Verbindungen
ipchains: Verbindungsaufbau
"Rückkanal"
ggf. darauf bezogene Verbindungen (FTP Data-Session)
>>>> Z.B. bei einer FTP Data-Session.
>>> Client oder Server?
>>> Ich kann keines sehen.
>> Dein FTP-Server wird eine Session zu Dir aufmachen.
> Bei aktiv FTP, ja. Und?
Du öffnest dann auch eine Range von Ports zu Deinem Client. Dein Client
kann durchaus selbst Dienste anbieten.
> Muss ich deswegen einen Portrange fuer tcp Syn auf den Server aufmachen?
> Nein. Also, wo siehst Du das Problem?
passives FTP
Mike Gerber
>> Das war nicht die Frage. Ich will FTP auf diesen Server
>> freischalten, egal welche Services dort sonst noch laufen.
> Nagut, wo horcht ein FTP Server?
> Port 21 (ftp(tcp))
Ja.
> Einloggen und dann mal weiter sehen:
> Port 20 (ftp-data(tcp))
> Wo ist das Problem?
a. ist diese Verbindung in die andere Richtung, hier aber nicht relevant.
b. gilt das lediglich für aktive FTP-Sessions.
> Du laesst tcp Pakete mit Syn Bit auf Port (tcp) 20 und 21 zu.
Falsch. Der Server schickt ein SYN, nicht der Client (hier nur die
SYN-Packets als tcpdump):
02:29:25.217888 eth0 < client.4112 > server.ftp: S
1601935317:1601935317(0) win 32120 <mss 1460,eol> (DF)
02:29:28.044215 eth0 > server.ftp-data > client.4113: S
1385294477:1385294477(0) win 32120
<mss 1460,sackOK,timestamp 184948277 0,nop,wscale 0> (DF) [tos 0x8]
> Wo bitte siehst Du da das Problem?
Du kennst das FTP-Protokoll?
Control-Session: Client (high port) ---SYN--> Server (port 21)
Data-Session (aktiv): Server (port 20) ---SYN--> Client (high port)
Data-Session (pass.): Client (high port) ---SYN--> Server (high port)
Bei letzterem hast Du ein erhebliches Problem: Sämtliche Services,
die nicht auf den priviledged Ports laufen, hast Du damit freigeschalten.
02:26:05.855616 eth0 < client.4106 > server.ftp: S
1385167799:1385167799(0) win 32120 <mss 1460,eol> (DF)
02:26:16.299783 eth0 < client.4107 > server.35786: S
1386848415:1386848415(0) win 32120
<mss 1460,sackOK,timestamp 28380623 0,nop,wscale 0> (DF)
Bei der aktiven Session (hier zwar nicht Thema) hast Du das Problem,
dass jemand damit eine Connection zu einem Dienst auf Deinem Client
zugreifen kann, sofern er mit Port 20 kommt.
Sind Dir das nicht Probleme genug?
>>> man bastion Host (Btw)
>> [kerouac:mg:~]man bastian Host (Btw)
>> bash: syntax error near unexpected token `(B'
> Werd nicht kindisch bitte.
Kindisch ist es ständig mit dem man-Befehl um sich zu schmeissen.
man tcpdump
(SCNR)
>> Aber für Dich: "man Realität": Realität ist, dass ein Server div. Services
>> anbietet.
> Und? Ein Dienst horcht auf einem Port (bleiben wir mal bei tcp) und Du
> laesst syn Pakete auf diesen Port zu, weil Du diesen Dienst anbieten
> willst, oder Du laesst keine Syn Pakete auf diesen Port, weil Du das
> nicht anbieten willst - jedenfalls nicht fuer $WORLD sondern fuer
> $INTERNES_NETZ.
s.o.
Bernd Eckenfels
> Nagut, wo horcht ein FTP Server?
> Port 21 (ftp(tcp))
> Einloggen und dann mal weiter sehen:
> Port 20 (ftp-data(tcp))
> Wo ist das Problem?
Du hast FTP nicht verstanden.
Gruss
Bernd
PS: http://www.freefire.org/articles/ftpexample.php leider is der FTP filter
Artikel immer noch nicht fertig, aber zum Thema "FTP Server muessen hardened
sein wenn man sicher gehen will" hab ich schon was geschrieben :)
Dietz Proepper
>Aber für Dich: "man Realität": Realität ist, dass ein Server div. Services
>anbietet.
Realität ist eher daß dies nicht schadet da Dienste die angeboten werden
so oder so detektierbar sind und damit gesichert werden müssen.
Warum man wenn man kann verschiedene Dienste(grupper) trotzdem auf
verschiedenen Maschinen isoliert ist eine andere Frage.
Dietz
Dietz Proepper
>PS: http://www.freefire.org/articles/ftpexample.php leider is der FTP filter
>Artikel immer noch nicht fertig, aber zum Thema "FTP Server muessen hardened
>sein wenn man sicher gehen will" hab ich schon was geschrieben :)
Wenn man sicher gehen will dann bietet man kranke Protokolle wie
ftp nicht an ;).
Wenn man es trotzdem muß dann setzt man den ftp-Server in ein separates
Segment, filtert (nicht gegen den ftp-Server, die andere Richtung)
und harden'd (wenn's Geld langt).
Die ftpd-Implementierungen die ich etwas genauer kenne erwecken bei
mir alle nicht das warme Gefühl von Vertrauen das ich bei nur
host-based gerne hätte.
Innennetz ist wie üblich was anderes.
Dietz
Dietz Proepper
>Ulrich Eckhardt <ulrich....@transcom.de> wrote:
>> Warum man allerdings noch [1] Checkpoint braucht, wo der Kernel 2.4
>> iptables mit stateful inspection und diversen möglichen und
>> unmöglichen Erweiterungen als Open Source und für 0 TDM
>> bietet weiss ich allerdings nicht.
>
>Gründe:
>- Unkompliziertes Management
0-Argument. In 95% aller Fälle bedeutet soein GUI nur Mehraufwand.
Kann z.B. das Teil die control-files meiner Skripten lesen? Nee? Schon
brauch' ich zwei Konsolen.
>- Distributed Firewalls
Was *ist* das? Bzw. Redundanz ist bei Verzicht auf stateful filter
einfach machbar.
>- Unkomplizierte VPNs, insbesondere für mobile Clients (SecuRemote)
>- Div. Möglichkeiten zur Authentication
Div. Möglichkeiten gibt das auch anderswo. Was mir auffällt - Dein
Fokus scheint auf der "Unkompliziertheit" zu liegen. Warum das?
Schließsysteme sind inhärent komplex.
>In einigen Punkten ist Linux/iptables da sicher gewachsen, für einige
>komplexe Installationen würde ich jedoch immernoch Checkpoint vorziehen.
Für welche genau?
>Allerdings muss da dann meist der Geldbeutel recht locker sitzen.
Wirkliche Beratung ist allerdings nicht billiger. Glaub' mir.
Dietz
Dietz Proepper
>Ulrich Eckhardt <ulrich....@transcom.de> wrote:
>> Checkpoint kann Stateful Inspection, was erst mit iptables
>> in Kernel 2.4 eingeführt wurde. Wobei ich stateful nicht unbedingt
>> als Killerargument bezeichnen würde, aber es macht das Leben
>> leichter und ich habe es mittlerweile recht lieb gewonnen :-)
>
>Naja, schonmal sauber(!) FTP in Deinen ipchains aufgesetzt? Aktiv und passiv?
>Ich nicht.
Sauber(!) FTP ohne state aufzusetzen ist unmöglich.
Y So gesehen ist "stateful" für mich schon ein Killerargument.
Du meinst, Du ersetzt verläßliche Hosts durch viel Technik am
zentralen Übergang? Keine gute Idee.
Dietz
Dietz Proepper
>Lutz Donnerhacke <lu...@iks-jena.de> wrote:
>>
>> Einem Dienstleister, der undokumentierte ipchains Scripte verfaßt,
>> würde ich genauso wenig trauen, wie einem Dienstleister, der deswegen
>> ein kommerzielles Produkt verkauft, weil er seine Leute im Notfall auf
>> Schulung schicken kann.
>
>Die ipchains-Skripte dieses Dienstleisters _sind_ ja dokumentiert -
>ziemlich gut sogar, soweit ich das beurteilen kann.
ipchains-Skripten sind hoffentlich nur ein (kleiner) Teil des
Sicherheitskonzepts.
>Daß vom Projektleiter des Dienstleisters im Rahmen der Wartung nun FW-1
>vorgeschlagen wird, hat mich nicht wenig verwundert.
Ähm. Es ist der selbe Dienstleister der Euch die ipchains-Skripten
gestrickt hat? Auf Anhieb zwei Möglichkeiten -
(1) der Mensch ist FW-1-Partner
(2) euer bestehendes Konzept ist so unbrauchbar daß er Euch
Den Standard (tm) verkaufen möchte.
(3) Es gibt kein Konzept. Der Mensch ist kein FW-1-Partner.
Sucht Euch einen neuen Partner. Schnell.
>Ich habe mich dann
>so überumpelt gefühlt, daß ich den Rest der Besprechung nur
>noch geschwiegen habe.
Woher kenn' ich das nur...
>> Die Lösungen sind firmenspezifisch und nicht abgeschrieben. Abgeschriebenen
>> Lösungen würde ich nicht trauen.
>
>Ja, dem stimme ich auch zu. Klar, daß jedes FW-Konzept eine
>Speziallösung für die jeweilige Firma ist. Ich meinte eigentlich,
>daß das Konfigurieren eines Dienstes (z.B. http-Freigabe) vom Prinzip
>her immer gleich abläuft.
Sowas hat man eigentlich - ob ipchains oder FW-1 - automatisiert.
Wobei FW-1 die (GUI-)Automatisierung auf komfortablem Niveau ermöglicht,
was bei ipchains nicht gelten muß.
>> Fordere verständliche Dokumentation zur ipchains Konfiguration (nimm sie
>> nicht ab, solange Du sie nicht verstehst) und Du hast etwas, womit Du im
>> Zweifel auch im Haus ein Problem lösen lassen kannst.
>
>Die Dokumentation ist, wie oben gesagt, ja vorhanden. Ich denke schon,
>daß ich in der Lage bin, aufgrund der Unterlagen selbst Änderungen
>vorzunehmen - es ist aber nicht in meiner Verantwortung dies zu tun.
Hättest Du - ohne das böse zu meinen - die Kompetenz? Firewalling ist
nicht "einmal & aus".
>Die
>Abteilungsleitung wünscht genau *das* (Änderungen & Wartungen
>durchführen) vom Dienstleister; das kommt mir natürlich schon
>entgegen ;-)
Dann knebelt ihn geeignet, holt Euch unabhängige Auditoren usw.
Oder lebt mit der Illusion.
>Von meiner Sichtweise sprach halt bisher nichts gegen ipchains,
>allerdings auch nichts gegen FW-1. Wie es technisch realisiert wird, ist
>mir im Prinzip auch egal - ich fand die höhren Kosten für FW-1
>einfach nicht gerechtfertigt.
Das sind sie imho oft auch nicht. FW-1 ist für manche Konstellationen
wohl ganz brauchbar, *ich* bin bisher mit OS meist gut ausgekommen.
Dietz
Marc Haber
>On Fri, 02 Mar 2001 11:59:41 +0100,
> Marc Haber <usene...@marc-haber.de> wrote:
>>jo...@joergland.wohnheim.uni-ulm.de (Joerg Wendland) wrote:
>>>Fuer eine DMZ ist Stateful filtering gefaehrlich.
>>
>>Magst Du diese Aussage etwas näher erläutern?
>
>Vielleicht war ich ein bisschen ungenau. Nicht direkt gefaehrlich fuer die
>DMZ, aber fuer den Firewall, der diese schuetzen soll. Wenn ich es schaffe,
>die interne Tabelle, in der die aktiven Connections gespeichert werden, zum
>Ueberlaufen zu bringen, kann eine DoS-Attacke fahren.
Das stimmt natürlich. Ich gehe aber davon aus, dass eine angemessen
dimensionierte Firewall dieses Problem nicht hat.
Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Marc Haber
>Du meinst, Du ersetzt verläßliche Hosts durch viel Technik am
>zentralen Übergang? Keine gute Idee.
Trotzdem in der Realität oftmals der einzig gangbare Kompromiß. Du
lebst in einer Welt, wo es zu viele Leute gibt, die Partout
Windows-Maschinen als Internet-Server einsetzen wollen und die viel
Geld dafür bezahlen, dass man deren Inkompetenz hinter einem
Paketfilter versteckt.
Da es sehr aufwendig ist, fünf oder zehn NT-Kisten internetfest zu
machen, konzentriert man diesen Aufwand doch lieber am zentralen
Übergang. Das ist doch der Grundgedanke bei Firewalls!
Marc Haber
>* Joerg Wendland <jo...@joergland.wohnheim.uni-ulm.de> wrote:
>> Schon klar, aber erzaehl das mal einem Manager, der entscheiden muss,
>> was gekauft wird. Eine Bash wird der nicht akzeptieren :(
>
>Ahnung hat.
Reality Check, please!
Daniel Schmidt
>Daniel Schmidt wrote:
>>Lutz Donnerhacke <lu...@iks-jena.de> wrote:
>>>
>>> Einem Dienstleister, der undokumentierte ipchains Scripte verfaßt,
>>> würde ich genauso wenig trauen, wie einem Dienstleister, der deswegen
>>> ein kommerzielles Produkt verkauft, weil er seine Leute im Notfall
>>> auf Schulung schicken kann.
>>
>>Die ipchains-Skripte dieses Dienstleisters _sind_ ja dokumentiert -
>>ziemlich gut sogar, soweit ich das beurteilen kann.
>
>ipchains-Skripten sind hoffentlich nur ein (kleiner) Teil des
>Sicherheitskonzepts.
Ja. Router-Paketfilter-DMZ-Paketfilter-LAN. In der DMZ Web, Proxy,
zukünftig noch ein Applikationsserver und ein zusätzlicher MTA. Im LAN
(noch) ein weiter Proxy, der auf den in der DMZ forwarded. Auf den
Komponenten, auf die die LAN-Rechner Zugriff haben (Mail, Proxy) wird auf
Viren gescannt, zusätzlich auf dem Fileserver im LAN. Direkte Verbindungen
aus dem LAN ins Internet sind nicht drin.
>>Daß vom Projektleiter des Dienstleisters im Rahmen der Wartung nun FW-1
>>vorgeschlagen wird, hat mich nicht wenig verwundert.
>
>Ähm. Es ist der selbe Dienstleister der Euch die ipchains-Skripten
>gestrickt hat? Auf Anhieb zwei Möglichkeiten -
Ja.
>(1) der Mensch ist FW-1-Partner
Ja.
>(2) euer bestehendes Konzept ist so unbrauchbar daß er Euch
> Den Standard (tm) verkaufen möchte.
Nein. Er hat mit uns zusammen das Konzept erarbeitet. An dem oben
beschriebenen ändert sich durch FW-1 nichts oder nur wenig.
Es wird aus meiner Sicht ein Filter durch einen anderen ersetzt (der
anscheined über eine grafische Oberfläche verfügt).
>(3) Es gibt kein Konzept. Der Mensch ist kein FW-1-Partner.
> Sucht Euch einen neuen Partner. Schnell.
Konzept vorhanden. Er ist FW-1-Partner, s.o.
>>Ich habe mich dann
>>so überumpelt gefühlt, daß ich den Rest der Besprechung nur
>>noch geschwiegen habe.
>
>Woher kenn' ich das nur...
>
>>> Die Lösungen sind firmenspezifisch und nicht abgeschrieben.
>>> Abgeschriebenen Lösungen würde ich nicht trauen.
>>
>>Ja, dem stimme ich auch zu. Klar, daß jedes FW-Konzept eine
>>Speziallösung für die jeweilige Firma ist. Ich meinte eigentlich,
>>daß das Konfigurieren eines Dienstes (z.B. http-Freigabe) vom Prinzip
>>her immer gleich abläuft.
>
>Sowas hat man eigentlich - ob ipchains oder FW-1 - automatisiert.
>Wobei FW-1 die (GUI-)Automatisierung auf komfortablem Niveau ermöglicht,
>was bei ipchains nicht gelten muß.
[...]
>Hättest Du - ohne das böse zu meinen - die Kompetenz? Firewalling ist
>nicht "einmal & aus".
Das "Firewalling" nicht "einmal & aus" bedeutet, ist mir sehr wohl klar.
Darum poche ich/die Firma so auf Wartung. Das regelmäßige Audits statt
finden sollten, sehe ich als selbstverständlich an.
Definiere mir bitte die notwendige Kompetenz, dann kann ich Dir (und mir)
diese Frage beantworten.
>>Die
>>Abteilungsleitung wünscht genau *das* (Änderungen & Wartungen
>>durchführen) vom Dienstleister; das kommt mir natürlich schon
>>entgegen ;-)
>
>Dann knebelt ihn geeignet, holt Euch unabhängige Auditoren usw.
Unabhängige Auditoren - das klingt wirklich gut. Aber wie finde ich die
richtigen Partner? Gelbe Seiten?
>Oder lebt mit der Illusion.
Danke, ich schlafe jetzt schon schlecht.
>>Von meiner Sichtweise sprach halt bisher nichts gegen ipchains,
>>allerdings auch nichts gegen FW-1. Wie es technisch realisiert wird,
>>ist mir im Prinzip auch egal - ich fand die höhren Kosten für FW-1
>>einfach nicht gerechtfertigt.
>
>Das sind sie imho oft auch nicht. FW-1 ist für manche Konstellationen
>wohl ganz brauchbar, *ich* bin bisher mit OS meist gut ausgekommen.
Das bestätigt ja irgendwie mein Gefühl. Und läßt mich FW-1 gleich
kritischer betrachten.
Ich danke für Deine Meinung,
mfg.,
-ds-
M00n[KDK]
out-of-the-box von Cisco oder ein selbstgebauter linux Rechner) ist in der
Regel belastbarer als eine box die auch noch was anderes tun mus.
Wenn du also ein großes Netzwerk schützen willst, dann stell doch besser
eine dedicated box hin.
Mit Hardware Firewall meinst du bestimmt einen kleinen grauen (oder blauen)
Kasten, denn man vorinstalliert mit Manual kaufen kann (z.B. PIX). (ich
versuche hier mal den Poster zu verstehen und nicht zurechtzuweisen SORRY!).
So ein Firewall hat natürlich auch einen Prozessor und ein OS, aber beides
ist in der Regel auf bestimmte Aufgaben hin optimiert und kann dadurch
Performance bringen und eine Menge Arbeit ersparen. Und weniger Sicher als
z.B. eine voll konfigurierte Linux Box ist sie auch nicht. Sofern die Kohle
stimmt, kann mal also mit einer Fertig Lösung nicht all zu viel falsch
machen.
Anders herum: ein Richtiges Netzwerk mit einem Win98 Rechner mit Norton
Internet Security Dingsbums zu sichern wäre mir eine wenig unsicher und
unstable. Aber für nur einen oder zwei Rechner würde ich dann auch wiederrum
keine DM 4000 ausgeben.
Ganz nebenbei habe ich auch noch nie gehört, dass eine Cisco Firewall so
genuked oder geflodded wurde, dass sie in die Knie ging.
Gruß an alle.
"Sven Mandel" <Sven....@SpCon.de> schrieb im Newsbeitrag
news:97l2cn$fso$01$1...@news.t-online.com...
> Kann mir jemand GUTE gründe nennen warum eine Hardware Firewall immer
> gegenüber einer Software Firewall bevorzugt werden sollte ? Und wenn man
> schon dabei ist, welche Hardware Firewalls sind im moment mit die Besten
auf
> dem Markt (bitte Preis/Leistungs verhältnis beachten !!!) Firewalls für
> mehrere 100TDM kommen nicht in Frage !
>
>
Mike Gerber
> [Windows-Maschinen als Internet-Server]
> Da es sehr aufwendig ist, fünf oder zehn NT-Kisten internetfest zu
> machen, konzentriert man diesen Aufwand doch lieber am zentralen
> Übergang. Das ist doch der Grundgedanke bei Firewalls!
Dummerweise reicht Port 80i/HTTP meist, um solche NT-Kisten mehr oder minder
einzunehmen oder zu DoSen. Jüngstes Beispiel vom 1.März:
Malformed URL can cause Service Failure in IIS 5.0 and Exchange 2000
http://www.microsoft.com/technet/security/bulletin/MS01-014.asp
Da sollte man meist versuchen, die Kunden zu bewegen, doch Ihr Betriebssystem
auf aktuellen Stand zu bringen und zu patchen. (Übrigens ist das mit einem
deutschen NT4 ein nahezu zum Scheitern verurteiltes Unterfangen, da kaum dt.
Patches verfügbar)
s/Patch/Hotfix/g
Leider reicht die Firewall nicht, ein Security-Konzept muss her, insb.
wenn der Kunde einen Server vom Internet erreichbar machen will. Manchmal
wird leider verkauft "Firewall = sicher", but that is not reality.
Mike Gerber
>>Naja, schonmal sauber(!) FTP in Deinen ipchains aufgesetzt? Aktiv und passiv?
>>Ich nicht.
> Sauber(!) FTP ohne state aufzusetzen ist unmöglich.
Danke für die Zustimmung.
>> So gesehen ist "stateful" für mich schon ein Killerargument.
> Du meinst, Du ersetzt verläßliche Hosts durch viel Technik am
> zentralen Übergang? Keine gute Idee.
Du liesst da was raus, was nicht da steht. ;-)
Da steht ungefähr:
Als paranoider Mensch will ich an jeder Ecke sichern, so gut ich kann (und
darüber hinaus). D.h.:
- Der/die/das Firewall darf nach meinem Verständnis nur dass durchlassen,
was ich möchte. Seiteneffekte (wie ausführlich erörtert bzgl. FTP-Protokoll)
möchte ich nicht. Darum gefällt mir ipchains nicht, und ich will iptables
einsetzen, in größeren Setups auch gern mal etwas kommerzielles.
- Wo möglich/sinnvoll/kostensinnvoll, werden Proxies eingesetzt.
- Die betreffenden Endgeräte (DMZ/Clients) werden zu "verläßliche Hosts"
gemacht. (In vielen Setups mit vielen Clients sieht die Realität meist
etwas schlechter aus, oder schon mal versucht >300 Clients ordentlich
gegen VBS und den neuesten IE5-Bug abzusichern? *graus* Da muß man dann
doch wieder am Proxy/Mailserver ansetzen.)
Ich denke, das ist so sinnvoll.
Mike Gerber
>>Aber für Dich: "man Realität": Realität ist, dass ein Server div. Services
>>anbietet.
> Realität ist eher daß dies nicht schadet da Dienste die angeboten werden
> so oder so detektierbar sind und damit gesichert werden müssen.
ACK.
> Warum man wenn man kann verschiedene Dienste(grupper) trotzdem auf
> verschiedenen Maschinen isoliert ist eine andere Frage.
ACK. Genau das versuche ich auch zu erreichen, allerdings versuche ich es,
nicht zu übertreiben.
Nur meist finde ich es etwas (eigentlich nicht nur etwas) übertrieben,
für einen WWW-Server (HTTP, FTP-Upload und MySQL) gleich 3 Maschinen
aufzustellen (ssh ausgeklammert, und unter der Annahme, dass 3 Maschinen
vom Load gesehen absolut unnötig sind).
Ich überlege grade: Ich müsste dann ja NFS o.ä. (sieht man mal von richtigen
Storage-Lösungen ab) zwischen HTTP- und FTP-Server fahren. *würg*
Sebastian Schlüter
>Eine IGMP Attacke interessiert mich. Wie macht man das?
Da er auch von einem Bluescreen gesprochen hat, nehme ich an, er meint
so etwas:
http://www.microsoft.com/technet/security/bulletin/ms99-034.asp
Gruß Sebastian
Mike Gerber
> Mike Gerber wrote:
>>Ulrich Eckhardt <ulrich....@transcom.de> wrote:
>>- Unkompliziertes Management
> 0-Argument. In 95% aller Fälle bedeutet soein GUI nur Mehraufwand.
Kann ich so nicht nachvollziehen. Ein GUI lässt mich bei Checkpoint
meine Rulebase zu entwickeln. Wo ist der Mehraufwand ggüber dem Editieren
eines Skripts?
Vorteile (sicher keine vollständige Liste):
- Verwaltung mehrerer Konfigurationen (geht natürlich auch mit "cp"),
- Zusammenfassen mehrere Regeln in der Art:
Any -> Mailserver pop-3 Accept
smtp
spop
ssmtp
Das erhöht die Übersichtlichkeit. Und ich glaube, dass Übersichtlichkeit
keine schlechte Sache ist.
- Userverwaltung
- Konsistenz-Check (sicher ein Gimmick, aber ganz praktisch),
> Kann z.B. das Teil die control-files meiner Skripten lesen? Nee? Schon
> brauch' ich zwei Konsolen.
Was sind die "control-files" deiner Skripten?
>>- Distributed Firewalls
> Was *ist* das? Bzw. Redundanz ist bei Verzicht auf stateful filter
> einfach machbar.
Du hast ein WAN (sei es über VPN oder leased lines) und hast div. Übergangs-
punkte in Richtung Internet o.ä. und kannst Deine Security-Policy für alle
Übergangspunkte zentral definieren und managen.
>>- Unkomplizierte VPNs, insbesondere für mobile Clients (SecuRemote)
>>- Div. Möglichkeiten zur Authentication
> Div. Möglichkeiten gibt das auch anderswo.
Bei iptables/ipchains wirst Du ein Problem haben, Deine telnet-
Connections z.B. über TACACS/RSA SecurID zu authentifizieren.
Bei FreeS/WAN wirst Du ein Problem haben, Deine "Roadwarrior" anders
als mit Certs oder PSK zu authentifizieren. Hier kann VPN-1 SecuRemote
z.B. RSA SecurID verwenden.
An den Umfang kommt höchstens noch die Cisco PIX dran.
> Was mir auffällt - Dein
> Fokus scheint auf der "Unkompliziertheit" zu liegen. Warum das?
> Schließsysteme sind inhärent komplex.
Warum sollte ich die technischen Hilfsmittel unnötig kompliziert halten?
Ich denke, dass Du in dem Punkt "Schließsysteme sind inhärent komplex"
recht hast, genau deswegen konzentriere ich mich darauf, das Konzept/die
Policy zu entwicklen und dann "The Right Tool for The Right Job" zu
verwenden. Gerade bei komplexen System erhöht ein unkompliziertes Management
die Übersicht.
Kurz: System komplex, also warum auch noch das Management komplex machen?
Genau aus dem selben Grund habe ich mir auch wrapper-Skripts für ipchains
geschrieben, um gleich input/output/forward-Chain samt "Rückkanal" (nicht-SYN-
Packets d.h. Antwort des Servers) zu Erschlagen, ohne gleich im einfachsten
Fall 6 Regeln aufzustellen.
>>In einigen Punkten ist Linux/iptables da sicher gewachsen, für einige
>>komplexe Installationen würde ich jedoch immernoch Checkpoint vorziehen.
> Für welche genau?
- Mehrere Firewalls
- Gehobene Ansprüche bei der Authentication (RSA SecurID gefällt vielen)
- Wenn Kunden wünschen, bestimmten Benutzergruppen besondere Rechte zu
erteilen. Dann kann man beispielsweise diese Berechtigungsstrukturen
in einem LDAP-Verzeichnis unterbringen, dass nachher sogar durch den
Kunden selbst pflegbar ist.
- Für Kunden, bei denen ich stateful als unumgänglich ansehe (wg.
zum Beispiel bereits exzessiv diskutiertem FTP-Problem). Da werde
ich sicher in Zukunft mit iptables mehr machen, jedoch warte ich
noch auf vielleicht Kernel 2.4.5 und eine vernünftige FreeS/WAN
Portierung.
>>Allerdings muss da dann meist der Geldbeutel recht locker sitzen.
> Wirkliche Beratung ist allerdings nicht billiger. Glaub' mir.
ACK
Mike Gerber
> Ganz nebenbei habe ich auch noch nie gehört, dass eine Cisco Firewall so
> genuked oder geflodded wurde, dass sie in die Knie ging.
Nimm eine Schrotflinte zum nuken und ein Eimer Wasser zum flooden.
Schliesslich wollen wir Hardware mit Hardware bekämpfen.
SCNR
Dietz Proepper
>> Warum man wenn man kann verschiedene Dienste(grupper) trotzdem auf
>> verschiedenen Maschinen isoliert ist eine andere Frage.
>
>ACK. Genau das versuche ich auch zu erreichen, allerdings versuche ich es,
>nicht zu übertreiben.
Wer hat schon Geld zu verschwenden.
>Nur meist finde ich es etwas (eigentlich nicht nur etwas) übertrieben,
>für einen WWW-Server (HTTP, FTP-Upload und MySQL) gleich 3 Maschinen
>aufzustellen (ssh ausgeklammert, und unter der Annahme, dass 3 Maschinen
>vom Load gesehen absolut unnötig sind).
Es hängt davon ab. Wenn nix Wichtiges auf der Maschine lagert und Du
Belästigungen Dritter auch für den Fall daß die Maschine kompromittiert
wurde ausschließen kannst dann wäre eine Trennung sicher sinnfrei.
Innerhalb meines bailiwick gibt es fast nie Gründe, ftp überhaupt
anzubieten. Wenn es denn sein muß dann auf jeden Fall isoliert.
>Ich überlege grade: Ich müsste dann ja NFS o.ä. (sieht man mal von richtigen
>Storage-Lösungen ab) zwischen HTTP- und FTP-Server fahren. *würg*
Nein. Du würdest Dir die man page zu rsync durchlesen und replizieren
z.B.
Dietz
Bernd Eckenfels
> Macht man auch mit Scripten, die man einmal schreibt und dann
> Umgebungsvariablen anpasst.
oder mit dem mächtigen fwctl. Der Einize Nachteil den fwctl noch hat ist, dass
er bei target und source aliasesn keine Klassigizierung vornimmt. D.h. wenn
ich eine Regel:
accept smtp -src INT_NET -dst INTERNET
habe, dann erlaubt diese als Ziel für die Verbindung 0/0 statt 0/0 OHNE
INT_NET, FIREWALL_IP, DMZ_NET ... d.h. man muss da noch mitdenken. Wie ist das
bei FW1?
Gruss
Bernd
Dietz Proepper
>dietz...@rotfl.franken.de (Dietz Proepper) wrote:
>>Du meinst, Du ersetzt verläßliche Hosts durch viel Technik am
>>zentralen Übergang? Keine gute Idee.
>
>Trotzdem in der Realität oftmals der einzig gangbare Kompromiß. Du
Ja, ich sehe das Problem. Ich bin leider in Nürberg, nicht in
Realität zu hause ;)
>lebst in einer Welt, wo es zu viele Leute gibt, die Partout
>Windows-Maschinen als Internet-Server einsetzen wollen und die viel
>Geld dafür bezahlen, dass man deren Inkompetenz hinter einem
>Paketfilter versteckt.
Damit habe ich auch kaum Probleme. Ich mache es einfach nicht. Punkt.
Bzw. schalt' den Leuten 'nen Port mit geeigneten ACLs frei und habe
eine Unterschrift daß das was dahinter liegt nicht meiner Verantwortung
unterliegt.
Achja. Wozu benötige ich in dem Szenario genau stateful filter?
Außerdem - ich lasse Leute die ich für mäßig kompetent halte selten
lange im Unklaren über meine Einschätzung, insbesondere wenn sie
$BIGBUCKS für die Kaschierung (an jemand anderen;) ausgeben wolle.
Wird einem zwar ab und an als "Teamunfähigkeit" ausgelegt, ist aber
ein guter Test, welche Kunden man gerne längerfristig hat.
>Da es sehr aufwendig ist, fünf oder zehn NT-Kisten internetfest zu
>machen, konzentriert man diesen Aufwand doch lieber am zentralen
>Übergang.
Ja, sicher. S.o. Was ich nur nicht verstehe ist was Dir hier stateful
filter helfen.
> Das ist doch der Grundgedanke bei Firewalls!
Ja, zumindest einer der. Ein anderer ist z.B. das KISS-Prinzip.
Dietz
Juergen Ilse
Frank Fiene <frank...@syntags.de> wrote:
> Sven Mandel wrote:
>> Kann mir jemand GUTE gründe nennen warum eine Hardware Firewall
>> immer gegenüber einer Software Firewall bevorzugt werden sollte ?
>> Und wenn man schon dabei ist, welche Hardware Firewalls sind im
>> moment mit die Besten auf dem Markt (bitte Preis/Leistungs
>> verhältnis beachten !!!) Firewalls für mehrere 100TDM kommen nicht
>> in Frage !
> Ich krieg die Krise. Was ist denn jetzt der Unterschied? Oder besser
> gefragt, was ist die Definition für Hardware-/Software-Firewall.
Gute Frage.
> Eine Firewall ist eine Kombination aus Hardware (aktive und passive
> Komponenten) und Software (Kernel-mode und User-Mode).
> Oder habe ich da etwas falsch verstanden?
Da fehlt noch eine Security Policy und einiges an Gehirnschmalz um die
Security Policy mit Hilfe der von dir genannten Komponenten umzusetzen.
Erst dann ist es eine Firewall (siehe auch die FAQ zu dieser Gruppe).
Tschuess,
Juergen Ilse (il...@asys-h.de)
--
Du hast keine Spracherkennung installiert? | Juergen Ilse
Doch Komma aber Mai Stenz Macht Sie den um Gang |Internet POP Hannover GmbH
mit dem Juice nett auch nicht leichter. |Vahrenwalder Str. 205
(Adrian Suter und Matthias Esken in dsnu) |30165 Hannover
Mike Gerber
>>für einen WWW-Server (HTTP, FTP-Upload und MySQL) gleich 3 Maschinen
>>aufzustellen (ssh ausgeklammert, und unter der Annahme, dass 3 Maschinen
>>vom Load gesehen absolut unnötig sind).
> Es hängt davon ab. Wenn nix Wichtiges auf der Maschine lagert und Du
> Belästigungen Dritter auch für den Fall daß die Maschine kompromittiert
> wurde ausschließen kannst dann wäre eine Trennung sicher sinnfrei.
Ich kann auch leider nicht sehen, inwiefern mich eine Trennung direkt
vor einer Kompromittierung schützen sollte. In jedem Fall muss ich meine
Dienste vor der Kompromitierung schützen.
> Innerhalb meines bailiwick gibt es fast nie Gründe, ftp überhaupt
> anzubieten. Wenn es denn sein muß dann auf jeden Fall isoliert.
Leider sind viele Menschen nicht von dem FTP-Protokoll abzubringen.
btw: Was ist "bailiwick"?
>>Ich überlege grade: Ich müsste dann ja NFS o.ä. (sieht man mal von richtigen
>>Storage-Lösungen ab) zwischen HTTP- und FTP-Server fahren. *würg*
> Nein. Du würdest Dir die man page zu rsync durchlesen und replizieren
> z.B.
Nunja, rsync wird meine kompromittierten Webseiten von meinem FTP-Server
zu meinem HTTP-Server tragen.
Mike Gerber
> * Mike Gerber <blue...@gmx.net> wrote:
>> Nur meist finde ich es etwas (eigentlich nicht nur etwas) übertrieben,
>> für einen WWW-Server (HTTP, FTP-Upload und MySQL) gleich 3 Maschinen
>> aufzustellen (ssh ausgeklammert, und unter der Annahme, dass 3 Maschinen
>> vom Load gesehen absolut unnötig sind).
> der da nichts zu suchen hat, per FTP deine Datenbank und/oder deinen
> Webcontent gegen huebsche Bilderchen austauscht und dann die Polizei vor
> _deiner_ Tuer steht.
Was macht es für einen Unterschied, ob er das per FTP oder ssh macht?
Dass man über FTP einfacher - durch "man ethereal" ;-) - an das Passwort
kommt, sofern man am richtigen Punkt sitzt, steht ausser Frage. Wir werden
uns wohl auch nicht streiten müssen, dass sowohl FTP- als auch SSH-Imple-
mentierungen Fehler enthalten können und auch bereits enthalten haben.
Was macht es für einen Unterschied, wenn er den FTP-Server kompromittiert,
und der HTTP-Server die kompromittierten Web-Seiten dann darstellt?
Was macht es für einen Unterschied, wenn er den MySQL-Server kompromittiert,
und der HTTP-Server die kompromittiereten Web-Seiten dann darstellt?
> Das Problem ist FTP und nicht der Paketfilter. Wer den Content seiner
> Webserver vom ganzen Internet aus per FTP anbietet und ueber diesen
> Zugang auch den Content aendern laesst, tut mir leid.
Wer bietet seinen Content über FTP an? "Otto-Normal-Web-Designer/-Master"
möchte jedoch seine Websites per FTP ändern.
>> Ich überlege grade: Ich müsste dann ja NFS o.ä. (sieht man mal von richtigen
>> Storage-Lösungen ab) zwischen HTTP- und FTP-Server fahren. *würg*
> Sonst faellt dir nichts ein?
rsync over ssh? scp?
> GUI => Girls use it
lol, wenn auch politisch nicht ganz korrekt.
Mike Gerber
> Du baust einen stateful Filter davor, damit die anderen Dienste, die Du
> unverstaendlicherweise dort auch noch laufen laesst und das auch noch
> auch upper tcp Ports, schuetzen kannst, obwohl es fuer einen Angreifer
> eher leicht ist, _wegen_ dem FTP Server auf deiner Maschine
> einzubrechen?
Ich kann die logische Folge:
FTP-Server -> Einbruch
nicht nachvollziehen. Bitte belegen.
>> (In vielen Setups mit vielen Clients sieht die Realität meist
>> etwas schlechter aus, oder schon mal versucht >300 Clients ordentlich
>> gegen VBS und den neuesten IE5-Bug abzusichern?
> Was hat jetzt dieser Unsinn mit dem Thema zu tun? Da kannst Du mit einer
> Firewall nichts machen.
Eine Firewall ist Mittel eines Sicherheitskonzepts.
In Deinem Sicherheits-Konzept sollte auch ein Antiviren-Konzept und ein
Konzept hinsichtlich Software-Bugs in Deinen Office-PCs Platz haben.
> Du kannst aber den Windows Scripting Host deinstallieren, die
> Dateinamenerweiterung wieder einschalten, deine User etwas schulen und
> den ersten rausschmeissen, der einen Virus einschleppt, weil er sich was
> runtergeladen und installiert hat und/oder auf unbekannte Attachments
> geclickt hat.
[ ] Ich glaube, Du hast das bereits bei über 10 Mitarbeitern gemacht.
Die Realität ist leider, dass die User auf jedes Attachment klicken werden,
die Du nicht vorher rausgefiltert hast. Der Scripting Host ist leider auch
schneller wieder da, als Du schauen kannst.
>> *graus* Da muß man dann
>> doch wieder am Proxy/Mailserver ansetzen.)
> Virenscanner am Proxy und Mailserver? Ich kann garnicht so viel fressen
> wie ich kotzen muss.
Bitte zügle Deine Sprache etwas. Warum bitte sollte man dort nicht ansetzen?
Deine User werden Viren heutzutage per Mail geschickt bekommen. Deine User
werden diese per Web herunterladen.
Den Mail-/Web-Proxy kannst Du im Gegensatz zu den Clients wirklich in *Deiner*
Kontrolle halten.
Ein Virenscanner am Mailserver ist genau das, was Anna Kornikova (sp?) und
Loveletter aufgehalten hat. Was gibt es hier zu "kotzen"?
> Bis hierhin habe ich dich wirklich ernst genommen und Du hast mich auch
> angeregt, ueber einige Sachen nochmals nachzudenken, aber das hier
> disqualifiziert dich.
Aha. Begründung?
>> Ich denke, das ist so sinnvoll.
> Ist es nicht.
Begründung?
Mike Gerber
[...FTP aktiv/passiv...]
>> Bei letzterem hast Du ein erhebliches Problem: Sämtliche Services,
>> die nicht auf den priviledged Ports laufen, hast Du damit freigeschalten.
> Bitte welche Dienste (TCP) bietest Du denn auf einem FTP Server auf
> einem unpriviledged Port an?
Die, die ich sonst noch möchte. Es ist keine Fehlkonfiguration, wenn ein
Server mehrere Dienste anbietet.
> Ein Paketfilter erhoeht in erster Linie die Fehlertolleranz. Er behebt
> nicht die Probleme, die entstehen, wenn der zu schuetzende Recher/das zu
> schuetzende Netz schlecht konfiguriert sind.
100% ACK.
Ich sehe jedoch den Vorteil eines stateful-Filters, der dafür sorgt,
dass lediglich jene Pakete den Filter passieren, die auch zu einer validen
Verbindung gehören. Damit erhöhe ich die o.g. Fehlertoleranz.
Das ich deswegen meine Systeme dahinter trotzdem korrekt konfigurieren
muss, steht ausser Frage.
> Es ist wie die Begruendungen gegen ZA. Wenn Du einen Dienst nicht
> anbieten willst, dann biete ihn nicht an. Ihn mit einem Paketfilter zu
> sperren, ist am Symptom rumgefummelt.
Mit der gleichen Begründung kannst Du auch gleich den Sinn von Paket-Filtern
im Allgemeinen bezweifeln.
>> Bei der aktiven Session (hier zwar nicht Thema) hast Du das Problem,
>> dass jemand damit eine Connection zu einem Dienst auf Deinem Client
>> zugreifen kann, sofern er mit Port 20 kommt.
> Aktives FTP sollte man entweder _nicht_ benutzen, oder ueber einen
> Proxy/Bastion host.
Vorteil?
> Du kannst nicht alle Probleme mit einem Paketfilter erschlagen. Sicher
> kannst Du mit iptables etwas flexibler eine schlechte Konfiguration der
> zu schuetzenden Clients und Server handhaben. Aber wenn Du dich darauf
> konzentrierst, die Kisten auch sicher aufzusetzen, dann reicht ein
> stateless paketfilter voellig aus und ein stateful paketfilter erheohet
> lediglich die Komplexitaet, nicht aber die Sicherheit.
Ich bitte um ein Beispiel, in dem ein stateful packetfilter die Komplexität
erhöht.
>> Sind Dir das nicht Probleme genug?
> Ich sehe immer noch keine, ausser dass die selben "Gruende" als "must"
> fuer iptables genannt werden, wie das bei den ZA Befuerwortern der Fall
> ist. Das Problem ist aber immer noch die Konfiguration, die schlecht bis
> fehlerhaft ist und nicht, dass man ein neues Spielzeug braucht, um einen
> Fehler zu korrigieren.
Es geht bei Paketfiltern um Risiko-Management. Pakete, die aufgrund eines
solchen Filters die Applikation erst gar nicht erreichen, können auch keinen
Fehler dort ausnutzen.
>> Kindisch ist es ständig mit dem man-Befehl um sich zu schmeissen.
> Staendig? Wuerdest Du ein paar Zitate aufzeigen, wo ich das staendig
> mache?
Sorry, besser s/ständig/unpassend/g. Passend ist der man-Befehl bei man-pages,
die auch existieren.
> Aber mal am Rande. Ausser den "Ausreden" bei ftp, wo bietet ein stateful
> Paketfilter mehr Sicherheit?
Du kannst keine Pakete schicken, die nicht zu einer erlaubten Verbindung
gehören? Anwendung: Remote OS Detection, Portscans. man nmap.
> Noch ein Problem: Du wirst in Produktivumgebungen den 2.4.x Kernel eher
> selten antreffen. Er ist noch etwas zu neu und noch nicht besonders
> ausgereift. Das kommt dann auch noch dazu.
Es gibt noch andere Filter neben Linux 2.4 netfilter.
> Und ausgerechnet bei einer Komponente wie dem Paketfilter, werde ich den
> Teufel tun uns solche Kernel installieren.
Korrekt.
Mike Gerber
>> meine Rulebase zu entwickeln. Wo ist der Mehraufwand ggüber dem Editieren
>> eines Skripts?
Eine kombinierte Rule statt zig Zeilen ipchains-Befehlen?
>> - Zusammenfassen mehrere Regeln in der Art:
>>
>> Any -> Mailserver pop-3 Accept
>> smtp
>> spop
>> ssmtp
> Macht man auch mit Scripten, die man einmal schreibt und dann
> Umgebungsvariablen anpasst.
Hier habe ich meinen "parse error".
>> Das erhöht die Übersichtlichkeit. Und ich glaube, dass Übersichtlichkeit
>> keine schlechte Sache ist.
> Eben. Aber was bringt mir da eine GUI?
Was es Dir bringt, weiss ich nicht. Mir bringt es mehr Übersicht, da ich damit
eine Rulebase schneller erfassen kann, als in den Skripts, die
ich bisher gesehen habe.
>> - Userverwaltung
> Wozu? Es gibt nur einen User auf einer Firewall.
Aber *davor/dahinter* sitzen einige User, die ggf. authentifiziert
werrden müssen.
>>>>- Distributed Firewalls
>>> Was *ist* das? Bzw. Redundanz ist bei Verzicht auf stateful filter
>>> einfach machbar.
>> Du hast ein WAN (sei es über VPN oder leased lines) und hast div. Übergangs-
>> punkte in Richtung Internet o.ä. und kannst Deine Security-Policy für alle
>> Übergangspunkte zentral definieren und managen.
> Ein Fehler und schon habe ich ihn ueberall. Sehr gut.
> Eine Firewall soll die Fehlertolleranz erhoehen und nicht das Gegenteil.
Deine kopierten Skripts haben diesen Fehler nicht? Du erhöhst die Komplexität
deines Systems nicht, in dem Du eigene Strategien zur Verteilung deiner
Skripts entwickelst?
>> Bei iptables/ipchains wirst Du ein Problem haben, Deine telnet-
>> Connections
> TELNET? Du benutzt TELNET?
> Und Du redest von Sicherheit?
> *verwirrt*
mal wieder ein Abstecher in die Realität: Du hast schon mal Cisco-Router
konfiguriert? Du hast auch bereits Deine Arbeitgeber gefragt, ob Sie Dir
x kDM für den Kauf von IPSec56-IOSen mit ssh-Support spendieren?
>> z.B. über TACACS/RSA SecurID zu authentifizieren.
> Wozu? Wozu soll ich telnet aufblasen? Gibt es nichts anderes?
Du darfst gerne: s/telnet/$wasdirbeliebt/g
>> An den Umfang kommt höchstens noch die Cisco PIX dran.
> Eine gute Security Policy beherzigt KISS und nicht BLOAD und Featueritis.
Riesige ipchains-Skripts können durchaus "bloat" sein. Was macht eine Check-
Point-Firewall für Dich zum bloat?
>> [ "The Right Tool for The Right Job" ]
> Telnet?
Ja, mit den richtigen Access-Lists und Beachtung der Kosten einer ssh-
Implementierung für die Plattform (Cisco), auf der ich Telnet benutze.
> FTP Server zur Contentadministration auf Webservern?
Ja, für die Web-Designer/-Master meist schon.
>> - Gehobene Ansprüche bei der Authentication (RSA SecurID gefällt vielen)
> Was willst Du denn damit? Wozu? Sag doch mal, was Du damit machst.
Vertriebsmitarbeiter authentifizieren, die eine VPN-Verbindung zu Ihrer
Firma aufbauen wollen.
>> - Wenn Kunden wünschen, bestimmten Benutzergruppen besondere Rechte zu
>> erteilen. Dann kann man beispielsweise diese Berechtigungsstrukturen
>> in einem LDAP-Verzeichnis unterbringen, dass nachher sogar durch den
>> Kunden selbst pflegbar ist.
> Benutzergruppen, die einen Dienst nutzen duerfen? Macht man das nicht an
> der Applikation?
Ja. Wenn diese Applikation nun aber nicht in Deinem Einflussbereich (sprich
"im Internet") ist?
> Du solltest das Konzept korrigieren und nicht mir iptables das Problem
> vernebeln.
Korrigiere Dein Konzept bitte.
Mike Gerber
> [fwctl]
> accept smtp -src INT_NET -dst INTERNET
> habe, dann erlaubt diese als Ziel für die Verbindung 0/0 statt 0/0 OHNE
> INT_NET, FIREWALL_IP, DMZ_NET ... d.h. man muss da noch mitdenken. Wie ist
> das bei FW1?
Mitdenken sollte man eigentlich immer müssen.
Nunja, Any heisst Any, d.h.
Any -> Mailserver smtp Accept
erlaubt *jedem* (sei es Inet, DMZ, LAN oder sonst) Zugriff auf Deinen
Mailserver. Sofern natürlich vorher nicht verboten.
Allerdings kannst Du Rules wie folgt erstellen:
Any -> Mailserver smtp Accept
!DMZ
!LAN
Was dann bedeutet: "Erlaube jedem außer DMZ und LAN eine Verbindung
zum SMTP-Dienst des Mailservers".
Bernd Eckenfels
> Allerdings kannst Du Rules wie folgt erstellen:
> Any -> Mailserver smtp Accept
> !DMZ
> !LAN
> Was dann bedeutet: "Erlaube jedem au?er DMZ und LAN eine Verbindung
> zum SMTP-Dienst des Mailservers".
OK, aber ich kann kein Object (so nennt sich das wohl in Fw1?) erstellen das
das Internet (also ANY) umfasst, aber ohne die lokalen IP-Addressen der
Firewall Interfaces und ohne all die internen Netze der Firewall?
Das !DMZ ist ja schon mal gut, aber ich muss es immer noch auflisten und vor
allem ist es unperformant, da es ja im Prinzip 2 Skip und eine Accept Regel
erzeugt. Durch geschicktes sortieren der Eintraege nach Netzmaske kann man das
aber vermeiden (besonders wenn man mehrere Regeln hat die ein !DMZ aufweisen).
Naja, ich seh schon, ich muss doch noch mal Fwctl hacken, wenn es nur nicht in
Perl wäre.
BTW: diese Diksussion hier macht klar, dass es sehr prakrtisch ist wenn man
regeln als Textconfiguration hat, dann kann man sie naemlich beser diskutieren
und dokumentieren.
Gruss
Bernd
Dietz Proepper
>jo...@joergland.wohnheim.uni-ulm.de (Joerg Wendland) wrote:
>>On Fri, 02 Mar 2001 11:59:41 +0100,
>> Marc Haber <usene...@marc-haber.de> wrote:
>>>jo...@joergland.wohnheim.uni-ulm.de (Joerg Wendland) wrote:
>>>>Fuer eine DMZ ist Stateful filtering gefaehrlich.
>>>
>>>Magst Du diese Aussage etwas näher erläutern?
>>
>>Vielleicht war ich ein bisschen ungenau. Nicht direkt gefaehrlich fuer die
>>DMZ, aber fuer den Firewall, der diese schuetzen soll. Wenn ich es schaffe,
>>die interne Tabelle, in der die aktiven Connections gespeichert werden, zum
>>Ueberlaufen zu bringen, kann eine DoS-Attacke fahren.
>
>Das stimmt natürlich. Ich gehe aber davon aus, dass eine angemessen
>dimensionierte Firewall dieses Problem nicht hat.
Wollen wir wetten daß mich ein angemessen dimensioniertes Angriffsystem
wesentlich weniger kostet?
Dietz
Rainer Weikusat
> Die Realität ist leider, dass die User auf jedes Attachment klicken werden,
> die Du nicht vorher rausgefiltert hast.
Was im Folgeschluß dazu führt, daß die Realität leider so ist, das die
nächste neue Variante eines Melissa-artigen Programmes, daß sich über
einen Dir unbekannten Kanal verbreitet hat (zB als JPEG-Kommentar, der
HTML enthält, weswegen der IE in gewohnter Zuverlässigkeit text/html
annimmt und das enthaltene Javascript ausführt) euer Netz eben leider
kaputt geht. Aber für solche Zwecke gibt es ja zum Glück
'Verantwortliche'...
--
SIGSTOP
Dietz Proepper
[ftp vs. ssh]
>Dass man über FTP einfacher - durch "man ethereal" ;-) - an das Passwort
>kommt, sofern man am richtigen Punkt sitzt, steht ausser Frage. Wir werden
>uns wohl auch nicht streiten müssen, dass sowohl FTP- als auch SSH-Imple-
>mentierungen Fehler enthalten können und auch bereits enthalten haben.
Aha. Dann beschreib' mir bitte die bekannten Fehler in ssh die mir
ohne auf dem Transportweg zu sitzen eine Kompromittierung erlauben?
Differenziere bitte zudem noch nach ssh-Protokoll. Jetzt solltest Du
erklären können weswegen ein ftpd in aller Regel komprmittierbarer als
ein sshd ist.
>Was macht es für einen Unterschied, wenn er den FTP-Server kompromittiert,
>und der HTTP-Server die kompromittierten Web-Seiten dann darstellt?
Frage, Mike, ganz im Vertrauen, Du weißt aber schon wovon Du sprichst?
>Was macht es für einen Unterschied, wenn er den MySQL-Server kompromittiert,
>und der HTTP-Server die kompromittiereten Web-Seiten dann darstellt?
Warum sollte jemand Webseiten verändern wollen? Achso. Wir sprechen von
Spielkindern. Nee, mit denen hab' ich eigentlich sogut wie nie Probleme.
Ernsthafte Angreifen kommen in meinen Setups halt sehr schwer von dem
geöffneten ftp-Server aus *irgendwo* hin. Nach spätestens 24 h fallen auch
ihre Modifikationen am System unweigerlich auf.
>Wer bietet seinen Content über FTP an? "Otto-Normal-Web-Designer/-Master"
>möchte jedoch seine Websites per FTP ändern.
Dann isolier' den ftp-server in fuerwarkens Namen und laß die
Synchronisation vom Benutzer anstoßen damit das Zeitfenster für
Veränderungen klein wird.
Oder laß Dir von Deinen Kunden zusichern daß sie die Verantwortung
für ein ungeeignetes Zugangsverfahren wählen.
Oder lebe mit einer Illusion. Ach ja, sollt ich mal wieder Probleme
mit gehackten ftpds haben die meine Netze beläßtigen dann geb' ich
die Kröten aus um die Verursacher (die Admins der ftpds) zu belangen.
Einfach um's mal zu wissen.
Dietz
Dietz Proepper
[ftpd&sonstwas auf einer Box]
>> Es hängt davon ab. Wenn nix Wichtiges auf der Maschine lagert und Du
>> Belästigungen Dritter auch für den Fall daß die Maschine kompromittiert
>> wurde ausschließen kannst dann wäre eine Trennung sicher sinnfrei.
>
>Ich kann auch leider nicht sehen, inwiefern mich eine Trennung direkt
>vor einer Kompromittierung schützen sollte.
Du vermeidest daß neben Deinem ftp-Server auch Deine anderen Dienste
kompromittiert werden. Sie liegen ja auf anderen Boxen und da Du ja dem
ftpd nicht vertraust vertraust Du auch dem ftp-Server sowenig daß der
Angreifer nicht weiter kommt.
Indem Du sie vor einen Paketfilter stellst kannst Du die die Verwendung
des Rechners z.B. als ddos-relay ("zombie" (sp??)) erschweren, wenn Du
nur passives ftp zulässt sogar recht verläßlich ausschliesen.
> In jedem Fall muss ich meine
>Dienste vor der Kompromitierung schützen.
Wenn Du unsichere Dienste anbietest dann hast Du ein ganz anderes
Problem - Du wirst evtl. zu einem Problem für Dritte die durch Deine
Boxen beeinträchtigt werden.
Ich bin mir nicht ganz sicher, ob man in so einem Fall Dich wegen
Fahrlässigkeit belangen kann, würde aber davon ausgehen, man
"den letzten beißen die Hunde".
>> Innerhalb meines bailiwick gibt es fast nie Gründe, ftp überhaupt
>> anzubieten. Wenn es denn sein muß dann auf jeden Fall isoliert.
>
>Leider sind viele Menschen nicht von dem FTP-Protokoll abzubringen.
Zum Glück muß man nicht mit jedem Deppen Geschäfte machen. Bzw.
man knirscht leicht mit den Zähnen und läßt sich ftp-Zugang
separat bezahlen.
>btw: Was ist "bailiwick"?
Sowas das man in einem Lexikon findet... bailiwick == Amtsbezirk,
Verantwortungsbereich.
>Nunja, rsync wird meine kompromittierten Webseiten von meinem FTP-Server
>zu meinem HTTP-Server tragen.
Nein, wird nicht. S. anderes posting.
Dietz
Mike Gerber
ACK.
Darum wird man auch Risiko-Kompensation betreiben, und zunächst jene Varianten
filtern, die einem bekannt sind.
Dietz Proepper
>Rainer Weikusat <weik...@mail.uni-mainz.de> wrote:
>> Mike Gerber <blue...@gmx.net> writes:
>>> Die Realität ist leider, dass die User auf jedes Attachment klicken werden,
>>> die Du nicht vorher rausgefiltert hast.
>> Was im Folgeschluß dazu führt, daß die Realität leider so ist, das die
>> nächste neue Variante eines Melissa-artigen Programmes, daß sich über
>> einen Dir unbekannten Kanal verbreitet hat (zB als JPEG-Kommentar, der
>> HTML enthält, weswegen der IE in gewohnter Zuverlässigkeit text/html
>> annimmt und das enthaltene Javascript ausführt) euer Netz eben leider
>> kaputt geht. Aber für solche Zwecke gibt es ja zum Glück
>> 'Verantwortliche'...
>
>ACK.
Ähm. Bist Du der Verantwortliche? Wieviele Vallies benötigst Du täglich
zum Einschlafen?
Um die Anzahl zu erhöhen, bedenk' mal welchen Schaden ein mail-Wurm der
von jemand wirklich kompetentem geschrieben wurde. Weiß ja nicht ob
Du Dir melissa & Co mal angeschaut hast, Könner waren das nicht.
Wenn ich email-Filter kostenlos und ohne Ressourcenverbrauch bekomme,
ja mei, die Realität sieht aber so aus daß die Systeme teuer und mäßig
brauchbar sind -> kann man das Geld sinnvoller investieren.
>Darum wird man auch Risiko-Kompensation betreiben,
Was kompensierst Du genau? Andersherum, wie lange denkst Du benötige
z.B. ich um einen mail-Wurm zu schreiben der von Deinem Scanner nicht
erkannt wird? Glaub' mir, Dein Scanner kostet Dich *wesentlich mehr*.
>und zunächst jene Varianten
>filtern, die einem bekannt sind.
Mann kann sich den Aufwand aber auch sparen und in eine sinnvolle
Variante investieren, z.B. Mitarbeiterschulung, Quarantänerechner
oder ganz generell überdenken weswegen jeder MA mail an seinem
Arbeitsplatz benötigt.
Dietz
Joerg Wendland
Dietz Proepper <dietz...@rotfl.franken.de> wrote:
>Wenn Du mit solchen Managern zusammenarbeitest dann mußt Du auch
>mit den Folgen leben - jeder macht sich sein Bett selber.
Wenn man sich seine Kunden nach dem Wissensstand der Entscheider auswaehlt,
macht man halt keine grossen Geschaefte. Leider.
Joerg
--
Freier Platz fuer Bearbeitungsvermerke, bitte nicht beschriften.
Mike Gerber
>>>> Schon klar, aber erzaehl das mal einem Manager, der entscheiden muss,
>>>> was gekauft wird. Eine Bash wird der nicht akzeptieren :(
>>>Dann soll er keine Entscheidungen zu Themen treffen, von denen er keine
>>>Ahnung hat.
>>Reality Check, please!
> Wenn Du mit solchen Managern zusammenarbeitest dann mußt Du auch
> mit den Folgen leben - jeder macht sich sein Bett selber.
Du willst also einen Auftrag ablehnen, weil Du den Manager, der darüber
entscheidet, für inkompetent hälst? Wie verdienst Du bitte Dein Geld?
Im übrigen kann man auch inkompetente Manager von den Vorteilen einer bash
überzeugen. Da fällt aber dann in den Bereich "Marketing & Psychologie".
Mike Gerber
>>Leider sind viele Menschen nicht von dem FTP-Protokoll abzubringen.
> Zum Glück muß man nicht mit jedem Deppen Geschäfte machen. Bzw.
> man knirscht leicht mit den Zähnen und läßt sich ftp-Zugang
> separat bezahlen.
Die "Deppen" sind es, die Dich bezahlen. Es ist schön für Dich, dass Du
nicht mit "Deppen" zusammenarbeiten musst.
Ich erlaube mir hier jetzt mal die Diskussion zusammenzufassen, möglichst
wertneutral:
- Die Diskussion startete mit der Aussage "FTP ist nicht sauber mit einem
stateless filter zu behandeln".
- Einige halten die sog. "stateful filter" für ein Mittel, das FTP-Protokoll
sauber in Ihrem Paketfilter zu behandeln.
- Die Gegenposition: FTP ist an sich das Problem, man sollte es nicht
verwenden. Wenn es umbedingt sein muss, dann nur mit Proxy und auf einem
getrennten System in einer DMZ. Darum reicht ein stateless filter aus.
Mike Gerber
> Du vermeidest daß neben Deinem ftp-Server auch Deine anderen Dienste
> kompromittiert werden.
Damit hast Du recht. Dem Kunden wirst Du jedoch die Vor- und Nachteile
der Lösung A (1 Server) und der Lösung B (3 Server) darstellen müssen.
Trotz aller Sicherheitsüberlegungen werden sich die meisten für Lösung A
entscheiden, da sie damit weniger einmalige und weniger laufende Kosten
(Wartung) haben. Auch wenn Du Ihnen darlegst, was eine Kompromittierung
kosten kann.
> Indem Du sie vor einen Paketfilter stellst kannst Du die die Verwendung
> des Rechners z.B. als ddos-relay ("zombie" (sp??)) erschweren, wenn Du
> nur passives ftp zulässt sogar recht verläßlich ausschliesen.
Und das kann nicht mit einem stateful filter nicht? Der schliesst genau
einen solchen Nutzen aus.