[buug-l] Vortrag?

[Alexander Stielau]

Am Tue, Feb 04, 2003 at 02:02:26AM +0100 schrieb Christoph Biedl:
> Alexander Stielau wrote...
> 
> > Hmm. Also das shreckliche shrekskript[1] stelle ich gerne vor, aber das
> > ist eigentlich eher was für @home und als Grundlage, wie iptables zuckt. 
> 
> .. und ich habe daran gut gelernt und hoffentlich auch mein Quentchen
> Feedback zurückgegeben.

Jup, hast du.

Da nun der HTP-Patch im Kernel ist (ab 2.4.20), muß ich das mal um
trafficshaping erweitern...
 
> > Das, was wir kommerziell einsetzen, eher ungerne. Das ist zwar
> > Opensource, aber damit verdienen wir unser Geld :)
> 
> Schade, aber verständlich. Ich habe mich seinerzeit von Deinen Skripten
> ausgehend ziemlich stark weiterentwickelt. Um dann irgendwann zu erkennen,
> daß ich vier verschiedene Rechner in erheblich mehr Konfigurationen (drei
> _sehr_ verschiedene Router, ein Notebook an vier oder fünf verschiedenen
> Standorten mit jeweils sehr unterschiedlicher Konfiguration) durch packet
> filtering absichern will und der Wartungsaufwand für handgeschriebene
> Skripte ins Unabsehbare steigt. Also habe ich kurzerhand das Rad neu
> erfunden und einen Generator geschrieben, der anhand einer Liste "Welche
> Interfaces gibt es auf diesem System, und welcher traffic ist zwischen
> ihnen erlaubt" das jeweilige Skript neu baut, so daß ich Erkenntnisgewinne
> wie den SYN flaw in <= 2.4.19 nur einmal einpflegen muß. Und dessen
> Resultat hätte ich doch gerne mal mit dem verglichen, was die Profis so
> machen.

Wir machen das aus deiner Sicht wahrscheinlich erschreckend primitiv. 
Aber einfach ist einfach und vermindert Fehler :)

Es gibt ein Grundgerüst, in dem werden die üblichen Variablen und Regeln 
(üblich im Sinne von schon mal vorgekommen) gesammelt, und dann je nach 
Kundencheckliste ein- oder auskommentiert und durch Spezialkram 
ergänzt.

Dies generisch zu lösen, also etwas zu Schreiben, was nach dem Einwerfen
von Grunddaten einen Regelsatz entwirft, macht aus meiner Sicht deutlich
mehr Arbeit, als jeweils vorhandene Bausteine (z.B. transparenter Proxy,
Mailserver in der DMZ) zusammenzukleben, weil die Kundenwünsche doch
sehr unterschiedlich sind, z.B.:

Kunde1 hat nen sdsl-Zugang, Portforwarding auf nen Web- und Mailserver
  in einer dmz, dazu ein internes Netz. 
  Teile der Mitarbeiter haben Zugriff auf z.B. ftp, andere nicht,
  Webmailer sollen gesperrt sein (ob das sinnvoll ist, steht nicht zur
  Debatte, Kundenwunsch eben).

Kunde2 hat nur ein internes Netz, aber dafür einen Tunnel zur
  Hauptniederlassung (die haben auch Kindernetz) und einen Wartungszugang
  für ne Fremdfirma und deren seltsame Spezialhardware. 

Kunde3 bestellt einen filternden Router mit 5 Beinen, der unglaublich
  fein abstuft, wie man von wo an welche tomcat-Server ran kann, und will
  über zwei Beine nfs-Traffic mit wechselnden Server-Ports und Accounting 
  auf alles, was nicht auf den Webserver Numero 3 geht.

Kunde4 hat isdn-dod und Kanalbündelung bei Last mit Webfrontend für 
  alle Mitarbeiter zum Schalten von 'immer an' 'dod' 'wochenende/nacht 
  (aus)' mit Squid, lokalem Mailserver.

Kunde5 schickt Beistellhardware mit Dual-PIII/SCSI-Raid 
  für Failover-Packetfilter und ner ganzen Farm Tarantella-Server dahinter.

Dazwischen bewegt es sich bei uns irgendwie - nicht besonders ähnliche
Ansprüche... :)


Das Problem der Wartung haben wir sowieso, aber aus nem etwas anderen
Grund:
Unsere Kunden bestellen ja solchen Kram, weil sie nicht das Know-How
haben (oder haben wollen), das heißt, wir warten die meisten Kisten auch 
im laufenden Betrieb, neben Neuwünschen (Geschäftsleitung braucht
nun doch Webmailer und Porno^Wedonkey, Mail liegt ab morgen auf IP X)
das Filtering betreffend haben wir auch die Kisten selbst am Wickel (und
dazu auch tatsächlich eine Datenbank, die uns tagesaktuell sagt, welche 
Software-Revision von welchem Package wo installiert ist, und das spart
ne Menge rumsucherei - wo ist den nun noch überall kaputte Version von X
installiert[1]).

Bei Änderungswünschen machen wir dies in der Regel direkt vor Ort,
vorgesehen ist es, alle Regelskripte im CVS vorzuhalten, was in der
Praxis aber kaum passiert (eine neue Mailservererlaubnis ist ratzfatz
eingetragen, die Datei aber von dem Rechner runterzubekommen und ins CVS
und wieder zurück ist Arbeit).

Ein Generator hat aus meiner Sicht dazu den Nachteil, das es keine
indivuduellen Kommentare mehr gibt, die ich benötige, um schnell was
wiederzufinden und auch um die Geschichte einer Regel nachvollziehen zu
können ('äh? wer hat das denn warum gemacht?').




Wir haben da zufällig gestern lange drüber diskutiert, aber eigentlich 
ist das, was wir da haben, nicht ein Produkt, sondern ein Projekt im 
Sinne von 'kann nur fertig an den Kunden ausgeliefert werden' im Gegensatz 
zu einer Installations-CD, die der Kunde einschiebt, und dann geht 'es',
was immer 'es' bedeutet.

> > Das kann ich vorstellen - interessiert wäre ich an einer kompetenten
> > Betrachtung von alternativen, z.B. duch Philipp und spamassessin/spand.
> 
> [x] make it so

Herr Grau, sag mal was.

> Ich selbst bin wahrscheinlich nur für ein Plauderstündchen "Was Ihnen
> alles an einem größeren abuse desk an ganz alltäglichem Wahnsinn
> widerfährt" gut. Das allerdings paßt auf keine Kuhhaut.

*tätschel*

Wärste mal neulich auch gekommen, dann hätten wir dich bestimmt
getröstet und keine komischen Fragen über den Weiterbetrieb von
irgendwas gestellt, keine Angst.

Aleks

[1]
Das sieht ungefähr so aus: http://oerks.de/bilder/kd.jpg
Frank hats gebaut und es basiert im wesentlichen auf debsums, md5 und ssh...

Das wäre vielleicht auch interessant vorzustellen, gerade für Leute, die
einen Arsch voll Rechner haben, die eben nicht identisch sind, weil auch
noch andere Leute darauf rumfrickeln.

-- 
Das heißt also Absenkung des Nach..., des, des, des, des, des, na, des Alters,
des Alters der Kinder, wenn sie, des Nachzugalters; dann kommt der fünfte Punkt,
und der sechste Punkt kommt dann sicherlich die Frage gleichge..., äh, nicht 
gleichgeschle..., sondern äh, ...   Edmund S. 20.1.2002, ARD in 'S.Christiansen'