Braucht man Hardware-Firewall für Firmennetzwerk?
Wolfgang Kueter
>
> Als Mailverteiler haben wir einen Mailserver, welcher auf Suse-Linux 6.3
> läuft und über eine IP-Adresse erreichbar ist.
> Bei unserem letzten Provider hatten wir einen Firewall auf einem
> Ascend-Router, mit den man diverse Ports abschalten konnte.
> Nun haben wir neuen Zugang incl. neuen Router ohne Firewall.
> Daher brauchen wir eine neue Firewall-Lösung.
Eine Firewall-Lösung beinhaltet mehr als Paketfilterung und NAT.
> Reicht da eine Absicherung mit ipchains oder den Suse beiliegenden
> Softwarefirewall?
Wer Firewalls konfiguriert, muß wissen, was er tut. ipchains ist nur ein
maskierender Router, sowas ist _ein Teil_ einer Firewall-Lösung, keine
komplette Firewall. Man erreicht durchaus etwas damit, ob das allerdings
im Einzelfall reicht, ist pauschal nicht zu sagen.
> Oder sollte man lieber einen Hardwarefirewall vorschalten?
Eine richtige Firewall [tm] ist eine Kombination aus (spezieller)
Hardware, Paketfilter(n) und Application Level Proxies. Ob man das alles
braucht und welchen Aufwand man im Einzelfall treiben soll/muß/will ist
ohne genaue Kenntnis und Analyse des Einzelfalls kaum zu sagen.
> ( Dazu habe ich bsw. ein Angebot über einen Cisco Secure PIX Firewall
> 506 auf dem Tisch liegen. )
> Braucht man so etwas unbedingt, da das Gerät ja doch eine Stange Geld
> kostet?
Was man braucht, hängt davon ab, wie hoch das Sicherheitsbedürfnis ist.
Ganz angenehm ist bei der PIX, daß die Kosten nicht abhängig von der
Anzahl der geschützten Rechner sind. Das ist bspw. bei Checkpoint
Firewall1 anders.
f'up to news:se.comp.security.firewall
Wolfgang
--
shconnect Internet Service
web: http://www.shconnect.de EMail: in...@shconnect.de
Grosse Strasse 17, 24392 Süderbrarup
Telefon: 04641-970556, Telefax: 04641-970557
Alexander Apathy
>
> Als Mailverteiler haben wir einen Mailserver, welcher auf Suse-Linux 6.3
> läuft und über eine IP-Adresse erreichbar ist
> Ascend-Router, mit den man diverse Ports abschalten konnte.
> Nun haben wir neuen Zugang incl. neuen Router ohne Firewall.
> Daher brauchen wir eine neue Firewall-Lösung.
> Softwarefirewall?
> 506 auf dem Tisch liegen. )
> Braucht man so etwas unbedingt, da das Gerät ja doch eine Stange Geld
> kostet?
Zuerst einmal glaube ich nicht, dass das auf dem Ascend eine "richtige"
Firewall war/ist. Sehr wahrscheinlich nur statisches Filtern mithilfe
von access-lists. Vorab meine persönliche Meinung: Die kleine Cisco PIX
506 kann durchaus uneingeschränkt empfohlen werden und ist erfolgreich
bei einigen Kunden von uns im Einsatz.
Grundsätzlich kann die PIX viel mehr als das ganze Linux-Zeug. Ich
möchte Linux (ipchains, ipfilter etc.) nicht schlecht machen, aber die
PIX macht statefull inspection, VPN etc. und ist alleine schon deswegen
und wegen des speziell dafür entwickelten (I)OS als viel sicherer
anzusehen, als (fast) jede selbstgebastelte Low-Cost FW auf Unix-Basis.
Checkpoinst FW1 auf Unix ist natürlich ganz was anderes ;-) Kann sein,
dass du das alles auch unter Unix lösen kannst, aber dazu benötigst du
viel Zeit und Wissen/Erfahrung. Außerdem: bei einem HEK von ATS 20k, bzw
gut DM 2800 ist die PIX 506 ein richtiges Schnäppchen. Lese dir doch mal
die Features unter
http://www.cisco.com/warp/public/cc/pd/fw/sqfw500/prodlit/_de_cs506_ds.htm
durch und entscheide selbst.
MfG, Alexander
PS: Hat das einen speziellen Grund, warum ihr euch eine Email-Adresse
teilt, oder ist euer Provider so geizig ;-) ??
Lutz Donnerhacke
>Grundsätzlich kann die PIX viel mehr als das ganze Linux-Zeug. Ich
Ja.
>PIX macht statefull inspection, VPN etc. und ist alleine schon deswegen
>und wegen des speziell dafür entwickelten (I)OS als viel sicherer
>anzusehen, als (fast) jede selbstgebastelte Low-Cost FW auf Unix-Basis.
Nunja. Aus einem Schreiben an den Kunden:
\section{Veraltete PIX Software}\label{sec:version}
Die Software der PIX ist derzeit 4.2(4). Diese ist veraltet~\cite{url:pix}.
Die schützt nicht gegen verschiedene Fragmentierungsangriffe. Insbesondere
ist sie selbst anfällig gegen \textrm{land.c}. Mit diesem weitverbreiteten
Angriff kann man die PIX komplett zum Stillstand bringen. Andere Probleme
sind unter anderem die fehlerhafte Behandlung von Broadcasts, fehlerhafte
Ablehnung von unzulässigen Verbindung von Innen nach Außen, möglicherweise
mehrfache Zuordnung von gemappten Adressen, fehlender Zugriff auf das zweite
MB des Flash-RAMs und teilweise fehlende Logginginformation, die zur
Identifizierung des Angreifers benötigt wird.
Ein Upgrade auf die aktuelle Version 4.4(x) ist dringend anzuraten. Evtl.
sollte auch ein Update auf die Version 5.x genommen werden, da diese neben
kosmetischen Feinheiten (Kommandosyntax wie IOS) auch softwaremäßig
Kryptographie unterstützt und so eine direkte Fernwartung und vernünftige
Authentifizierungen gestattet.
Die derzeitig installierte Version gestattet nur 128 gleichzeitige
Verbindungen durch die Firewall hindurch. Evtl. ist ein Upgrade nachzukaufen.
[...]
\bibitem{url:pix} Cisco Dokumentation zur PIX Firewall,
\url{http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/}
--
the \year=2001 TeX calendar; IKS Garamond, 2000; ISBN 3-934601-10-3
Stefan Nobis
> Grundsätzlich kann die PIX viel mehr als das ganze Linux-Zeug. Ich
So genau kenne ich die PIX nicht, das möchte ich also nicht beurteilen.
> PIX macht statefull inspection, VPN etc. und ist alleine schon deswegen
> und wegen des speziell dafür entwickelten (I)OS als viel sicherer
> anzusehen, als (fast) jede selbstgebastelte Low-Cost FW auf Unix-Basis.
Aber das ist ja wohl grausiger Unsinn! Hat Cisco alle fähigen Programmierer
der Welt bei sich sitzen und alle anderen, die nicht bei Cisco arbeiten, sind
unfähig?
Und die Tatsache, dass PIX statefull inspection, VPN etc. beherrscht, ist eher
ein Indiz dafür, dass sie *unsicherer* ist! Ein stateless Paketfilter ist
bedeutend einfacher zu programmieren und damit per se erstmal fehlerfreier. Da
eines der größten Probleme bei Firewalls eben Bugs in der verwendeten Software
ist (und PIX ist auch nur ein Stück Software, wie jede andere auch), ist eine
Software, die besonders viele Features aufweist eben gerade unsicherer, da sie
größer und komplexer ist und damit potentiell bedeutend mehr Fehler enthält.
Dazu kommt dann noch, dass rein prinzipiell nur sehr wenige Augen den PIX-Code
nach Fehlern absuchen, während bei Open-Source sehr viele Augen nach Fehlern
suchen (können). Also wäre eigentlich Open-Source als viel sicherer anzusehen.
Aber ich will hier Linux nicht mit Gewalt das Wort reden (gnausowenig BSD oder
was auch immer). Nur ist ein Stück Software, weil sie für einen bestimmten
Zweck geschrieben wurde oder von einer bestimmten Firma kommt nicht per se
sicherer als andere Software.
Nie vergessen: Eine gute Firewall hält sich an das KISS-Prinzip. Und eine
lange Featureliste ist da eher kontraproduktiv.
--
Until the next mail...,
Stefan.
Felix von Leitner
> Vorab meine persönliche Meinung: Die kleine Cisco PIX 506 kann
> durchaus uneingeschränkt empfohlen werden
Nein.
> und ist erfolgreich bei einigen Kunden von uns im Einsatz.
Ah, hier kommen wir auf des Pudels Kern: Du hast es aus Unwissenheit
mehrfach verkauft und möchtest dir jetzt einreden, daß das eine richtige
Entscheidung war.
> Grundsätzlich kann die PIX viel mehr als das ganze Linux-Zeug.
Nein.
> Ich möchte Linux (ipchains, ipfilter etc.) nicht schlecht machen,
Doch.
> aber die PIX macht statefull inspection,
Alexander, du kannst das Feature ja noch nicht mal richtig buchstabieren,
wie kannst du dir dann in irgendeiner Weise Kompetenz zutrauen, über
Firewalls insgesamt zu schreiben?
Ob Stateful Inspection grundsätzlich anzuraten ist, ist umstritten.
Ich rate jedenfalls lieber zu einer anständigen und klaren Installation
als zu Stateful Inspection. Aber: auch Linux macht seit Jahren Stateful
Inspection.
> VPN etc.
Auch VPN gibt es seit Jahren frei für Linux.
> und ist alleine schon deswegen und wegen des speziell dafür
> entwickelten (I)OS als viel sicherer anzusehen, als (fast) jede
> selbstgebastelte Low-Cost FW auf Unix-Basis.
Was faselst du denn hier inkohärent Marketing-Müll nach?
IOS ist speziell für die PIX entwickelt? Unfug!
Spezielle Betriebssysteme sind sicher(er)? Noch gröberer Unfug!
Deine eigentliche Aussage ist: schmeißt mir bitte weiter euer Geld in
den Rachen und im Ausgleich vernebele ich euch anständig, damit ihr
nicht zur Forbildung kommt und meine Müllaussagen hinterfragt oder gar
versteht.
> Checkpoinst FW1 auf Unix ist natürlich ganz was anderes ;-)
Checkpoint ist auf allen Betrübssystemen schlecht.
> Kann sein, dass du das alles auch unter Unix lösen kannst, aber dazu
> benötigst du viel Zeit und Wissen/Erfahrung.
1. Widerspruch zu deinen früheren Aussagen, 2. auch Unfug.
> Außerdem: bei einem HEK von ATS 20k, bzw
> gut DM 2800 ist die PIX 506 ein richtiges Schnäppchen.
Hey, ich habe hier noch ein paar Hektar Morast^Wfruchtbares
Waldgrundstück in Florida, daß ich ebenfalls günstig abzugeben habe!
Felix
Stefan Heinecke
>Zuerst einmal glaube ich nicht, dass das auf dem Ascend eine "richtige"
>Firewall war/ist. Sehr wahrscheinlich nur statisches Filtern mithilfe
>506 kann durchaus uneingeschränkt empfohlen werden und ist erfolgreich
>bei einigen Kunden von uns im Einsatz.
Sagmal, bist Du der aus sicherheitsgruenden ungenannte Sicherheitsexperte
aus der oesterreichischen "News" der behauptet hat, Trojaner wie Sub7 etc.
waeren schwer zu entdecken?
Die Cisco PIX kann nicht uneingeschraenkt empfohlen werden:
http://www.cisco.com/warp/public/707/pixftp-pub.shtml.
http://www.cisco.com/warp/public/707/pixtcpreset-pub.shtml
http://www.cisco.com/warp/public/707/PIXfirewallSMTPfilter-pub.shtml
Das bekommt man mit freier Software besser hin.
Stefan
Alexander Apathy
Hallo!
Wenn ich mir eine neue PIX kaufe, ist automatisch Version 5.2 drauf. Daher haben
die obigen Ausführung absolut keine Gültigkeit mehr. Version 4.x ist veraltet
und buggy, keine Frage. Was die Anzahl der Connections betrifft, so liegt diese
bei >4000 concurrent connections. Ich kann also die obigen Ausführungen in
keinster Weise bestätigen. Dass man die Firewall-Software (egal welche Platform)
auf dem aktuellsten Stand halten muss, versteht sich von selbst.
MfG, Alexander
Lutz Donnerhacke
>Wenn ich mir eine neue PIX kaufe, ist automatisch Version 5.2 drauf. Daher
>haben die obigen Ausführung absolut keine Gültigkeit mehr.
Falsch.
>Version 4.x ist veraltet und buggy, keine Frage.
Falsch.
>Ich kann also die obigen Ausführungen in keinster Weise bestätigen. Dass
>man die Firewall-Software (egal welche Platform) auf dem aktuellsten Stand
>halten muss, versteht sich von selbst.
Falsch. Wenn Du der Meinung bist, die PIX wäre ideal, sollte dort die
Softwareversion 1.0 laufen. Wenn Du andere Versionen benutzen mußt, hast Du
einen Denkfehler begangen.
Alexander Apathy
Es wird dir jeder, der sich mit FWs auskennt bestätigen, dass statefull
inspection besser ist als "normales" packet filtering. Eine Firewall nach dem
ursprünglichen Programmieraufwand zu beurteilen halte ich außerdem für ein
schwaches Argument. Außerdem: die PIX ist gem. TTAP (Trust Technoloy Assessment
Program (TTAP), von der NSA und der ICSA zertifiziert. Das musst du mir bei
Linux+IPchains erst einmal zeigen ...
Open-Source ist sicher eine super Sache, das zeigt sich auch daran, dass die
Nokia FWs auf BSD Unix basieren. Allerdings ist das schon wieder soweit
angepasst und optimiert, dass mann nicht mehr von Open-Source sprechen kann.
Meine Einstellung gegen Linux als Basis-Plattform ist, dass sich ich da in der
Praxis schon negative Erfahrungen gemacht habe. Die Leute glauben, dass sie sich
mit ein paar How-to's und Anfänger-Wissen eine FW basteln können. Das halte ich
für eine grobe Fehler.
MfG, Alexander
Lutz Donnerhacke
>Es wird dir jeder, der sich mit FWs auskennt bestätigen, dass statefull
>inspection besser ist als "normales" packet filtering. Eine Firewall nach
>dem ursprünglichen Programmieraufwand zu beurteilen halte ich außerdem für
>ein schwaches Argument. Außerdem: die PIX ist gem. TTAP (Trust Technoloy
>Assessment Program (TTAP), von der NSA und der ICSA zertifiziert. Das
>musst du mir bei Linux+IPchains erst einmal zeigen ...
Was sagt das Zertifikat aus? Eben.
>Meine Einstellung gegen Linux als Basis-Plattform ist, dass sich ich da in
>der Praxis schon negative Erfahrungen gemacht habe. Die Leute glauben,
>dass sie sich mit ein paar How-to's und Anfänger-Wissen eine FW basteln
>können. Das halte ich für eine grobe Fehler.
Ja, Du wirst mit der Einstellung genau das gemacht haben. Glaubst Du Fefe
wäre das passiert?
Alexander Apathy
>
> Nein.
Was spricht denn deiner - hochwerten - Meinung nach gegen eine PIX? Oder bist du
nur gegen Cisco und meinst alles müsste Open-Source sein? Hast du mit PIX
überhaupt Erfahrung? Es gibt einen Haufen (großer) Firmen, die PIX einsetzen.
Die PIX ist anerkanntermaßen eine _sehr_ gute Firewall.
> Ah, hier kommen wir auf des Pudels Kern: Du hast es aus Unwissenheit
> mehrfach verkauft und möchtest dir jetzt einreden, daß das eine richtige
> Entscheidung war.
>
Das ist ein starkes Stück mir Unwissenheit vorzuwerfen - bin jetzt schwer
gekränkt ;-) Ich muss mir nicht einreden, dass es eine richtige Entscheidung
ist; sie _ist_ richtig.
>
> Alexander, du kannst das Feature ja noch nicht mal richtig buchstabieren,
> wie kannst du dir dann in irgendeiner Weise Kompetenz zutrauen, über
> Firewalls insgesamt zu schreiben?
>
Danke für den hinweis, schreibt man "stateful inspection". Das finde ich
kindisch von dir, aufgrund eines Tippfehlers auf meine Kompetenz Rückschlüsse zu
ziehen. Ich habe halt nicht den ganzen Tag Zeit, meine Rechtschreibung zu
checken.
> Ich rate jedenfalls lieber zu einer anständigen und klaren Installation
> als zu Stateful Inspection. Aber: auch Linux macht seit Jahren Stateful
> Inspection.
>
Da stimme ich dir zu. Es nützen dir die besten Features nichts, wenn nicht die
Basis stimmt. In dem ursprünglichen Thread in de.comp.os.unix.networking ging es
um SuSE Linx. Es ist daher nicht weit hergeholt anzunehmen, dass IPchains mit
dem SuSE-eigenen FW-Skript eingesetzt wird. Und IPchains ist definitiv nicht
stateful.
> > VPN etc.
>
> Auch VPN gibt es seit Jahren frei für Linux.
>
Ja, nur dass das wesentlich schwieriger zu implementiern ist, als auf einer PIX.
Das ist keine Vermutung, das weiß ich - leidvoll - aus der Praxis.
>
> Spezielle Betriebssysteme sind sicher(er)? Noch gröberer Unfug!
>
Jedenfalls muss ich viel mehr unternehmen, um ein Unix-System sicherer zu
machen, als beim PIX-OS, da es für firewalling optimiert wurde. Vor allem bei
SuSE Linux gibt es Lücken en masse.
> Deine eigentliche Aussage ist: schmeißt mir bitte weiter euer Geld in
> den Rachen und im Ausgleich vernebele ich euch anständig, damit ihr
> nicht zur Forbildung kommt und meine Müllaussagen hinterfragt oder gar
> versteht.
>
Das habe ich nie behauptet. Fortbildung ist sehr wichtig, denn was nützt dir die
beste FW, wenn du den Background nicht verstehst.
> Checkpoint ist auf allen Betrübssystemen schlecht.
>
So ein Blödsinn - Checkpoint auf Nokia performt hervorragend.
/alexander
Andreas Ender
Felix von Leitner schrieb:
>
> > Checkpoinst FW1 auf Unix ist natürlich ganz was anderes ;-)
>
> Checkpoint ist auf allen Betrübssystemen schlecht.
>
Wieso kommst du zu so einer Aussage?
Gibt es dafür Gründe ?
--
mit freundlichen Grüssen
Andreas Ender
Andreas Ender
Alexander Apathy schrieb:
> So ein Blödsinn - Checkpoint auf Nokia performt hervorragend.
>
Was hat den nun Perfomance mit Security zu tun.
Also ich kann mich da nur den anderen Meinungen anschliessen.
Du bist wahrscheinlich ein Verkäufer der die Marketingbroschüren
auswendig lernt ;-) (Nix für ungut)
Andreas Ender
Alexander Apathy schrieb:
> Meine Einstellung gegen Linux als Basis-Plattform ist, dass sich ich da in der
> Praxis schon negative Erfahrungen gemacht habe.
Linux ist keine Plattform, sondern nur ein KERNEL.
Und der eignet sich hervorragend für Firewalls.
Andreas Ender
Alexander Apathy schrieb:
> So ein Blödsinn - Checkpoint auf Nokia performt hervorragend.
>
Soviel ich weiss, lässt sich die Nokia per Webbrowser (HTTP nicht
HTTPS zumindest laut Datenblatt) administrieren.
Eine Remote-Administration ohne Verschlüsselung ist meiner
Meinung nach schon mehr als fahrlässig.
Das ist Performance kein Argument mehr.
Alexander Apathy
>
> Sagmal, bist Du der aus sicherheitsgruenden ungenannte Sicherheitsexperte
> aus der oesterreichischen "News" der behauptet hat, Trojaner wie Sub7 etc.
> waeren schwer zu entdecken?
>
> Die Cisco PIX kann nicht uneingeschraenkt empfohlen werden:
> http://www.cisco.com/warp/public/707/pixftp-pub.shtml.
> http://www.cisco.com/warp/public/707/pixtcpreset-pub.shtml
> http://www.cisco.com/warp/public/707/PIXfirewallSMTPfilter-pub.shtml
>
O.k. dafür gibt es schließlich die aktuellste Version 5.2.
> Das bekommt man mit freier Software besser hin.
>
Wobei man diese auch immer auf dem aktuellsten Stand halten muss.
/alexander
Charly Kuehnast
>> Checkpoint ist auf allen Betrübssystemen schlecht.
> Wieso kommst du zu so einer Aussage?
>
> Gibt es dafür Gründe ?
Die FW-1 hat ihre Macken. Sie konnte bis zur Version 3.0b unter
bestimmten Umstaenden sogar ftp-Verbindungen durcheinanderkegeln und
von innen durch gezieltes Vollmuellen der Connection Table bis
zum Pupillenstillstand ausgebremst werden. Die aktuelle Version hat
diese Macken allerdings nicht mehr, und wenn man sich mal von der
grafischen Oberflaeche loest und seine Finger direkt in den
InspectCode steckt, findet man durchaus ein maechtiges Instrument vor
- mit dem man sich aber auch recht gut in den Fuss schiessen kann.
Aus eigener Erfahrunge kann ich allerdings nur ueber die FW-1/Solaris
reden, auf anderen Plattformen hatte ich noch keine aktuelle FW-1 in
den Fingern.
Charly
Peter Maria Stirnberg
Alexander Apathy wrote:
> Da stimme ich dir zu. Es nützen dir die besten Features nichts, wenn
> nicht die Basis stimmt. In dem ursprünglichen Thread in
> de.comp.os.unix.networking ging es um SuSE Linx. Es ist daher nicht
> weit hergeholt anzunehmen, dass IPchains mit dem SuSE-eigenen
> FW-Skript eingesetzt wird. Und IPchains ist definitiv nicht stateful.
in dem ursprünglichen Thread ging es um die Frage: "Hardware"firewall
oder "Software"firewall und wenn Software, reicht dann SuSE. Deine
Aussage zu dem Thema war: Cisco PIX 506 ist besser und kann mehr als
"all das selbstgebastelete Linuxzeug" und ist wegem dem extra dafür
entwickelten OS als sicherer anzusehen. Und deswegen weht Dir hier
jetzt ein bischen Wind ins Gesicht. Immer hübsch auf dem Teppich
bleiben.
Gruss
Peter
--
Wegen des, extra für den ländlichen Bereich entwickelten MO(tors) ist
der neue Magirus-Traktor das sicherste Fortbewegungsmittel für das
Sauerland.
Alexander Apathy
Neue PIX 506 von der C2000 -> v. 5.2 compiled Sep 17/00 Anscheinend reden wir da
aneinander vorbei. Ich meine mit Version 5.2 das Softwareimage der PIX. Meines
Wissens ist das die aktuellste Verion.
http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_v52/ Kannst du mir
bitte begründen, warum du Version 1.0 für richtig hältst und v4.x nicht veraltet
und buggy sein soll?
/alexander
Alexander Schreiber
>Stefan Nobis wrote:
>>
>
>Es wird dir jeder, der sich mit FWs auskennt bestätigen, dass statefull
>inspection besser ist als "normales" packet filtering.
Darueber kann man sich gerne streiten solange man will. Fakt ist aber das
ein Firewall mit stateful filtering eine Verwundbarkeit mehr hat - ich kann
ihm die state tables volllaufen lassen ... und je nach Implementation
crasht die Kiste dann weil kein RAM mehr verfuegbar ist oder es koennen
zumindest erstmal keine weiteren Verbindungen aufgebaut werden (bis wieder
Platz in den state tables ist). Wenn man das durch wegwerfen ''alter''
Eintraege in den state tables vermeiden will: welche Eintraege wirft man
dann weg?
>Außerdem: die PIX ist gem. TTAP (Trust Technoloy Assessment
>Program (TTAP), von der NSA und der ICSA zertifiziert. Das musst du mir bei
>Linux+IPchains erst einmal zeigen ...
So eine Zertifizierung mag fuer rudimentaeres CYA reichen, aber ueber
die Praxistauglichkeit sagt sie nicht wirklich was aus.
>Meine Einstellung gegen Linux als Basis-Plattform ist, dass sich ich da in der
>Praxis schon negative Erfahrungen gemacht habe. Die Leute glauben, dass sie sich
>mit ein paar How-to's und Anfänger-Wissen eine FW basteln können. Das halte ich
>für eine grobe Fehler.
''Meine Einstellung gegen Autos als Transportmittel ist, dass ich da in der
Praxis schon negative Erfahrungen gemacht habe. Die Leute glauben sie koennten
mit ihrem gerade erworbenen Fuehrerschein nachts betrunken 180 km/h auf
der Landstrasse fahren. Das halte ich fuer einen groben Fehler.''
Eine Plattform zu verdammen nur weil auch Ahnungslose damit hantieren ist
IMHO reichlich unsachlich. Wenn Du Linux aus technischen Gruenden
ausschliessen wuerdest (''Kann kein $FOO, $FOO ist aber wichtig fuer unseren
Einsatzzweck''), ok, kein Thema. Aber so ist das arg duenn. Mit der
Argumentation landet naemlich auch Deine geliebte PIX ganz schnell auf der
Muellhalde ...
Man liest sich,
Alex.
--
------------------------------------------------------------------------------
EMail : a...@thangorodrim.de | WWW : http://www.thangorodrim.de/
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
Lutz Donnerhacke
>Kannst du mir bitte begründen, warum du Version 1.0 für richtig hältst und
>v4.x nicht veraltet und buggy sein soll?
Deine Behauptung, das Teil sei besser als alles andere impliziert Bugfreiheit.
Diese ist aber - wie die Versionsnummern zeigen - nicht gegeben. Warum
sollte 5.2 bugfrei sein?
Dietz Proepper
>als zu Stateful Inspection. Aber: auch Linux macht seit Jahren Stateful
>Inspection.
Unter 2.1? Unter 2.2?
Oder weckt gar der iptables-Code ein warmes, wohliges Gefühl der
Geborgenheit bei Dir?
Dietz
Helge Harder
news:slrn91ps6...@baileys.convergence.de...
[...]
> > aber die PIX macht statefull inspection,
> Alexander, du kannst das Feature ja noch nicht mal richtig buchstabieren,
> wie kannst du dir dann in irgendeiner Weise Kompetenz zutrauen, über
> Firewalls insgesamt zu schreiben?
>
> Ob Stateful Inspection grundsätzlich anzuraten ist, ist umstritten.
> Ich rate jedenfalls lieber zu einer anständigen und klaren Installation
> als zu Stateful Inspection. Aber: auch Linux macht seit Jahren Stateful
> Inspection.
>
> > VPN etc.
>
> Auch VPN gibt es seit Jahren frei für Linux.
>
> > und ist alleine schon deswegen und wegen des speziell dafür
> > entwickelten (I)OS als viel sicherer anzusehen, als (fast) jede
> > selbstgebastelte Low-Cost FW auf Unix-Basis.
>
> Was faselst du denn hier inkohärent Marketing-Müll nach?
> IOS ist speziell für die PIX entwickelt? Unfug!
> Spezielle Betriebssysteme sind sicher(er)? Noch gröberer Unfug!
>
> Deine eigentliche Aussage ist: schmeißt mir bitte weiter euer Geld in
> den Rachen und im Ausgleich vernebele ich euch anständig, damit ihr
> nicht zur Forbildung kommt und meine Müllaussagen hinterfragt oder gar
> versteht.
[...]
Felix, du kannst das Wort Fortbildung ja noch nicht mal richtig
buchstabieren,
wie kannst du dir dann in irgendeiner Weise Kompetenz zutrauen, über
Firewalls insgesamt zu schreiben? Nur mal so als Denkanstoß.
Helge
Felix von Leitner
> Neue PIX 506 von der C2000 -> v. 5.2 compiled Sep 17/00 Anscheinend reden wir da
> aneinander vorbei. Ich meine mit Version 5.2 das Softwareimage der PIX. Meines
> Wissens ist das die aktuellste Verion.
> http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_v52/ Kannst du mir
> bitte begründen, warum du Version 1.0 für richtig hältst und v4.x nicht veraltet
> und buggy sein soll?
Wenn eine Software uneingeschränkt empfohlen werden können soll, dann
muß sie in jeder Version getaugt haben. Ansonsten empfiehlst du nicht
die Software, sondern die spezielle Version. Hast du aber nicht.
Felix
Felix von Leitner
> Es wird dir jeder, der sich mit FWs auskennt bestätigen, dass statefull
> inspection besser ist als "normales" packet filtering.
Nein.
Ich kenne mich mit Firewalls aus und sage das Gegenteil.
> Eine Firewall nach dem ursprünglichen Programmieraufwand zu beurteilen
> halte ich außerdem für ein schwaches Argument.
Na besser als deine tollen Aussagen, die enthalten nämlich gar keine
Argumente.
> Außerdem: die PIX ist gem. TTAP (Trust Technoloy Assessment
> Program (TTAP), von der NSA und der ICSA zertifiziert. Das musst du mir bei
> Linux+IPchains erst einmal zeigen ...
Hahaha, hahahahahaha, haha, oh Mann. *wisch Tränen aus den Augen*
Tut mir leid, so dämlich kann doch gar keiner sein, oder?
Darauf antworte bitte jemand anderes, mir fällt nichts ein. Vielleicht
sollte man diese Aussage auch einfach so stehen lassen.
Als Mahnung für die Nachwelt oder so.
> Open-Source ist sicher eine super Sache, das zeigt sich auch daran, dass die
> Nokia FWs auf BSD Unix basieren.
Genau, genau _daran_ kann man das sicher prima erkennen.
Ein Glück, daß hier endlich mal ein echter Profi in der Newsgroup ist,
der uns das mal alles so richtig handfest erklären kann. Wir sind
nämlich hier alle die unbegründeten Dumpfschwall-Aussagen der
Marketing-Fuzzies leid, und dagegen hebst du dich mit deinen technisch
versierten und durch die Bank wohlbegründeten Aussagen ab. NOT!
> Allerdings ist das schon wieder soweit angepasst und optimiert, dass
> mann nicht mehr von Open-Source sprechen kann. Meine Einstellung
> gegen Linux als Basis-Plattform ist, dass sich ich da in der Praxis
> schon negative Erfahrungen gemacht habe. Die Leute glauben, dass sie
> sich mit ein paar How-to's und Anfänger-Wissen eine FW basteln können.
> Das halte ich für eine grobe Fehler.
Ah, fassen wir also zusammen: du warst zu dämlich, um das mit Linux
hinzukriegen, und findest PIX gut, weil es da so ein Klick-Interface für
Idioten gibt. Richtig?
Felix
Felix von Leitner
> > Nein.
> Was spricht denn deiner - hochwerten - Meinung nach gegen eine PIX?
1. ich habe keinen Quellcode
2. sie werben nicht mit Fakten, sondern mit Kinderkacke wie
irgendwelchen Pseudo-Zertifikaten
3. der Kram ist von irgendeiner drittklassigen Schrott-Klitsche
dazugekauft. Cisco macht das in letzter Zeit öfters und gerät
damit immer mehr in Miskredit. Und ihre Software haben sie dadurch
zunehmend weniger im Griff, weil der Überblick verlorengegangen
ist.
4. Es gab einige ausgesprochen peinliche Veröffentlichungen
PIX ist Kinderkram für Windoze-Klicki-Luser. Ernsthaft Sicherheit kann
man damit nicht betreiben.
> Oder bist du nur gegen Cisco und meinst alles müsste Open-Source sein?
Ich bin nicht gegen Cisco. Mit deren Aktien habe ich viel Geld
verdient. Und die haben ganz gute Router im Angebot. Aber Security
können sie halt nicht.
> Hast du mit PIX überhaupt Erfahrung?
Ja.
Ich mußte mich beherrschen, den Kunden nicht laut auszulauchen, daß er
sich derartigen Schrott hat andrehen lassen.
> Es gibt einen Haufen (großer) Firmen, die PIX einsetzen.
Diese Firmen setzen auch alle Windows ein und haben ihren Untergang
schon alleine deswegen verdient.
Millionen von Fliegen können nicht irren -- freßt Scheiße!
> Die PIX ist anerkanntermaßen eine _sehr_ gute Firewall.
Wer erkennt das an? Du?! Hahahaha. Beeindruckend.
> > Ah, hier kommen wir auf des Pudels Kern: Du hast es aus Unwissenheit
> > mehrfach verkauft und möchtest dir jetzt einreden, daß das eine richtige
> > Entscheidung war.
> Das ist ein starkes Stück mir Unwissenheit vorzuwerfen - bin jetzt schwer
> gekränkt ;-) Ich muss mir nicht einreden, dass es eine richtige Entscheidung
> ist; sie _ist_ richtig.
Na immerhin stehst du zu deinen Fehlentscheidungen.
Das ist doch schonmal was.
> Ich habe halt nicht den ganzen Tag Zeit, meine Rechtschreibung zu
> checken.
Und genug Zeit, um deine Aussagen oder gar frühere Entscheidungen zu
überdenken, hast du wohl auch nicht, wie?
> > Ich rate jedenfalls lieber zu einer anständigen und klaren Installation
> > als zu Stateful Inspection. Aber: auch Linux macht seit Jahren Stateful
> > Inspection.
> Da stimme ich dir zu. Es nützen dir die besten Features nichts, wenn nicht die
> Basis stimmt. In dem ursprünglichen Thread in de.comp.os.unix.networking ging es
> um SuSE Linx. Es ist daher nicht weit hergeholt anzunehmen, dass IPchains mit
> dem SuSE-eigenen FW-Skript eingesetzt wird. Und IPchains ist definitiv nicht
> stateful.
insmod ip_masq_ftp. Das ist stateful.
Oder sind dir die Begrifflichkeiten vielleicht nicht wirklich bekannt
und du meintest mehr als du gesagt hast?
> > > VPN etc.
> > Auch VPN gibt es seit Jahren frei für Linux.
> Ja, nur dass das wesentlich schwieriger zu implementiern ist, als auf einer PIX.
> Das ist keine Vermutung, das weiß ich - leidvoll - aus der Praxis.
Du hast "ich habe die Dokumentation nicht gelesen und da ist mir meine
Software auf den Fuß gefallen" sehr merkwürdig formuliert. Ich erinnere
mich schon gar nicht mehr an mein erstes Linux-VPN. Ich glaube, es war
1997 oder so.
> > Spezielle Betriebssysteme sind sicher(er)? Noch gröberer Unfug!
> Jedenfalls muss ich viel mehr unternehmen, um ein Unix-System sicherer zu
> machen, als beim PIX-OS, da es für firewalling optimiert wurde. Vor allem bei
> SuSE Linux gibt es Lücken en masse.
Na klar, wenn du Windows installierst, hast du keine Security.
Ob das jetzt Microsoft Windows oder SuSE Windows ist, spielt keine
Rolle.
Was hat das noch gleich mit Linux oder Firewalls zu tun?
> > Deine eigentliche Aussage ist: schmeißt mir bitte weiter euer Geld in
> > den Rachen und im Ausgleich vernebele ich euch anständig, damit ihr
> > nicht zur Forbildung kommt und meine Müllaussagen hinterfragt oder gar
> > versteht.
> Das habe ich nie behauptet. Fortbildung ist sehr wichtig, denn was nützt dir die
> beste FW, wenn du den Background nicht verstehst.
Genau. In diesem Sinne: bilde dich mal fort, damit du nie wieder
jemandem PIX empfehlen mußt.
> > Checkpoint ist auf allen Betrübssystemen schlecht.
> So ein Blödsinn - Checkpoint auf Nokia performt hervorragend.
Ah, auf dem Betrübssystem Nokia, ja? Keine weiteren Fragen, euer Ehren.
Im Übrigen: Wen interessiert die Performance?
Kannst dir ja gleich nen Switch kaufen, der ist noch viel schneller!
Felix
Alexander Apathy
Ihr habt recht - das war von mir falsch formuliert. Ich meinte nicht,
dass ich das uneingeschränkt empfehlen kann, denn Fehler wirds immer und
überall geben. Ich persönlich bin mit der PIX zufrieden. Wobei ich jetzt
nicht Werbung für Cisco machen möchte, falls das manche vielleicht so
verstanden haben. Es gibt natürlich auch genug andere gute Produkte...
/alexander
Alexander Apathy
>
>
> Genau, genau _daran_ kann man das sicher prima erkennen.
> Ein Glück, daß hier endlich mal ein echter Profi in der Newsgroup ist,
> der uns das mal alles so richtig handfest erklären kann. Wir sind
> nämlich hier alle die unbegründeten Dumpfschwall-Aussagen der
> Marketing-Fuzzies leid, und dagegen hebst du dich mit deinen technisch
> versierten und durch die Bank wohlbegründeten Aussagen ab. NOT!
>
Aber überheblich und großkotzig bist du gar nicht ...
>
> Ah, fassen wir also zusammen: du warst zu dämlich, um das mit Linux
> hinzukriegen, und findest PIX gut, weil es da so ein Klick-Interface für
> Idioten gibt. Richtig?
>
Ich konfiguriere die PIX grundsätzlich über die Kommandozeile, nicht
über das "Klick-Interface", wie du das bezeichnest ...
/alexander
Bernd Eckenfels
> Es wird dir jeder, der sich mit FWs auskennt bestätigen, dass statefull
> inspection besser ist als "normales" packet filtering.
Könnten wir die Begriffe Statefull Packet Filter bitte von Statefull
Inspection trennen? Das eine hat mit dem anderen nichts zu tun und das
andere ist vor allem Checkpint Marketingbla.
> Eine Firewall nach dem
> ursprünglichen Programmieraufwand zu beurteilen halte ich außerdem für ein
> schwaches Argument. Außerdem: die PIX ist gem. TTAP (Trust Technoloy Assessment
> Program (TTAP), von der NSA und der ICSA zertifiziert. Das musst du mir bei
> Linux+IPchains erst einmal zeigen ...
Was sagt diese Zertifizierung aus, ausser dass der Antagsteller die Gebühr
gezahlt hat? Das TTAP Programm bescheinigt der PIX eine beeindruckede
Sicherheit nach CC C2! Toll, das hat ein Windows Rechner auch (naja... mehr
oder weniger :)
http://www.radium.ncsc.mil/tpep/ttap/Process.html
> The Trust Technology Assessment Program (TTAP) is a joint National Security
> Agency (NSA) and National Institute of Standards
> (NIST) program to establish commercial facilities to perform trusted product
> evaluations _at_ _lower_ _levels_ _of_ _assurance_.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
oder:
http://www.cisco.com/warp/public/146/pressroom/1999/mar99/11.html
> confirming that the solution is compliant with the U.S.
> Government Traffic Filter Firewall for _Low_ _Risk_ _Environments_
> _Common_ _Criteria_ _Protection_ _Profile_.
> Meine Einstellung gegen Linux als Basis-Plattform ist, dass sich ich da in der
> Praxis schon negative Erfahrungen gemacht habe. Die Leute glauben, dass sie sich
> mit ein paar How-to's und Anfänger-Wissen eine FW basteln können. Das halte ich
> für eine grobe Fehler.
1. bist du ja nicht "Die Leute" und kannst es besser machen und 2. gibt es
ja wohl kaum einen Cisco Anwender der keine schlechte erfahrungen gemacht
hat.
Gruss
Bernd
Daniel Roesen
> Es wird dir jeder, der sich mit FWs auskennt bestätigen, dass statefull
> inspection besser ist als "normales" packet filtering. Eine Firewall
> nach dem ursprünglichen Programmieraufwand zu beurteilen halte ich
> außerdem für ein schwaches Argument.
Es geht nicht um den Aufwand, sondern um die Komplexitaet.
Du willst Dir mal im Bugtraq-Archiv das letzte PIX-Advisory
anschauen. Absolut alberner State-Machine-Fehler im SMTP-Inspector.
Und wenn Du ihn mal irgendwo finden solltest, schau mal in den
PIX-Source.
> Außerdem: die PIX ist gem. TTAP (Trust Technoloy Assessment
> Program (TTAP), von der NSA und der ICSA zertifiziert.
Diese Zertifizierung kannst Du Dir uebers Bett nageln. Zu mehr
ist sie nicht zu gebrauchen. Hoechstens als Indiz, dass die NSA
gerne sehen wuerde, dass Leute PIX kaufen. Und das sicherlich
nicht, weil sie die NSA effektiv aussperren wuerde.
Herrje sind Leute zertifikatsgeil...
> Das musst du mir bei Linux+IPchains erst einmal zeigen ...
Bei Linux zeige ich Dir den Source. Versuche mir ne Backdoor
nachzuweisen.
Dann zeigst Du mir irgendwas, was mir ermoeglicht, sicher zu
gehen, dass PIX keinerlei Backdoors fuer wen auch immer
enthaelt. Nein, Zertifikate gelten nicht.
Woraus ziehst Du eigentlich Dein blindes Vertrauen?
> Meine Einstellung gegen Linux als Basis-Plattform ist, dass sich ich
> da in der Praxis schon negative Erfahrungen gemacht habe. Die Leute
> glauben, dass sie sich mit ein paar How-to's und Anfänger-Wissen
> eine FW basteln können. Das halte ich für eine grobe Fehler.
Du solltest Dich mal etwas umsehen, welche Leute an FW1 und PIX
Configs rumklicken ohne auch nur den geringsten Plan zu haben was
sie da tun. Du schliesst vom Benutzer auf das Werkzeug. Fehler.
Daniel
Daniel Roesen
> > http://www.cisco.com/warp/public/707/pixftp-pub.shtml.
> > http://www.cisco.com/warp/public/707/pixtcpreset-pub.shtml
> > http://www.cisco.com/warp/public/707/PIXfirewallSMTPfilter-pub.shtml
> >
> O.k. dafür gibt es schließlich die aktuellste Version 5.2.
Erm, hattest Du nicht eben was von zertifizierter Sicherheit
gefaselt? War das nicht auch schon fuer Versionen <5.1?
> > Das bekommt man mit freier Software besser hin.
> Wobei man diese auch immer auf dem aktuellsten Stand halten muss.
Moment. Eben hast Du noch behauptet dass das generell
ueberhaupt nicht stimmen wuerde?!?
Alexander, Du verstrickst Dich herb in Widersprueche.
Daniel
--
Hallen-Einmarschmusik einer Microsoft Marketingveranstaltung:
Faithless - God is a DJ
"This is my church. This is where I heal my hurts."
Jens Dittmar
> Alexander Apathy <alex...@osiris.at> wrote:
>> Außerdem: die PIX ist gem. TTAP (Trust Technoloy Assessment Program
>> (TTAP), von der NSA und der ICSA zertifiziert. Das musst du mir bei
>> Linux+IPchains erst einmal zeigen ...
>
> Was sagt diese Zertifizierung aus, ausser dass der Antagsteller die
> Gebühr gezahlt hat?
Daß man bei der NSA daran interessiert ist, dieses Produkt in
flächendeckendem Einsatz zu sehen ... ;)
Jens
--
Is there anybody listening?
Is there anyone who smiles without a mask?
Joern Seemann
wrote:
>Aus eigener Erfahrunge kann ich allerdings nur ueber die FW-1/Solaris
>reden, auf anderen Plattformen hatte ich noch keine aktuelle FW-1 in
>den Fingern.
Die Software ist bis auf die Binaries auf allen Plattformen identisch.
Gruss Jörn
Frank Fiene
> Stefan Nobis wrote:
>
> Es wird dir jeder, der sich mit FWs auskennt bestätigen, dass statefull
> inspection besser ist als "normales" packet filtering. Eine Firewall nach
> dem ursprünglichen Programmieraufwand zu beurteilen halte ich außerdem für
> ein schwaches Argument. Außerdem: die PIX ist gem. TTAP (Trust Technoloy
> Assessment Program (TTAP), von der NSA und der ICSA zertifiziert. Das
> musst du mir bei Linux+IPchains erst einmal zeigen ...
Haha, NSA, das ich nicht lache.
Das waren doch die, die den Clipper-Chip in den USA einführen lassen
wollten.
Ein Produkt, welches Hardware-Ver- und Entschlüsselung in hoher
Geschwindigkeit ausführen sollte mit einer annehmbraen Schlüssellänge.
Wie gut, dass das Ding Backdoors hatte, damit man wegen der nationalen
Sicherheit bla bla bla.
Die NSA zertifiziert gerne Systeme, die sie einfach knacken kann. Wobei ich
mich überhaupt frage, welche Systeme sie nicht knacken kann.
Frank
--
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
Frank Fiene
Frank Fiene
> Felix von Leitner wrote:
> > > VPN etc.
> >
> > Auch VPN gibt es seit Jahren frei für Linux.
> >
> Ja, nur dass das wesentlich schwieriger zu implementiern ist, als auf
> einer PIX. Das ist keine Vermutung, das weiß ich - leidvoll - aus der
> Praxis.
FreeS/WAN ist schwierig zu implementieren? Aha. Ist mir noch nicht
aufgefallen. Oder welche VPN Lösung meinst du, ssh, ...?
Also FreeS/WAN deckt zwar nur das Minimum des RFC (es fehlt z.B. der
Aggressive Mode bei der ersten Phase des Schlüsselaustausches, aber der ist
ja auch mit DOS-Attacken angreifbarer als der Main-Mode, weil immer die
Private und Public Keys erzeugt werden, aber egal), aber ist einfach zu
konfigurieren, OpenSource und funktioniert.
> > Spezielle Betriebssysteme sind sicher(er)? Noch gröberer Unfug!
> >
> Jedenfalls muss ich viel mehr unternehmen, um ein Unix-System sicherer zu
> machen, als beim PIX-OS, da es für firewalling optimiert wurde. Vor allem
> bei SuSE Linux gibt es Lücken en masse.
Meinst du, weil man in der PIX weniger Einstellungen machen, also verhauen,
kann, ist das OS besser? Du weißt doch gar nicht, was das OS macht, und
kennst niemanden der das System analysiert hat! Ohne Source-Code geht das
wohl schlecht.
> > Checkpoint ist auf allen Betrübssystemen schlecht.
> >
> So ein Blödsinn - Checkpoint auf Nokia performt hervorragend.
Hier geht es nicht um Performance. Wir haben auch leider Checkpoint im
Einsatz, unter NT und Linux, das läuft stabil und schnell, aber ich muss
Felix Recht geben, wenn er sagt: Kein Source: keine Sicherheit. Die
Firewall-Systeme scheinen sicher zu sein, VPN funktioniert auch. Aber es
hat vielleicht auch noch niemand versucht, einzubrechen? Und der Mossad hat
vielleicht nicht soviel Geldmittel wie die NSA, aber bestimmt gute
Mathematiker, die den israelischen Firmen ihre Gesetze aufzwingen.
Stefan Nobis
> Es wird dir jeder, der sich mit FWs auskennt bestätigen, dass statefull
> inspection besser ist als "normales" packet filtering. Eine Firewall nach dem
Na ja, dann kenne ich mich wohl nicht aus. Aber meiner dümmlichen und naiven
Meinung nach steigt mit der Komplexität eines Systems auch die Fehlerrate. Und
ob nun das Regelsystem sehr simpel und übersichtlich und dafür der
Regelinterpreter komplex und umfangreich ist (-> stateful inspection) oder ob
es sich genau umgekehrt verhält (-> stateless inspection) ist für die
Situation im Gesamtsystem eher uninteressant.
Man kann natürlich anführen, dass der Regelinterpreter nur einmal entwickelt
und fehlerfrei gemacht werden muss, während man die Regeln für das System sehr
viel häufiger manipuliert (und an sehr viel mehr Stellen). Das berührt aber
mehr die Handhabbarkeit/Usability (für den Firewall-Admin wird's vielleicht
leichter), aber das Gesamtsystem ist und bleibt komplex. Hinzu kommt, dass es
bei einem komplexen Interpreter sehr viel leichter zu
(unerwarteten/unerwünschten) Seiteneffekten kommt als bei einem sehr simplen,
geradlinigen Interpreter.
Insofern halte ich deine Ansicht zumindest für fragwürdig, zumal ernsthafte
Firewalls ganz sicher nicht ausschließlich aus Paketfiltern bestehen, sondern
diese nur ein kleiner Teil der gesamten Firewall darstellen.
> ursprünglichen Programmieraufwand zu beurteilen halte ich außerdem für ein
> schwaches Argument. Außerdem: die PIX ist gem. TTAP (Trust Technoloy
> Assessment
Wieso? Könntest du deine Meinung auch irgendwie mit sachlichen Argumenten
begründen oder ist einfach so ein Bauchgefühl?
> Program (TTAP), von der NSA und der ICSA zertifiziert. Das musst du mir bei
> Linux+IPchains erst einmal zeigen ...
Na ja, was heute so alles zertifiziert wird... aber OK, das ist ein Punkt.
> Meine Einstellung gegen Linux als Basis-Plattform ist, dass sich ich da in
> der Praxis schon negative Erfahrungen gemacht habe. Die Leute glauben, dass
> sie sich mit ein paar How-to's und Anfänger-Wissen eine FW basteln
> können. Das halte ich für eine grobe Fehler.
Das ist ein *Grundproblem* und mitnichten linuxspezifisch.
--
Until the next mail...,
Stefan.
Felix von Leitner
> >Aus eigener Erfahrunge kann ich allerdings nur ueber die FW-1/Solaris
> >reden, auf anderen Plattformen hatte ich noch keine aktuelle FW-1 in
> >den Fingern.
> Die Software ist bis auf die Binaries auf allen Plattformen identisch.
Das war ja die Aussage des Monats!
Aus was besteht das denn neben den Binaries?
Man Pages? _Grins_
Fefe
Jonas Luster
> >Aus eigener Erfahrunge kann ich allerdings nur ueber die FW-1/Solaris
> >reden, auf anderen Plattformen hatte ich noch keine aktuelle FW-1 in
> >den Fingern.
>
> Die Software ist bis auf die Binaries auf allen Plattformen identisch.
Falsch!
jonas
--
Hey, that was my vote you dropped there. Vote Nader!
Rainer Weikusat
> Felix von Leitner wrote:
> >als zu Stateful Inspection. Aber: auch Linux macht seit Jahren Stateful
> >Inspection.
>
> Unter 2.1? Unter 2.2?
Quizfrage: Wenn ich irgendwo einen Rechner stehen habe, der auschließlich
ftp maskiert, was muß der dazu wohl tun?
--
SIGSTOP
Dietz Proepper
Quizantwort: unter stateful stell' ich mir was anderes als masq_ftp
vor.
Dietz
Rainer Weikusat
> >Quizfrage: Wenn ich irgendwo einen Rechner stehen habe, der auschließlich
> > ftp maskiert, was muß der dazu wohl tun?
>
> Quizantwort: unter stateful stell' ich mir was anderes als masq_ftp
> vor.
Was Du Dir vorstellst, ist mir, solange Du es nicht für nötig hälst,
mir das auch mitzuteilen, herzlich wurscht.
--
SIGSTOP
Bernd Eckenfels
> Die Software ist bis auf die Binaries auf allen Plattformen identisch.
Mit Ausnahme des Netzwerklayers, und genau die sind unter NT ein grosses
Problem (NIDS), da diese zu sehr von den Kartentreibern (Herstellern)
abhaengen.
Oder wie macht das die Firewall sonst an die Pakete dranzukommen?
Gruss
Bernd
Bernd Eckenfels
> Quizantwort: unter stateful stell' ich mir was anderes als masq_ftp
> vor.
du wirst es nicht glauben, das state modul aller gaengigen kommerziellen
firewalls tut nicht mehr als ein normales masquerading. Kein Sequenze
nummern Check, kein window Abgleich, kein Reassembly nichts (oder nur sehr
eingeschränkt!)
Bei ICMP ist es noch viel schlimmer, da muss man erst mal seine eigenen
Scripten schreiben dass es was tut (zumindest bei aeltereen FW1s).
Das hat mich auch sehr erschreckt. Ich verspreche mir sehr viel von
iptables/netfilter.
Gruss
Bernd
Michael Koehne
> Insofern halte ich deine Ansicht zumindest für fragwürdig, zumal ernsthafte
> Firewalls ganz sicher nicht ausschließlich aus Paketfiltern bestehen, sondern
> diese nur ein kleiner Teil der gesamten Firewall darstellen.
Moin Guru's,
zunaechstermal mag ich die urspruengliche frage mit !JA! beantworten.
Ein Router routet, ein Server bietet Services an, an einer Workstation
sollte gearbeitet werden. Aber Services auf nem Router oder ner Station
sind igit.
Erst recht wenn der router sich mit dem beiwort firewall schmueckt.
In dieser hinsicht sind so manche Linux-Firewalls die als shared host
implementiert sind, und neben routing/masq auch proxies relays und
services anbieten genauso sicher, wie die in dieser liste gern
belaesterten Personal-Windoof-Firewalls !
Ein firmennetz mit firewall sollte folgende structur haben :
InterNet <-> FW-Router <-> DMZ-Server <-> FW-Router <-> IntraNet
Aber !
Die FW-Router muessen nicht unter IOS laufen. Ein Linux rechner ohne
festplatte, mit schreibgeschuetzter boot disk, und serieller console
ist genauso sicher als router. Und hat die vorteile als bastelloesung
weniger zu kosten, wenn die kosten fuer personal ignoriert werden.
Fuer zuhause oder das eigene buero, wuerde ich also den Linux-FW-Router
bevorzugen, waerend ich einem kunden die CISCO hinstellen wuerde, weil
"auspacken/einschalten/rechnung" ergibt ne saubere "schluesselfertige
loesung" fuer die gut bezahlt wird, waerend das selbstgebasteltet selten
mit vollem stundensatz in rechnung gehen kann.
Bye Michael
--
mailto:kra...@copyleft.de UNA:+.? 'CED+2+:::Linux:2.2.17'UNZ+1'
http://www.xml-edifact.org/ CETERUM CENSEO WINDOWS ESSE DELENDAM
Thomas Seck
[...]
> Fuer zuhause oder das eigene buero, wuerde ich also den Linux-FW-Router
> bevorzugen, waerend ich einem kunden die CISCO hinstellen wuerde, weil
> "auspacken/einschalten/rechnung" ergibt ne saubere "schluesselfertige
> loesung" fuer die gut bezahlt wird, waerend das selbstgebasteltet selten
> mit vollem stundensatz in rechnung gehen kann.
Ähem, du verkaufst bewußt Systeme, die "problematisch" sind? Nur weil
man das besser in Rechnung stellen kann? Na, danke.
Grüße,
Thomas Seck
--
Theoretisch gibt es keinen Unterschied zwischen Theorie und Praxis.
Jonas Luster
> > "auspacken/einschalten/rechnung" ergibt ne saubere "schluesselfertige
> > loesung" fuer die gut bezahlt wird, waerend das selbstgebasteltet selten
> > mit vollem stundensatz in rechnung gehen kann.
>
> Ähem, du verkaufst bewußt Systeme, die "problematisch" sind? Nur weil
> man das besser in Rechnung stellen kann? Na, danke.
Was ist an einer PIX als Packetfilter problematisch (post 5.1.9?)
Thomas Seck
Jonas Luster <lo...@netwarriors.org> schreibt:
> Thomas Seck <tms...@web.de> writes:
>
> > > "auspacken/einschalten/rechnung" ergibt ne saubere
> > > "schluesselfertige loesung" fuer die gut bezahlt wird, waerend
> > > das selbstgebasteltet selten mit vollem stundensatz in
> > > rechnung gehen kann.
> >
> > Ähem, du verkaufst bewußt Systeme, die "problematisch" sind? Nur weil
> > man das besser in Rechnung stellen kann? Na, danke.
>
> Was ist an einer PIX als Packetfilter problematisch (post 5.1.9?)
Das Eis einer grundsätzlichen Diskussion über "Firewalls-in-a-box" ist
mir zu dünn (ich muss auch niemanden ausser mir und meinen Vorturnen
beraten, geschweige denn, irgendwas verkaufen). Ich schliesse mich
aber Fefes grundsätzlichen Bedenken aus
<slrn91qdr...@baileys.convergence.de> an, deswegen die
Tüddelchen.
Grüße,
Thomas Seck
--
Die Erzeugung von Zufallszahlen darf man nicht dem Zufall überlassen.
Jonas Luster
> > > Ähem, du verkaufst bewußt Systeme, die "problematisch" sind? Nur weil
> > > man das besser in Rechnung stellen kann? Na, danke.
> >
> > Was ist an einer PIX als Packetfilter problematisch (post 5.1.9?)
>
> Das Eis einer grundsätzlichen Diskussion über "Firewalls-in-a-box" ist
> mir zu dünn (ich muss auch niemanden ausser mir und meinen Vorturnen
> beraten, geschweige denn, irgendwas verkaufen). Ich schliesse mich
> aber Fefes grundsätzlichen Bedenken aus
> <slrn91qdr...@baileys.convergence.de> an, deswegen die
> Tüddelchen.
,----[ fefe ]
|
| 1. ich habe keinen Quellcode
| 2. sie werben nicht mit Fakten, sondern mit Kinderkacke wie
| irgendwelchen Pseudo-Zertifikaten
| 3. der Kram ist von irgendeiner drittklassigen Schrott-Klitsche
| dazugekauft. Cisco macht das in letzter Zeit öfters und gerät
| damit immer mehr in Miskredit. Und ihre Software haben sie dadurch
| zunehmend weniger im Griff, weil der Überblick verlorengegangen
| ist.
| 4. Es gab einige ausgesprochen peinliche Veröffentlichungen
|
| PIX ist Kinderkram für Windoze-Klicki-Luser. Ernsthaft Sicherheit kann
| man damit nicht betreiben.
|
| > So ein Blödsinn - Checkpoint auf Nokia performt hervorragend.
|
| Ah, auf dem Betrübssystem Nokia, ja? Keine weiteren Fragen, euer Ehren.
|
`----
Ich habe FeFes letzten Satz da auch noch mal stehen lassen, weil er
dosch sehr schoen den Gesamtumfang des Postngs
widerspiegelt. Zugegeben ist das FreeBSD 2.6 unter dem die Nokia
Checkpoint laufen hat nicht besonders der Hammer, aber Polemik und
Haehme sind zumindest ebenso grosse Feinde der Sicherheit wie es
Unwissenheit oder Selbstueberschaetzung sind.
Zu 1 = recht hat er, der FeFe - er hat keinen Quellcode. Den hat er zu
den OSS-Unix-Firewalls und ein paar anderen, kleinen,
Firewallprojekten. Den hat er schon nicht mehr zu dem Switch-OS davor,
dem Router der unabdingbar auch davor lauert, zum BIOS in seiner
Netzwerkkarte, etc. Ich vertrete durchaus die Ansicht, dass der
Quellcode besser verfuegbar ist, generelle Sicherheitsbedenken habe
ich auch wenn ich den Sourcecode nicht kenne, daraus aber die
generelle Sicherheit einen Systems ableiten zu wollen ist sehr arglos
- und deshalb gehoert es nicht in die Liste oben.
Zu 2 = Wer Werbung glaubt ist selbst schuld. Oder glaubt man Theo de
Raadts Werbung fuer OpenSSH? Nein, tut man nicht. Man wirft das
Produkt aber auch nicht aus dem Fenster, nur weil Theo Scheisse labert
und manchmal recht gut darin ist.
Zu 3 sage ich nicht viel ausser dass es falsch ist. Der Griff und die
Schrottklitsche.
Zu 4: Ja, die gab es.
das Fazit kann nur von Jemandem kommen, der sich gerne reden hoert und
mit lautstarken Wortmalereien impregnieren will. Robin Socha konnte
das beliebig besser, FeFe muss da noch viel lernen.
Gerade aeltere PIX-Versionen (die unsaeglichen 4.x mit dem
Buffer-Problem, die 5.0.1(deployment).x mit dem netten failover poll
bug die Fragmentation_errors in 4.x) hatten und haben Bugs, die man
kennen muss - und Jeder der sich die Arbeit macht, die Jeder machen
sollte der Entscheidungsgewalt oder Empfehlungsgewalt hat kennt die,
der hat ja ein Auditing hinter sich und ein paar Tage hardcore-tests.
Was FeFe bisher nicht gelungen ist, ist mir ein Bild zu malen wie er
mit Firewalls, die seinen Anspruechen genuegen, die Ziele die ein
Unternehmen der Groesse n (wobei n > dot.com-Klitsche) abbilden und
befriedigen will.
Jonas Luster
> * Jonas Luster <lo...@netwarriors.org> wrote:
> >Thomas Seck <tms...@web.de> writes:
> >> Ähem, du verkaufst bewußt Systeme, die "problematisch" sind? Nur weil
> >> man das besser in Rechnung stellen kann? Na, danke.
> >Was ist an einer PIX als Packetfilter problematisch (post 5.1.9?)
>
> Lies doch mal Bugtraq.
Tu' ich konstant. Die Frage ist nach dem Packetfilter - und abgesehen
von Versionen pre 5.1.9 (pre-SSH) und deren Frag-Problem kenne ich
Keine Probleme mit dem packetfilter-Mechanismus - und das obwohl ich
bash-2.04$ ls | grep .PIX | wc -l
2146
mit ein paar PIXen ab und zu zu tun habe.
Felix von Leitner
> Was ist an einer PIX als Packetfilter problematisch (post 5.1.9?)
Wie, das weißt du nicht?
Hast du es nicht selber im Quellcode gesehen?
Felix
Jonas Luster
> Richtig, er zeigt jemandem, der ganz offensichtlich nicht mehr als die
> Werbeprospekte von sich gibt eben, dass er besser lesen statt schreiben
> sollte, wenn es um dieses Thema geht.
>
> > Zugegeben ist das FreeBSD 2.6 unter dem die Nokia
> >Checkpoint laufen hat nicht besonders der Hammer, aber Polemik und
> >Haehme sind zumindest ebenso grosse Feinde der Sicherheit wie es
> >Unwissenheit oder Selbstueberschaetzung sind.
>
> Du willst Felix "Unwissenheit" und/oder "Selbstueberschaetzung"
> unterstellen? Alleine der erste Punkt den er nennt, reicht doch schon.
Nein, Polemik und Haehme. Destruktivismus. Ich bin gerne bereit Stuff
zu dissen, wenn ich dafuer eine bessere Loesung anbieten kann. Wenn
ich das nicht (mehr) kann, dann lasse ich es im Allgemeinen mit der
Haehme und dem polemischen Ansatz.
> Security by obscurity hat naemlich mit Sicherheit auch nichts zu tun.
> Und genau das hast Du bei einer Pix.
Nein, die Obscurity dient nicht der Security - und das ist auch nicht
die Intention. Nochmal, auch fuer Dich: Ich bin kein Fan von closed
source, ich bin kein Fan von Cisco und das TAC-Team dort hasst mich
und hat meine Caller-ID im Filter. Ich bin nicht bereit, eine Lanze
fuer Cisco's PIX zu brechen, im Augenblick stellt sie jedoch eine der
ganz wenigen Loesungen dar, die man ab einer gewissen Datenmenge und
Groesse einsetzen kann. Mit Destruktivismus erreicht man aber gerade
in der Welt der Security gar nix (in Zahlen: 0). Und genau das ist
vormals von mir referenzierter Artikel.
[Fw-1 und PIX]
> Bei denen kannst Du nichtmal einschaetzen, wie ernst sie zu nehmen sind.
Richtig. Welche Firewall kannst Du denn ernst nehmen? Ich frage in
meinem Ursprungsartikel "Welche Probleme siehst Du denn..." - als
Antwort bekomme ich die Message-ID einer Liste warum man PIX nicht
einsetzen will, die bestenfalls als destruktive Polemik zu werten ist.
> > Den hat er schon nicht mehr zu dem Switch-OS davor,
>
> Der dient auch nicht als Paketfilter.
Sicherheit hoert nicht am Paketfilter auf, besser noch: sie sollte den
Paketfilter nicht einmal als wichtigstes Bestandteil ansehen.
> >dem Router der unabdingbar auch davor lauert, zum BIOS in seiner
> >Netzwerkkarte, etc.
>
> Achso. Du meinst, wenn man das schon nicht hat, dann ist es auch egal,
> wie unsicher der Rest ist?
Nein, aber Du implizierst die Unsicherheit einer Firewall aus derem
'closed source'-Modell. Es ist natuerlich mir und Dir nicht moeglich,
genau zu sagen wie sicher oder unsicher diese Firewall nun ist - aber
die PIX besteht aus hard- und Software und zumindest 50% dieser
Komponenten kennst Du in Deiner Aplpha, i386 oder SPARC auch nicht -
bist aber geren bereit das OSS-Teilchen auf diesen Kisten als
'geeigneter' und 'sicherer' einzuschaetzen?
> >generelle Sicherheit einen Systems ableiten zu wollen ist sehr arglos
> >- und deshalb gehoert es nicht in die Liste oben.
>
> Es ist ein unwiederlegbares Argument.
ACK. Wenn man Destruktivismus betreiben will. Wenn man konstruktiv
sein will, muss man zuerst einmal bessere Moeglichkeiten aufzaehlen
koennen und die Unzulaenglichkeiten bis auf's Haar nennen
koennen. Beides ist nicht geschehen, deshalb irrelevant.
> Leider erfaehrt man davon eher zu spaet als frueh genug. Und was bringt
Wieso? So ziemlich jeden Bug der PIX haben wir im Lab gefunden bevor
die PIX-Version auch nur an den Start ging. TAC-case, drei Anrufe bei
einem Cisco VP (Brett Shockley, Telefonnumer hat man, wenn man bei
Cisco direkt kauft) und Du hast eine gefixete Version. Das ich den
Source-Code nicht habe ist hinderlich aber sollte Jemanden, der seinen
Job ernst nimmt, nicht davon abhalten die Bugs zu finden und zu
fixen/fixen zu lassen.
> dich zu der Ueberzeugung, dass DU mit einer aktuellen Pix weniger
> Probleme haben wirst?
Die Tatsache das von Allen PIXen, die meine Gruppe betreut genau 2
jemals ihn Ausuebung ihrer Dienste versagt haben. Klar, ich muss Wege
gehen um etwas gefixed zu bekommen oder einen Audit ueber den
Quellcode, aber genau das muss Otto-Normal-Netzsite auch, denn die
haben niemanden der mal eben schnell den Source zu einer OSS-Kiste
audited und dem sie vertrauen koennen.
> >Was FeFe bisher nicht gelungen ist, ist mir ein Bild zu malen wie er
> >mit Firewalls, die seinen Anspruechen genuegen, die Ziele die ein
> >Unternehmen der Groesse n (wobei n > dot.com-Klitsche) abbilden und
> >befriedigen will.
>
> Wo siehst Du das Problem?
Das ich lieber konstruktiv bin? PIXe stellen nicht einmal eine
Minoritaet unter den Systemen dar, die als Firewall irgendwas mit mir
zu tun haben, die Maioritaet ist immer noch Open Source Firewall
Software auf einer Hardware die ich - incl. BIOS der Komponenten -
kenne. Aber PIXe als generell Scheisse abzutun ist erst dann
erfolgreich wenn man a) Alternativen bieten kann und b) es genau
belegen kann.
Michael Koehne
>> Fuer zuhause oder das eigene buero, wuerde ich also den Linux-FW-Router
>> bevorzugen, waerend ich einem kunden die CISCO hinstellen wuerde, weil
>> "auspacken/einschalten/rechnung" ergibt ne saubere "schluesselfertige
>> loesung" fuer die gut bezahlt wird, waerend das selbstgebasteltet selten
>> mit vollem stundensatz in rechnung gehen kann.
> Ähem, du verkaufst bewußt Systeme, die "problematisch" sind? Nur weil
> man das besser in Rechnung stellen kann? Na, danke.
ne ich bin programmierer nicht verkaeufer. Ich bastel lieber die loesung
die mir gefaellt, die aber dann eigendlich keiner in DM bezahlen kann ;-(
Aber das "auspacken/einschalten/rechnung" ist realitaet. Mit nem Linux
PC-Router laesst sich keine marge machen. Mit ner CISCO schon. Frag mal
nen verkaeufer (nach 3-5 bier) warum eigenlich so haeufig Oracle bei
anwendungen eingesetzt wird fuer die eine SDBM oder MySQL ausreichen
wuerde, ja sogar sinniger ist, weil die daten ins RAM passen. Die antwort
ist aehnlich. Oracle ist ein markenproduct mit einer kalkulierbaren
gewinnspanne, waerend die selbstgebastelte MySQL loesung keine gewinnspanne
bietet, weil sie umsonst ist. - lieber 30% von 50kDM, als 100% von 0DM.
Ich seh den linux router erst dann aus der bastler ecke verschwinden,
wenns den als "auspacken/einschalten/rechnung" fuer DM1000 wahlweise als
1"x19" oder anrufbeantwortergross fuern desktop gibt. Wichtig ist das
die kiste mit speziellen bauteilen ausgeruestet ist. Zusaetzliches RAM,
SAN-DISK, Ethernet, ..., muessen richtig speziell und teuer sein damit
sich die 20%-35% des haendlers lohnen ;-)
Bye Michael
PS : Und wer jetzt bugtraq zitiert kann auch die kernel mailing liste
gegenstellen. " It will trash but it won't lockup. " 2.2.18pre21
heist hoffen auf 2.2.19. Das vm problem zieht sich schon seit
2.2.14 durch die stabilen kernel.
Thomas Seck
> Thomas Seck <tms...@web.de> wrote:
> >> Fuer zuhause oder das eigene buero, wuerde ich also den Linux-FW-Router
> >> bevorzugen, waerend ich einem kunden die CISCO hinstellen wuerde, weil
> >> "auspacken/einschalten/rechnung" ergibt ne saubere "schluesselfertige
> >> loesung" fuer die gut bezahlt wird, waerend das selbstgebasteltet selten
> >> mit vollem stundensatz in rechnung gehen kann.
>
> > Ähem, du verkaufst bewußt Systeme, die "problematisch" sind? Nur weil
> > man das besser in Rechnung stellen kann? Na, danke.
>
> ne ich bin programmierer nicht verkaeufer. Ich bastel lieber die loesung
> die mir gefaellt, die aber dann eigendlich keiner in DM bezahlen kann ;-(
>
> Aber das "auspacken/einschalten/rechnung" ist realitaet. Mit nem Linux
> PC-Router laesst sich keine marge machen.
[...]
Tja, sieht aus, als waere meine Abneigung gegen sales droids mal
wieder auf allerbeste bestaetigt worden.
> PS : Und wer jetzt bugtraq zitiert kann auch die kernel mailing liste
> gegenstellen. " It will trash but it won't lockup. " 2.2.18pre21
> heist hoffen auf 2.2.19. Das vm problem zieht sich schon seit
> 2.2.14 durch die stabilen kernel.
Es gibt auch andere OS'se als Linux... ;-)
Gruesse,
Thomas Seck
--
Ein wirklich weiser Mann spielt mit einem Einhorn nicht Bockspringen.
Robin S. Socha
> Was FeFe bisher nicht gelungen ist, ist mir ein Bild zu malen wie er
> mit Firewalls, die seinen Anspruechen genuegen, die Ziele die ein
> Unternehmen der Groesse n (wobei n > dot.com-Klitsche) abbilden und
> befriedigen will.
Schön, dass Du Dich noch für etwas begeistern kannst. Schade, dass
dabei vor allem "Security by ich-hab-ganz-viel" oder "Security by
ich-kenn-da-jemand-den-ich-anrufen-kann" herauskommt. Ursprünglich
ging es übrigens darum, dass der junge Herr aus Österreich exakt
diesen .com-Klitschen PIXes verkaufen wollte; seine Begründung war,
dass OSS kein statefull irgendwas und kein VPN kann. Wenn Du für 5m
mal von Deinem Ego-Surftrip runterkommst, kannst Du ja mal einen
qualifizierten und überprüfbar begründeten Kommentar dazu abgeben,
warum die .com-Klitsche die PIX kaufen sollte.
Stefan Nobis
> ,----[ fefe ]
> |
> | 1. ich habe keinen Quellcode
> | 2. sie werben nicht mit Fakten, sondern mit Kinderkacke wie
> | irgendwelchen Pseudo-Zertifikaten
> | 3. der Kram ist von irgendeiner drittklassigen Schrott-Klitsche
> | dazugekauft. Cisco macht das in letzter Zeit öfters und gerät
> | damit immer mehr in Miskredit. Und ihre Software haben sie dadurch
> | zunehmend weniger im Griff, weil der Überblick verlorengegangen
> | ist.
> | 4. Es gab einige ausgesprochen peinliche Veröffentlichungen
> |
> | PIX ist Kinderkram für Windoze-Klicki-Luser. Ernsthaft Sicherheit kann
> | man damit nicht betreiben.
> |
> | > So ein Blödsinn - Checkpoint auf Nokia performt hervorragend.
> |
> | Ah, auf dem Betrübssystem Nokia, ja? Keine weiteren Fragen, euer Ehren.
> |
> `----
>
> Ich habe FeFes letzten Satz da auch noch mal stehen lassen, weil er
> dosch sehr schoen den Gesamtumfang des Postngs
> widerspiegelt. Zugegeben ist das FreeBSD 2.6 unter dem die Nokia
Vielleicht hättest du den Kontext genauer ansehen sollen. Es ging ursprünglich
vor allem darum, dass PIX als Firewall "uneingeschränkt" empfehlenswert
sei. Und dann kam u.a. der Einfwurf (merke, es ging eigentlich um
Sicherheitsfragen), dass Checkpoint auf Nokia hervorragend performt. Und das
ist dermaßen am Thema vorbei, dass IMHO die Polemik von FeFe durchaus ihre
Rechtfertigung findet (es ging ja nicht gegen FreeBSD, sondern sollte
vermutlich einfach die Unwissenheit und schlampigen Formulierungen der Posters
herausstellen).
Und ein anderer Punkt: Eine Software oder ein System, dass in der
Vergangenheit dermaßen viele Probleme aufgeworfen hat, soll nun plötzlich der
Renner sein? Sorry, aber ich muss gestehen, dass ich da doch etwas
zurückhaltender bin.
Damit will ich jetzt nicht Linux oder BSD Firwalls in den Himmel loben, die
haben ganz sicher auch ihre Probleme (ganz besonders Linux -- ich stecke mein
Vertrauen schließlich nicht blind in eine extrem neue und frische
Implementierung, zumal, wenn man mitbekommt, wie chaotisch die Entwicklung da
teilweise ist).
Ich denke, der Kern ist doch einfach, dass man, egal welchen, Lösungen nicht
einfach sein Vertrauen schenkt, sei es, weil es so cool ist, weil es von einem
bestimmten Hersteller kommt oder warum auch immer, sondern dass man *immer*
kritisch an die Sache herangehen sollte.
Dietz Proepper
>Dietz Proepper <dietz...@rotfl.franken.de> wrote:
>> Quizantwort: unter stateful stell' ich mir was anderes als masq_ftp
>> vor.
>
>du wirst es nicht glauben, das state modul aller gaengigen kommerziellen
>firewalls tut nicht mehr als ein normales masquerading. Kein Sequenze
>nummern Check, kein window Abgleich, kein Reassembly nichts (oder nur sehr
>eingeschränkt!)
Ich glaub's schon. Aber das steht nicht im Widerspruch zu
oben. Bedenke, Quizsituation ,)
>Bei ICMP ist es noch viel schlimmer, da muss man erst mal seine eigenen
>Scripten schreiben dass es was tut (zumindest bei aeltereen FW1s).
yukk. Ich bin FW1 nie näher als 2 hops gekommen. U.a. aus solchen
Gründen.
>Das hat mich auch sehr erschreckt. Ich verspreche mir sehr viel von
>iptables/netfilter.
Hmm, weiß man schon wie die Implementation of the day für 2.5 aussehen
soll?
Ich habe mir den iptables bzw. netfilter-Code nochnicht so genau
angeschaut aber verglichen mit 2.0 scheint er mir *stark* an
Komplexität gewonnen zu haben. MaW. nach ca. 4h hab' ich grad mal in
groben Ansätzen verstanden was die Implementierung treibt.
Nicht so toll, imo.
Dietz
Felix von Leitner
> Wenn man konstruktiv sein will, muss man zuerst einmal bessere
> Moeglichkeiten aufzaehlen koennen und die Unzulaenglichkeiten bis
> auf's Haar nennen koennen. Beides ist nicht geschehen, deshalb
> irrelevant.
Es gibt Argumente, die sofort zu einem Ausscheiden führen.
Was übrig bleibt, kann man dann abwägen.
> > Leider erfaehrt man davon eher zu spaet als frueh genug. Und was bringt
> Wieso? So ziemlich jeden Bug der PIX haben wir im Lab gefunden bevor
> die PIX-Version auch nur an den Start ging. TAC-case, drei Anrufe bei
> einem Cisco VP (Brett Shockley, Telefonnumer hat man, wenn man bei
> Cisco direkt kauft) und Du hast eine gefixete Version. Das ich den
> Source-Code nicht habe ist hinderlich aber sollte Jemanden, der seinen
> Job ernst nimmt, nicht davon abhalten die Bugs zu finden und zu
> fixen/fixen zu lassen.
In der Zeit, in der du einen kompletten Blindtest einer PIX im Labor
durchführst, kannst du einen Open Source Paketfilter (sogar mit stateful
inspection) nicht nur komplett durchlesen und verstehen, sondern
_selber_ _schreiben_.
Felix
Felix von Leitner
[snip]
> Zu 1 = recht hat er, der FeFe - er hat keinen Quellcode. Den hat er zu
> den OSS-Unix-Firewalls und ein paar anderen, kleinen,
> Firewallprojekten. Den hat er schon nicht mehr zu dem Switch-OS davor,
> dem Router der unabdingbar auch davor lauert, zum BIOS in seiner
> Netzwerkkarte, etc.
Meine Netzwerkkarte hat kein BIOS.
Es hat ein PROM zum Remote Boot, aber kein BIOS.
Und wenn du auf meinem Switch/Router einbrichst, kannst du ein bißchen
sniffen (kannst du auch, wenn bei meinem Upstream einbrichst) und DoS
(dito), d.h. du tust keine neuen Gefahrenquellen auf.
> Zu 2 = Wer Werbung glaubt ist selbst schuld. Oder glaubt man Theo de
> Raadts Werbung fuer OpenSSH? Nein, tut man nicht. Man wirft das
> Produkt aber auch nicht aus dem Fenster, nur weil Theo Scheisse labert
> und manchmal recht gut darin ist.
Ich arbeite, wenn ich es irgend einrichten kann, nur mit seriösen
Partnern zusammen. Dazu gehört, daß die Werbung sachlich korrekt ist
und keinen Scheiß erzählt.
Wenn das bei dir nicht so ist, dann ist das dein Problem.
> Zu 3 sage ich nicht viel ausser dass es falsch ist. Der Griff und die
> Schrottklitsche.
Du willst hier gerade behaupten, daß Cisco PIX nicht dazugekauft hat, ja?
> Was FeFe bisher nicht gelungen ist, ist mir ein Bild zu malen wie er
> mit Firewalls, die seinen Anspruechen genuegen, die Ziele die ein
> Unternehmen der Groesse n (wobei n > dot.com-Klitsche) abbilden und
> befriedigen will.
Ich habe das getan und werde es wieder tun.
Allerdings tue ich das nicht kostenlos und öffentlich auf Zuruf von
Herrn "ich bin der Größte und verdiene pro Tag mehr als ihr alle
zusammen" im Usenet.
Felix
Jonas Luster
(Apologies for being late, aber ich komme gerade erst von einem
daemlichen Sales-Meeting wieder)
"Robin S. Socha" <ro...@socha.net> writes:
> > Was FeFe bisher nicht gelungen ist, ist mir ein Bild zu malen wie er
> > mit Firewalls, die seinen Anspruechen genuegen, die Ziele die ein
> > Unternehmen der Groesse n (wobei n > dot.com-Klitsche) abbilden und
> > befriedigen will.
>
> Schön, dass Du Dich noch für etwas begeistern kannst. Schade, dass
> dabei vor allem "Security by ich-hab-ganz-viel" oder "Security by
> ich-kenn-da-jemand-den-ich-anrufen-kann" herauskommt. Ursprünglich
Die einzige Security, der ich traue ist "Security by multiple
measures", etwas das ich versuche zu betreiben. Nun hat nicht Jeder
die Moeglichkeit das zu tun, deshalb gibt es security-firmen, die es
fuer Dich tun. Ich bin auch nur ein kleines Rad in diesen Massnahmen
aber Behauptungen wie "alles scheisse ausser X" und dann "aber warum X
besser ist als Y sage ich Dir nicht", ist ein Stil, den ich von CISSPs
und anderen Idioten gewohnt bin, wenn mir Jemand der behauptet Ahnung
zu haben, so kommt, bin ich normalerweise ziemlich angewidert.
> ging es übrigens darum, dass der junge Herr aus Österreich exakt
> diesen .com-Klitschen PIXes verkaufen wollte; seine Begründung war,
> dass OSS kein statefull irgendwas und kein VPN kann. Wenn Du für 5m
Das ist Beides Bullshit und wir wissen das. Wenn er seinen Kunden
damit eine PIX (und dadurch Kosten) aufhalst, dann gehoert er in die
gleiche Ecke wie die 'alles Scheisse ausser X'-Leute. Tatsache ist,
dass ich Anwendungsgebiete sehe (s.u.) in denen Du Dich auf den Kopf
stellen und die Beine abhacken kannst, eine OSS-Firewall wird es nicht
koennen.
Typisches Szenario: Eine der ganz grossen Suchmaschinen hat n
Frontendmaschinen, dann Firewalls, dann Backend, dann Firewalls, dann
Database, dann Firewalls, dann zwei T3 in die Firmenraeume.
Waehrend ich liebend gerne OSS an die T3 und zwischen Datenbank und
Backend stelle, renne ich gegen das grosse Problem dass keine
OSS-Architektur es bisher geschafft hat die 2xGigE die der Kunde da
abbekommt zu bearbeiten. Also muss ein System her das an der Backplane
das Routers ansetzt und dort das geforderte IDS realisiert. Dabei
werden zwar ein- bis zwei nette Attacken die direkt an der Linecard
ansetzen nicht abgefangen aber ich bekomme fast 99% der Daten von
aussen nach Innen auf 12 ports sauber gefiltert und ge-IDS-t.
Der Kunde hat ausserdem das Problem mit seinem Spanning-Tree Setup,
dass es zwar problemlos States verlieren kann, downtime aber sehr
kostenintensiv ist weil Andere von seinem Backend profitieren. Mit OSS
kann ich zwar Failovering realisieren haben dann aber in allen Faellen
50% totes Equipment.
Mit GigE-Cards in der PIX kann ich schoen meine 20 Maschinchen an die
Peers stacken, Failover-Kabel ran und lass sie mal schoen syncen. Mach'
mir das mit OSS, vorzugsweise moechte ich 2x T3 auf Vollast ueber einen
IPSEC tunnel ziehen, ich moechte ganz einfach deny any any any, allow any
any http, allow any any https divert otherinterface, an einer GigE-Leitung
haben, ich will das Ganze ohne Interaktion auf meiner Seite am Besten mit
einem IDS syncen und dann untereinander, ich will das ueber 8 Interafces
streuen und dabei bitte das SNA-gate (jede Latency ueber 10ms ist nicht
mehr tragbar, 6ms ist die Leitung) ueber einen IPSEC-tunnel fuettern.
> mal von Deinem Ego-Surftrip runterkommst, kannst Du ja mal einen
> qualifizierten und überprüfbar begründeten Kommentar dazu abgeben,
> warum die .com-Klitsche die PIX kaufen sollte.
Die dot.Com-Klitsche kann fast Alles kaufen, wenn sie das Geld
hat. Ueberlegen sollte sie sich aber schon was sie da hinstellt und
welchen Zweck es erfuellt. Alles unter einer 7500 am Netz ist nicht
wirklich geeignet, ACLs zu fahren, wenn man was Groesseres als das
hat, kann man sich auch ueberlegen einfach eine ACL dort aufzulegen
und auf den Rest zu verzichten, bzw. das VPN ueber zwei OSS-Boxen
realisieren und den Rest der Hardware ueberlassen.
Wenn sie nur ein paar Ports dichtmachen wollen dann gibt es mehr als
eine Antwort, OSS ist EINE moegliche.
Wenn man mehr moechte muss man sich umsehen - klar kann man alles das
auch unter OSS realisieren, aber da gibt es auch immer noch eine
Kosten/Nutzen-Rechnung und waehrend ich weiter versuche OSS genuegen
zu propagieren werde ich um's Verrecken nicht hingehen und einem
Kunden erzehlen dass das, was er da vorhat nicht moeglich ist weil das
Equipment das er dazu braucht nicht OSS ist.
Jonas Luster
> Und wenn du auf meinem Switch/Router einbrichst, kannst du ein bißchen
> sniffen (kannst du auch, wenn bei meinem Upstream einbrichst) und DoS
> (dito), d.h. du tust keine neuen Gefahrenquellen auf.
Kommt imemr daruf an, wie Du den Router einsetzt und wie wichtig Dir
welcher Teil von 'sicher' ist. Firewalls sind Netwerksicherheit, fuer
die Sicherheit der Hosts gibt es andere Massnamen, Netzwerksicherheit
endet aber nicht an der Firewall (und beginnt da auch nicht). "Ein
bisschen sniffen und DoS" ist recht viel und mehr als ich tolerieren
wuerde.
> > Zu 2 = Wer Werbung glaubt ist selbst schuld. Oder glaubt man Theo de
> > Raadts Werbung fuer OpenSSH? Nein, tut man nicht. Man wirft das
> > Produkt aber auch nicht aus dem Fenster, nur weil Theo Scheisse labert
> > und manchmal recht gut darin ist.
>
> Ich arbeite, wenn ich es irgend einrichten kann, nur mit seriösen
> Partnern zusammen. Dazu gehört, daß die Werbung sachlich korrekt ist
> und keinen Scheiß erzählt.
Prima, sind wir uns ja einig.
> > Zu 3 sage ich nicht viel ausser dass es falsch ist. Der Griff und die
> > Schrottklitsche.
>
> Du willst hier gerade behaupten, daß Cisco PIX nicht dazugekauft hat, ja?
Das bestreitet niemand. Die Frage ist, bist Du in einer Position von
der aus Du eine Firma deren Namen Du wahrscheinlich nicht einmal
kennst, als "Schrottklitsche" bezeichnen kannst?
> Ich habe das getan und werde es wieder tun.
> Allerdings tue ich das nicht kostenlos und öffentlich auf Zuruf von
Damit reduzierts Du Dein Klientel auf Menschen die unbesehen glauben
(Der FeFe sagts, dann muss es stimmen) - exakt das Clientel auf das
ICH verzichten kann - wenn Du es nicht kannst, dann tust Du mir
leid. Du kannst Deinen Standpunkt nicht beweisen? Hmm, muss man Dir
wohl glauben wenn Du sagst es sei so - ich glaube Dir nicht, das ist
auch ein Teil der Sicherheit by "Multiple Measures", dass ich es sehen
will, performend, bevor ich es glaube.
> Herrn "ich bin der Größte und verdiene pro Tag mehr als ihr alle
> zusammen" im Usenet.
Falsch.
Felix von Leitner
> Die einzige Security, der ich traue ist "Security by multiple
> measures", etwas das ich versuche zu betreiben.
Damit maximierst du nicht die Sicherheit, sondern die Komplexität und
damit die Fehlerwahrscheinlichkeit.
Mach lieber eine Maßnahme und die richtig als fünf halbe Sachen, die am
Ende noch Kram verwenden, von dem du den Quellcode nicht hast.
Das ist natürlich prima, wenn deine Leistungen an sich nicht ausreichen,
um für eine langfristige Geschäftsbeziehung zu sorgen, weil du dich
damit unentbehrlich machst ("außer mir hat eh keiner mehr den Überblick
über die 20 Loadbalancer, 50 Router und 20 Firewall-Cluster"). Aber mit
Sicherheit hat das nichts zu tun. Ob dir das gefällt oder nicht.
Im Übrigen warte ich ja darauf, daß von dir mal eine verwertbare Aussage
kommt, anhand derer man sich mal eine Meinung darüber bilden kann, ob du
nur ein großed Mundwerk oder tatsächlich Expertise besitzt.
> Tatsache ist, dass ich Anwendungsgebiete sehe (s.u.) in denen Du Dich
> auf den Kopf stellen und die Beine abhacken kannst, eine OSS-Firewall
> wird es nicht koennen.
Oh, hier kommt eine solche Aussage. Gut, du hast nur ein großen
Mundwerk.
Es gibt natürlich überhaupt keinerlei Basis für die Aussage, daß
irgendetwas mit OSS-Firewalls nicht geht. Höchstens, daß es dir nicht
gelungen ist, unter Verwendung der von dir getesteten vorgebastelten
Lösungen den gewünschten Parametern zu genügen.
> Typisches Szenario: Eine der ganz grossen Suchmaschinen hat n
> Frontendmaschinen, dann Firewalls, dann Backend, dann Firewalls, dann
> Database, dann Firewalls, dann zwei T3 in die Firmenraeume.
Eine T3-Leitung trägt ca 5 Megabytes pro Sekunde.
SELBSTVERSTÄNDLICH kann das in Echtzeit auf heutigen Aldi-Rechnern
gefiltert werden. Ich würde sogar behaupten: im User Space!
> Waehrend ich liebend gerne OSS an die T3 und zwischen Datenbank und
> Backend stelle, renne ich gegen das grosse Problem dass keine
> OSS-Architektur es bisher geschafft hat die 2xGigE die der Kunde da
> abbekommt zu bearbeiten.
Es ist völlig wurscht, was für Leitungen da rauskommen. Wichtig ist,
wieviel Traffic da rüber kommt, und wenn du da mehrere T3s hast, dann
kommt da pro T3 eine Firewall hin und gut ist.
> Also muss ein System her das an der Backplane das Routers ansetzt und
> dort das geforderte IDS realisiert.
Aha, jetzt sind wir also plötzlich vom Paketfilter zum IDS gesprungen?
Jonas, so kommen wir nicht weiter. Formuliere dein Problem klar und wir
können reden. Aber du wirfst hier unkontrolliert mit Buzzwords herum.
> Dabei werden zwar ein- bis zwei nette Attacken die direkt an der
> Linecard ansetzen nicht abgefangen aber ich bekomme fast 99% der Daten
> von aussen nach Innen auf 12 ports sauber gefiltert und ge-IDS-t.
Wenn du tatsächlich wüßtest, wovon du redest, wüßtest du, daß die
Leistung von IDS nicht von der Bandbreite sondern von den Anzahl der
Pakete abhängt.
> Der Kunde hat ausserdem das Problem mit seinem Spanning-Tree Setup,
> dass es zwar problemlos States verlieren kann, downtime aber sehr
> kostenintensiv ist weil Andere von seinem Backend profitieren. Mit OSS
> kann ich zwar Failovering realisieren haben dann aber in allen Faellen
> 50% totes Equipment.
Wow, da buzzt es mir ja gerade entgegen, daß die Schwarte kracht! ;-)
Wo gehen dir States verloren, welche Art von States sind das, warum
gehen sie dir verloren, und was hat das mit Downtime zu tun?
Was hat OSS mit Failover zu tun und wie kommst du darauf, daß man mit
OSS keine feinere Granularität haben kann?
> Mit GigE-Cards in der PIX kann ich schoen meine 20 Maschinchen an die
> Peers stacken, Failover-Kabel ran und lass sie mal schoen syncen.
Ich weiß ja nicht, was du uns mitteilen willst, aber deiner ist
offensichtlich echt am Längsten. Vielleicht können wir das hier
abkürzen, wenn ich das mal unumwunden zugebe ;-)
Ich setze Gigabit Ethernet nur ein, wenn es sinnvoll ist, nicht aus
Prinzip und weil das cool zum Herumerzählen ist. Und es ist bisher
verdammt selten sinnvoll gewesen.
> Mach' mir das mit OSS, vorzugsweise moechte ich 2x T3 auf Vollast
> ueber einen IPSEC tunnel ziehen,
Ah, prima! Jetzt kommt auch noch IPsec dazu!
Ich kann mich des Eindrucks nicht erwehren, daß du jetzt solange
Probleme aus dem Hut ziehst, bis du dir ganz sicher bist, daß das
niemand mit OSS hinkriegen wird und dich widerlegen könnte ;-)
Um zwei T3 über IPsec zu tunneln braucht man Hardware-Crypto. OpenBSD
unterstützt mehrere davon. Lösbar ist das Problem jedenfalls.
Und gleichzeitig kann man natürlich auch in Echtzeit filtern,
insbesondere wenn die Regeln so einfach sind wie von dir angegeben.
> ich moechte ganz einfach deny any any any, allow any any http, allow
> any any https divert otherinterface, an einer GigE-Leitung haben, ich
> will das Ganze ohne Interaktion auf meiner Seite am Besten mit einem
> IDS syncen und dann untereinander, ich will das ueber 8 Interafces
> streuen und dabei bitte das SNA-gate (jede Latency ueber 10ms ist
> nicht mehr tragbar, 6ms ist die Leitung) ueber einen IPSEC-tunnel
> fuettern.
Hihi, Jonas, du bist wirklich lustig.
Jetzt noch schnell eine Packung SNA in die Tonne gestreut, hauptsache
insgesamt deckt es genügend Gebiete ab, daß es sicher keiner hinkriegt,
wie?
Ob ein OSS-IDS das in Echtzeit hinkriegt hängt wie gesagt von der Anzahl
der Pakete ab. Das gleiche gilt auch für kommerzielle IDS. Wenn das
bei dir also läuft, dann geht das höchstwahrscheinlich auch mit OSS.
> Wenn man mehr moechte muss man sich umsehen - klar kann man alles das
> auch unter OSS realisieren, aber da gibt es auch immer noch eine
> Kosten/Nutzen-Rechnung und waehrend ich weiter versuche OSS genuegen
> zu propagieren werde ich um's Verrecken nicht hingehen und einem
> Kunden erzehlen dass das, was er da vorhat nicht moeglich ist weil das
> Equipment das er dazu braucht nicht OSS ist.
Andersherum hast du aber kein Problem damit, deinen Kunden überteuerten
Kommerz-Schrott zu verkaufen, der so anfällig und fehlerhaft ist, daß du
schon die Telefonnummer des CTO des Herstellers auswendig kennst.
Philister, elender!
Felix
Jonas Luster
> Im Übrigen warte ich ja darauf, daß von dir mal eine verwertbare Aussage
> kommt, anhand derer man sich mal eine Meinung darüber bilden kann, ob du
> nur ein großed Mundwerk oder tatsächlich Expertise besitzt.
Glashaus, Steine. Mehr als "mit OSS kann ich das auch" habe ich von
Dir auch nicht gehoert.
> > Tatsache ist, dass ich Anwendungsgebiete sehe (s.u.) in denen Du Dich
> > auf den Kopf stellen und die Beine abhacken kannst, eine OSS-Firewall
> > wird es nicht koennen.
>
> Oh, hier kommt eine solche Aussage. Gut, du hast nur ein großen
> Mundwerk.
Beweise das Gegenteil oder stelle Dich in die Ecke in die Du mich
stellen willst.
> Es gibt natürlich überhaupt keinerlei Basis für die Aussage, daß
> irgendetwas mit OSS-Firewalls nicht geht. Höchstens, daß es dir nicht
Grosse Worte, Herr von Leitner, wo ist der Beweis? Hast Du nicht?
Angeber.
> Eine T3-Leitung trägt ca 5 Megabytes pro Sekunde.
> SELBSTVERSTÄNDLICH kann das in Echtzeit auf heutigen Aldi-Rechnern
> gefiltert werden. Ich würde sogar behaupten: im User Space!
Lesen bildet - wie ich schon geschrieben haben habe ich kein Problem
da eine OSS-Wall davorzustellen, tu ich auch. Und, wenn Du wirklich
so ein schlaues Maennlein waerst wie Du vorgibst zu sein, dann waerst
Du auf Defcon nicht an mir und der BOF dazu vorbeigehetzt sondern
haettest Dich dazugesetzt.
> > Waehrend ich liebend gerne OSS an die T3 und zwischen Datenbank und
> > Backend stelle, renne ich gegen das grosse Problem dass keine
> > OSS-Architektur es bisher geschafft hat die 2xGigE die der Kunde da
> > abbekommt zu bearbeiten.
>
> Es ist völlig wurscht, was für Leitungen da rauskommen. Wichtig ist,
> wieviel Traffic da rüber kommt, und wenn du da mehrere T3s hast, dann
> kommt da pro T3 eine Firewall hin und gut ist.
Nun, glaubst Du im Ersnt irgendwer ist so dumm und zahlt das Extra
fuer all den beschissenen Fiberkram, wenn er ihn nicht braucht Geh'
einfach mal ruhig davon aus, dass der Traffic die Leitungen zwar nicht
auf 90% bringt aber durchaus etwas ueber dem liegt was ich mit einer
oder mehreren T3 abfackeln kann.
> > Also muss ein System her das an der Backplane das Routers ansetzt und
> > dort das geforderte IDS realisiert.
>
> Aha, jetzt sind wir also plötzlich vom Paketfilter zum IDS gesprungen?
> Jonas, so kommen wir nicht weiter. Formuliere dein Problem klar und wir
> können reden. Aber du wirfst hier unkontrolliert mit Buzzwords herum.
Wenn Du weiter unten weiterliesst, dann liest Du, dass eine der
geforderten Leistungen die ist, dass ich mit dem IDS reden kann und
seine Daten irgendwie mitverwalte. Es ist wirklich laecherlich wie Du
versuchst genau das zu tun, was Du mir vorwirfst - Du laberst ohne
auch nur ansatzweise eine Loesung zu bringen. Klar, warum hast Du
klargemacht: Nicht umsonst und nicht fuer micht, aber das erklaert
noch lange nicht WAS denn Deiner Meinung nach alles was nicht OSS
ist unbrauchbar macht (ausser dass es nicht OSS ist).
> Wo gehen dir States verloren, welche Art von States sind das, warum
> gehen sie dir verloren, und was hat das mit Downtime zu tun?
Wie ich geschrieben habe - lies nochmal - ist es scheissegal ob ich
bei einem Failover auch die aktuelle Statetable kopiere - da es der
Site nicht drauf ankommt. Was ihnen wichtig ist, ist dass ich (ich
denke ich bekomme Dich noch zum Kotzen mit den Buzzwords, aber Du
darft das gerne fuer Deine naechste unqualifizierte Attacke verwenden)
redundant Firewalls rausziehen und reischieben kann und ueber den
vorhandenen Park abgleichen (Rulebase, IPSec-Ednpunkte, etc.)
Ich warte immer noch auf den Beweis - musst es ja nicht bauen, nicht
mal einem Idioten ohne Ahnung wie mir erklaeren, nur anreissen - dass
Du das mit einer beliebeingen Loesung ebenso sauber wie mit der PIX
hinbekommst, OSS nur als 3 von mehreren Alternativen.
Deine Gruende warum Du PIX nicht magst kenne ich:
a) Ist nicht OSS - eine valide Aussage, die aber den Nutzen eines
PIX-Systems nicht auf Null reduziert.
b) Marketing bei Cisco luegt sich einen ab - nicht valide aber wenn Du
Deinen Masstab an Hochglanzprospekten anlegst, bittesehr.
c) Es gibt einen Haufen an boesen Exploits. Der CBAC-exploit ist
gefixed, die FTP-exploits sind zu, der RST-Bug war etwa vier
Stunden nach dem Finden oeffentlich downloadbar (incl. Mail an
alle registrierten Besitzer einer PIX), etc. Natuerlich gibt es 'ne
ganze Menge an Dingen, die passieren koennen, aber wenn OSS
wirklich so ueberlegen ist (in diesem Punkt, ich kann Dir auch 'ne
Menge Punkte nennen, bei denen OSS im Allgemeinen alle closed
source programme schlaegt), warum hast Du den rst_bug in IPFilter
dann verschlafen? Oder warum hast Du ihn nie publik gemacht? Oder
hast Du ihne einfach nicht gesehen? Siehste, ich auch nicht, aber
ich behaupte zumindest nicht eine OSS-Firewall in zwei Wochen
schreiben zu koennen.
> Ich weiß ja nicht, was du uns mitteilen willst, aber deiner ist
> offensichtlich echt am Längsten. Vielleicht können wir das hier
> abkürzen, wenn ich das mal unumwunden zugebe ;-)
Wenn Du mit mir ueber koerperliche Unzulaenglichkeiten diskutieren
willst, dann wilkommen, aber nicht hier. Wenn Du das Ganze auf einem
anderen Level halten moechtest, auch wilkommen. Wenn Du lieber
laberst, dann beenden wir das hier, OK?
> Um zwei T3 über IPsec zu tunneln braucht man Hardware-Crypto. OpenBSD
> unterstützt mehrere davon. Lösbar ist das Problem jedenfalls.
Hast Du die Sourcen fuer die Cryptocards?
> Hihi, Jonas, du bist wirklich lustig.
> Jetzt noch schnell eine Packung SNA in die Tonne gestreut, hauptsache
> insgesamt deckt es genügend Gebiete ab, daß es sicher keiner hinkriegt,
> wie?
Wie gesagt, ich bekomme es hin - mit Open Source (ipf und OpenBSD) und
einer Portion PIX wo ich die Netzlast nicht mehr ordentlich mit der
Open Source Loesung abfackeln kann.
> Ob ein OSS-IDS das in Echtzeit hinkriegt hängt wie gesagt von der Anzahl
> der Pakete ab. Das gleiche gilt auch für kommerzielle IDS. Wenn das
> bei dir also läuft, dann geht das höchstwahrscheinlich auch mit OSS.
Sorry, wenn ich Dich da enttaeuschen muss. Das geht weder mit
closed-source noch mit Open Source richtig gut, das Einzige was ich
bisher gefunden habe ist Ciscos Netranger-Spinoff an der 120xx
backplane. Ich weiss dass kein IDS die 100% schafft, ehrliche IDSe
geben das zu und reichen Statistiken nach wie viel sie gedropped haben
(NFR), unehrliche tun das nicht. Cisco ist da recht unehrlich (ich
bekomme nur sehr spaerliche Stats) aber immer noch performanter als
die anderen Tools. Und das hat mit OSS vs CSS nicht viel zu tun, das
liegt daran, dass es eben direkt and der Backplane sitzt.
> Philister, elender!
Deine Sachlichkeit ist dem Rest Deiner Verhaltensmuster identisch.
jonas
Stefan Heinecke
>Philister, elender!
Das war das einzige was ich nicht verstanden habe, der Duden sagt mir:
Phi|lis|ter <nach dem Volk an der Küste Südpalästinas, in der Bibel als
ärgster Feind der Israeliten dargestellt> der; -s, -: 1. kleinbürgerlicher
Mensch; Spießbürger. 2. im Berufsleben stehender Alter Herr
(Verbindungsw.). 3. (Studentenspr. veraltend) Nichtakademiker.
bin aber immer noch ratlos.
Philipp Hemker
> Es gibt natürlich überhaupt keinerlei Basis für die Aussage, daß
> irgendetwas mit OSS-Firewalls nicht geht.
Irgendwie erinnert mich das an deinen Bericht bzgl.
FTP-Server mit Gigabit-Ethernet auf x86...
bis dann,
philipp
--
Felix von Leitner
> > > Tatsache ist, dass ich Anwendungsgebiete sehe (s.u.) in denen Du Dich
> > > auf den Kopf stellen und die Beine abhacken kannst, eine OSS-Firewall
> > > wird es nicht koennen.
> > Oh, hier kommt eine solche Aussage. Gut, du hast nur ein großen
> > Mundwerk.
> Beweise das Gegenteil oder stelle Dich in die Ecke in die Du mich
> stellen willst.
Deine Aussage ist per Definition falsch.
Denn morgen könnte dein Lieblings-Anbieter deine Lieblings-Lösung zu OSS
erklären und schon wäre sie falsch. Du schließt hier viel zu generell
aus.
Daher auch meine Reaktion.
> > Es gibt natürlich überhaupt keinerlei Basis für die Aussage, daß
> > irgendetwas mit OSS-Firewalls nicht geht. Höchstens, daß es dir nicht
> Grosse Worte, Herr von Leitner, wo ist der Beweis? Hast Du nicht?
> Angeber.
Das "OSS" macht keinerlei Aussage über die Qualität einer Software, nur
über das Business-Modell des Autors.
Behauptungen, die basierend auf diesem Aussagen über die Qualität machen
sind genau Unfug. In beide Richtungen, natürlich. Software ist auch
nicht automatisch scheiße, weil sie Kommerz-Software ist. Sie ist nur
meistens scheiße, wenn sie Kommerz-Software ist. Morgen könnte mir
schließlich taugliche Kommerz-Software begegnen.
> > Eine T3-Leitung trägt ca 5 Megabytes pro Sekunde.
> > SELBSTVERSTÄNDLICH kann das in Echtzeit auf heutigen Aldi-Rechnern
> > gefiltert werden. Ich würde sogar behaupten: im User Space!
> Lesen bildet - wie ich schon geschrieben haben habe ich kein Problem
> da eine OSS-Wall davorzustellen, tu ich auch.
Wollen wir uns jetzt wirklich Quotes unserer Postings um die Ohren
schlagen? Du schriebst, daß du gerne zwischen T3 und Datenbank eine
OSS-Firewall einsetzen würdest, aber es geht halt nicht.
Genau das zweifle ich oben an.
> Und, wenn Du wirklich so ein schlaues Maennlein waerst wie Du vorgibst
> zu sein, dann waerst Du auf Defcon nicht an mir und der BOF dazu
> vorbeigehetzt sondern haettest Dich dazugesetzt.
Meine Zeit auf der Defcon ist komplett ausgelastet gewesen. Ich kann
mich auch nicht erinnern, dein BoF wahrgenommen zu haben. Es tut mir
leid, wenn ich das übersehen habe. Es lag nicht daran, daß ich an dem
Thema nicht interessiert gewesen wäre.
> > Es ist völlig wurscht, was für Leitungen da rauskommen. Wichtig ist,
> > wieviel Traffic da rüber kommt, und wenn du da mehrere T3s hast, dann
> > kommt da pro T3 eine Firewall hin und gut ist.
> Nun, glaubst Du im Ersnt irgendwer ist so dumm und zahlt das Extra
> fuer all den beschissenen Fiberkram, wenn er ihn nicht braucht Geh'
> einfach mal ruhig davon aus, dass der Traffic die Leitungen zwar nicht
> auf 90% bringt aber durchaus etwas ueber dem liegt was ich mit einer
> oder mehreren T3 abfackeln kann.
Äh, kannst du dich bitte mal auf ein Szenario einigen?
Du schriebst, daß da zwei volle T3s ankommen, dann irgendwie in Form
eines Gigabit Ethernet Kabels bei einer Firewall ankommen und dann in
Form von 8 Ethernet Trunks da rauskommen sollen.
Und jetzt ist es plötzlich mehr Traffic, als man mit ein paar T3s
abfackeln kann?!
Und wo zahlt der Kunde da mehr? Was kostet dich denn eine PIX, die
einmal Gigabit Ethernet verarbeiten kann?
> > Aha, jetzt sind wir also plötzlich vom Paketfilter zum IDS gesprungen?
> > Jonas, so kommen wir nicht weiter. Formuliere dein Problem klar und wir
> > können reden. Aber du wirfst hier unkontrolliert mit Buzzwords herum.
> Wenn Du weiter unten weiterliesst, dann liest Du, dass eine der
> geforderten Leistungen die ist, dass ich mit dem IDS reden kann und
> seine Daten irgendwie mitverwalte. Es ist wirklich laecherlich wie Du
> versuchst genau das zu tun, was Du mir vorwirfst - Du laberst ohne
> auch nur ansatzweise eine Loesung zu bringen. Klar, warum hast Du
> klargemacht: Nicht umsonst und nicht fuer micht, aber das erklaert
> noch lange nicht WAS denn Deiner Meinung nach alles was nicht OSS
> ist unbrauchbar macht (ausser dass es nicht OSS ist).
Ich sage nicht, daß alles automatisch scheiße ist, was nicht freie
Software ist. Ich spiele z.B. zur Zeit gerne Baldurs Gate 2, ohne die
Quellen davon zu haben.
Aber wenn es um kritische Elemente der Infrastruktur geht, dann hat
Qualität zu entscheiden, und sonst nichts. Insbesondere nicht der tolle
große Name des Herstellers oder der supergünstige Preis oder gar daß der
Chef ein Laptop geschenkt bekommt, wenn er genügend viel Hardware für
die Firma abnimmt.
> > Wo gehen dir States verloren, welche Art von States sind das, warum
> > gehen sie dir verloren, und was hat das mit Downtime zu tun?
> Wie ich geschrieben habe - lies nochmal - ist es scheissegal ob ich
> bei einem Failover auch die aktuelle Statetable kopiere - da es der
> Site nicht drauf ankommt. Was ihnen wichtig ist, ist dass ich (ich
> denke ich bekomme Dich noch zum Kotzen mit den Buzzwords, aber Du
> darft das gerne fuer Deine naechste unqualifizierte Attacke verwenden)
> redundant Firewalls rausziehen und reischieben kann und ueber den
> vorhandenen Park abgleichen (Rulebase, IPSec-Ednpunkte, etc.)
Kannst du bitte einfach mal dein Szenario kohärent beschreiben?
Redundante Paketfilter und IPsec Tunnel sind mit OSS jedenfalls kein
Problem, auch für die Datenrate einer T3-Leitung. Wenn man mehr Daten
hat, muß man das halt aufteilen.
> Ich warte immer noch auf den Beweis - musst es ja nicht bauen, nicht
> mal einem Idioten ohne Ahnung wie mir erklaeren, nur anreissen - dass
> Du das mit einer beliebeingen Loesung ebenso sauber wie mit der PIX
> hinbekommst, OSS nur als 3 von mehreren Alternativen.
Wie kommst du denn darauf, daß die PIX "sauber" ist?
Und auf was bezieht sich das "sauber" überhaupt?
Ich sehe erst einmal nicht viel Grund, ein System für sauber
implementiert oder konzeptioniert zu halten, wenn sich der Hersteller
nicht traut, mir den Quellcode mitzuliefern.
> a) Ist nicht OSS - eine valide Aussage, die aber den Nutzen eines
> PIX-Systems nicht auf Null reduziert.
"Of course it does not work, but look how fast it is!" ;-)
> b) Marketing bei Cisco luegt sich einen ab - nicht valide aber wenn Du
> Deinen Masstab an Hochglanzprospekten anlegst, bittesehr.
Ich glaube nicht, daß Cisco massiv herumlügt, aber sie werben mit
Pillepalle-Kram, nicht mit Fakten. Das stört mich in der Tat immens.
> c) Es gibt einen Haufen an boesen Exploits. Der CBAC-exploit ist
> gefixed, die FTP-exploits sind zu, der RST-Bug war etwa vier
> Stunden nach dem Finden oeffentlich downloadbar (incl. Mail an
> alle registrierten Besitzer einer PIX), etc. Natuerlich gibt es 'ne
> ganze Menge an Dingen, die passieren koennen, aber wenn OSS
> wirklich so ueberlegen ist (in diesem Punkt, ich kann Dir auch 'ne
> Menge Punkte nennen, bei denen OSS im Allgemeinen alle closed
> source programme schlaegt), warum hast Du den rst_bug in IPFilter
> dann verschlafen?
Ich benutze kein IPFilter.
> Siehste, ich auch nicht, aber ich behaupte zumindest nicht eine
> OSS-Firewall in zwei Wochen schreiben zu koennen.
Ich habe ein schrottiges User Space Tool an zwei Tagen gehackt, das
Ethernet-Pakete sniffen, rudimentär manglen und wieder ins Netz ausgeben
kann. Da ein paar Regeln drumherum zu basteln ist nun wirklich kein
Problem und in zwei Wochen kriegt man da sogar ein richtiges command
line Interface oder Konfigurationsdateien mit yacc-Parser hin.
Das ist dann nicht poliert, hat noch keine Dokumentation und hat
wahrscheinlich auch noch Bugs, aber es ist machbar.
> > Ich weiß ja nicht, was du uns mitteilen willst, aber deiner ist
> > offensichtlich echt am Längsten. Vielleicht können wir das hier
> > abkürzen, wenn ich das mal unumwunden zugebe ;-)
> Wenn Du mit mir ueber koerperliche Unzulaenglichkeiten diskutieren
> willst, dann wilkommen, aber nicht hier. Wenn Du das Ganze auf einem
> anderen Level halten moechtest, auch wilkommen. Wenn Du lieber
> laberst, dann beenden wir das hier, OK?
Ich will mit dir über die Fakten diskutieren, aber deine Aussage
zentrieren sich um typische Elemente eines Dick Size Wars ("Gigabit",
"multiple T3", "10 us Latenz").
Diese Art von "ich habe so unglaublich viel Daten, das hast du noch nie
gesehen!" wird gewöhnlich von Salesdroids benutzt. Insbesondere ist IBM
bekannt dafür, daß sie so ihre Systeme verkloppen. Denn das hat den
Nebeneffekt, daß man dem Kunden gleich vermittelt, daß man ihn ernst
nimmt und für wichtig hält, wenn man ihm irgendwelche Mondwerte zitiert,
was für Bandbreite und Latenzen er unbedingt braucht.
> > Um zwei T3 über IPsec zu tunneln braucht man Hardware-Crypto. OpenBSD
> > unterstützt mehrere davon. Lösbar ist das Problem jedenfalls.
> Hast Du die Sourcen fuer die Cryptocards?
Nein.
> > Hihi, Jonas, du bist wirklich lustig.
> > Jetzt noch schnell eine Packung SNA in die Tonne gestreut, hauptsache
> > insgesamt deckt es genügend Gebiete ab, daß es sicher keiner hinkriegt,
> > wie?
> Wie gesagt, ich bekomme es hin - mit Open Source (ipf und OpenBSD) und
> einer Portion PIX wo ich die Netzlast nicht mehr ordentlich mit der
> Open Source Loesung abfackeln kann.
Dann verstehe ich nicht, wieso du hier so ein Name Dropping machst.
Bevor du mir überhaupt die Change gibst, zu deinem ursprünglichen
Problem etwas zu sagen, wirfst du gleich fünf weitere Probleme in den
Ring. Tut mir leid, aber das wirkt einfach nicht seriös auf mich.
> > Ob ein OSS-IDS das in Echtzeit hinkriegt hängt wie gesagt von der Anzahl
> > der Pakete ab. Das gleiche gilt auch für kommerzielle IDS. Wenn das
> > bei dir also läuft, dann geht das höchstwahrscheinlich auch mit OSS.
> Sorry, wenn ich Dich da enttaeuschen muss. Das geht weder mit
> closed-source noch mit Open Source richtig gut, das Einzige was ich
> bisher gefunden habe ist Ciscos Netranger-Spinoff an der 120xx
> backplane. Ich weiss dass kein IDS die 100% schafft, ehrliche IDSe
> geben das zu und reichen Statistiken nach wie viel sie gedropped haben
> (NFR), unehrliche tun das nicht. Cisco ist da recht unehrlich (ich
> bekomme nur sehr spaerliche Stats) aber immer noch performanter als
> die anderen Tools. Und das hat mit OSS vs CSS nicht viel zu tun, das
> liegt daran, dass es eben direkt and der Backplane sitzt.
Wieviele IDS-Regeln performt Cisco denn da pro Paket?
Und wieviele Pakete habt ihr pro Sekunde?
Verstehe mich nicht falsch: ich schließe nicht aus, daß Cisco das kann
und sogar gut kann. Aber ich habe einfach zu viele Kommerzprodukte beim
Entstehen gesehen. Da kommt halt eine Deadline und wenn das Teil dann
halt nur die ersten drei Regeln abarbeitet, dann ist das immerhin besser
als wenn es gar keine abarbeiten würde, und man kloppt das trotzdem auf
den Markt.
Felix
Jonas Luster
> Jonas Luster <lo...@netwarriors.org> wrote:
> > > > Tatsache ist, dass ich Anwendungsgebiete sehe (s.u.) in denen Du Dich
> > > > auf den Kopf stellen und die Beine abhacken kannst, eine OSS-Firewall
> > > > wird es nicht koennen.
> > > Oh, hier kommt eine solche Aussage. Gut, du hast nur ein großen
> > > Mundwerk.
> > Beweise das Gegenteil oder stelle Dich in die Ecke in die Du mich
> > stellen willst.
>
> Deine Aussage ist per Definition falsch.
Ich loesche mal alles und setze unten an:
- OFFICE -
|| ||
CLOUD
|| ||
OSS OSS (OpenBSD Ipfilter)
|| ||
Datenbank
|| ||
Viele Viele Viele Viele
Backend Maschinen
||
Firewall(s)
||
Viele Viele Viele Viele
Frontend Maschinen
||
Firewall(s) --- IDS
||
Router
||
CLOUD
- das ist es, was ich versucht habe (poorly, wenn ich Deine Reaktion
richtig einschaetze) zu beschreiben. CLOUD ist natuerlich das
Internet, weil ich mit ASCII keine Wolken malen kann.
Im Anfang was Alles da oben OSS, gute Software der einfach die
Hardware fehlte um die Last des Traffics aufzuhalten. Und genau das
setzt meine Kritik an - ich bin weder ein OSS-Feind (sonst haette ich
das Ding damals nicht per OSS gebaut) noch halte ich OSS fuer
schwaecher als kommerzielle Software, im Gegenteil - ich halte es fuer
staerker in vielen Punkten. Ich sehe aber Gelegenheiten bei denen ich
entweder Monate in die Entwicklung einer eigenen Implementation eines
PF stecken muss (den ich dann natuerlich Open Sourcen wuerde) oder auf
vorgandene Software zurueckgreife - von der genau zwei
Implementationen die Last da oben verkraften und ihre Arbeit tun. Auf
der 'clean' Side ist bei Beiden Enden nicht soviel los, einzig dfie
egress-Firewalls am unteren Ende muessen einen Datenstrom aushalten
der je nach Tag und Zeit zwei GigE-Interfaces halb bis 3/4
auslasted. Das sind sowohl Kunden als auch eine Menge illegitimer
Traffic sowie ein Puffer fuer spaeter wenn der Traffic noch groesser
wird - man will ja nicht staendig upgraden.
Das ist eine Menge hysterischer Kram drin, das SNA-gerutsche z.B., und
dank der Attacken im Januar ist dieser Kunde auch ganz erpicht darauf
ein IDS mit einer netten Packetrate zu haben. Die letzte
Implementation einer Firewall, die GigE abkonnte (ich gehe immer von
einer Netzauslastung von 65% aus) waren 16 Solaris-Kisten mit ipf, die
dann spaeter gegen 12 Kisten mit FW-1 ausgetauscht wurden,
L4-geswitcht.
Meine Argumentation liest sich in etwa so: Ich habe keine Probleme mit
aktuellen Releases der PIX FW. In der Vergangenheit sind vier Exploits
auf meine Nerven gegengen von denen ich alle, zum Glueck, im heissen
Test am Netz gefunden habe. Ciscos FW-Team ist schnell, wenn man einen
BUg meldet ist das neue Image im Normalfall in 2-3 Tagen draussen, bei
boesen blopps auch mal nach 4 Stunden. Ich kenne mich mit ipchains
nicht soo besonders aus, ich verwende OpenBSD fuer's Firewalling und
da kenne ich zumindes 5 bugs die ich nicht gesehen haette haette mir
nicht Jemand den Kopf druaf gestossen - mag meine eigene Unfaehigkeit
sein oder einfach die Tatsache dass man erstmal drauf kommen muss. Ich
disse OSS nicht, ich weiss nur dass ich mit den PIXen sowohl in
Leistung als auch in comfort (commandline, nicht das verdammte Tool)
gute Erfahrungen gemacht habe und Sachen, die einfach mit
z.Zt. vorhandenen OSS-Loesungen (noch) nicht gehen, dort gehen.
Ich halte den Einwand der "ist nicht OSS" fuer valide, aber Du gibst
selbst zu dass schon wenn Du eine Cryptocard brauchst, Du einen Teil
der Sicherheitsloesung nicht mehr kennst - was schade aber fuer
gewisse Situationen (noch) nicht vermeidbar ist. Was in 1 Jahr ist,
weiss ich nicht. Vielleicht setzen Leute dann Dein oder mein System
ein und wir schaffe es, Alles das zu implementieren was bisher noch
fehlt, aber die allgemeine Aussage "nimm OSS, das ist besser" kann ich
nicht bestaetigen.
jonas
Felix von Leitner
> > Es gibt natürlich überhaupt keinerlei Basis für die Aussage, daß
> > irgendetwas mit OSS-Firewalls nicht geht.
> Irgendwie erinnert mich das an deinen Bericht bzgl.
> FTP-Server mit Gigabit-Ethernet auf x86...
Ja und?
Das waren Limits der PC-Architektur.
Wer sagt dir, daß die gleiche OSS-Software auf einer S390 das gleiche
Problem hätte?
Wir gehen natürlich von der Prämisse aus, daß die Software auf der
gleichen Art Hardware läuft wie Kommerz-Software, sonst ist das kein
Software-Vergleich, sondern Schwachsinn.
Felix
Marc Haber
>unterstützt mehrere davon. Lösbar ist das Problem jedenfalls.
Und von der Hardware-Crypto hast Du den "Quelltext", dass Du die
Korrektheit prüfen kannst? Jetzt Buzzst Du.
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
Felix von Leitner
> Felix von Leitner <usenet-...@fefe.de> wrote:
> >Um zwei T3 über IPsec zu tunneln braucht man Hardware-Crypto. OpenBSD
> >unterstützt mehrere davon. Lösbar ist das Problem jedenfalls.
> Und von der Hardware-Crypto hast Du den "Quelltext", dass Du die
> Korrektheit prüfen kannst? Jetzt Buzzst Du.
Es gibt Hardware-Crypto, wo es den Quelltext gibt, aber der Vergleich
hinkt generell.
Das Interface für Hardware-Crypto ist ziemlich klar, und man setzt es ab
einem gewissen Volumen ein. Für eine sinnvolle Datenstrommanipulation
müßte auf dieser Hardware also Speicher im zweistelligen Megabytebereich
drauf sein, und das kann man durch Draufgucken sehen.
Da Hardware-Crypto kein Protokoll-Parsing macht, gibt es auch keine
Buffer Overflows, keine Metazeichen und keine Temp-Dateien.
Natürlich könnte da eine Hintertür drauf sein.
Das wird man auch nur mit gehörigem Aufwand feststellen können.
Nur wäre dieser Angriff viel teurer als mir ein Netzkabel mit Abstrahler
im Stecker zu verkaufen oder ähnliches. Ich bin daher der Meinung, daß
diese von euch hier skizzierte "Bedrohung" sehr theoretischer Natur ist.
Felix
Felix von Leitner
> Ich loesche mal alles und setze unten an:
[Diagramm weggelassen]
> - das ist es, was ich versucht habe (poorly, wenn ich Deine Reaktion
> richtig einschaetze) zu beschreiben. CLOUD ist natuerlich das
> Internet, weil ich mit ASCII keine Wolken malen kann.
Das kam so schon ungefähr rüber, aber die Frage ist, wieviel Traffic auf
wie vielen Leitungen jeweils Peak auftreten kann, und wie viele Pakete
das maximal sein können. Wenn diese Daten vorliegen, dann sind Aussagen
über die richtige Implementation möglich. Vorher nicht.
> Auf der 'clean' Side ist bei Beiden Enden nicht soviel los, einzig
> dfie egress-Firewalls am unteren Ende muessen einen Datenstrom
> aushalten der je nach Tag und Zeit zwei GigE-Interfaces halb bis 3/4
> auslasted.
Verstehe ich dich richtig, daß da einkommend und ausgehend je zwei GigE
Interfaces sind?
Das ist jenseits der Architektur von Aldi-PCs, keine Frage.
Es ist also auf jeden Fall eine Hardware-Frage, die man mit 64-bit 66
MHz PCI hinkriegen können sollte, solange man genügend viele PCI-Busse
hat. Linux supportet so etwas, aber ich habe es noch nicht in den
Händen gehabt.
Ob die CPU mit der Bandbreite klar kommt hängt natürlich von der Anzahl
der Subnetze habt, die ihr durchlassen wollt, und von der Verteilung der
Pakete auf diese Subnetze.
Wenn da tatsächlich nur statisches Egress-Filtern stattfinden soll, kann
man das natürlich auch kostensparend auf mehrere Filter-Boxen verteilen.
> Das ist eine Menge hysterischer Kram drin, das SNA-gerutsche z.B., und
> dank der Attacken im Januar ist dieser Kunde auch ganz erpicht darauf
> ein IDS mit einer netten Packetrate zu haben. Die letzte
> Implementation einer Firewall, die GigE abkonnte (ich gehe immer von
> einer Netzauslastung von 65% aus) waren 16 Solaris-Kisten mit ipf, die
> dann spaeter gegen 12 Kisten mit FW-1 ausgetauscht wurden,
> L4-geswitcht.
Ich kann nicht glauben, daß man dafür ernsthaft 12 Kisten braucht. Oder
ist das doppelt redundant für Failover?
> Meine Argumentation liest sich in etwa so: Ich habe keine Probleme mit
> aktuellen Releases der PIX FW. In der Vergangenheit sind vier Exploits
> auf meine Nerven gegengen von denen ich alle, zum Glueck, im heissen
> Test am Netz gefunden habe. Ciscos FW-Team ist schnell, wenn man einen
> BUg meldet ist das neue Image im Normalfall in 2-3 Tagen draussen, bei
> boesen blopps auch mal nach 4 Stunden.
Das ist zwar alles nett, aber Cisco hat mein Vertrauen komplett
verspielt seit dieser Sache mit der EU. Für Sicherheitsbelange würde
ich schon deshalb niemals Cisco einsetzen, wenn nicht jemand mit einer
großen Pistole hinter mir steht.
> Ich kenne mich mit ipchains nicht soo besonders aus, ich verwende
> OpenBSD fuer's Firewalling und da kenne ich zumindes 5 bugs die ich
> nicht gesehen haette haette mir nicht Jemand den Kopf druaf gestossen
> - mag meine eigene Unfaehigkeit sein oder einfach die Tatsache dass
> man erstmal drauf kommen muss.
ipchains ist nicht der aktuelle Stand der Technik bei Linux, reicht aber
für das statische Filtern aus. OpenBSD mag mich nicht sonderlich, aber
ich hatte im Hinterkopf, daß da im User Space gefiltert wird, korrekt?
Das wäre in einer Konfiguration wie deiner ein Ausschlußkriterium wegen
der Performance.
> Ich halte den Einwand der "ist nicht OSS" fuer valide, aber Du gibst
> selbst zu dass schon wenn Du eine Cryptocard brauchst, Du einen Teil
> der Sicherheitsloesung nicht mehr kennst - was schade aber fuer
> gewisse Situationen (noch) nicht vermeidbar ist.
Zur Cryptocard schrieb ich gerade zu jemand anderem etwas.
Ich sehe da kein ernsthaftes Risiko.
> Was in 1 Jahr ist, weiss ich nicht. Vielleicht setzen Leute dann Dein
> oder mein System ein und wir schaffe es, Alles das zu implementieren
> was bisher noch fehlt, aber die allgemeine Aussage "nimm OSS, das ist
> besser" kann ich nicht bestaetigen.
Das war auch nicht die Aussage.
Der Quellcode zum Betriebssystem meines Fernsehers liegt mir auch nicht
vor.
Die Aussage war: nimm OSS, wenn du die Wahl hast.
Felix
--
Mitchell's Law of Committees:
Any simple problem can be made insoluble if
enough meetings are held to discuss it.
Lutz Donnerhacke
>Das ist zwar alles nett, aber Cisco hat mein Vertrauen komplett verspielt
>seit dieser Sache mit der EU. Für Sicherheitsbelange würde ich schon
>deshalb niemals Cisco einsetzen, wenn nicht jemand mit einer großen
>Pistole hinter mir steht.
*Hmm* Wenn Du die Geschicht mit den GATT Verhandlungen meinst, so muß ich
Dir sagen, daß mich das breite Grinsen des CISCO Technikers immer noch
fasziniert, als ich ihm eine halbe Stunde vor Vortragsbeginn mitteilte, ich
würde diesen Fall erwähnen. Sein Kommentar war nur noch: "Was können wir
dafür, daß man unsere Geräte nicht richtig konfigurierte?"
Philipp Hemker
> > Irgendwie erinnert mich das an deinen Bericht bzgl.
> > FTP-Server mit Gigabit-Ethernet auf x86...
> Das waren Limits der PC-Architektur.
> Wer sagt dir, daß die gleiche OSS-Software auf einer S390 das gleiche
> Problem hätte?
Ich sage mir, daß die Software auch auf x86 kein Problem hatte.
> Wir gehen natürlich von der Prämisse aus, daß die Software auf der
> gleichen Art Hardware läuft wie Kommerz-Software, sonst ist das kein
> Software-Vergleich, sondern Schwachsinn.
Software ansich unterliegt keinen Beschränkungen. Im weiteren Verlauf
des Threads erwähnst du selbst zB. 64bit PCI und einen ausreichend
schnellen Prozessor als Vorraussetung - was die Menge der verfügbaren
Firewall/Paketfilter-Software vielleicht etwas einschränkt.
<news:slrn92in9...@baileys.convergence.de>
> Es ist also auf jeden Fall eine Hardware-Frage
bis dann,
philipp
--
Felix von Leitner
> >Das ist zwar alles nett, aber Cisco hat mein Vertrauen komplett verspielt
> >seit dieser Sache mit der EU. Für Sicherheitsbelange würde ich schon
> >deshalb niemals Cisco einsetzen, wenn nicht jemand mit einer großen
> >Pistole hinter mir steht.
> *Hmm* Wenn Du die Geschicht mit den GATT Verhandlungen meinst, so muß ich
> Dir sagen, daß mich das breite Grinsen des CISCO Technikers immer noch
> fasziniert, als ich ihm eine halbe Stunde vor Vortragsbeginn mitteilte, ich
> würde diesen Fall erwähnen. Sein Kommentar war nur noch: "Was können wir
> dafür, daß man unsere Geräte nicht richtig konfigurierte?"
Das hätte ich als Cisco Techniker auch gesagt.
Felix
Lutz Donnerhacke
Selbst Du kannst nicht so aussagekräftig grinsen.
Felix von Leitner
> >Das hätte ich als Cisco Techniker auch gesagt.
> Selbst Du kannst nicht so aussagekräftig grinsen.
Oha. Hast du ein Photo gemacht? ;-)
Felix