named hinter FW
Gernot Zander
ich habe auf einer Kiste (wo ich mir nichts aussuchen kann)
einen named 4.9.8-REL. Kernel 2.0.34 (kann ich mir auch nicht
aussuchen).
Die Kiste geht mit T-DSL ans Netz (ppp0).
Ich würde den named gern von außen absperren, jedoch scheint
er mit Source-Port 53 rauszugehen, sodass die Antworten auch
an 53 kommen, und wenn ich 53 also nicht für ppp0 aufmache,
kriegt er keine Antworten... Kann man schön am ipfwadm (kann
ich mir auch nicht aussuchen) sehen, wenn ich -o dazugebe.
-k bringt nichts, ich kann damit trotzdem von außen drauf...
Leider kann ich den auch nicht an die internen Interfaces
biden...
Kann ich da noch was tun?
Der 8er bind geht ja mit einem anderen Source-Port (1025) nach
draußen, wenn ich das richtig sehe?!
mfg.
Gernot
--
<hi...@gmx.de> (Gernot Zander) www.kabelmax.de *Keine Mailkopien bitte!*
Wenn dem Bürger das letzte Hemd abgenommen wurde, erhebt der
Finanzminister eine FKK-Steuer!
(Carsten Albrecht <c.alb...@mikona.dinet.com>)
Juergen P. Meier
>ich habe auf einer Kiste (wo ich mir nichts aussuchen kann)
>einen named 4.9.8-REL. Kernel 2.0.34 (kann ich mir auch nicht
>aussuchen).
Unschoen.
>Die Kiste geht mit T-DSL ans Netz (ppp0).
Das koennte man schon fast als "kriminell" bezeichnen.
>Ich würde den named gern von außen absperren, jedoch scheint
>er mit Source-Port 53 rauszugehen, sodass die Antworten auch
>an 53 kommen, und wenn ich 53 also nicht für ppp0 aufmache,
>kriegt er keine Antworten... Kann man schön am ipfwadm (kann
>ich mir auch nicht aussuchen) sehen, wenn ich -o dazugebe.
>-k bringt nichts, ich kann damit trotzdem von außen drauf...
Ist ja auch UDP, das kennt die TCP flags nicht.
>Leider kann ich den auch nicht an die internen Interfaces
>biden...
>Kann ich da noch was tun?
Entweder den kernel gegen einen 2.4er oder einen 2.2er mit
netfilter patches austauschen, oder besser: den bind4 gegen
einen aktuellen bind 8 oder 9 oder gegen einen djbdns austauschen.
>Der 8er bind geht ja mit einem anderen Source-Port (1025) nach
>draußen, wenn ich das richtig sehe?!
Er macht das, was du ihm sagst. (sprich, was in seiner konfig steht)
Sprich: er kann sowohl als auch, jenachdem was du einstellst.
Juergen
--
J...@lrz.fh-muenchen.de
"This World is about to be Destroyed!"
Wolfgang Kueter
>
> * Gernot Zander <hi...@gmx.de> schrieb:
>
> > ich habe auf einer Kiste (wo ich mir nichts aussuchen kann) einen
> > named 4.9.8-REL. Kernel 2.0.34 (kann ich mir auch nicht aussuchen).
>
Das könnte eine alte Cobalt Kiste sein, die kamen gerne mit Kernel
2.0.34
Wenn es Cobalt ist, dann Updates nur von Cobalt ...
Wolfgang
Felix von Leitner
> ich habe auf einer Kiste (wo ich mir nichts aussuchen kann)
> einen named 4.9.8-REL. Kernel 2.0.34 (kann ich mir auch nicht
> aussuchen).
Für beides gilt: _großer_ Fehler.
> Ich würde den named gern von außen absperren, jedoch scheint
> er mit Source-Port 53 rauszugehen, sodass die Antworten auch
> an 53 kommen, und wenn ich 53 also nicht für ppp0 aufmache,
> kriegt er keine Antworten... Kann man schön am ipfwadm (kann
> ich mir auch nicht aussuchen) sehen, wenn ich -o dazugebe.
> -k bringt nichts, ich kann damit trotzdem von außen drauf...
> Leider kann ich den auch nicht an die internen Interfaces
> biden...
> Kann ich da noch was tun?
Bind -> Tonne.
Uralt-Kernel -> Tonne.
> Der 8er bind geht ja mit einem anderen Source-Port (1025) nach
> draußen, wenn ich das richtig sehe?!
Der 8er bind ist auch langsam, unsicher und auch anderweitig
minderwertig.
Aber wenn du den Kernel nicht updatest, nützt dir djbdns nicht viel.
Felix
Felix von Leitner
> Kennt bind4 eigentlich schon ACLs und Optionen wie 'listen-on'?
Who cares? Die Software ist so derartig obsolet, daß sich selber das
ISC mit Magenverstimmungen abgewendet hat. Und das ist ein starkes
Stück für die offizielle Resteverwertungseinrichtung des Internets.
Die "warten" schließlich auch BIND 8 (yuck), INN (kotz) und diese
grottige DHCP-Implementation.
Das muß einfach mal alles gesammelt in die Tonne.
Felix
Gernot Zander
in de.comp.security.firewall Wolfgang Kueter <wku...@more-it.net> wrote:
> Heiko Schlenker wrote:
>>
>> * Gernot Zander <hi...@gmx.de> schrieb:
>>
>> > ich habe auf einer Kiste (wo ich mir nichts aussuchen kann) einen
>> > named 4.9.8-REL. Kernel 2.0.34 (kann ich mir auch nicht aussuchen).
>>
>> Es ist Halloween-Zeit.
> Das könnte eine alte Cobalt Kiste sein, die kamen gerne mit Kernel
> 2.0.34
Erraten...
> Wenn es Cobalt ist, dann Updates nur von Cobalt ...
Es ist mir immerhin gelungen, ein eigenes ipfwadm-Script
unterzuschieben. Und nein, listen-on kennt der named dort nicht.
mfg.
Gernot
--
<hi...@gmx.de> (Gernot Zander) www.kabelmax.de *Keine Mailkopien bitte!*
chmod a+x /bin/laden
Juergen P. Meier
>> Das könnte eine alte Cobalt Kiste sein, die kamen gerne mit Kernel
>> 2.0.34
>
>Erraten...
>
>> Wenn es Cobalt ist, dann Updates nur von Cobalt ...
>
>Es ist mir immerhin gelungen, ein eigenes ipfwadm-Script
>unterzuschieben. Und nein, listen-on kennt der named dort nicht.
Wende dich vertrauensvoll an deinen Sun Microsystems Support.
Wenn das nicht klappt oder du keinen Support mehr hast, dann ersetze halt
das Cobalt-OS durch eiene besser geeignete/gewartete Linux distribution.
Debian Potato (mit bunk's 2.4er patches) ware da eine der Empfehlungen.
Du kannst dann halt nicht mehr so schoen bunt mit einem WebGUI einstellungen
machen, aber das ist ja auch nicht wirklich erstrebenswert.
Eric Wick
> an 53 kommen, und wenn ich 53 also nicht für ppp0 aufmache,
> kriegt er keine Antworten... Kann man schön am ipfwadm (kann
53 eingehend habe ich für den DNS-Proxy auf die 4 Forwarder beschränkt
(ipchains), nur mit Spoofing könnte da jemand dran und kriegt dann
wohl auch keine Antwortpakete.
> Der 8er bind geht ja mit einem anderen Source-Port (1025) nach
> draußen, wenn ich das richtig sehe?!
Das würde jemand per Portscanner ebenso herausfinden können.
Gruß
Eric
--
Linuxgateway, L-Notebook, Drucker, Hardwareentlärmung, Amiga
SN-Newsserver, Netzwerk, Digi-Fotografie, Speeddragon, LCD
LANG=DE only: http://www.ew-tech-hh.de : Mail limited 2.5MB
Bernd Eckenfels
>> Der 8er bind geht ja mit einem anderen Source-Port (1025) nach
>> draußen, wenn ich das richtig sehe?!
> Das würde jemand per Portscanner ebenso herausfinden können.
Nun ja, mal abgeshen davon dass Source-Port kein Listening Port ist, ist es
natuerlich kein Geheimnis welchem Port man verwendet, aber die Tatsache dass
es ein fester Port ist, hilft beim unterscheiden.
Gruss
Bernd
Gernot Zander
in de.comp.security.firewall Eric Wick <eric...@gmx.de> wrote:
> Gernot Zander <hi...@gmx.de> wrote:
>> an 53 kommen, und wenn ich 53 also nicht für ppp0 aufmache,
>> kriegt er keine Antworten... Kann man schön am ipfwadm (kann
> 53 eingehend habe ich für den DNS-Proxy auf die 4 Forwarder beschränkt
> (ipchains), nur mit Spoofing könnte da jemand dran und kriegt dann
> wohl auch keine Antwortpakete.
Ja, leider ist der aber nicht als Forwarder konfiguriert, und
ausgerechnet das kann ich nicht ändern (die Konfig wird
aus einer DB per Script erzeugt, an die Scripte darf und will
ich nicht ran).
>> Der 8er bind geht ja mit einem anderen Source-Port (1025) nach
>> draußen, wenn ich das richtig sehe?!
> Das würde jemand per Portscanner ebenso herausfinden können.
_Nach_ draußen! Er nimmt auf dem Port aber keine Requests
an! Es könnte nur jemand die Antworten faken...
mfg.
Gernot
--
<hi...@gmx.de> (Gernot Zander) www.kabelmax.de *Keine Mailkopien bitte!*
Gefährlich ist es, wenn Dumme fleißig werden.
Gernot Zander
in de.comp.security.firewall Juergen P. Meier <J...@lrz.fh-muenchen.de> wrote:
> Gernot Zander <hi...@gmx.de> wrote:
>>> Das könnte eine alte Cobalt Kiste sein, die kamen gerne mit Kernel
>>> 2.0.34
>>
>>Erraten...
>>
> Wende dich vertrauensvoll an deinen Sun Microsystems Support.
> Wenn das nicht klappt oder du keinen Support mehr hast, dann ersetze halt
> das Cobalt-OS durch eiene besser geeignete/gewartete Linux distribution.
> Debian Potato (mit bunk's 2.4er patches) ware da eine der Empfehlungen.
> Du kannst dann halt nicht mehr so schoen bunt mit einem WebGUI einstellungen
> machen, aber das ist ja auch nicht wirklich erstrebenswert.
Leider doch - denn es soll so sein, dass ich nicht der einzige
bin, der damit was anfangen kann.
Der Qube 2.0 soll genaugenommen einen bereits existierenden
Linux-Server ersetzen und wurde mir sozusagen vor die Nase
gesetzt. Ich hatte ehrlich nicht geglaubt, dass es noch
Systeme mit 2.0.x gibt, und dass die sogar neu verkauft
werden... Entsprechend mein Gesicht...
Konkret: Alle Berliner Schulen (die es wollten, müssen
sehr viele sein) haben den bekommen mit dem Hinweis, dass
Support nur noch gegeben werde, wenn man den benutzt und
auch darüber ins Netz geht. Und sie sind fix auf einen
zentralen Mailserver eingestellt usw. usf.
Die Idee ist ja nicht schlecht (schließlich gibt's nicht
an jeder Schule jemanden, der einen halbwegs annehmbaren
Admin abgibt). Nur die Ausführung...
Ich muss also minimalinvasive Eingriffe machen, die mit
nichts kollidieren...
Offenbar hat Sun es geschafft, den Beschaffern das Ding einzureden
und konnte die noch verbliebenen Lagerbestände erfolgreich zu
Geld machen. Und ich steh jetzt da mit einem Scheißding, das
ich am liebsten aus dem Fenster schmeißen würde.
Übrigens, da der keine normale Intel-Architektur ist,
sondern Mips und wasweißich als Bios - mit Lilo bootet
er jedenfalls nicht - wüsste ich auch gar nicht, wie
ich da einen anderen Kernel booten könnte. Und Quellen
für das LC-Display (Moni hat er ja nicht) sind natürlich
auch nicht bei.
mfg.
Gernot
--
<hi...@gmx.de> (Gernot Zander) www.kabelmax.de *Keine Mailkopien bitte!*
Strom macht klein, schwarz und häßlich.
Guido Stepken
> Hi,
>
> ich habe auf einer Kiste (wo ich mir nichts aussuchen kann)
> einen named 4.9.8-REL. Kernel 2.0.34 (kann ich mir auch nicht
> aussuchen).
> Die Kiste geht mit T-DSL ans Netz (ppp0).
> Ich würde den named gern von außen absperren, jedoch scheint
> er mit Source-Port 53 rauszugehen, sodass die Antworten auch
> an 53 kommen, und wenn ich 53 also nicht für ppp0 aufmache,
> kriegt er keine Antworten... Kann man schön am ipfwadm (kann
> ich mir auch nicht aussuchen) sehen, wenn ich -o dazugebe.
> -k bringt nichts, ich kann damit trotzdem von außen drauf...
> Leider kann ich den auch nicht an die internen Interfaces
> biden...
> Kann ich da noch was tun?
Ja, auf Linux 2.4.13+ und iptables umsteigen. Diese Firewall ist dann
Statefull, und behandelt UDP Pakete dann so, als wenn sie ein SYS-Flag
hätten, d.h. das Senden eines UDP Paketes aus dem Internet durch die
Firewall an den DNS-Server im Intranet wird somit unterbunden.
Antwortpakete hingegen werden zugelassen. Für 10 Sekunden bleibt dann der
UDP Port dieser bestimmten IP-Nummer für UDP Zugriff von außen offen.
Deine Firewallkonstrunktion ist in wenigen Minuten zu durchtunneln. Man
nehme einfach einen BufferOverlow für BIND und schon ist man durch die
Firewall hindurch. Bei Deinen Versionsnummern benötige ich ca. 10 Minuten,
um den Exploit zu finden, und weitere 2 Minuten, um diesen zu kompilieren
und zu starten. Danach habe ich zumindest eine User-Shell, sofern Du mit
RedHat arbeitest, oder eine root-Shell, sofern Du mit SuSE 6.x arbeitest.
Ich habe vor einigen Wochen genau einen solchen Angriff analysiert.
Dabei hat ein Hacker auf dem Intranetserver einen Trojaner installiert
(w0rm von Hacers without attitude).
Vermeide also bitte unbedingt solche Konstruktionen, sie sind grob
fahrlässig.
Gru/3, Guido Stepken
Felix von Leitner
> Ja, auf Linux 2.4.13+ und iptables umsteigen. Diese Firewall ist dann
> Statefull, und behandelt UDP Pakete dann so, als wenn sie ein SYS-Flag
> hätten,
Im IP-Header gibt es kein SYS-Flag.
Im UDP-Header gibt es kein SYS-Flag.
Stateful schreibt man mit einem l.
Du weißt nicht, wovon du sprichst.
> d.h. das Senden eines UDP Paketes aus dem Internet durch die
> Firewall an den DNS-Server im Intranet wird somit unterbunden.
Unfug.
> Antwortpakete hingegen werden zugelassen.
Antwortpakete aus dem Internet sind auch UDP-Pakete aus dem Internet und
du kannst ihnen genau gar nicht ansehen, daß sie nicht gespooft sind.
> Für 10 Sekunden bleibt dann der UDP Port dieser bestimmten IP-Nummer
> für UDP Zugriff von außen offen.
Boah, ey. Und das hilft konzeptionell... wogegen? Richtig: gar nicht.
In 10 Sekunden kann ich locker 65535 UDP-Pakete rausschicken.
> Deine Firewallkonstrunktion ist in wenigen Minuten zu durchtunneln. Man
> nehme einfach einen BufferOverlow für BIND und schon ist man durch die
> Firewall hindurch.
Wer BIND einsetzt, ist eh ein Idiot.
Gut, little-idiot.de steht bei einem Hoster, daher wollen wir mal nicht
so sein, aber da fährt z.B. BIND 8.2.3-REL. Gutes Zeichen dafür, daß
man da nicht gehostet werden will. Ich würde an deiner Stelle das Maul
nicht gar so weit aufreißen.
> Bei Deinen Versionsnummern benötige ich ca. 10 Minuten,
> um den Exploit zu finden, und weitere 2 Minuten, um diesen zu kompilieren
> und zu starten. Danach habe ich zumindest eine User-Shell, sofern Du mit
> RedHat arbeitest, oder eine root-Shell, sofern Du mit SuSE 6.x arbeitest.
> Ich habe vor einigen Wochen genau einen solchen Angriff analysiert.
> Dabei hat ein Hacker auf dem Intranetserver einen Trojaner installiert
> (w0rm von Hacers without attitude).
Ui, wie l33t!1!!
> Vermeide also bitte unbedingt solche Konstruktionen, sie sind grob
> fahrlässig.
Vielleicht liest du dir erst mal in Ruhe http://learn.to/quote durch,
bevor du hier wieder rumpupst.
[überflüssiges Müll-Quoting entsorgt]
Guido Stepken
> Thus spake Guido Stepken (ste...@little-idiot.de):
>> Ja, auf Linux 2.4.13+ und iptables umsteigen. Diese Firewall ist dann
>> Statefull, und behandelt UDP Pakete dann so, als wenn sie ein SYS-Flag
>> hätten,
>
> Im IP-Header gibt es kein SYS-Flag.
Stimmt, habe ich nicht behauptet.
> Im UDP-Header gibt es kein SYS-Flag.
Genau. Habe ich auch nie behauptet. Das SYS Flag wird von Paketfiltern
verwendet, um festzustellen, aus welcher Richtung eine Verbindung initiiert
wurde (3 - Wege - Handshake) und von wo aus also Antwortpakete erwartet
werden, d.h. passieren dürfen.
> Stateful schreibt man mit einem l.
freudsche Fehlleistung.
> Du weißt nicht, wovon du sprichst.
>
Ich weiß, daß ich nichts weiß - und noch nicht einmal das !
>> d.h. das Senden eines UDP Paketes aus dem Internet durch die
>> Firewall an den DNS-Server im Intranet wird somit unterbunden.
>
> Unfug.
Nein. Bei "nicht stateful firewalls" muß man die UDP/53 Regeln so
gestalten, daß bidirektional Pakete passieren dürfen.
>
>> Antwortpakete hingegen werden zugelassen.
>
> Antwortpakete aus dem Internet sind auch UDP-Pakete aus dem Internet und
> du kannst ihnen genau gar nicht ansehen, daß sie nicht gespooft sind.
>
Das ist korrekt. Das gilt aber für reine IP Pakete allgemein (nicht IPSec
mit AH !)
>> Für 10 Sekunden bleibt dann der UDP Port dieser bestimmten IP-Nummer
>> für UDP Zugriff von außen offen.
>
> Boah, ey. Und das hilft konzeptionell... wogegen? Richtig: gar nicht.
> In 10 Sekunden kann ich locker 65535 UDP-Pakete rausschicken.
>
Ich war auch etwas erstaunt, als ich mir den Quellcode von Linux abgesehen
habe, und feststellen mußte, daß hier einige Timeouts eine wichtige Rolle
spielen. Dasselbe gilt auch für die Makrosprache der Checkpoint. Da gibt es
Timeouts für UDP Antwortpakete und diverse IP-Flags.....SYN/SYN-ACK. Siehe
auch PROC-Mechanismus /proc/sys/net/ipv4/...timeout....unter Linux.
>> Deine Firewallkonstrunktion ist in wenigen Minuten zu durchtunneln. Man
>> nehme einfach einen BufferOverlow für BIND und schon ist man durch die
>> Firewall hindurch.
>
> Wer BIND einsetzt, ist eh ein Idiot.
Hast Du eine Alternative, die es erlaubt, DNS im Intranet aufzusetzen, der
dann auch als forwarder Server im Internet befragen darf ?
>
> Gut, little-idiot.de steht bei einem Hoster, daher wollen wir mal nicht
> so sein, aber da fährt z.B. BIND 8.2.3-REL. Gutes Zeichen dafür, daß
> man da nicht gehostet werden will. Ich würde an deiner Stelle das Maul
> nicht gar so weit aufreißen.
Du erscheinst mir recht streitbar, warum ?
>> Vermeide also bitte unbedingt solche Konstruktionen, sie sind grob
>> fahrlässig.
>
> Vielleicht liest du dir erst mal in Ruhe http://learn.to/quote durch,
> bevor du hier wieder rumpupst.
Danke für die Belehrung. Ich werde stets an Dich als freundliches und
bescheidenes Vorbild denken....;-))
> [überflüssiges Müll-Quoting entsorgt]
>
Guido Stepken
> Gut, little-idiot.de steht bei einem Hoster, daher wollen wir mal nicht
> so sein, aber da fährt z.B. BIND 8.2.3-REL. Gutes Zeichen dafür, daß
> man da nicht gehostet werden will. Ich würde an deiner Stelle das Maul
> nicht gar so weit aufreißen.
Hmm, mal nachschauen ....:
http://www.isc.org/products/BIND/bind-security.html
Welchen (bekannten) BUG hat denn die Version BIND 8.2.3 sonst noch ? Hast
Du weitere Tips ?
Gru/3, Guido Stepken
Sebastian Jaenicke
>
> Genau. Habe ich auch nie behauptet. Das SYS Flag wird von Paketfiltern
> verwendet, um festzustellen, aus welcher Richtung eine Verbindung initiiert
> wurde (3 - Wege - Handshake) und von wo aus also Antwortpakete erwartet
> werden, d.h. passieren dürfen.
[X] Du laberst Muell.
--
Sebastian Jaenicke
whois pgpkey-...@whois.ripe.net|perl -ne's-^certif: +--&&print'
Guido Stepken
> * Guido Stepken <ste...@little-idiot.de> wrote:
>>
>> Genau. Habe ich auch nie behauptet. Das SYS Flag wird von Paketfiltern
>> verwendet, um festzustellen, aus welcher Richtung eine Verbindung
>> initiiert
>> wurde (3 - Wege - Handshake) und von wo aus also Antwortpakete erwartet
>> werden, d.h. passieren dürfen.
>
> [X] Du laberst Muell.
>
>
SYN Flag, sorry !
Gernot Zander
in de.comp.security.firewall Guido Stepken <ste...@little-idiot.de> wrote:
> Ja, auf Linux 2.4.13+ und iptables umsteigen. Diese Firewall ist dann
...
Du hast bitte meine Frage gelesen? Zur Erinnerung nochmal:
> ich habe auf einer Kiste (wo ich mir nichts aussuchen kann)
> einen named 4.9.8-REL. Kernel 2.0.34 (kann ich mir auch nicht
> aussuchen).
Diese Ratschläge helfen mir genau nicht - die kenne ich
selbst, da hätte ich hier nicht gefragt.
mfg.
Gernot
--
<hi...@gmx.de> (Gernot Zander) www.kabelmax.de *Keine Mailkopien bitte!*
Dieser Artikel besteht ausschließlich aus recyclebaren Zeichen.
Öffnen Sie nach dem Bildlöschen die kleine Klappe unten am Monitor,
entnehmen Sie die gebrauchten Buchstaben und führen Sie diese einer
ordnungsgemäßen Entsorgung zu.
Felix von Leitner
> >> Ja, auf Linux 2.4.13+ und iptables umsteigen. Diese Firewall ist dann
> >> Statefull, und behandelt UDP Pakete dann so, als wenn sie ein SYS-Flag
> >> hätten,
> > Im IP-Header gibt es kein SYS-Flag.
> Stimmt, habe ich nicht behauptet.
> > Im UDP-Header gibt es kein SYS-Flag.
> Genau. Habe ich auch nie behauptet. Das SYS Flag wird von Paketfiltern
> verwendet, um festzustellen, aus welcher Richtung eine Verbindung initiiert
> wurde (3 - Wege - Handshake) und von wo aus also Antwortpakete erwartet
> werden, d.h. passieren dürfen.
UDP hat auch kein 3-Wege-Handshake.
> >> d.h. das Senden eines UDP Paketes aus dem Internet durch die
> >> Firewall an den DNS-Server im Intranet wird somit unterbunden.
> > Unfug.
> Nein. Bei "nicht stateful firewalls" muß man die UDP/53 Regeln so
> gestalten, daß bidirektional Pakete passieren dürfen.
Da UDP kein Handshake hat, kann jeder jeden Absender eintragen, ohne daß
er die TCP-Daten (Window, Sequence Number) raten muß. Bei DNS über UDP
muß er
a) die 16-bit Port-Nummer raten. Bei BIND 4 und 8 vor den bleeding
edge Versionen ist das auch noch konstant 53.
b) eine 16-bit Nummer im DNS-Header raten.
Das ist also ABSOLUT TRIVIAL zu raten, d.h. selbst ein allwissender
Paketfilter kann Spoofing bei DNS nicht verhindern. D.h. selbst wenn er
funktionieren würde, würde er nicht helfen. Aber das hast du ja nicht
behauptet, sondern du hast behauptet, daß er das Senden eines
UDP-Paketes irgendwo im Internet unterbinden könnte, und daß das Unsinn
ist, muß ich ja wohl hoffentlich nicht weiter belegen?!
Auch obiger "Rettungs"-Satz ist Unfug. Natürlich müssen UDP-Pakete
in beide Richtungen erlaubt sein, mit oder ohne stateful inspection.
Man will ja fragen können und darauf Antwort kriegen.
> >> Antwortpakete hingegen werden zugelassen.
> > Antwortpakete aus dem Internet sind auch UDP-Pakete aus dem Internet und
> > du kannst ihnen genau gar nicht ansehen, daß sie nicht gespooft sind.
> Das ist korrekt. Das gilt aber für reine IP Pakete allgemein (nicht IPSec
> mit AH !)
Auch bei IPsec kannst du den Paketen nicht ansehen, ob sie gespooft sind.
Du kannst nur kryptographisch den Inhalt verifizieren.
> Ich war auch etwas erstaunt, als ich mir den Quellcode von Linux abgesehen
> habe, und feststellen mußte, daß hier einige Timeouts eine wichtige Rolle
> spielen.
Was hast du nach der Lektüre der einschlägigen RFCs denn erwartet?!
> > Wer BIND einsetzt, ist eh ein Idiot.
> Hast Du eine Alternative, die es erlaubt, DNS im Intranet aufzusetzen, der
> dann auch als forwarder Server im Internet befragen darf?
Ist das eine Trickfrage?
man djbdns
> > Gut, little-idiot.de steht bei einem Hoster, daher wollen wir mal nicht
> > so sein, aber da fährt z.B. BIND 8.2.3-REL. Gutes Zeichen dafür, daß
> > man da nicht gehostet werden will. Ich würde an deiner Stelle das Maul
> > nicht gar so weit aufreißen.
> Du erscheinst mir recht streitbar, warum ?
BIND ist übler Legacy-Müll.
Jedem, der sich im Internet über Security unterhält, muß das klar sein.
Leute müssen davor gewarnt werden. Das hast du nicht getan.
BIND 9 sah mal eine kurze Zeit ganz gut aus. Anfangs, als sie ihn
ankündigten. Aber dann kam _noch_ größere Software raus, die von einem
nmap gekillt wurde. Zusammenfassung: BIND muß sterben. Bist du nicht
Teil der Lösung, bist du Teil des Problems.
Felix
Felix von Leitner
> http://www.isc.org/products/BIND/bind-security.html
BIND _ist_ der Bug! Du hast die Liste der bisher gefundenen Bugs vor
dir und findest es immer noch vertretbar, diese Software einzusetzen!?
Bist du blind?
Juergen P. Meier
>> gestalten, daß bidirektional Pakete passieren dürfen.
>
>Da UDP kein Handshake hat, kann jeder jeden Absender eintragen, ohne daß
>er die TCP-Daten (Window, Sequence Number) raten muß. Bei DNS über UDP
>muß er
>
> a) die 16-bit Port-Nummer raten. Bei BIND 4 und 8 vor den bleeding
> edge Versionen ist das auch noch konstant 53.
>
> b) eine 16-bit Nummer im DNS-Header raten.
c) die 32-bit IP-Nummer des angefragten DNS-Servers raten. (oder aber
er betreibt diesen server selbst. Nur warum dann noch spoofen?)
>Das ist also ABSOLUT TRIVIAL zu raten, d.h. selbst ein allwissender
Da auch die IP des angefragten DNS servers geraten werden muss, nicht ganz.
>Paketfilter kann Spoofing bei DNS nicht verhindern. D.h. selbst wenn er
>funktionieren würde, würde er nicht helfen. Aber das hast du ja nicht
>behauptet, sondern du hast behauptet, daß er das Senden eines
>UDP-Paketes irgendwo im Internet unterbinden könnte, und daß das Unsinn
>ist, muß ich ja wohl hoffentlich nicht weiter belegen?!
Er unterbindet das weiterleiten von UDP paketen, die keinem Eintrag
seiner conntrack-tabelle entsprechen. Nicht mehr und auch nicht weniger.
>Auch obiger "Rettungs"-Satz ist Unfug. Natürlich müssen UDP-Pakete
>in beide Richtungen erlaubt sein, mit oder ohne stateful inspection.
>Man will ja fragen können und darauf Antwort kriegen.
Du hast das konzept der UDP-pseudostatefulness nicht verstanden?
Erst wenn der interne Resolver ein UDP paket an server a.b.c.d port 53
schickt (mit source-port xyz) dann erlaubt der Paketfilter fuer einen
gewissen timeout UDP pakete von diesem server a.b.c.d source-port 53
an den resolver zielport xyz.
Die bei stateless filtern noetige extra regel fuer DNS antworten ist eben
darum nicht laenger notwendig.
>> >> Antwortpakete hingegen werden zugelassen.
>> > Antwortpakete aus dem Internet sind auch UDP-Pakete aus dem Internet und
>> > du kannst ihnen genau gar nicht ansehen, daß sie nicht gespooft sind.
>> Das ist korrekt. Das gilt aber für reine IP Pakete allgemein (nicht IPSec
>> mit AH !)
>
>Auch bei IPsec kannst du den Paketen nicht ansehen, ob sie gespooft sind.
>Du kannst nur kryptographisch den Inhalt verifizieren.
Aber auch nur, wenn man bei IPsec AH verwendet... (jaja, das ist ne andere
Geschichte ;)
>> > Wer BIND einsetzt, ist eh ein Idiot.
>> Hast Du eine Alternative, die es erlaubt, DNS im Intranet aufzusetzen, der
>> dann auch als forwarder Server im Internet befragen darf?
>
>Ist das eine Trickfrage?
>man djbdns
Sofern man keine secondaries hat, wo man aus vielfaeltigen gruenden heraus
keinen Einfluss auf die verwendete software ausueben kann...
Das sollte hier jedoch kaum zutreffen.
[BIND-rant entsorgt. Du kannst bei diesen Argumenten s/BIND/Linux/ und s/9/2.4/
machen, kommt aufs gleiche raus.]
Rainer Weikusat
> SYN Flag, sorry!
Wenn wir schon mal dabei sind: Das ist ein Flag im TCP-Header, das den
Wunsch nach dem Aufbau einer neuen Verbindung signalisiert oder eine
Bestätigung, daß diesem Wunsch entsprochen wurde.
--
near
distant
Rainer Weikusat
> Ja, auf Linux 2.4.13+ und iptables umsteigen. Diese Firewall ist dann
> Statefull, und behandelt UDP Pakete dann so, als wenn sie ein
> SYS-Flag hätten
Guido, kannst Du nicht wenigstens *endlich* mal versuchen, die Worte
anderer Leute richtig zu behalten?
F'up2 poster
--
near
distant
Wolfgang Kueter
>
> Gernot Zander wrote:
>
> > Hi,
> >
> > ich habe auf einer Kiste (wo ich mir nichts aussuchen kann)
> > einen named 4.9.8-REL. Kernel 2.0.34 (kann ich mir auch nicht
> > aussuchen).
> Ja, auf Linux 2.4.13+ und iptables umsteigen. [...]
Wenn Du den ganzen Thread gelesen hättest, hättest Du mitgekriegt, dass
der OP im konkreten Fall mit einer Cobalt Maschine im Rahmen eines
Schulvernetzungsprojektes zu tun hat. Der OP hatte die Umstände etwas
erläutert, er kann in dieser Lage nicht mal eben einen 2.4.13er Kernel
auf die Cobalt Kiste packen und iptables zur Paketfilterung nutzen. Die
ganze Sache ist wegen der Umstände (alte Cobalts im Behördenumfeld)
vertrackt.
Wolfgang
Guido Stepken
Hmmm, sendmail hat auch eine lange Geschichte von BUGS, inzwischen hat
jedoch sendmail erheblich an Sicherheit aufgeholt, dank erheblicher
Anstrengungen. Bei BIND in einer CHROOT() Umgebung scheint mir das Risiko,
daß der Server komplett gecrackt wird, recht niedrig ...
C-Programme sind immer kritisch, zumal diese oft völlig unlesbar sind. Hier
ein anschauliches Beispiel zur Berechnung von PI auf ~16.000 Stellen.......
int a=1e4,b,c=56980,d,e,f[56980],g,h,i;
main(){for(;b=c,c-=14;i=printf("%04d",e+d/a),e=d%a)
while(g=--b*2)d=h*b+a*(i?f[b]:a/5),h=d/--g,f[b]=d%g;}
Grausam ! Schön wäre ein DNS Server in PERL oder besser Python geschrieben.
Hier von D.J.Bernstein, Autor von QMail ein "sicherer" Caching DNS Server :
http://cr.yp.to/djbdns/faq.html
Was ist von dem zu halten ?
Gru73, Guido Stepken
Guido Stepken
> Das ist also ABSOLUT TRIVIAL zu raten, d.h. selbst ein allwissender
> Paketfilter kann Spoofing bei DNS nicht verhindern. D.h. selbst wenn er
> funktionieren würde, würde er nicht helfen. Aber das hast du ja nicht
> behauptet, sondern du hast behauptet, daß er das Senden eines
> UDP-Paketes irgendwo im Internet unterbinden könnte, und daß das Unsinn
> ist, muß ich ja wohl hoffentlich nicht weiter belegen?!
> Auch obiger "Rettungs"-Satz ist Unfug. Natürlich müssen UDP-Pakete
> in beide Richtungen erlaubt sein, mit oder ohne stateful inspection.
> Man will ja fragen können und darauf Antwort kriegen.
Ja, der macht aber nur dann auf, wenn zuvor eine Anfrage an einen
bestimmten DNS-Server im Internet gestellt wurde. Ab dann läuft ein Timer
für 10 Sekunden. Danach ist die Firewall wieder für UDP/53 nicht mehr
offen, d.h. evtl. Buffer Overflow Angriffe müssen geschickter durchgeführt
werden. Hierzu muß der Cracker dann auf dem DNS des Providers sitzen, wie
bei ARCOR vor kurzem passiert ist. Das bedeutet Mehraufwand und erhöht die
Gefahr, entdeckt zu werden.
>
> Auch bei IPsec kannst du den Paketen nicht ansehen, ob sie gespooft sind.
> Du kannst nur kryptographisch den Inhalt verifizieren.
Wenn die gespoofte Adresse des IP-Headers nicht mit dem entschlüsselten
Header übereinstimmt, wird das Paket abgelehnt. Daher bietet IPSec einen
Schutz gegen das Spoofing.
>> Ich war auch etwas erstaunt, als ich mir den Quellcode von Linux
>> abgesehen habe, und feststellen mußte, daß hier einige Timeouts eine
>> wichtige Rolle spielen.
>
> Was hast du nach der Lektüre der einschlägigen RFCs denn erwartet?!
Ich meine den Code der SPF
>> > Wer BIND einsetzt, ist eh ein Idiot.
Naja, das Risiko bei BIND in einer CHROO() Umgebung ist recht gering,
sofern man stets die neuesten Patches aufspielt.
>> Hast Du eine Alternative, die es erlaubt, DNS im Intranet aufzusetzen,
>> der dann auch als forwarder Server im Internet befragen darf?
>
> Ist das eine Trickfrage?
> man djbdns
Soweit ich mich erinnere, gab es mehrere Security Meldungen auch bei Qmail
und sogar bei postfix, beide waren unter dem Aspekt der Sicherheit
programmiert worden. Vor kurzem hats auch das TIS FWTK wieder zerlegt,
obwohl es uralt ist.
Ich denke, daß "Idioten" folgende Punkte beachten sollten:
1. Alle Dämonen in einer CHROOT() Umgebung mit geringen User-Rechten
installieren.
2. Die CHROOT() Umgebung nach Änderungen der Konfiguration wieder readonly
mounten, also auf einer eigenen Partition lagern.
3. Patches stets schnell aufspielen.
4. QoS Modul im Linux Kernel aktivieren, um Flooding und die Überlastung
des Server zu verhindern.
5. Server als User-Mode Linux auf einem Linux laufen lassen. Im Falle einer
Fehlbedienung oder einer Sabotage ist ein Virtuelles Linux innerhalb von 5
Minuten wiederherzustellen.
6. User-Mode Linux erlaubt die Feststellung von Manipulationen durch
Abgleich mit den Backup's der darunter liegenden Maschine.
7. Nicht INTEL CPU's verwenden, da die meisten Buffer Overflows speziell
für Intel Prozessoren geschrieben wurden.
8. Ein PERL/Python/BASH Script für den Test der Funktionsfähigkeit der
Dämonen alle paar Minuten starten. Evtl. die Dämonen neu starten (gegen DoS)
9. Niemals einen Server via SSH, TELNET+SSL o.ä. "sichere" Interfaces
administrieren. SSHD selber ist auch ein Sicherheitsproblem. ISDN mit EAZ
Kennung ist da viel sicherer. Stets für Nutzlast und Administration
unterschiedliche Netzwerke verwenden (VLAN, ISDN, Modem ...)
10. KISS Prinzip (Keep It Small and Simple) beachten.
Damit sollte man auch mit fehlerhafter Software viele Einbrüche vereiteln
können.
>> Du erscheinst mir recht streitbar, warum ?
>
> BIND ist übler Legacy-Müll.
> Jedem, der sich im Internet über Security unterhält, muß das klar sein.
> Leute müssen davor gewarnt werden. Das hast du nicht getan.
Ich verdamme nicht einfach Software, weil sie Fehler hat. Mit o.a. Tips
kann man sehr viel mehr an Stabilität und Sicherheit erreichen.
> BIND 9 sah mal eine kurze Zeit ganz gut aus. Anfangs, als sie ihn
> ankündigten. Aber dann kam _noch_ größere Software raus, die von einem
> nmap gekillt wurde. Zusammenfassung: BIND muß sterben. Bist du nicht
> Teil der Lösung, bist du Teil des Problems.
Hihi, naja DoS auf den Dämon ist immer unangenehm .....
Gru/3, Guido
> Felix
>
Guido Stepken
> BIND 9 sah mal eine kurze Zeit ganz gut aus. Anfangs, als sie ihn
> ankündigten. Aber dann kam _noch_ größere Software raus, die von einem
> nmap gekillt wurde. Zusammenfassung: BIND muß sterben. Bist du nicht
> Teil der Lösung, bist du Teil des Problems.
Ok, dann lassen wir ihn mal sterben.
Hier ein Lösungsvorschlag:
PDNSD !!!!!!!!!
http://home.t-online.de/home/Moestl/doc.html
Das Entscheidende:
-mto: pdnsd will use TCP only. TCP queries usually take longer time than
UDP queries, but are more secure against certain attacks, where an attacker
tries to guess your query id and to send forged answers. TCP queries are
not supported by some name servers.
-mtu: pdnsd will try to use TCP, and will fall back to UDP if its
connection is refused.
Ähnlich den IBM DNS Servern kann man diesen Caching DNS Server
seine Anfragen durch eine "normale" Firewall, d.h. durch einen normalen
Paketfitler via TCP ausführen lassen. Sicherheitshalber in einer CHROOT()
Umgebung mit minimalen User-Rechten.
Damit sollten sich dann viele der hier diskutierten Probleme erübrigen,
oder nicht ?
Gru73, Guido Stepken
Rainer Weikusat
> C-Programme sind immer kritisch, zumal diese oft völlig unlesbar sind. Hier
> ein anschauliches Beispiel zur Berechnung von PI auf ~16.000 Stellen.......
>
> int a=1e4,b,c=56980,d,e,f[56980],g,h,i;
> main(){for(;b=c,c-=14;i=printf("%04d",e+d/a),e=d%a)
> while(g=--b*2)d=h*b+a*(i?f[b]:a/5),h=d/--g,f[b]=d%g;}
>
> Grausam!
Das einzige, was hier 'grausam' ist, ist Dein vollkommenes Unwissen,
gepaart mit Deinem Rededrang.
> Hier von D.J.Bernstein, Autor von QMail ein "sicherer" Caching DNS Server:
> http://cr.yp.to/djbdns/faq.html
>
> Was ist von dem zu halten?
Falls Du das nach Lektüre der einschlägigen Texte auf cr.yp.to nicht
beurteilen kannst, brauchst Du auch niemanden zu fragen.
--
near
distant
Stefan Heinecke
>Soweit ich mich erinnere, gab es mehrere Security Meldungen auch bei Qmail
>und sogar bei postfix, beide waren unter dem Aspekt der Sicherheit
>programmiert worden. Vor kurzem hats auch das TIS FWTK wieder zerlegt,
>obwohl es uralt ist.
Lies: http://cr.yp.to/qmail/guarantee.html und folge den Links.
Alt ist kein Qualitätsmerkmal für Sicherheit.
>1. Alle Dämonen in einer CHROOT() Umgebung mit geringen User-Rechten
>installieren.
Guter Anfang ...
>2. Die CHROOT() Umgebung nach Änderungen der Konfiguration wieder readonly
>mounten, also auf einer eigenen Partition lagern.
Readonly ist oft konzeptbedingt nicht möglich.
>3. Patches stets schnell aufspielen.
man ratrace, unverzüglich ist gut, aber auch nicht immer möglich.
Lieber gute Software verwenden, Alternativen erwägen und umsetzen.
Sicherheit bereits bei der Implementierung von Diensten erwägen und
nicht erst hinterher.
>4. QoS Modul im Linux Kernel aktivieren, um Flooding und die Überlastung
>des Server zu verhindern.
Unnötig, das kann man schon vorher machen, besser noch der Provider
machts für einen.
>7. Nicht INTEL CPU's verwenden, da die meisten Buffer Overflows speziell
>für Intel Prozessoren geschrieben wurden.
Security by obscurity - funktioniert nicht.
>8. Ein PERL/Python/BASH Script für den Test der Funktionsfähigkeit der
>Dämonen alle paar Minuten starten. Evtl. die Dämonen neu starten (gegen DoS)
Aga, am besten Du verschickst noch ne E-mail. Wirf einen Blick
auf: http://cr.yp.to/daemontools.html
>9. Niemals einen Server via SSH, TELNET+SSL o.ä. "sichere" Interfaces
>administrieren. SSHD selber ist auch ein Sicherheitsproblem. ISDN mit EAZ
>Kennung ist da viel sicherer. Stets für Nutzlast und Administration
>unterschiedliche Netzwerke verwenden (VLAN, ISDN, Modem ...)
ISDN und Modem kann ich ja verstehen, warum Du einem VLAN mehr
zutraust als SSL und SSH ist mir nicht klar.
>10. KISS Prinzip (Keep It Small and Simple) beachten.
Keep it simple, stupid. Es gibt auch Systeme die sind einfach
nicht klein.
>Damit sollte man auch mit fehlerhafter Software viele Einbrüche vereiteln
>können.
Du kannst Einbrüche nicht vereiteln, Du kannst es einem
Angreifer nur schwerer machen, eine Kompromitierung wirst
Du nicht verhindern mit deiner Vorgehensweise, es klingt sehr
nach Flickwerk.
>Ich verdamme nicht einfach Software, weil sie Fehler hat. Mit o.a. Tips
>kann man sehr viel mehr an Stabilität und Sicherheit erreichen.
Ein gutes Konzept und ein guter Evaluationsprozess bringt eine
wesentlich bessere und sichere Implementierung.
>Hihi, naja DoS auf den Dämon ist immer unangenehm .....
Du bist nicht auf dem Stand der Technik, schau dich um.
Guido Stepken
> Guido Stepken <ste...@little-idiot.de> wrote:
>>Soweit ich mich erinnere, gab es mehrere Security Meldungen auch bei Qmail
>>und sogar bei postfix, beide waren unter dem Aspekt der Sicherheit
>>programmiert worden. Vor kurzem hats auch das TIS FWTK wieder zerlegt,
>>obwohl es uralt ist.
>
> Lies: http://cr.yp.to/qmail/guarantee.html und folge den Links.
> Alt ist kein Qualitätsmerkmal für Sicherheit.
>
>>1. Alle Dämonen in einer CHROOT() Umgebung mit geringen User-Rechten
>>installieren.
>
> Guter Anfang ...
>
>>2. Die CHROOT() Umgebung nach Änderungen der Konfiguration wieder readonly
>>mounten, also auf einer eigenen Partition lagern.
>
> Readonly ist oft konzeptbedingt nicht möglich.
Dinge, die sich wenig ändern sollte man halt mit ro,noatime mounten. Andere
gehen öft natürlich nicht ...
>>3. Patches stets schnell aufspielen.
>
> man ratrace, unverzüglich ist gut, aber auch nicht immer möglich.
> Lieber gute Software verwenden, Alternativen erwägen und umsetzen.
> Sicherheit bereits bei der Implementierung von Diensten erwägen und
> nicht erst hinterher.
>
>>4. QoS Modul im Linux Kernel aktivieren, um Flooding und die Überlastung
>>des Server zu verhindern.
>
> Unnötig, das kann man schon vorher machen, besser noch der Provider
> machts für einen.
Provider .... nur wenige, oder ?
>>7. Nicht INTEL CPU's verwenden, da die meisten Buffer Overflows speziell
>>für Intel Prozessoren geschrieben wurden.
>
> Security by obscurity - funktioniert nicht.
Das habe ich damit nicht gemeint, jedoch die Skript-Kiddies, die ca. 90%
aller Einbrüche in Webserver durchführen, kann man jedoch damit gut
fernhalten.
>>8. Ein PERL/Python/BASH Script für den Test der Funktionsfähigkeit der
>>Dämonen alle paar Minuten starten. Evtl. die Dämonen neu starten (gegen
>>DoS)
>
> Aga, am besten Du verschickst noch ne E-mail. Wirf einen Blick
> auf: http://cr.yp.to/daemontools.html
;-))) Habe die Dinger selbstgeschrieben ....
>>9. Niemals einen Server via SSH, TELNET+SSL o.ä. "sichere" Interfaces
>>administrieren. SSHD selber ist auch ein Sicherheitsproblem. ISDN mit EAZ
>>Kennung ist da viel sicherer. Stets für Nutzlast und Administration
>>unterschiedliche Netzwerke verwenden (VLAN, ISDN, Modem ...)
>
> ISDN und Modem kann ich ja verstehen, warum Du einem VLAN mehr
> zutraust als SSL und SSH ist mir nicht klar.
Wenn das VLAN durch einen Switch mit allen Security Features aktiviert
(Port-Based VPAN...) kontrolliert wird, dann sollte man alle Server über
eine 2. Netzwerkkarte und dieses ADMIN-VLAN handeln, IMHO.
>>10. KISS Prinzip (Keep It Small and Simple) beachten.
>
> Keep it simple, stupid. Es gibt auch Systeme die sind einfach
> nicht klein.
Hmmm, 3000 Zeilen C-Code entsprechen etwa 250 Zeilen Python Code.
Es ginge schon, mit Funktionaler Programmierung, und einer wirklichen
OO-Sprache, die auch noch überaus lesbar ist.
Zahlreiche Python Projekte haben das gezeigt, darunter auch Proxies
(rubbishproxy), Server (Zope), die Code - reuse erlauben und überaus lesbar
noch nach Jahren sind.
>>Damit sollte man auch mit fehlerhafter Software viele Einbrüche vereiteln
>>können.
>
> Du kannst Einbrüche nicht vereiteln, Du kannst es einem
> Angreifer nur schwerer machen, eine Kompromitierung wirst
> Du nicht verhindern mit deiner Vorgehensweise, es klingt sehr
> nach Flickwerk.
>
IMHO ist es eh ein Kampf gegen Windmühlen ....man muß es
so schwer, wie möglich machen.
>>Ich verdamme nicht einfach Software, weil sie Fehler hat. Mit o.a. Tips
>>kann man sehr viel mehr an Stabilität und Sicherheit erreichen.
>
> Ein gutes Konzept und ein guter Evaluationsprozess bringt eine
> wesentlich bessere und sichere Implementierung.
JAVA , RMI ? Ich mag JAVA nicht, Python ist besser ....;-))
>>Hihi, naja DoS auf den Dämon ist immer unangenehm .....
>
> Du bist nicht auf dem Stand der Technik, schau dich um.
>
Sorry, aber wer ist das schon .....angesichts der Komplexität, sprich der
tausenden von Mannjahren, die in einigen Softwarepaketen stecken.
Gru/3, Guido
Guido Stepken
> * Guido Stepken <ste...@little-idiot.de> schrieb:
>
>> 7. Nicht INTEL CPU's verwenden, da die meisten Buffer Overflows
>> speziell für Intel Prozessoren geschrieben wurden.
>
> Aha, "security through obscurity" also.
>
Nein, Erfahrungen. Die Skripkiddies, also die 9-15 -jährigen und evtl. noch
einige kindliche "Erwachsenen", sind eh zu faul, um Assembler zu
lernen.....daher hat man mehr Ruhe mit skurilen Prozessoren. Es maht immer
wieder Freude, zu sehen, wie BufferOverflows für Linux (Intel) auf einer
SPARC einschlagen ....hihi...
> Übersichtsartikel zum Thema "buffer overflow":
> http://www.research.avayalabs.com/project/libsafe/doc/usenix00/paper.html
>
> Gruß, Heiko
>
Urs [Ayahuasca] Traenkner
> Felix von Leitner wrote:
[Bind ist nicht toll]
> Grausam ! Schön wäre ein DNS Server in PERL oder besser Python geschrieben.
> Hier von D.J.Bernstein, Autor von QMail ein "sicherer" Caching DNS Server :
> http://cr.yp.to/djbdns/faq.html
> Was ist von dem zu halten ?
*grins*
Such mal nach "bind vs. djbdns" bei google. Wenn ich den Titel jetzt
nicht mehr richtig in Erinnerung habe, suche nach Autor: Felix von
Leitner / enthaelt: Daniel Roesen, falls das zuviel ausspuckt, tu noch
"Idiot Schwachsinn Scheisse" dazu und Du landest definitiv beim
richtigen Thread.
Ja, der hat viel Spass gemacht beim Lesen.
Gruss Urs...
Nicholas Preyß
> Heiko Schlenker wrote:
>
>
>>* Guido Stepken <ste...@little-idiot.de> schrieb:
>>>7. Nicht INTEL CPU's verwenden, da die meisten Buffer Overflows
>>>speziell für Intel Prozessoren geschrieben wurden.
>>>
>>Aha, "security through obscurity" also.
>>
> Nein, Erfahrungen. Die Skripkiddies, also die 9-15 -jährigen und evtl. noch
> einige kindliche "Erwachsenen", sind eh zu faul, um Assembler zu
> lernen.....daher hat man mehr Ruhe mit skurilen Prozessoren. Es maht immer
> wieder Freude, zu sehen, wie BufferOverflows für Linux (Intel) auf einer
> SPARC einschlagen ....hihi...
IMHO ist der allgemeine Aspekt der Heterogenität bei Soft- wie auch
Hardware viel entscheidender. Durch einheitliche Hardware schafft man
sich vorallem eine Art "Single-Point-of-Failure" und das sollte
tunlichst vermieden werden. Also ist meiner Meinung nach der Rat nicht
Marktfuehrer-Hardware zu benutzen durchaus gerechtfertigt. Natürlich
kommt das sehr stark auf den spezifischen Anwendungfall und das
alternative Angebot an.
nicholas
--
Aequo animo audienda sunt imperitorum convicia.
Seneca
Guido Stepken
> Guido Stepken wrote:
>
> IMHO ist der allgemeine Aspekt der Heterogenität bei Soft- wie auch
> Hardware viel entscheidender. Durch einheitliche Hardware schafft man
> sich vorallem eine Art "Single-Point-of-Failure" und das sollte
> tunlichst vermieden werden. Also ist meiner Meinung nach der Rat nicht
> Marktfuehrer-Hardware zu benutzen durchaus gerechtfertigt. Natürlich
> kommt das sehr stark auf den spezifischen Anwendungfall und das
> alternative Angebot an.
>
>
> nicholas
>
>
>
Interessant ist auch die Inzucht bei Clustern, wie z.B. bei einigen
größeren WWW-Clustern. Da verwende die doch hinter einem LoadBalancer
einheitlich dasselbe OS. Ein DoS, 12x wiederholt, läßt dann die komplette
Serverphalanx down gehen, anstatt ein Linux, ein OpenBSD, ein Solaris ...
abwechselnd einzusetzen. GNU Software ist ja "write once, run everywhere"
Gru/3, Guido
Daniel Schmidt
> Ich denke, daß "Idioten" folgende Punkte beachten sollten:
>
> 7. Nicht INTEL CPU's verwenden, da die meisten Buffer Overflows speziell
> für Intel Prozessoren geschrieben wurden.
*Das* klingt in meinen Ohren ziemlich an den Haaren herbei gezogen.
Kannst Du das bitte einmal etwas naeher erlaeutern und ggf. mit ein paar
Quellenangaben wuerzen?
[1. bis n.]
> Damit sollte man auch mit fehlerhafter Software viele Einbrüche vereiteln
> können.
Insgesamt ein Riesenaufwand, findest Du nicht? Waere es nicht einfacher,
auf weniger anfaelliger Software aufzubauen? Mit viel Trickserei viele
Einbrueche zu verhindern ist ziemlich relativ. Wie hoch ist der
Prozentsatz von "viele"?
> Ich verdamme nicht einfach Software, weil sie Fehler hat. Mit o.a. Tips
> kann man sehr viel mehr an Stabilität und Sicherheit erreichen.
Ja, klar. Hat man dann einen Tipp nicht befolgt, oder aufgrund simpler
Unkenntnis den Tipp gar nicht erst gekannt, hat man halt Pech gehabt.
Zugegeben, ich setze auch bind 8.2.3-REL ein, allerdings in einer
Umgebung und Art, die unkritisch ist.
Ich kann allerdings deiner Tip-Reihe trotzdem nicht recht folgen; ich
habe den Eindruck, dass es im Moment auf reine Verteidigung hinauslauft.
mfg.,
-ds-
Stefan Heinecke
>Provider .... nur wenige, oder ?
Es ist technisch gesehen kein Problem.
>> Security by obscurity - funktioniert nicht.
>Das habe ich damit nicht gemeint, jedoch die Skript-Kiddies, die ca. 90%
>aller Einbrüche in Webserver durchführen, kann man jedoch damit gut
>fernhalten.
Du kannst niemanden fernhalten, träum schön weiter. Deine
Argumentation ist wenn ich einen anderen Prozessor als "Standard"
verwende, werden Skriptkids ferngehalten. Es ist doch nur eine Frage
der Zeit bis das automatisiert wird, bzw., ist es ein leichtes einfach
mehrere Varianten zu probieren, soviele unterschiedliche Techniken
und Prozessoren gibt es da nicht.
>Wenn das VLAN durch einen Switch mit allen Security Features aktiviert
>(Port-Based VPAN...) kontrolliert wird, dann sollte man alle Server über
>eine 2. Netzwerkkarte und dieses ADMIN-VLAN handeln, IMHO.
Mich beschleicht das Gefühl Du machst Sicherheit um der Sicherheit Willen.
Damit gewinnst Du idR keine zusätzliche Sicherheit, im besten Fall etwas
Zeit aber dafür einen höheren Administrationsaufwand.
>Hmmm, 3000 Zeilen C-Code entsprechen etwa 250 Zeilen Python Code.
>Es ginge schon, mit Funktionaler Programmierung, und einer wirklichen
>OO-Sprache, die auch noch überaus lesbar ist.
Ich sprach von Systemen nicht von "Sourcecode". Du beherzigst deine
eigenen Regeln nicht scheint mir.
>IMHO ist es eh ein Kampf gegen Windmühlen ....man muß es
> so schwer, wie möglich machen.
Nein, man sollte es so einfach wie möglich machen, wenn du dein
Sicherheitskonzept nicht offenlegen kannst, weil es den Angreifer
dann erlaubt dein System zu kompromitieren gewinnst Du nichts.
>Sorry, aber wer ist das schon .....angesichts der Komplexität, sprich der
>tausenden von Mannjahren, die in einigen Softwarepaketen stecken.
Klingt wie ein Argument für Blackboxen.
Stefan Heinecke
>"Security by obscurity" eben.
Ja, das möchte niemand, das macht einem das Leben selbst schwer.
>Nun lass mal meinem Namensvetter seine Illusion.
Nein, ich hab grad schnupfen und kann nicht schlafen.
Das ist Grund genug mal wieder Usenet News zu lesen :).
[VLAN]
>Und alle Rechner in diesem VLAN sind dann eben im Arsch, wenn _einer_
>davon gefallen ist. Das scheint meinen Namensvetter auch nicht zu
>interessieren.
Naja, ich seh den Sinn nicht noch ein VLAN dranzutackern, und dann
das Argument zu bringen das wäre jetzt sicherer :)
>> Mich beschleicht das Gefühl Du machst Sicherheit um der Sicherheit Willen.
>Was?
>Das waere ja noch vertretbar.
Ich bin in der Beziehung Hardliner, man macht Sicherheit nicht zum
Selbstzweck, dann kannst Du auch gleich den Stecker ziehen und sagen:
"nu isses sicher", das ist einfacher ;)
>Er verkauft Dummheit als Sicherheit - das ist das Problem.
Ich glaube eher das sein Problem ist, das er mit den Lösungen
die sich ausdenkt nicht arbeiten muss, das ist der Vorteil eines
jeden Externen.
>> Damit gewinnst Du idR keine zusätzliche Sicherheit, im besten Fall etwas
>> Zeit aber dafür einen höheren Administrationsaufwand.
>Und damit _weniger_ Sicherheit.
Indirekt ja, aber das Bewusstsein fehlt bei vielen.
>Aber er will "Security by obscurity".
Ich denke ihm fehlt ein wenig Praxis in einem heterogenem Umfeld.
>Und wie ein Argument fuer "Security by obscurity".
In der Praxis sieht es oft anders aus, ich tendiere auch dazu
zu flickschustern, weil es im Moment ncht anders geht, aber das
als Lösung zu propagieren ist nicht gut, man bringt sich damit
selbst nur in Zugzwang.
>Nun lass ihn mal, er will auch mal mit den grossen Hunden pissen.
Na dann soll er sich mal ein wenig anstrengen :).
Rainer Weikusat
> Nein, Erfahrungen. Die Skripkiddies, also die 9-15 -jährigen und evtl. noch
> einige kindliche "Erwachsenen", sind eh zu faul, um Assembler zu
Sagen Dir das Wort 'sadmind' vielleicht zufällig was?
<URL:http://www.zdnet.com/products/stories/reviews/0,4161,2716653,00.html>
'Weniger skurile Webserver' wären vielleicht eine bessere Idee :->.
> Es maht immer wieder Freude, zu sehen, wie BufferOverflows für Linux
> (Intel) auf einer SPARC einschlagen
'Linux' ist ein Kernel. Exploits, die Schreibzugriffe außerhalb von
Feldgrenzen ausgenutzt hätten, gab es dafür, wie sich mit Hilfe von
<URL:http://www.linux.org.uk/VERSION> unschwer ermitteln läßt,
wenigstens seid dem 13.08.1999 keine (allerdings mglw einen Fehler,
der einen solchen erlaubt hätte, aber ich bin im Moment zu faul,
2.2.15-diffs zu lesen...).
--
near
distant
Guido Stepken
> * Guido Stepken <ste...@little-idiot.de> wrote:
> [...]
>> Interessant ist auch die Inzucht bei Clustern, wie z.B. bei einigen
>> größeren WWW-Clustern. Da verwende die doch hinter einem LoadBalancer
>> einheitlich dasselbe OS. Ein DoS, 12x wiederholt, läßt dann die komplette
>> Serverphalanx down gehen, anstatt ein Linux, ein OpenBSD, ein Solaris ...
>> abwechselnd einzusetzen. GNU Software ist ja "write once, run everywhere"
>
> Und nun wuerde mich mal interessieren, wie dich unterschiedliche
> Betriebssysteme vor einem DoS schuetzen koennen.
Nehmen wir z.B. einige TCP/IP BUGS in einem NT Server (ähnlich PoD,
LAND...)
Schießt Du den ersten NT Wolfpack Server ab, sprint der 2. an und ist auch
direkt tot.
Kritischer wird es bei einer Serverphalanx von z.B. SuSE 7 Servern. Da
haben doch Hacker mit einfachen Tools von packetstormsecurity.com die
Server der Reihe nach abgeschossen, hinter dem LOAD-Balacer.
Mit einem heterogenen Gemisch aus verschiedensten UNIXen wäre dieser
Versuch jedenfalls gescheitert, z.B.
Ich habe inzwischen einige dieser Angriffe gesehen ....
Gru/3, Guido Stepken
Guido Stepken
> Guido Stepken <ste...@little-idiot.de> wrote:
>
>> Ich denke, daß "Idioten" folgende Punkte beachten sollten:
>>
>> 7. Nicht INTEL CPU's verwenden, da die meisten Buffer Overflows speziell
>> für Intel Prozessoren geschrieben wurden.
>
> *Das* klingt in meinen Ohren ziemlich an den Haaren herbei gezogen.
> Kannst Du das bitte einmal etwas naeher erlaeutern und ggf. mit ein paar
> Quellenangaben wuerzen?
Meine eigenen Erfahrungen. Einbrüche via BO in mir bakannte Server sind
seit der Umstellung auf SUN Server (Linux 2.4.x+LIDS) fast auf NULL
zurückgegangen. Außerdem brauchst Du dir nur mal die Quellcodes von BO auf
http://www.rootshell.com oder packetstormsecurity.com ansehen, da ist in
den HEX DATA's immer Intel-Code enthalten. Einige gibt's für ARM und noch
weniger für Solaris. Der Hit ist der Hitachi H3/4, dafür habe ich noch nix
gesehen.
Es ist doch völlig logisch, daß diejenigen BO, die man so im Internet
findet, auf andern Prozessoren keinen Schaden anrichten können.
> [1. bis n.]
>> Damit sollte man auch mit fehlerhafter Software viele Einbrüche vereiteln
>> können.
>
> Insgesamt ein Riesenaufwand, findest Du nicht? Waere es nicht einfacher,
> auf weniger anfaelliger Software aufzubauen? Mit viel Trickserei viele
> Einbrueche zu verhindern ist ziemlich relativ. Wie hoch ist der
> Prozentsatz von "viele"?
Siehe oben.
>> Ich verdamme nicht einfach Software, weil sie Fehler hat. Mit o.a. Tips
>> kann man sehr viel mehr an Stabilität und Sicherheit erreichen.
>
> Ja, klar. Hat man dann einen Tipp nicht befolgt, oder aufgrund simpler
> Unkenntnis den Tipp gar nicht erst gekannt, hat man halt Pech gehabt.
> Zugegeben, ich setze auch bind 8.2.3-REL ein, allerdings in einer
> Umgebung und Art, die unkritisch ist.
> Ich kann allerdings deiner Tip-Reihe trotzdem nicht recht folgen; ich
> habe den Eindruck, dass es im Moment auf reine Verteidigung hinauslauft.
Bestimmt ;-))
mfg, Guido Stepken
> mfg.,
>
> -ds-
>
Guido Stepken
> Guido Stepken <ste...@little-idiot.de> writes:
>> Nein, Erfahrungen. Die Skripkiddies, also die 9-15 -jährigen und evtl.
>> noch einige kindliche "Erwachsenen", sind eh zu faul, um Assembler zu
>> lernen ... daher hat man mehr Ruhe mit skurilen Prozessoren.
>
> Sagen Dir das Wort 'sadmind' vielleicht zufällig was?
>
> <URL:http://www.zdnet.com/products/stories/reviews/0,4161,2716653,00.html>
>
> 'Weniger skurile Webserver' wären vielleicht eine bessere Idee :->.
>
SADMIND hat sicherlich sehr viele 2.5.1 Systeme befallen, die noch sehr
häufig im Einsatz sind, um dann NT IIS anzugereifen ........Den Wurm selber
habe ich noch nicht gesehen.....Ich verwende auch kein NT....
>> Es macht immer wieder Freude, zu sehen, wie BufferOverflows für Linux
>> (Intel) auf einer SPARC einschlagen
>
> 'Linux' ist ein Kernel. Exploits, die Schreibzugriffe außerhalb von
Klar
> Feldgrenzen ausgenutzt hätten, gab es dafür, wie sich mit Hilfe von
> <URL:http://www.linux.org.uk/VERSION> unschwer ermitteln läßt,
> wenigstens seid dem 13.08.1999 keine (allerdings mglw einen Fehler,
> der einen solchen erlaubt hätte, aber ich bin im Moment zu faul,
> 2.2.15-diffs zu lesen...).
>
Deine URL scheint etwas veraltet, zumindest habe ich das Kernel - Leak,
welches in Verbindung mit sendmail zu einer Lücke führte nicht gefunden,
das ist nur wenige Monate her ....
Gru/3, Guido
Rainer Weikusat
> Daniel Schmidt wrote:
> >> 7. Nicht INTEL CPU's verwenden, da die meisten Buffer Overflows speziell
> >> für Intel Prozessoren geschrieben wurden.
> >
> > *Das* klingt in meinen Ohren ziemlich an den Haaren herbei gezogen.
> > Kannst Du das bitte einmal etwas naeher erlaeutern und ggf. mit ein paar
> > Quellenangaben wuerzen?
>
> Meine eigenen Erfahrungen. Einbrüche via BO in mir bakannte Server sind
> seit der Umstellung auf SUN Server (Linux 2.4.x+LIDS) fast auf NULL
> zurückgegangen.
Das muß man sich mal in Ruhe auf der Zunge zergehen lassen ...
> Außerdem brauchst Du dir nur mal die Quellcodes von BO auf
> http://www.rootshell.com oder packetstormsecurity.com ansehen, da ist in
> den HEX DATA's immer Intel-Code enthalten. Einige gibt's für ARM und noch
> weniger für Solaris. Der Hit ist der Hitachi H3/4, dafür habe ich noch nix
> gesehen.
Ich wünschte, ich hätte ausreichend Zeit und Geld einen dieser
Exploits auf jeden Prozessor zu portieren, der überhaupt irgendwo
verwendet wird, damit diese Schwachsinnsdebatte hier zu einem aprupten
Ende käme.
Fehlerhafte Programme möchte man reparieren, nicht im Keller
verstecken. Gefunden werden sie da nämlich auch.
> Es ist doch völlig logisch, daß diejenigen BO, die man so im Internet
> findet, auf andern Prozessoren keinen Schaden anrichten können.
Das ist völliger Blödsinn und gegenteilige Quellen sollten Dir bekannt
sein. Ersatzweise könntest Du mal nach welchen _suchen_, aber das wäre
ja Arbeit, nicht?
> > Ich kann allerdings deiner Tip-Reihe trotzdem nicht recht folgen; ich
> > habe den Eindruck, dass es im Moment auf reine Verteidigung
> > hinauslauft.
Nein. Das hier ist ein Fall von wirklich hartgesottenem Schamanentum.
--
near
distant
Rainer Weikusat
> > Sagen Dir das Wort 'sadmind' vielleicht zufällig was?
> >
> > <URL:http://www.zdnet.com/products/stories/reviews/0,4161,2716653,00.html>
> >
> > 'Weniger skurile Webserver' wären vielleicht eine bessere Idee :->.
> >
> SADMIND hat sicherlich sehr viele 2.5.1 Systeme befallen, die noch sehr
> häufig im Einsatz sind,
<URL:http://sunsolve.sun.com/pub-cgi/retrieve.pl?doctype=coll&doc=secbull/191&type=0&nav=sec.sba>
Deine 'Es gibt keine Exploits für non-x86'-Behauptung ist folglich
Makulatur.
> > Feldgrenzen ausgenutzt hätten, gab es dafür, wie sich mit Hilfe von
> > <URL:http://www.linux.org.uk/VERSION> unschwer ermitteln läßt,
> > wenigstens seid dem 13.08.1999 keine (allerdings mglw einen Fehler,
> > der einen solchen erlaubt hätte, aber ich bin im Moment zu faul,
> > 2.2.15-diffs zu lesen...).
> >
> Deine URL scheint etwas veraltet,
Warum liest Du sie eigentlich nicht?
> zumindest habe ich das Kernel-Leak welches in Verbindung mit
> sendmail zu einer Lücke führte nicht gefunden,
Falls es 'in Verbindung mit sendmail' zu einer Lücke führte, war es
mit Sicherheit kein remote exploitbarer Überlauf im
Linux-TCP/IP-Stack (pcap?). Wie wärs wenn Du Deine Behauptungen mal
mit etwas mehr Hintergrund als 'Ich kann mich erinnern' unterfüttern
würdest?
--
near
distant
Guido Stepken
> Guido Stepken <ste...@little-idiot.de> writes:
>> > Sagen Dir das Wort 'sadmind' vielleicht zufällig was?
>> >
>> >
<URL:http://www.zdnet.com/products/stories/reviews/0,4161,2716653,00.html>
>> >
>> > 'Weniger skurile Webserver' wären vielleicht eine bessere Idee :->.
>> >
>> SADMIND hat sicherlich sehr viele 2.5.1 Systeme befallen, die noch sehr
>> häufig im Einsatz sind,
>
>
<URL:http://sunsolve.sun.com/pub-cgi/retrieve.pl?doctype=coll&doc=secbull/191&type=0&nav=sec.sba>
>
> Deine 'Es gibt keine Exploits für non-x86'-Behauptung ist folglich
> Makulatur.
Ich redete von BO und Exploits u.a. für LINUX/SPARC , der o.a. BUG ist ohne
spezielle Assembler Kenntnisse auszunutzen. Natürlich gibt es auch
BufferOverflows für SUN OS / SPARC.
>> > Feldgrenzen ausgenutzt hätten, gab es dafür, wie sich mit Hilfe von
>> > <URL:http://www.linux.org.uk/VERSION> unschwer ermitteln läßt,
>> > wenigstens seid dem 13.08.1999 keine (allerdings mglw einen Fehler,
>> > der einen solchen erlaubt hätte, aber ich bin im Moment zu faul,
>> > 2.2.15-diffs zu lesen...).
>> >
>> Deine URL scheint etwas veraltet,
>
> Warum liest Du sie eigentlich nicht?
BUGTRAQ und packetstormsecurity.com sind informativer ....
>> zumindest habe ich das Kernel-Leak welches in Verbindung mit
>> sendmail zu einer Lücke führte nicht gefunden,
>
> Falls es 'in Verbindung mit sendmail' zu einer Lücke führte, war es
> mit Sicherheit kein remote exploitbarer Überlauf im
> Linux-TCP/IP-Stack (pcap?). Wie wärs wenn Du Deine Behauptungen mal
> mit etwas mehr Hintergrund als 'Ich kann mich erinnern' unterfüttern
> würdest?
>
>
Siehe http://www.securityfocus.com ..../bugtraq ...
Guido Stepken
> Guido Stepken <ste...@little-idiot.de> writes:
>> Meine eigenen Erfahrungen. Einbrüche via BO in mir bakannte Server sind
>> seit der Umstellung auf SUN Server (Linux 2.4.x+LIDS) fast auf NULL
>> zurückgegangen.
>
> Das muß man sich mal in Ruhe auf der Zunge zergehen lassen ...
??
>> Außerdem brauchst Du dir nur mal die Quellcodes von BO auf
>> http://www.rootshell.com oder packetstormsecurity.com ansehen, da ist in
>> den HEX DATA's immer Intel-Code enthalten. Einige gibt's für ARM und noch
>> weniger für Solaris. Der Hit ist der Hitachi H3/4, dafür habe ich noch
>> nix gesehen.
>
> Ich wünschte, ich hätte ausreichend Zeit und Geld einen dieser
> Exploits auf jeden Prozessor zu portieren, der überhaupt irgendwo
> verwendet wird, damit diese Schwachsinnsdebatte hier zu einem aprupten
> Ende käme.
"auf jeden Prozessor" ??? Probier doch mal einen BufferOverflow für
Linux/Intel auf Linux/ARM oder Linux/Sparc aus ....da passiert nämlich nix.
> Fehlerhafte Programme möchte man reparieren, nicht im Keller
> verstecken. Gefunden werden sie da nämlich auch.
Nix dagegen ....
>> Es ist doch völlig logisch, daß diejenigen BO, die man so im Internet
>> findet, auf andern Prozessoren keinen Schaden anrichten können.
>
> Das ist völliger Blödsinn und gegenteilige Quellen sollten Dir bekannt
> sein. Ersatzweise könntest Du mal nach welchen _suchen_, aber das wäre
> ja Arbeit, nicht?
Nochmal:
Probier doch mal einen BufferOverflow für Linux/Intel auf Linux/ARM oder
Linux/Sparc aus ....da passiert nämlich nix.
>> > Ich kann allerdings deiner Tip-Reihe trotzdem nicht recht folgen; ich
>> > habe den Eindruck, dass es im Moment auf reine Verteidigung
>> > hinauslauft.
>
> Nein. Das hier ist ein Fall von wirklich hartgesottenem Schamanentum.
>
Buh !
Felix von Leitner
> > dir und findest es immer noch vertretbar, diese Software einzusetzen!?
> > Bist du blind?
> Hmmm, sendmail hat auch eine lange Geschichte von BUGS, inzwischen hat
> jedoch sendmail erheblich an Sicherheit aufgeholt,
Nein.
> Bei BIND in einer CHROOT() Umgebung scheint mir das Risiko, daß der
> Server komplett gecrackt wird, recht niedrig ...
Relevant ist nicht, was dir scheint, sondern was in der Realität
passiert. Ein Server, auf dem der BIND ständig mysteriös abraucht, ist
schlecht. Ob da jetzt ein Cracker bis zu einer root-Shell kommt oder
nicht spielt keine Rolle.
> C-Programme sind immer kritisch,
Nein.
> zumal diese oft völlig unlesbar sind.
Bullshit.
> Grausam ! Schön wäre ein DNS Server in PERL oder besser Python geschrieben.
Mann, du bist ja eine Gefahr in deiner Unkenntnis!
Warst du nicht sogar der Typ, der ein Firewall-HOWTO oder so geschrieben
hatte? Oh Graus!
> Hier von D.J.Bernstein, Autor von QMail ein "sicherer" Caching DNS Server :
> http://cr.yp.to/djbdns/faq.html
> Was ist von dem zu halten ?
Ist das eine Trickfrage?
Felix
Felix von Leitner
> c) die 32-bit IP-Nummer des angefragten DNS-Servers raten. (oder aber
> er betreibt diesen server selbst. Nur warum dann noch spoofen?)
> >Das ist also ABSOLUT TRIVIAL zu raten, d.h. selbst ein allwissender
Wieso? Wenn ich die Daten für fnord.org im DNS-Cache auf 1.2.3.4
spoofen will, dann spoofe ich die Pakete so, daß sie von einem für
fnord.org zuständigen Nameserver kommen. Viel raten muß man da nicht.
> >Paketfilter kann Spoofing bei DNS nicht verhindern. D.h. selbst wenn er
> >funktionieren würde, würde er nicht helfen. Aber das hast du ja nicht
> >behauptet, sondern du hast behauptet, daß er das Senden eines
> >UDP-Paketes irgendwo im Internet unterbinden könnte, und daß das Unsinn
> >ist, muß ich ja wohl hoffentlich nicht weiter belegen?!
> Er unterbindet das weiterleiten von UDP paketen, die keinem Eintrag
> seiner conntrack-tabelle entsprechen. Nicht mehr und auch nicht weniger.
Sicherheits-Auswirkung in der Praxis: keine.
> >Auch obiger "Rettungs"-Satz ist Unfug. Natürlich müssen UDP-Pakete
> >in beide Richtungen erlaubt sein, mit oder ohne stateful inspection.
> >Man will ja fragen können und darauf Antwort kriegen.
> Du hast das konzept der UDP-pseudostatefulness nicht verstanden?
Doch. Es bringt nur nichts.
> Die bei stateless filtern noetige extra regel fuer DNS antworten ist eben
> darum nicht laenger notwendig.
Eine Firewall kann nicht verhindern, daß bei einem Cache falsche Daten
ankommen. Der Cache muß also in jedem Fall gegen Spoofing immun sein,
soweit das möglich ist. Und dann kannst du dir den ganzen
Firewall-Schwachsinn auch sparen, weil das gerade bei "statefullness"
enorm Komplexität beinhaltet, die an der Stelle nicht nötig ist.
> [BIND-rant entsorgt. Du kannst bei diesen Argumenten s/BIND/Linux/ und s/9/2.4/
> machen, kommt aufs gleiche raus.]
Ja, genau. Laßt uns einen Linux 2.4 rant machen. Zeit dafür ist es ja
schon lange. Wer fängt an? Lutz?
Felix
--
Doing linear scans over an associative array is like trying to club
someone to death with a loaded Uzi.
--lw...@netlabs.com (Larry Wall)
Felix von Leitner
> bestimmten DNS-Server im Internet gestellt wurde.
Oi, na _das_ ist ja schwierig zu bewerkstelligen. Besonders bei
üblichen BIND-Setups, die von jedem Anfragen entgegen nehmen.
> Ab dann läuft ein Timer für 10 Sekunden. Danach ist die Firewall
> wieder für UDP/53 nicht mehr offen, d.h. evtl. Buffer Overflow
> Angriffe müssen geschickter durchgeführt werden.
Oh, mein Fehler. Ich nahm an, es ginge hier um Sicherheit und nicht um
Hokus-Pokus. Wenn ich keine Buffer Overflows haben will, dann setze ich
eine Software ein, die keine hat, und fummel nicht irgendwelche
Obfuscation Layer mit irgendwelchen Paketfilter-Kludges zusammen.
> Hierzu muß der Cracker dann auf dem DNS des Providers sitzen,
Nein.
> >> Ich war auch etwas erstaunt, als ich mir den Quellcode von Linux
> >> abgesehen habe, und feststellen mußte, daß hier einige Timeouts eine
> >> wichtige Rolle spielen.
> > Was hast du nach der Lektüre der einschlägigen RFCs denn erwartet?!
> Ich meine den Code der SPF
Ja und? Natürlich müssen da Timeouts drin sein, sonst alloziert Linux
unendlich viel Speicher für Tabellen, wenn alte Einträge nicht
rausfliegen. Guido, hast du eigentlich an irgend einer Stelle auch nur
rudimentär Ahnung von Security, Algorithmen und Firewalls oder läßt du
nur gerne Buzzwords fallen?
> >> > Wer BIND einsetzt, ist eh ein Idiot.
> Naja, das Risiko bei BIND in einer CHROO() Umgebung ist recht gering,
> sofern man stets die neuesten Patches aufspielt.
Solange man sich nicht im Universum aufhält, ist man vor Kometen sicher.
Ganz toll.
> > Ist das eine Trickfrage?
> > man djbdns
> Soweit ich mich erinnere, gab es mehrere Security Meldungen auch bei Qmail
> und sogar bei postfix, beide waren unter dem Aspekt der Sicherheit
> programmiert worden.
Schmerz laß nach, noch mehr FUD über Sachen, die du nicht verstanden
hast? Oh Mann. Seufz.
Das "sogar bei postfix" finde ich persönlich die Krönung deiner
Inkompetenz. Laß gut sein, Guido. Bevor du dich noch mehr lächerlich
machst.
> 1. Alle Dämonen in einer CHROOT() Umgebung mit geringen User-Rechten
> installieren.
Ganz toller Plan. man sshd. man ftpd.
> 2. Die CHROOT() Umgebung nach Änderungen der Konfiguration wieder readonly
> mounten, also auf einer eigenen Partition lagern.
Wird ja immer besser. Bin ja gespannt, wie du deine Kunden dann per FTP
Dateien uploaden läßt.
> 3. Patches stets schnell aufspielen.
Job-Security marke Guido Stepken, wie?
Ich wähle meine Software lieber so aus, daß keine Patches notwendig
werden, und sorge auf konzeptioneller Ebene für eine
Schadenseingrenzung.
> 4. QoS Modul im Linux Kernel aktivieren, um Flooding und die Überlastung
> des Server zu verhindern.
Pappnase!
"Ihr Webserver ist nicht erreichbar! Ist der gehackt worden?"
"Nein, das ist eine Sicherheitsmaßnahme unseres Beraters Guido Stepken,
damit der Server nicht überlastet wird"
> 5. Server als User-Mode Linux auf einem Linux laufen lassen. Im Falle einer
> Fehlbedienung oder einer Sabotage ist ein Virtuelles Linux innerhalb von 5
> Minuten wiederherzustellen.
Grandiose Obscurity. Und bei heutigen PC-Preisen nicht nachvollziehbar.
Außerdem ist nicht klar, wieso jemand, der in ein virtuelles Linux
einbrechen kann, nicht auch in das Linux darüber einbrechen können
sollte.
Hast du dir deine großartigen Ideen schon patentieren lassen?
> 6. User-Mode Linux erlaubt die Feststellung von Manipulationen durch
> Abgleich mit den Backup's der darunter liegenden Maschine.
Das ist ja wirklich grotesk.
> 7. Nicht INTEL CPU's verwenden, da die meisten Buffer Overflows speziell
> für Intel Prozessoren geschrieben wurden.
Huihuihui, das wird ja immer sicherer!
Guido, sagt dir "Security by Obscurity isn't" etwas?
Offensichtlich nicht.
> 8. Ein PERL/Python/BASH Script für den Test der Funktionsfähigkeit der
> Dämonen alle paar Minuten starten. Evtl. die Dämonen neu starten (gegen DoS)
Muhahaha. Jemand erzeugt per DoS eine Monster-Load auf deiner Kiste,
und du machst das noch viel schlimmer, indem du a) bloat-monster wie
Python oder perl alle paar Minuten laufen läßt und b) ständig Daemons
restartest.
> 9. Niemals einen Server via SSH, TELNET+SSL o.ä. "sichere" Interfaces
> administrieren. SSHD selber ist auch ein Sicherheitsproblem. ISDN mit EAZ
> Kennung ist da viel sicherer.
Bwaaaaahahaha, Guido, geh weg. Lösche deinen tollen Firewall-Guide und
laß das jemanden machen, der sich damit auskennt. Hint: das bist nicht
du. Am besten solltest du auch schnell eine Umschulung machen. Es
findet sich sicher ein Job für dich, aber der wird weit weg von Security
und Computern sein.
> Stets für Nutzlast und Administration unterschiedliche Netzwerke
> verwenden (VLAN, ISDN, Modem ...)
Ein VLAN ist kein unterschiedliches Netzwerk.
Du machst wirklich alles falsch. Erstaunlich.
> 10. KISS Prinzip (Keep It Small and Simple) beachten.
Das sagt jemand, der geschachtelte User-Mode-Linuxe mit minütlichen
Perl- oder Python-Scripts laufen lassen will? Wo ist die versteckte
Kamera? Das ist doch mit Sicherheit eine Satiresendung hier!
> >> Du erscheinst mir recht streitbar, warum ?
> > BIND ist übler Legacy-Müll.
> > Jedem, der sich im Internet über Security unterhält, muß das klar sein.
> > Leute müssen davor gewarnt werden. Das hast du nicht getan.
> Ich verdamme nicht einfach Software, weil sie Fehler hat. Mit o.a. Tips
> kann man sehr viel mehr an Stabilität und Sicherheit erreichen.
Deine "Tips" zeugen von einer Inkompetenz von geradezu kosmischen
Ausmaßen und erreichen das Gegenteil von Stabilität. Du baust hier
irgendwelche filigranen Fantasie-Komplexitäten zusammen und wunderst
dich dann, wenn unten ein Hund gegenpinkelt und alles zusammenfällt.
> > BIND 9 sah mal eine kurze Zeit ganz gut aus. Anfangs, als sie ihn
> > ankündigten. Aber dann kam _noch_ größere Software raus, die von einem
> > nmap gekillt wurde. Zusammenfassung: BIND muß sterben. Bist du nicht
> > Teil der Lösung, bist du Teil des Problems.
> Hihi, naja DoS auf den Dämon ist immer unangenehm .....
Das war nicht nur ein DoS auf einen Dämon, das war ein fucking
Port-Scan, wie er jeden Tag millionenfach im Internet passiert.
Felix
Rainer Weikusat
> <URL:http://sunsolve.sun.com/pub-cgi/retrieve.pl?doctype=coll&doc=secbull/191&type=0&nav=sec.sba>
> >
> > Deine 'Es gibt keine Exploits für non-x86'-Behauptung ist folglich
> > Makulatur.
>
> Ich redete von BO und Exploits u.a. für LINUX/SPARC , der o.a. BUG ist ohne
> spezielle Assembler Kenntnisse auszunutzen.
Read: Es gibt Exploits dafür. Wir drehen uns im Kreis.
<URL:http://archives.indenial.com/hypermail/bugtraq/1998/June1998/0067.html>
'Spezielle Assemblerkenntnisse' sind für den elementaren Quatsch
ohnehin nicht vonnöten, eher stupide Bastelwut. Registermaschinen sind
nicht wirklich kompliziert zu programmieren.
> Natürlich gibt es auch BufferOverflows für SUN OS / SPARC.
Nein, für Sparc gibt es keine buffer overflows (allmählich kann ichs
nicht mehr hören), denn das ist ein Mikrochip.
Das sieht so aus:
<URL:http://bwrc.eecs.berkeley.edu/CIC/die_photos/ultrasparc.jpg>
Es gibt auch keine Bufferoverflows für SunOS, aber möglicherweise in
SunOS oder anderen darunter auf einem Sparc-Rechner laufenden
Programmen.
ZB sowas:
int main()
{
char buf[256];
while (gets(buf)) printf("%s\n", buf);
return 0;
}
Wie man deutlich sehen kann, gibt es keine Ähnlichkeiten zur oa
Fotografie.
Für solche (latenten) Pufferüberläufe gibt es wiederum Exploits, zB
für Sparc-Prozessoren, s.o.
> >> > der einen solchen erlaubt hätte, aber ich bin im Moment zu faul,
> >> > 2.2.15-diffs zu lesen...).
> >> >
> >> Deine URL scheint etwas veraltet,
> >
> > Warum liest Du sie eigentlich nicht?
>
> BUGTRAQ und packetstormsecurity.com sind informativer ...
Als Ausrede für 'aber das sind ja die 2.2 RELNOTES, wie konnte mir das
nur entgehen' bleibt das etwas dämlich.
> > Falls es 'in Verbindung mit sendmail' zu einer Lücke führte, war es
> > mit Sicherheit kein remote exploitbarer Überlauf im
> > Linux-TCP/IP-Stack (pcap?). Wie wärs wenn Du Deine Behauptungen mal
> > mit etwas mehr Hintergrund als 'Ich kann mich erinnern' unterfüttern
> > würdest?
> >
> >
> Siehe http://www.securityfocus.com ..../bugtraq ...
Also nein. Hätte mich auch gewundert.
--
near
distant
Felix von Leitner
> gehen öft natürlich nicht ...
Guido brilliert wieder mit seinem Wissen... :(
Warum machst du nicht gleich ro,noatime,ro,ro,ro? Und am besten noch
mount -r? Hint: noatime ist überflüssig bei ro.
> >>3. Patches stets schnell aufspielen.
> >
> > man ratrace, unverzüglich ist gut, aber auch nicht immer möglich.
> > Lieber gute Software verwenden, Alternativen erwägen und umsetzen.
> > Sicherheit bereits bei der Implementierung von Diensten erwägen und
> > nicht erst hinterher.
> >
Quoten kann er auch nicht :-((((
> >>8. Ein PERL/Python/BASH Script für den Test der Funktionsfähigkeit der
> >>Dämonen alle paar Minuten starten. Evtl. die Dämonen neu starten (gegen
> >>DoS)
> > Aga, am besten Du verschickst noch ne E-mail. Wirf einen Blick
> > auf: http://cr.yp.to/daemontools.html
> ;-))) Habe die Dinger selbstgeschrieben ....
Oi, wie beeindruckend. Geradezu eine Meisterleistung.
> > ISDN und Modem kann ich ja verstehen, warum Du einem VLAN mehr
> > zutraust als SSL und SSH ist mir nicht klar.
> Wenn das VLAN durch einen Switch mit allen Security Features aktiviert
> (Port-Based VPAN...) kontrolliert wird, dann sollte man alle Server über
> eine 2. Netzwerkkarte und dieses ADMIN-VLAN handeln, IMHO.
Tolles Sicherheitsverständnis, das du da hast. Du vertraust einem
Black-Box-Switch mehr als einem ssh, für das du den Quellcode hast.
Guido, du hast den Beruf verfehlt. Und zwar weiträumig.
> >>10. KISS Prinzip (Keep It Small and Simple) beachten.
> > Keep it simple, stupid. Es gibt auch Systeme die sind einfach
> > nicht klein.
> Hmmm, 3000 Zeilen C-Code entsprechen etwa 250 Zeilen Python Code.
Bullshit.
> Es ginge schon, mit Funktionaler Programmierung, und einer wirklichen
> OO-Sprache, die auch noch überaus lesbar ist.
Dieser Satz macht keinen Sinn.
> Zahlreiche Python Projekte haben das gezeigt, darunter auch Proxies
> (rubbishproxy), Server (Zope), die Code - reuse erlauben und überaus lesbar
> noch nach Jahren sind.
Zope war doch die Software, wo alle halbe Stunde ein Security- oder
Stability-Update rauskommt, oder? Gutes Zeichen für echt lesbaren Code.
Duh. Guido, spontan fallen mir nicht viele Gruben ein, in die du noch
fallen könntest. D.h. warte, du könntest noch aus Sicherheitsgründen
Windows empfehlen.
> IMHO ist es eh ein Kampf gegen Windmühlen ....man muß es
> so schwer, wie möglich machen.
So mag das aus der Ferne aussehen, wenn man das alles nicht versteht,
aber trotzdem wichtig aussehen will. Man deklariert einfach, daß es eh
nicht geht, aber nur mit deinen eigenen innovativen Sicherheitstips ist
Sicherheit überhaupt annäherbar. Da stehen deine Kunden sicher tierisch
drauf. Deine Mami muß stolz auf dich sein.
> JAVA , RMI ? Ich mag JAVA nicht, Python ist besser ....;-))
Depp.
Felix von Leitner
> >Wenn das VLAN durch einen Switch mit allen Security Features aktiviert
> >(Port-Based VPAN...) kontrolliert wird, dann sollte man alle Server über
> >eine 2. Netzwerkkarte und dieses ADMIN-VLAN handeln, IMHO.
> Mich beschleicht das Gefühl Du machst Sicherheit um der Sicherheit Willen.
Mich beschleicht das Gefühl, er macht überhaupt keine Sicherheit.
> >Sorry, aber wer ist das schon .....angesichts der Komplexität, sprich der
> >tausenden von Mannjahren, die in einigen Softwarepaketen stecken.
> Klingt wie ein Argument für Blackboxen.
Nein, das klingt wie eine Ausrede für Inkompetenz.
Felix
--
Fast ship? You mean you've never heard of the Millennium Falcon?
--Han Solo
Felix von Leitner
> größeren WWW-Clustern. Da verwende die doch hinter einem LoadBalancer
> einheitlich dasselbe OS. Ein DoS, 12x wiederholt, läßt dann die komplette
> Serverphalanx down gehen, anstatt ein Linux, ein OpenBSD, ein Solaris ...
> abwechselnd einzusetzen. GNU Software ist ja "write once, run everywhere"
Du Knalltüte verwechselst hier offensichtlich Symptom und Krankheit.
Sicher ist ein System, wenn der DoS-Angriff gar nicht funktioniert,
nicht wenn er "nur" bei der Hälfte funktioniert.
Felix
Felix von Leitner
> Es gibt auch keine Bufferoverflows für SunOS,
Sicher?
> aber möglicherweise in SunOS oder anderen darunter auf einem
> Sparc-Rechner laufenden Programmen.
> ZB sowas:
> int main()
> {
> char buf[256];
> while (gets(buf)) printf("%s\n", buf);
> return 0;
> }
>
> Wie man deutlich sehen kann, gibt es keine Ähnlichkeiten zur oa
> Fotografie.
> Für solche (latenten) Pufferüberläufe gibt es wiederum Exploits, zB
> für Sparc-Prozessoren, s.o.
Aufpassen. Bei SPARC ist das mit den Buffer Overflows schwieriger, da
Funktionsaufrufe über Registerfenster gehandhabt werden, d.h. erst nach
einem System Call oder Kontextwechsel werden die Daten vom Stack gelesen
und werden aktiv. Daher funktionieren Buffer Overflow Exploits auf
SPARC so, daß sie den _zweiten_ Stackframe angreifen, d.h. wenn die
Funktion, die die Funktion mit dem Buffer Overflow aufgerufen hat,
beendet wird, wird erst der Exploit-Code ausgeführt. Im obigen Fall
also: nie.
Disclaimer: ich hab mir den SPARC Startup-Code nicht angesehen, kann
also nicht ausschließen, daß da nicht auch noch ein return drin ist.
Felix
Felix von Leitner
> Exploits auf jeden Prozessor zu portieren, der überhaupt irgendwo
> verwendet wird, damit diese Schwachsinnsdebatte hier zu einem aprupten
> Ende käme.
Das wäre sozusaugen automatisch der Fall, wenn ich die diet libc auf so
eine Plattform portieren würde. Leider kenne ich niemanden, der eine
SuperH hat und mich mal damit basteln lassen würde. :(
> Fehlerhafte Programme möchte man reparieren, nicht im Keller
> verstecken. Gefunden werden sie da nämlich auch.
ACK.
Rainer Weikusat
> Rainer Weikusat wrote:
> > Ich wünschte, ich hätte ausreichend Zeit und Geld einen dieser
> > Exploits auf jeden Prozessor zu portieren, der überhaupt irgendwo
> > verwendet wird, damit diese Schwachsinnsdebatte hier zu einem aprupten
> > Ende käme.
>
> "auf jeden Prozessor"?
Ja.
> Probier doch mal einen BufferOverflow für
> Linux/Intel auf Linux/ARM oder Linux/Sparc aus ....da passiert
> nämlich nix.
Doch.
> Probier doch mal einen BufferOverflow für Linux/Intel auf Linux/ARM oder
> Linux/Sparc aus ....da passiert nämlich nix.
Du wolltest 'Shellcode' sagen und das passiert sehr wohl etwas,
lediglich resultiert das nicht in einer root-Shell.
--
near
distant
Ralf Ertzinger
>> verwendet wird, damit diese Schwachsinnsdebatte hier zu einem aprupten
>> Ende käme.
>
>"auf jeden Prozessor" ??? Probier doch mal einen BufferOverflow für
>Linux/Intel auf Linux/ARM oder Linux/Sparc aus ....da passiert nämlich nix.
Ach was. Fuehr Dir doch mal das zu Gemuete:
http://www.phrack.org/show.php?p=57&a=14
Wuensche angenehme Traeume.
Felix von Leitner
Hahaha, _Threads_ hahahaha.
Absolut lächerlich. Der Mann kann ja sogar von Herrn Dingler noch was
lernen.
Ach ja, und anfragen gehen immer von Port 53 raus. -> Tonne.
> -mto: pdnsd will use TCP only. TCP queries usually take longer time than
> UDP queries, but are more secure against certain attacks, where an attacker
> tries to guess your query id and to send forged answers. TCP queries are
> not supported by some name servers.
Wie er selber sieht, lohnt sich eine Standardverletzung nicht wirklich.
-> Tonne.
> -mtu: pdnsd will try to use TCP, and will fall back to UDP if its
> connection is refused.
Boah, ey. Vereint also die Nachteile von beiden.
> Ähnlich den IBM DNS Servern kann man diesen Caching DNS Server seine
> Anfragen durch eine "normale" Firewall, d.h. durch einen normalen
> Paketfitler via TCP ausführen lassen.
"Wenn du den Feind nicht besiegen kannst, verwirre ihn!" oder wie?
Was soll das denn für eine Aussage sein?!
> Sicherheitshalber in einer CHROOT() Umgebung mit minimalen
> User-Rechten.
Herr, vergib ihm, denn er weiß nicht, was er tut.
> Damit sollten sich dann viele der hier diskutierten Probleme erübrigen,
> oder nicht ?
Die Probleme erübrigen sich, wenn man eine sichere Software benutzt.
Wie z.B. djbdns.
Felix
Felix von Leitner
> PDNSD !!!!!!!!!
Noch kurz am Rande:
-rwxr-xr-x 1 leitner users 120316 Nov 3 18:07 src/pdnsd
-rwxr-xr-x 1 root root 48264 Nov 3 10:12 /usr/local/bin/dnscache
-rwxr-xr-x 1 root root 21232 Nov 3 10:12 /usr/local/bin/tinydns
Guido Stepken
Ja ? Ein Beispiel:
#!/usr/bin/python
import httplib
h = httplib.HTTP('www.leitner.de')
h.putrequest('GET', '/index.html')
h.putheader('Accept', 'text/html')
h.putheader('Accept', 'text/plain')
h.endheaders()
errcode, errmsg, headers = h.getreply()
print errcode
f = h.getfile()
print f.read()
f.close()
und noch eins:
#!/usr/bin/python
import CGIHTTPServer, BaseHTTPServer
#class Handler(CGIHTTPServer.CGIHTTPRequestHandler):
# cgi_directories = ["/cgi-bin"]
def startServer():
PORT = 8020
httpd = BaseHTTPServer.HTTPServer(("", PORT),"")
httpd.serve_forever()
Einen Proxy kann man einfache aus diesen beiden Skripten zusammenfügen,
einen kleinen Filter einbauen ...., ist auch nur 1 A4 Seite
.....Feldlängenbegrenzungen sind durch Hinzufügen von [:30] an geeigneter
Stelle zu machen. Da sieht man auch direkt, an welcher Stelle auf
Sicherheit geachtet wurde.
>> Es ginge schon, mit Funktionaler Programmierung, und einer wirklichen
>> OO-Sprache, die auch noch überaus lesbar ist.
>
> Dieser Satz macht keinen Sinn.
OK. Dein Problem.
>> Zahlreiche Python Projekte haben das gezeigt, darunter auch Proxies
>> (rubbishproxy), Server (Zope), die Code - reuse erlauben und überaus
>> lesbar noch nach Jahren sind.
>
> Zope war doch die Software, wo alle halbe Stunde ein Security- oder
> Stability-Update rauskommt, oder? Gutes Zeichen für echt lesbaren Code.
> Duh. Guido, spontan fallen mir nicht viele Gruben ein, in die du noch
> fallen könntest. D.h. warte, du könntest noch aus Sicherheitsgründen
> Windows empfehlen.
>> IMHO ist es eh ein Kampf gegen Windmühlen ....man muß es
>> so schwer, wie möglich machen.
>
> So mag das aus der Ferne aussehen, wenn man das alles nicht versteht,
> aber trotzdem wichtig aussehen will. Man deklariert einfach, daß es eh
> nicht geht, aber nur mit deinen eigenen innovativen Sicherheitstips ist
> Sicherheit überhaupt annäherbar. Da stehen deine Kunden sicher tierisch
> drauf. Deine Mami muß stolz auf dich sein.
Deine hat zumindest bei Deiner Erziehung gefehlt.
>> JAVA , RMI ? Ich mag JAVA nicht, Python ist besser ....;-))
>
> Depp.
>
>
Danke ! Ich weiß ja, von wem es kommt.
Guido Stepken
> Thus spake Guido Stepken (ste...@little-idiot.de):
>> > BIND _ist_ der Bug! Du hast die Liste der bisher gefundenen Bugs vor
>> > dir und findest es immer noch vertretbar, diese Software einzusetzen!?
>> > Bist du blind?
>> Hmmm, sendmail hat auch eine lange Geschichte von BUGS, inzwischen hat
>> jedoch sendmail erheblich an Sicherheit aufgeholt,
>
> Nein.
>
>> Bei BIND in einer CHROOT() Umgebung scheint mir das Risiko, daß der
>> Server komplett gecrackt wird, recht niedrig ...
>
> Relevant ist nicht, was dir scheint, sondern was in der Realität
> passiert. Ein Server, auf dem der BIND ständig mysteriös abraucht, ist
> schlecht. Ob da jetzt ein Cracker bis zu einer root-Shell kommt oder
> nicht spielt keine Rolle.
In der Praxis schon, im einen Fall muß Du nämlich Deinen Server neu
aufbauen, im anderen einen Dämon neu starten. Für mich macht das einen
Unterschied...
>> C-Programme sind immer kritisch,
>
> Nein.
Aha. Deswegen wurde auch viel Geld für die Entwicklung von ADA z.B.
ausgegeben, weil man in C ja so gut, einfach, übersichtlich und lesbar
programmieren kann .....
>> zumal diese oft völlig unlesbar sind.
>
> Bullshit.
Ja ?
>> Grausam ! Schön wäre ein DNS Server in PERL oder besser Python
>> geschrieben.
>
> Mann, du bist ja eine Gefahr in deiner Unkenntnis!
> Warst du nicht sogar der Typ, der ein Firewall-HOWTO oder so geschrieben
> hatte? Oh Graus!
Du möchtest irgendwie nichts dazu lernen.....ok. Dann verwende doch Deine
überaus hohe Intelligenz mal zum Nutzen der Allgemeinheit, und suche in
Linux nach Fehlern, z.B. in u.a. Code....
>> Hier von D.J.Bernstein, Autor von QMail ein "sicherer" Caching DNS Server
>> : http://cr.yp.to/djbdns/faq.html
>
>> Was ist von dem zu halten ?
>
> Ist das eine Trickfrage?
>
Nein, ich habe mir den Code noch nicht angesehen ..... ich gehe mal davon
aus, das djbdns ebenso, wie qmail sie hat(te) auch Fehler hat. Hast Du den
Code analysiert ? Viele Augen sehen ja mehr als wenige ...
int stralloc_catb(stralloc *sa,const char *s,unsigned int n)
{
if (!sa->s) return stralloc_copyb(sa,s,n);
if (!stralloc_readyplus(sa,n + 1)) return 0;
byte_copy(sa->s + sa->len,n,s);
sa->len += n;
sa->s[sa->len] = 'Z'; /* ``offensive programming'' */
return 1;
Bei dem Code wird mir übel. Das geht dann hunderte Seiten so weiter. Wer
soll denn da noch Fehler finden ?
Ich denke, wir baruchen neue Konzepte für die Programmierung von Diensten
auf Servern, soweit ich weiß, bemühen sich sehr viele kluge Köpfe darum.
Gru/3, Guido
> Felix
>
Felix von Leitner
> >> Dinge, die sich wenig ändern sollte man halt mit ro,noatime mounten.
> >> Andere gehen öft natürlich nicht ...
> >
> > Guido brilliert wieder mit seinem Wissen... :(
> >
> > Warum machst du nicht gleich ro,noatime,ro,ro,ro? Und am besten noch
> > mount -r? Hint: noatime ist überflüssig bei ro.
> >
Guido, DU MUSST DAS MIT DEM QUOTEN LERNEN, sonst wird man die
Schwachsinnigkeit deiner inhaltlichen Aussagen gar nicht wahrnehmen,
weil dein Posting-Stil schon so unter aller Sau ist.
[28 weitere Zeilen Müll-Quoting gelöscht]
> >> Hmmm, 3000 Zeilen C-Code entsprechen etwa 250 Zeilen Python Code.
> > Bullshit.
> Ja ? Ein Beispiel:
> #!/usr/bin/python
> import httplib
>
> h = httplib.HTTP('www.leitner.de')
> h.putrequest('GET', '/index.html')
> h.putheader('Accept', 'text/html')
> h.putheader('Accept', 'text/plain')
> h.endheaders()
> errcode, errmsg, headers = h.getreply()
> print errcode
> f = h.getfile()
> print f.read()
> f.close()
#include <stdlib.h>
main() {
system("fget http://www.leitner.de/index.html");
}
> und noch eins:
> #!/usr/bin/python
> import CGIHTTPServer, BaseHTTPServer
> #class Handler(CGIHTTPServer.CGIHTTPRequestHandler):
> # cgi_directories = ["/cgi-bin"]
>
> def startServer():
> PORT = 8020
> httpd = BaseHTTPServer.HTTPServer(("", PORT),"")
> httpd.serve_forever()
#include <stdlib.h>
main() {
system("tcpserver -RHl localhost 0 8020 fnord");
}
[noch 25 überflüssige Zeilen Quoting gelöscht]
Guido, sagte ich schon, daß du DAS MIT DEM QUOTING JETZT SOFORT UMGEHEND
LERNEN MUSST, und daß du HIER NIE WIEDER POSTEN SOLLST, BIS DU DAS
VERSTANDEN HAST?
> >> IMHO ist es eh ein Kampf gegen Windmühlen ....man muß es
> >> so schwer, wie möglich machen.
> > So mag das aus der Ferne aussehen, wenn man das alles nicht versteht,
> > aber trotzdem wichtig aussehen will. Man deklariert einfach, daß es eh
> > nicht geht, aber nur mit deinen eigenen innovativen Sicherheitstips ist
> > Sicherheit überhaupt annäherbar. Da stehen deine Kunden sicher tierisch
> > drauf. Deine Mami muß stolz auf dich sein.
> Deine hat zumindest bei Deiner Erziehung gefehlt.
Danke für dein Eingeständnis, daß du keine Ahnung hast und dich die
inhaltlichen Argumente völlig überfordern und du daher nur ein bißchen
unrelevanten Bullshit zu sagen hast. Das wird anderen bei der
Evaluierung deiner Aussagen helfen.
> >> JAVA , RMI ? Ich mag JAVA nicht, Python ist besser ....;-))
> > Depp.
> Danke ! Ich weiß ja, von wem es kommt.
War erwartest du Knalltüte denn, wenn du Aussagen der Form "Zucker ist
besser als Salz" triffst?
Felix
Ralf Ertzinger
>Das wäre sozusaugen automatisch der Fall, wenn ich die diet libc auf so
>eine Plattform portieren würde. Leider kenne ich niemanden, der eine
>SuperH hat und mich mal damit basteln lassen würde. :(
In der Dreamcast laeuft ein SH4, wenn Dir das genuegt. Die sind im
Moment sehr billig zu kriegen, und Linux laeuft da auch drauf.
Das einzige Problem ist, den Ethernet-Adapter zu bekommen.
Immo 'FaUl' Wehrenberg
begin followup to the posting of Guido Stepken:
>>> Hmmm, 3000 Zeilen C-Code entsprechen etwa 250 Zeilen Python Code.
>>
>> Bullshit.
> Ja ? Ein Beispiel:
> #!/usr/bin/python
> import httplib
>
> h = httplib.HTTP('www.leitner.de')
> h.putrequest('GET', '/index.html')
> h.putheader('Accept', 'text/html')
> h.putheader('Accept', 'text/plain')
> h.endheaders()
> errcode, errmsg, headers = h.getreply()
> print errcode
> f = h.getfile()
> print f.read()
> f.close()
Muhaha
#include "myhtmllib.h"
int main (void) {
return printhtmlsite("www.leitner.de");
}
ist das gleiche und kuerzer.
> und noch eins:
[snip]
...was man genauso in C machen koennte. Man, in Pyton muessen die
Librarys geschrieben werden, in C auch.
FaUl
end
This article does not support incompatible and broken newsreader.
--
"Um sich als Idiot zu qualifizieren, mußt man eine Frage stellen, die
trivial in unter einer halben Stunde eigener Recherche zu klären gewesen
wäre." - Felix von Leitner
Guido Stepken
> Guido Stepken <ste...@little-idiot.de> writes:
>>
<URL:http://sunsolve.sun.com/pub-cgi/retrieve.pl?doctype=coll&doc=secbull/191&type=0&nav=sec.sba>
>> >
>> > Deine 'Es gibt keine Exploits für non-x86'-Behauptung ist folglich
>> > Makulatur.
>>
>> Ich redete von BO und Exploits u.a. für LINUX/SPARC , der o.a. BUG ist
>> ohne spezielle Assembler Kenntnisse auszunutzen.
>
> Read: Es gibt Exploits dafür. Wir drehen uns im Kreis.
>
>
<URL:http://archives.indenial.com/hypermail/bugtraq/1998/June1998/0067.html>
>
> 'Spezielle Assemblerkenntnisse' sind für den elementaren Quatsch
> ohnehin nicht vonnöten, eher stupide Bastelwut. Registermaschinen sind
> nicht wirklich kompliziert zu programmieren.
>
>> Natürlich gibt es auch BufferOverflows für SUN OS / SPARC.
>
> Nein, für Sparc gibt es keine buffer overflows (allmählich kann ichs
> nicht mehr hören), denn das ist ein Mikrochip.
habe ich so nicht gesagt.
> Das sieht so aus:
>
> <URL:http://bwrc.eecs.berkeley.edu/CIC/die_photos/ultrasparc.jpg>
>
Fein. Ein Bild.
> Es gibt auch keine Bufferoverflows für SunOS, aber möglicherweise in
> SunOS oder anderen darunter auf einem Sparc-Rechner laufenden
> Programmen.
>
> ZB sowas:
>
> int main()
> {
> char buf[256];
>
> while (gets(buf)) printf("%s\n", buf);
> return 0;
> }
Ich ging stillschweigend von Remote Exploits aus, die irgendwelche Cracker
von Zuhause aus ausführen, nicht von lokalem Blödsinn, denn man so machen
kann.
>
> Wie man deutlich sehen kann, gibt es keine Ähnlichkeiten zur oa
> Fotografie.
>
> Für solche (latenten) Pufferüberläufe gibt es wiederum Exploits, zB
> für Sparc-Prozessoren, s.o.
>
>> >> > der einen solchen erlaubt hätte, aber ich bin im Moment zu faul,
>> >> > 2.2.15-diffs zu lesen...).
>> >> >
>> >> Deine URL scheint etwas veraltet,
>> >
>> > Warum liest Du sie eigentlich nicht?
>>
>> BUGTRAQ und packetstormsecurity.com sind informativer ...
>
> Als Ausrede für 'aber das sind ja die 2.2 RELNOTES, wie konnte mir das
> nur entgehen' bleibt das etwas dämlich.
>
>> > Falls es 'in Verbindung mit sendmail' zu einer Lücke führte, war es
>> > mit Sicherheit kein remote exploitbarer Überlauf im
>> > Linux-TCP/IP-Stack (pcap?). Wie wärs wenn Du Deine Behauptungen mal
>> > mit etwas mehr Hintergrund als 'Ich kann mich erinnern' unterfüttern
>> > würdest?
>> >
>> >
>> Siehe http://www.securityfocus.com ..../bugtraq ...
>
> Also nein. Hätte mich auch gewundert.
>
;-)
Guido Stepken
>> Ab dann läuft ein Timer für 10 Sekunden. Danach ist die Firewall
>> wieder für UDP/53 nicht mehr offen, d.h. evtl. Buffer Overflow
>> Angriffe müssen geschickter durchgeführt werden.
>
> Oh, mein Fehler. Ich nahm an, es ginge hier um Sicherheit und nicht um
> Hokus-Pokus. Wenn ich keine Buffer Overflows haben will, dann setze ich
> eine Software ein, die keine hat, und fummel nicht irgendwelche
> Obfuscation Layer mit irgendwelchen Paketfilter-Kludges zusammen.
>
Mit Deiner Argumentation sollte man besser sichere Server und Clients
schreiben, dann sind Firewalls jedenfalls völlig überflüssig. Armes
Checkpoint ;-))
>> Hierzu muß der Cracker dann auf dem DNS des Providers sitzen,
>
> Nein.
>
>> >> Ich war auch etwas erstaunt, als ich mir den Quellcode von Linux
>> >> abgesehen habe, und feststellen mußte, daß hier einige Timeouts eine
>> >> wichtige Rolle spielen.
>> > Was hast du nach der Lektüre der einschlägigen RFCs denn erwartet?!
>> Ich meine den Code der SPF
>
> Ja und? Natürlich müssen da Timeouts drin sein, sonst alloziert Linux
> unendlich viel Speicher für Tabellen, wenn alte Einträge nicht
> rausfliegen. Guido, hast du eigentlich an irgend einer Stelle auch nur
> rudimentär Ahnung von Security, Algorithmen und Firewalls oder läßt du
> nur gerne Buzzwords fallen?
Nö. Anscheinend ja nicht, aber ich lerne ja von Dir.
>> >> > Wer BIND einsetzt, ist eh ein Idiot.
>> Naja, das Risiko bei BIND in einer CHROOT() Umgebung ist recht gering,
>> sofern man stets die neuesten Patches aufspielt.
>
> Solange man sich nicht im Universum aufhält, ist man vor Kometen sicher.
> Ganz toll.
>
Sehr sachlich.
>> Soweit ich mich erinnere, gab es mehrere Security Meldungen auch bei
>> Qmail und sogar bei postfix, beide waren unter dem Aspekt der Sicherheit
>> programmiert worden.
>
> Schmerz laß nach, noch mehr FUD über Sachen, die du nicht verstanden
> hast? Oh Mann. Seufz.
Ok.
> Das "sogar bei postfix" finde ich persönlich die Krönung deiner
> Inkompetenz. Laß gut sein, Guido. Bevor du dich noch mehr lächerlich
> machst.
Einerseits sagst Du, es gäbe keine sicheren Lösungen, andereseits scheinst
Du bestimmte Paket für sicher zu halten. Was meinst Du wirklich ?
>> 1. Alle Dämonen in einer CHROOT() Umgebung mit geringen User-Rechten
>> installieren.
>
> Ganz toller Plan. man sshd. man ftpd.
Hä ?
>> 2. Die CHROOT() Umgebung nach Änderungen der Konfiguration wieder
>> readonly mounten, also auf einer eigenen Partition lagern.
>
> Wird ja immer besser. Bin ja gespannt, wie du deine Kunden dann per FTP
> Dateien uploaden läßt.
Die natürlich nicht auf die Nutzlast-Partition....
>> 3. Patches stets schnell aufspielen.
>
> Job-Security marke Guido Stepken, wie?
> Ich wähle meine Software lieber so aus, daß keine Patches notwendig
> werden, und sorge auf konzeptioneller Ebene für eine
> Schadenseingrenzung.
>
Das ist natürlich immer gut. Bitte posten.
>> 4. QoS Modul im Linux Kernel aktivieren, um Flooding und die Überlastung
>> des Server zu verhindern.
>
> Pappnase!
Karneval ist erst am 11.11. ;-)
> "Ihr Webserver ist nicht erreichbar! Ist der gehackt worden?"
> "Nein, das ist eine Sicherheitsmaßnahme unseres Beraters Guido Stepken,
> damit der Server nicht überlastet wird"
Zumindest kann man einige DoS und DDoS Angriffe damit abwehren. Mehr als
xxx SYN's/Sekunde von und (vor allem!) zu einer IP - Nummer muß man ja
nicht zulassen. Außerdem hilft ja noch Random Early Drop im TCP/IP Stack
...gegen gespooftes SYN-Flooding ....
>> 5. Server als User-Mode Linux auf einem Linux laufen lassen. Im Falle
>> einer Fehlbedienung oder einer Sabotage ist ein Virtuelles Linux
>> innerhalb von 5 Minuten wiederherzustellen.
>
> Grandiose Obscurity. Und bei heutigen PC-Preisen nicht nachvollziehbar.
> Außerdem ist nicht klar, wieso jemand, der in ein virtuelles Linux
> einbrechen kann, nicht auch in das Linux darüber einbrechen können
> sollte.
>
> Hast du dir deine großartigen Ideen schon patentieren lassen?
Nö, ich wichs mir aber immer wieder einen drauf, wenn ich Deine Kommentare
lese....hihi....und hoffe, daß es "Otto- Normaladminstrator" nachvollziehen
kann.
>> 6. User-Mode Linux erlaubt die Feststellung von Manipulationen durch
>> Abgleich mit den Backup's der darunter liegenden Maschine.
>
> Das ist ja wirklich grotesk.
>
Ich liebe das .... ;-)
>> 7. Nicht INTEL CPU's verwenden, da die meisten Buffer Overflows speziell
>> für Intel Prozessoren geschrieben wurden.
>
> Huihuihui, das wird ja immer sicherer!
>
> Guido, sagt dir "Security by Obscurity isn't" etwas?
> Offensichtlich nicht.
>
Ich habe schon seit Jahren nix mehr mit Closed Source zu tun....
>> 8. Ein PERL/Python/BASH Script für den Test der Funktionsfähigkeit der
>> Dämonen alle paar Minuten starten. Evtl. die Dämonen neu starten (gegen
>> DoS)
>
> Muhahaha. Jemand erzeugt per DoS eine Monster-Load auf deiner Kiste,
> und du machst das noch viel schlimmer, indem du a) bloat-monster wie
> Python oder perl alle paar Minuten laufen läßt und b) ständig Daemons
> restartest.
Ein kleines Geheimnis: Wenn man es geschickt anstellt, dann kann man auch
feststellen, wann einer überlastet ist.....und Gegenmaßnahmen z.B. über die
in Linux eingebaute Firewall in Verbindung mit dem Bandbreiten limiter
einleiten..... counter intelligence ......genannt.
>
>> 9. Niemals einen Server via SSH, TELNET+SSL o.ä. "sichere" Interfaces
>> administrieren. SSHD selber ist auch ein Sicherheitsproblem. ISDN mit EAZ
>> Kennung ist da viel sicherer.
>
> Bwaaaaahahaha, Guido, geh weg. Lösche deinen tollen Firewall-Guide und
> laß das jemanden machen, der sich damit auskennt. Hint: das bist nicht
> du. Am besten solltest du auch schnell eine Umschulung machen. Es
Wieso, als Schwimmlehrer arbeiten mach doch Spaß ....
> findet sich sicher ein Job für dich, aber der wird weit weg von Security
> und Computern sein.
Hihi.
>> Stets für Nutzlast und Administration unterschiedliche Netzwerke
>> verwenden (VLAN, ISDN, Modem ...)
>
> Ein VLAN ist kein unterschiedliches Netzwerk.
> Du machst wirklich alles falsch. Erstaunlich.
>
Laut Bedienungsanleitung von Switchen kann man einzelne Ports zu einer
colllision domain schalten ....geniale Idee.
>> 10. KISS Prinzip (Keep It Small and Simple) beachten.
>
> Das sagt jemand, der geschachtelte User-Mode-Linuxe mit minütlichen
> Perl- oder Python-Scripts laufen lassen will? Wo ist die versteckte
> Kamera? Das ist doch mit Sicherheit eine Satiresendung hier!
>
Habe ich nicht gesagt.
>> Ich verdamme nicht einfach Software, weil sie Fehler hat. Mit o.a. Tips
>> kann man sehr viel mehr an Stabilität und Sicherheit erreichen.
>
> Deine "Tips" zeugen von einer Inkompetenz von geradezu kosmischen
> Ausmaßen und erreichen das Gegenteil von Stabilität. Du baust hier
> irgendwelche filigranen Fantasie-Komplexitäten zusammen und wunderst
> dich dann, wenn unten ein Hund gegenpinkelt und alles zusammenfällt.
>
Ich habe nur ein Steh-Auf-Männchen (Server) gebaut, mehr nicht.
>> > BIND 9 sah mal eine kurze Zeit ganz gut aus. Anfangs, als sie ihn
>> > ankündigten. Aber dann kam _noch_ größere Software raus, die von einem
>> > nmap gekillt wurde. Zusammenfassung: BIND muß sterben. Bist du nicht
>> > Teil der Lösung, bist du Teil des Problems.
>> Hihi, naja DoS auf den Dämon ist immer unangenehm .....
>
> Das war nicht nur ein DoS auf einen Dämon, das war ein fucking
> Port-Scan, wie er jeden Tag millionenfach im Internet passiert.
>
Was ?
> Felix
>
Felix von Leitner
> >> Server komplett gecrackt wird, recht niedrig ...
> > Relevant ist nicht, was dir scheint, sondern was in der Realität
> > passiert. Ein Server, auf dem der BIND ständig mysteriös abraucht, ist
> > schlecht. Ob da jetzt ein Cracker bis zu einer root-Shell kommt oder
> > nicht spielt keine Rolle.
> In der Praxis schon, im einen Fall muß Du nämlich Deinen Server neu
> aufbauen, im anderen einen Dämon neu starten. Für mich macht das einen
> Unterschied...
Wen interessiert das? Wenn es zu einem der beiden kommt, hast du als
Sicherheitsberater komplett versagt. Scheint bei dir ja öfter
vorzukommen, wenn man nach deinen verzweifelten "Maßnahmen" hier geht.
"Machen wir mal nen anderen Prozessor rein, vielleicht schaffen sie es
dann nicht mehr".
> >> C-Programme sind immer kritisch,
> > Nein.
> Aha. Deswegen wurde auch viel Geld für die Entwicklung von ADA z.B.
> ausgegeben, weil man in C ja so gut, einfach, übersichtlich und lesbar
> programmieren kann .....
Nur weil _du_ es nicht kannst, heißt das nicht, daß es nicht geht.
> >> zumal diese oft völlig unlesbar sind.
> > Bullshit.
> Ja ?
Ja. "Oft" ist kein sinnvoller Quantor, weil seine einzige Aussage ist,
daß der Sprecher weniger erwartet hätte. Diese Aussage ist also absolut
wertlos.
> >> Grausam ! Schön wäre ein DNS Server in PERL oder besser Python
> >> geschrieben.
> > Mann, du bist ja eine Gefahr in deiner Unkenntnis!
> > Warst du nicht sogar der Typ, der ein Firewall-HOWTO oder so geschrieben
> > hatte? Oh Graus!
> Du möchtest irgendwie nichts dazu lernen.....ok. Dann verwende doch Deine
> überaus hohe Intelligenz mal zum Nutzen der Allgemeinheit, und suche in
> Linux nach Fehlern, z.B. in u.a. Code....
Hast du mal in Erwägung gezogen, vor dem Posten minimale Erkundigungen
einzuziehen?
> >> Hier von D.J.Bernstein, Autor von QMail ein "sicherer" Caching DNS Server
> >> : http://cr.yp.to/djbdns/faq.html
> >> Was ist von dem zu halten ?
> > Ist das eine Trickfrage?
> Nein,
Ich habe eine FAQ dazu geschrieben und auf meiner Homepage
veröffentlicht. Sie ist von www.tinydns.org verlinkt.
Es war also gar nicht so einfach für dich, sie _nicht_ zu finden.
> ich habe mir den Code noch nicht angesehen ..... ich gehe mal davon
> aus, das djbdns ebenso, wie qmail sie hat(te) auch Fehler hat.
qmail hatte keine Fehler und djbdns auch nicht.
> Hast Du den Code analysiert ?
Ja.
> Viele Augen sehen ja mehr als wenige ...
Deine Augen sehen offensichtlich gar nichts.
> Bei dem Code wird mir übel. Das geht dann hunderte Seiten so weiter. Wer
> soll denn da noch Fehler finden ?
Wenn du es nicht kannst, dann solltest du einen Beruf suchen, der dich
nicht so grob überfordert.
> Ich denke, wir baruchen neue Konzepte für die Programmierung von Diensten
> auf Servern, soweit ich weiß, bemühen sich sehr viele kluge Köpfe darum.
"Blubber"
Felix
Guido Stepken
Das sind recht nette Tricks. Um das so machen zu können, muß man jedoch
lokaler User auf dem Server sein. I dem Falle ist fast jeder Server
verloren. Remote Exploits sind aber so nicht zu kontruieren, da muß man
bereits gezielt Assembler einsetzen, um diese Art von Exploit plazieren zu
können.
Wie gesagt, ich gehe immer von remote Exploits aus...
Gru/3, Guido Stepken
Guido Stepken
> Thus spake Guido Stepken (ste...@little-idiot.de):
>
>> Hast Du den Code analysiert ?
>
> Ja.
Du scheinst Größenwahnsinnig.
Felix von Leitner
> > Hokus-Pokus. Wenn ich keine Buffer Overflows haben will, dann setze ich
> > eine Software ein, die keine hat, und fummel nicht irgendwelche
> > Obfuscation Layer mit irgendwelchen Paketfilter-Kludges zusammen.
> Mit Deiner Argumentation sollte man besser sichere Server und Clients
> schreiben,
Natürlich sollte man das. Firewalls helfen nicht gegen unsichere
Client- oder Server-Software.
> dann sind Firewalls jedenfalls völlig überflüssig.
> Armes Checkpoint ;-))
Checkpoint ist sowieso völlig überflüssig. Firewalls haben in
Umgebungen Sinn, wo die Clients bekanntermaßen unsicher sind.
Trotzdem können sie nur einen Teil der Angriffsvektoren schließen und
sind daher nur in Kombination mit anderen Maßnahmen sinnvoll.
> >> Hierzu muß der Cracker dann auf dem DNS des Providers sitzen,
> >
> > Nein.
Guido, das mit dem Quoten ist WIRKLICH DRINGEND bei dir.
> >> >> > Wer BIND einsetzt, ist eh ein Idiot.
> >> Naja, das Risiko bei BIND in einer CHROOT() Umgebung ist recht gering,
> >> sofern man stets die neuesten Patches aufspielt.
> > Solange man sich nicht im Universum aufhält, ist man vor Kometen sicher.
> > Ganz toll.
> Sehr sachlich.
Mann, Software wird nicht sicher, wenn du sie auf einem Read-Only-Medium
laufen läßt und irgendwo hin chrootest.
Software wird sicher, wenn man sie sicher konzeptioniert und
implementiert. Das ist bei BIND beides schlicht nicht der Fall.
> > Das "sogar bei postfix" finde ich persönlich die Krönung deiner
> > Inkompetenz. Laß gut sein, Guido. Bevor du dich noch mehr lächerlich
> > machst.
> Einerseits sagst Du, es gäbe keine sicheren Lösungen,
Wo soll ich das gesagt haben?
> andereseits scheinst Du bestimmte Paket für sicher zu halten. Was
> meinst Du wirklich ?
Letzteres.
> >> 1. Alle Dämonen in einer CHROOT() Umgebung mit geringen User-Rechten
> >> installieren.
> > Ganz toller Plan. man sshd. man ftpd.
> Hä ?
Aufgabe: web-Hoster, User haben Homes, in die sie per ftp uploaden
sollen und wo sie sich per ssh einloggen können sollen.
Verstehst du wirklich nicht, wieso du sshd und ftpd da nicht chrooten
kannst?
> > Wird ja immer besser. Bin ja gespannt, wie du deine Kunden dann per FTP
> > Dateien uploaden läßt.
> Die natürlich nicht auf die Nutzlast-Partition....
Klar, Kunden dürfen keine Nutzdaten anfassen. Ist ja nur so, daß das
ihre Nutzdaten sind und sie dich dafür bezahlen, daß die da liegen und
geupdated werden können. Prima Konzept. Die Kunden werden in Scharen
zu die strömen.
> Das ist natürlich immer gut. Bitte posten.
man djbdns
> > "Ihr Webserver ist nicht erreichbar! Ist der gehackt worden?"
> > "Nein, das ist eine Sicherheitsmaßnahme unseres Beraters Guido Stepken,
> > damit der Server nicht überlastet wird"
> Zumindest kann man einige DoS und DDoS Angriffe damit abwehren.
Unfug. DDoS flutet dich mit Traffic. Ob du davon die Hälfte
wegschmeißt oder nicht ist unrelevant, deine Außenanbindung ist dicht.
> Mehr als xxx SYN's/Sekunde von und (vor allem!) zu einer IP - Nummer
> muß man ja nicht zulassen. Außerdem hilft ja noch Random Early Drop im
> TCP/IP Stack ...gegen gespooftes SYN-Flooding ....
SYN-Flooding verhindert man mit SYN-Cookies. Ist seit Jahren im Linux
Kernel implementiert und im Übrigen eine Idee von Dan Bernstein. Random
Early Drop trifft auch legitime Kunden und ist daher keine Abwehr,
sondern Obfuscation. Wie deine anderen Tips auch :-(
> > Guido, sagt dir "Security by Obscurity isn't" etwas?
> > Offensichtlich nicht.
> Ich habe schon seit Jahren nix mehr mit Closed Source zu tun....
Du solltest dich auch von Open Source fernhalten.
Und jetzt hast du die Hausaufgabe, dich über obigen Satz zu informieren
und warum er deine gesamten Vorschläge invalidiert.
> > Muhahaha. Jemand erzeugt per DoS eine Monster-Load auf deiner Kiste,
> > und du machst das noch viel schlimmer, indem du a) bloat-monster wie
> > Python oder perl alle paar Minuten laufen läßt und b) ständig Daemons
> > restartest.
> Ein kleines Geheimnis: Wenn man es geschickt anstellt, dann kann man auch
> feststellen, wann einer überlastet ist.....und Gegenmaßnahmen z.B. über die
> in Linux eingebaute Firewall in Verbindung mit dem Bandbreiten limiter
> einleiten..... counter intelligence ......genannt.
Guido, das ist so schön, das kommt in eine Signature. Counter
Intelligence, muhahaha. Köstlich! Wir reagieren auf DoS, indem wir uns
selber DoSsen! Beeindruckend in seiner Abwegigkeit.
> > Ein VLAN ist kein unterschiedliches Netzwerk.
> > Du machst wirklich alles falsch. Erstaunlich.
> Laut Bedienungsanleitung von Switchen kann man einzelne Ports zu einer
> colllision domain schalten ....geniale Idee.
> > Das sagt jemand, der geschachtelte User-Mode-Linuxe mit minütlichen
> > Perl- oder Python-Scripts laufen lassen will? Wo ist die versteckte
> > Kamera? Das ist doch mit Sicherheit eine Satiresendung hier!
> Habe ich nicht gesagt.
Doch. In <9ru6c7$a7v$07$1...@news.t-online.com>.
Ich zitiere das jetzt nicht alles noch mal.
> > Das war nicht nur ein DoS auf einen Dämon, das war ein fucking
> > Port-Scan, wie er jeden Tag millionenfach im Internet passiert.
> Was ?
BIND 9 ist in einer der ersten veröffentlichten Version (nach über zwei
Jahren Entwicklungszeit im Verschlossenen) bei einem simplen Portscan
gestorben.
Felix
Felix von Leitner
> jedoch lokaler User auf dem Server sein. I dem Falle ist fast jeder
> Server verloren.
Nein, warum denn?
> Remote Exploits sind aber so nicht zu kontruieren,
Du bist wirklich ein naiver Troll ohne jede Sachkompetenz.
NATÜRLICH kann man den Shellcode für einen Remote Exploit benutzen.
> da muß man bereits gezielt Assembler einsetzen,
Wen willst du damit verarschen, daß du Assembler als Hürde darzustellen
versuchst?
Felix von Leitner
> >> Hast Du den Code analysiert ?
> > Ja.
> Du scheinst Größenwahnsinnig.
Du scheinst überfordert.
[19 Zeilen Schrott-Quoting entsorgt]
Guido, warum belästigst du uns weiter mit deiner Anwesenheit? Geh doch
einfach wieder dahin, wo du zwischen Juli und dem 1. November warst.
Felix von Leitner
Cool, da müßte ich sogar eine von im Zugriff haben. Danke für den
Hinweis!
Fefe
Guido Stepken
Man muß bereits einen funkionierenden remote Exploit haben, um den in
PHRACK beschriebenen Exploit auf den Rechner transportieren zu können.
Dieser *muß* in der korrekten Maschinensprache geschrieben sein.
Es gibt kein "common assembler"....vielleicht aber bei .NET etwas ähnliches
in Zukunft....
Gru/3, Guido
Rainer Weikusat
> > int main()
> > {
> > char buf[256];
> >
> > while (gets(buf)) printf("%s\n", buf);
> > return 0;
> > }
>
> Ich ging stillschweigend von Remote Exploits aus,
'Remote' wird das in dem Moment, in dem es Eingaben aus dem Netz
bekommt.
--
near
distant
Rainer Weikusat
> Thus spake Rainer Weikusat (weik...@mail.uni-mainz.de):
> > Es gibt auch keine Bufferoverflows für SunOS,
>
> Sicher?
Wenigstens fällt mir nichts sinnvolles ein, was ich ... _für_ SunOS
nennen könnte. 'Von' eher.
--
near
distant
Guido Stepken
Merkwürdig - da behaupten ausgewachsene Mathematiker und Informatiker, daß
man schon bei mehr als 10 Zeilen Code die Korrektheit des (resultierenden)
Codes, mathematisch gesehen, nicht mehr nachweisen kann, und Du behauptest
das Gegenteil.
Der QMail Binary Code enthält noch eine Unmenge von Code der GLIBC und
anderer Bibliotheken, deren Sicherheit sehr fraglich ist.
Warum entdecken die OpenBSD Leute ca. 60.000 mögliche BUGS in dem Code, in
den letzen 3 Jahren Code review ?
Ich möchte meine wirklich Hand nicht ins Feuer legen dafür, daß das QMAIL
Binary keine Fehler hat.
Naja, bei soviel Nettigkeiten Deinerseits hast Du dich in einigen
menschlichen Eigenschaften disqualifiziert.
Ich denke, ich habe genug dazugelernt.
Gru/3, Guido Stepken
Gabriel Krummenacher
> SYN-Flooding verhindert man mit SYN-Cookies. Ist seit Jahren im Linux
> Kernel implementiert und im Übrigen eine Idee von Dan Bernstein.
http://www2.little-idiot.de/firewall/zusammen-49.html#kerneloptionen, den
Abschnitt zu SYN-Cookies beachten.
Gabriel, nur so zur allgemeinen Erheiterung...
Felix von Leitner
> man schon bei mehr als 10 Zeilen Code die Korrektheit des (resultierenden)
> Codes, mathematisch gesehen, nicht mehr nachweisen kann,
Ach ja? Wer behauptet das?
Wann und wo hat er das behauptet?
Bin ja mal gespannt, ob du jetzt Namen nennst, und dich so Rufmordklagen
seitens der beleidigten Mathematiker und Informatiker aussetzt.
> Der QMail Binary Code enthält noch eine Unmenge von Code der GLIBC und
> anderer Bibliotheken,
Nein.
> deren Sicherheit sehr fraglich ist.
Zeige ein Beispiel einer von qmail benutzten libc-Funktion, die jemals
irgendwo eine Sicherheitsloch hatte.
Du hast den qmail-Code offensichtlich nicht einmal _annähernd_
auch nur überflogen und pupst hier trotzdem laut rum! Peinlich,
peinlich.
Ich nehme dir das ab. Ich habe nämlich nicht nur qmail komplett
studiert, sondern auch die intern genutzten Libraries extrahiert und
reimplementiert. Und ich habe eine libc geschrieben, gegen die ich mein
qmail gelinkt habe. Ich kenne daher nicht nur das komplette von qmail
genutzte API, ich habe es auch einmal implementiert.
Es kommen genau zwei Sachen in Frage: res_query/search und syslog.
res_query/search stinken natürlich, wenn man die Variante aus den
BIND-Sourcen nimmt, aber haben m.W. nie Buffer Overflows o.ä. gehabt.
qmail 2 wird das trotzdem gegen eine eigene Implementation tauschen.
syslog() ist in splogger isoliert und Dan hat mit multilog eine drop-in
Alternative geschaffen, daher zählt das nicht.
> Warum entdecken die OpenBSD Leute ca. 60.000 mögliche BUGS in dem Code, in
> den letzen 3 Jahren Code review ?
Weil die BSD-Codebasis bis zum Pluto stinkt?
> Ich möchte meine wirklich Hand nicht ins Feuer legen dafür, daß das QMAIL
> Binary keine Fehler hat.
Parse Error.
> Ich denke, ich habe genug dazugelernt.
Und wieder eine Perle für die Signature-Sammlung!
Du bist wirklich zu gütig.
Felix von Leitner
> PHRACK beschriebenen Exploit auf den Rechner transportieren zu können.
> Dieser *muß* in der korrekten Maschinensprache geschrieben sein.
> Es gibt kein "common assembler"....vielleicht aber bei .NET etwas ähnliches
> in Zukunft....
Schade, zu lang. Sonst wäre das wieder ein prima Kandidat für die
Signaturesammlung gewesen. Kannst du diesen hanebüchenen Unsinn bitte
mal eben auf vier Zeilen mit je unter 78 Zeichen kürzen? Danke.
Die Nachwelt wird dir dankbar sein, daß du so für ihre Erheiterung sorgst.
Felix
Ralf Ertzinger
>Man muß bereits einen funkionierenden remote Exploit haben, um den in
>PHRACK beschriebenen Exploit auf den Rechner transportieren zu können.
Es ging nicht um das grundsaetzliche Vorhandensein eines Exploits, sondern
um das Problem, was auf der Zielmaschine laeuft.
Zugegeben ist es meist einfacher, das auf anderem Wege als zur Laufzeit
rauszufinden.
>Es gibt kein "common assembler"....vielleicht aber bei .NET etwas ähnliches
>in Zukunft....
Der Artikel loest dieses Problem. Liest Du mit?
--
np: Instant Remedy, Commando
Guido Stepken
> Thus spake Guido Stepken (ste...@little-idiot.de):
>> Merkwürdig - da behaupten ausgewachsene Mathematiker und Informatiker,
>> daß man schon bei mehr als 10 Zeilen Code die Korrektheit des
>> (resultierenden) Codes, mathematisch gesehen, nicht mehr nachweisen kann,
>
> Ach ja? Wer behauptet das?
> Wann und wo hat er das behauptet?
int n=10000,b,c=5600,d,e,f[5602],g;main()
{for(;b-c;)f[b++]=n/5;
for(;d=0,g=c*2;c-=14,printf("%.4d",e+d/n),e=d%n)
for(b=c;d+=f[b]*n,f[b]=d%--g,d/=g--,--b;d*=b);}
Etwas provokativ: Beweise mir, daß dieses Programm die Zahl PI korrekt
liefert.
Angesichts der vielen hundert Zeilen von QMAIL dürften diese paar Zeilen
für Dich ja kein Problem sein ....
Ich möchte hiermit nur sagen, daß es verdammt schwierig ist, allein diesen
Vierzeiler korrekt zu testen.
Vielleicht liest Du Dir unter diesem Aspekt nochmals Deine hochtrabenden
Worte durch ....
Ich muß nach diesen "Behauptungen" der Mathematiker selber mal suchen - ist
eine Ewigkeit her....irgendwas mit "Proof mathematical correctness of code"
war das ........
Gru/3, Guido Stepken
Stefan Heinecke
>Mich beschleicht das Gefühl, er macht überhaupt keine Sicherheit.
Doch schon, nur sind seine Konzepte eher fragwürdig und orientieren
sich nicht an Sicherheit, sondern an Lösungen die ein Problem
deterministisch lösen.
>Nein, das klingt wie eine Ausrede für Inkompetenz.
Ich sehe tagtäglich schlimmeres, aber da scheint es nach oben hin keine
Grenze zu geben, Kompentenz zu finden ist schon schwierig, und
letztendlich scheitert es dann am Preis, weil die GF der Meinung ist
das billgste Angebot würde auch reichen, dann kommt sowas dabei raus.
Die CPU-Security-by-obscurity-Argumentation ist völlig zerbrochenes
Design, aber für meinen Chef (Zitat: "Ich bin Laie"), klingt sowas
plausibel, der würd das glatt kaufen, wenn es preiswert genug ist
und das Problem löst.
Stefan Heinecke
(...)
>Ich muß nach diesen "Behauptungen" der Mathematiker selber mal suchen - ist
>eine Ewigkeit her....irgendwas mit "Proof mathematical correctness of code"
>war das ........
Du verwexelst da was, das ist glaube ich dein Problem. Bitte lern quoten.
Felix von Leitner
> >Mich beschleicht das Gefühl, er macht überhaupt keine Sicherheit.
> Doch schon, nur sind seine Konzepte eher fragwürdig und orientieren
> sich nicht an Sicherheit, sondern an Lösungen die ein Problem
> deterministisch lösen.
s/deterministisch/manchmal/
Wenn er deterministisch Sicherheit schaffen könnte, würde ich mich ja
überhaupt nicht über sein Geschreibsel aufregen.
> >Nein, das klingt wie eine Ausrede für Inkompetenz.
> Ich sehe tagtäglich schlimmeres,
Klar. Ich auch.
Trotzdem kann man sowas hier nicht durchgehen lassen, sonst handelt da
noch jemand nach.
> Die CPU-Security-by-obscurity-Argumentation ist völlig zerbrochenes
> Design, aber für meinen Chef (Zitat: "Ich bin Laie"), klingt sowas
> plausibel, der würd das glatt kaufen, wenn es preiswert genug ist
> und das Problem löst.
Nein, der Chef kann ja nicht sehen, ob es das Problem löst.
Das ist ja die Crux bei Computer-Sicherheit.
Chef kann nur sehen, ob jemand bei ihm einbricht. Und wenn ihm sein
Dienstleister dann was von Nanoprobe-Technologie aus geheimen
sibirischen Militärlabors erzählt, gegen die sich niemand wehren könnte,
dann wird Chef ihn auch nicht wegen grober Fahrlässigkeit zu belangen
versuchen.
Felix
Felix von Leitner
> > Wann und wo hat er das behauptet?
> int n=10000,b,c=5600,d,e,f[5602],g;main()
> {for(;b-c;)f[b++]=n/5;
> for(;d=0,g=c*2;c-=14,printf("%.4d",e+d/n),e=d%n)
> for(b=c;d+=f[b]*n,f[b]=d%--g,d/=g--,--b;d*=b);}
> Etwas provokativ: Beweise mir, daß dieses Programm die Zahl PI korrekt
> liefert.
Das tut es nicht.
\pi hat unendlich viele Stellen. Dieses Programm terminiert.
Also kann es nicht \pi ausgeben.
> Angesichts der vielen hundert Zeilen von QMAIL dürften diese paar Zeilen
> für Dich ja kein Problem sein ....
Willst oder kannst du nicht verstehen?
> Ich möchte hiermit nur sagen, daß es verdammt schwierig ist, allein
> diesen Vierzeiler korrekt zu testen.
"Ich verstehe das nicht, also kann es auch sonst niemand verstehen"
Typischer Fall von Napoleon-Komplex.
[46 Zeilen TOFU entsorgt]
Guido, was müssen wir tun, damit du richtig zu Quoten lernst?
Gib uns bitte einen anderen Ausweg als dich als unbelehrbaren Idioten zu
betrachten und im Killfile zu versenken!
Stefan Heinecke
Der kausale Zusammenhang ist deterministisch, Shellcode
für intelkompatible CPUs wird auf anderen CPUs nicht funktionieren.
Das löst nicht das Problem da sind wir uns einig.
>Wenn er deterministisch Sicherheit schaffen könnte, würde ich mich ja
>überhaupt nicht über sein Geschreibsel aufregen.
Hmm ich mag mich nicht mehr aufregen, ich find es eher amüsant, aufregen
muss ich mich schon auf der Arbeit und da tendier ich auch immer mehr
dazu Dinge unmissverständlich zu formulieren und mir unterschreiben zu
lassen, das wir auf Fehlkonfiguration und Mängel hingewiesen haben und
deshalb keine Verantwortung/SLAs/Wartung übernehmen möchten.
>Klar. Ich auch.
>Trotzdem kann man sowas hier nicht durchgehen lassen, sonst handelt da
>noch jemand nach.
Ich bewundere deine Ausdauer in diesem Zusammenhang.
>Nein, der Chef kann ja nicht sehen, ob es das Problem löst.
>Das ist ja die Crux bei Computer-Sicherheit.
Ich sehe das eher als Problem, aber das ist Ansichtssache.
>Chef kann nur sehen, ob jemand bei ihm einbricht. Und wenn ihm sein
>Dienstleister dann was von Nanoprobe-Technologie aus geheimen
>sibirischen Militärlabors erzählt, gegen die sich niemand wehren könnte,
>dann wird Chef ihn auch nicht wegen grober Fahrlässigkeit zu belangen
>versuchen.
Es geht nicht ums Belangen, es geht ums Verständnis der Chefetage für
(komplexe) Zusammenhänge. Beispiel: Wenn ich 30 neue Boxen aufstelle, muss
ich das Adminteam zwangsläufig verstärken, weil es früher oder später zu
Zwischenfällen kommen wird, wenn die Dienste auf den Boxen von Externen
in Betrieb genommen aber nicht gewartet werden. Es wird über kurz oder
lang zu Zwischenfällen kommen, da die Zeit die für den zu betreuenden
Park (meist heterogen) gleich bleibt, aber die Zeit pro Maschine sinkt.
Insofern sind Zwischenfälle vorprogrammiert, und jeder Zwischenfall
reduziert die Betreuungszeit weiter und weiter (schöne Spirale nach
unten).
Aber das sprengt den Rahmen und ist offtopic hier.
Fup2poster gesetzt.
Rainer Weikusat
> Man muß bereits einen funkionierenden remote Exploit haben, um den in
> PHRACK beschriebenen Exploit auf den Rechner transportieren zu
> können. Dieser *muß* in der korrekten Maschinensprache geschrieben
> sein.
Das war der falsche. Außerdem liegt der entscheidende Punkt weniger
darin, daß jemand mit genügend Zeit und Mühe imstande ist, etwas
zusammenzubauen, was zur Laufzeit durch eine Serie von expliziten und
impliziten Tests so etwas tolles wie 'bedingte Verzweigungen'
erzwingt, sondern darin, daß Du (oder jeder andere) binnen einer
beliebig kurzen Zeitspanne 'Shellcode' für jeden Prozessor in allen
Farben, Formen und Größen finden kannst.
ZB in diesem Artikel. Cut'n'Paste genügt.
--
near
distant
Rainer Weikusat
> Die CPU-Security-by-obscurity-Argumentation ist völlig zerbrochenes
> Design,
Sie ist völliger Unsinn. Sie basiert nämlich auf 'zur Zeit höre ich
von den meisten funktionierenden Angriffen gegen x86-Systeme' [Die
stehen nämlich auch in der Zeitung] (vereinfacht). Das sagt etwas
über die Qualität der üblicherweise dort laufenden Software aus. Du
kannst Dir denselben Müll unter Solaris/Sparc installieren und
bekommst sofort genau dieselben Probleme. Sogar das gröhlt schon
ZDNET an den Straßenecken, nur zuhören müßte noch 'von alleine'.
> aber für meinen Chef (Zitat: "Ich bin Laie"), klingt sowas
> plausibel,
Dann würde es Zeit, ihm das mal unplausibel zu machen.
> der würd das glatt kaufen, wenn es preiswert genug ist
> und das Problem löst.
Es ist aber nur dann 'preiswert' 'wenn es das Problem löst'. Was nicht
der Fall ist. Kauft mehr Sparcs, dann gibt es mehr erfolgreiche
Angriffe auf Sparcs. Ist doch hübsch einfach, oder?
--
near
distant
Guido Stepken
Es ist eh nicht so ernst gemeint. Ich habe mir mal den Code von QMail
angesehen. Ich verstehe auch nicht, warum der RFC 822 Parser nicht mit
yacc/bison geschrieben wurde, und jeder mit aufwändigem C und Pointern
teilweise grandiose Pointerkonstruktionen erzeugt, deren Sicherheit mehr
als fraglich ist. Sinus Firewall unter Kernel 2.2 verwendet z.B. yacc für
die "Stateful Inspection Machine", die läuft recht gut. Es hat sich auch
gezeigt, daß viele Parser, die mit Yacc/Flex oder BISON geschrieben wurden,
zuverlässig liefen. (Nicht so der Registry - Parser in NT, wo plötzlich bei
einem Überlangen Passwort alle folgenden Einträge nicht mehr erkannt werden
und z.B. das CDROM ausfällt) In u. a. Beispiel liefert das Programm PI auf
ein paar Stellen, was ist jedoch, wenn man z.B. c=10200 setzt. ?
[root@home stepken]# ./pi1
Segmentation fault (core dumped)
[root@home stepken]# more pi1.c
int n=10000,b,c=10200,d,e,f[5602],g;main()
{for(;b-c;)f[b++]=n/5;
for(;d=0,g=c*2;c-=14,printf("%.4d",e+d/n),e=d%n)
for(b=c;d+=f[b]*n,f[b]=d%--g,d/=g--,--b;d*=b);}
core dumped. Ein bisher korrekt laufendes Programm hat einen BufferOverflow.
IMHO muß man nicht nur die Korrektheit des Codes überprüfen, sondern auch
jedwelche Kombination der Eingabemöglichkeiten auf Überlängen im Einzelnen
und auch in Kombination checken. Diese Zahl an Möglichkeiten halte ich für
nicht überprüfbar.
Einige Angriffe auf Exchange z.B. laufen über überlange Strings in dem
Header der Mail, die halt nicht den typischen Mails entsprechen, jedoch die
möglichen Freiheiten der Definition RFC 822 einer Mail phantasievoll
ausnutzen. Bisher hat noch jeder Exchange seinen Geist aufgegeben, durch
die Firewall hindurch.
Ich möchte nun hiermit nicht behaupten, daß QMail alle phantasievollen
Varianten nicht kennt, jedoch finde ich für mich persönlich, daß der Parser
vom Gefühl her viel zuwenige Anfragen und Verzweigungen hat.
Allein von den kombinatorischen Möglichkeiten her sind hier viel mehr
Varianten möglich, als IF - Abfragen im Code enthalten sind.
Ich habe mich in letzer Zeit daher viel mit Python und sog. Pattern
(Ähnlich REGEXP, aber leistungsfähiger) beschäftigt, um vernünfitge Filter
zu schreiben.....sehr komplex.
Ich möchte daher die Hindernisse für Hacker so schwierig, wie möglich
gestalten, dazu gehört auch u.a. LIDS, OPENWALL Patches, chroot(). Sie
bieten zwar, objetiv gesehen, keinen Schutz, jedoch geben sie mir die
Möglichkeit, den Hacker/Cracker etwas länger zu beschäftigen, was
hoffentlich einige dann abschreckt und den Betrieb aufrecht erhält. In der
Praxis hat es bisher gut funktioniert.
Danke für die nettere PM, ich suche stets noch sichere Alternativen für
Webserver mit CGI-BIN und SQL ....
Gru/3, Guido
Urs [Ayahuasca] Traenkner
> Thus spake Guido Stepken (ste...@little-idiot.de):
[source]
> > Etwas provokativ: Beweise mir, daß dieses Programm die Zahl PI korrekt
> > liefert.
> Das tut es nicht.
> \pi hat unendlich viele Stellen. Dieses Programm terminiert.
> Also kann es nicht \pi ausgeben.
Das erinnert mich daran, letztens in der Zeitung gelesen zu haben, dass
die Herren Mathematiker gerade dabei sind (vielleicht auch schon haben),
zu beweisen, dass PI "normal" ist. Wobei "normal" bedeutet, dass
_irgendwo_ in PI _jede_ Information mind. einmal enthalten ist. Z.B.
dieses Posting. Oder "Krieg und Frieden" von Tolstoi. Man muss nur lange
genug danach suchen.
Schon ein witziges Voelkchen :)
fup2p, Gruss Urs...
Ralf Ertzinger
>die "Stateful Inspection Machine", die läuft recht gut. Es hat sich auch
>gezeigt, daß viele Parser, die mit Yacc/Flex oder BISON geschrieben wurden,
>zuverlässig liefen. (Nicht so der Registry - Parser in NT, wo plötzlich bei
Das ist doch das gleiche Argument wie anderswo in diesem Thread mit dem
20-Zeilen-Python-Proxy, oder? Du kannst doch Komplexitaet nicht dadurch
wegdiskutieren, dass Du sie in externe Programme/Libraries/foo steckst.
>core dumped. Ein bisher korrekt laufendes Programm hat einen BufferOverflow.
>IMHO muß man nicht nur die Korrektheit des Codes überprüfen, sondern auch
>jedwelche Kombination der Eingabemöglichkeiten auf Überlängen im Einzelnen
>und auch in Kombination checken. Diese Zahl an Möglichkeiten halte ich für
>nicht überprüfbar.
Du erzeugst durch Manipulation des Quellcodes einen coredump, und ver-
gleichst das dann mit Bufferoverflows durch Eingaben aus Quellen, die
nicht vertrauenswuerdig sind? Ich habe irgendwo dawzischen den
Faden verloren.
--
R!
Guido Stepken
> Guido Stepken (ste...@little-idiot.de):
>
>>die "Stateful Inspection Machine", die läuft recht gut. Es hat sich auch
>>gezeigt, daß viele Parser, die mit Yacc/Flex oder BISON geschrieben
>>wurden, zuverlässig liefen. (Nicht so der Registry - Parser in NT, wo
>>plötzlich bei
>
> Das ist doch das gleiche Argument wie anderswo in diesem Thread mit dem
> 20-Zeilen-Python-Proxy, oder? Du kannst doch Komplexitaet nicht dadurch
> wegdiskutieren, dass Du sie in externe Programme/Libraries/foo steckst.
Korrekt. Es lohnt sich aber die dahinter liegenden Python Bilbliotheken
anzusehen, die sind auch recht kurz, im Gegensatz zu C.
>>core dumped. Ein bisher korrekt laufendes Programm hat einen
>>BufferOverflow. IMHO muß man nicht nur die Korrektheit des Codes
>>überprüfen, sondern auch jedwelche Kombination der Eingabemöglichkeiten
>>auf Überlängen im Einzelnen und auch in Kombination checken. Diese Zahl an
>>Möglichkeiten halte ich für nicht überprüfbar.
>
> Du erzeugst durch Manipulation des Quellcodes einen coredump, und ver-
> gleichst das dann mit Bufferoverflows durch Eingaben aus Quellen, die
> nicht vertrauenswuerdig sind? Ich habe irgendwo dawzischen den
> Faden verloren.
>
Irgendwo läuft immer eine Schleife, die Eingaben entgegennimmt, und diese
Daten auf überlängen testet. Was ich mit diesem Beispiel nur einfach sagen
wollte, daß es halt nicht so einfach ist, bereits in einem 4-Zeiler einen
möglichen Fehler durch "mal drübersehen" zu finden, geschweige denn zu
analysieren, was das Programm eigentlich tut. Oder hast Du verstanden,
warum da die ersten Ziffern von Pi herauskommen ?
Gru/3, Guido
Guido Stepken
>> Angesichts der vielen hundert Zeilen von QMAIL dürften diese paar Zeilen
>> für Dich ja kein Problem sein ....
>
> Willst oder kannst du nicht verstehen?
>
http://www.cert.org/research/isw/isw97/all_the_papers/no5.html
Naja, da arbeiten Leute mit insgesamt 150 Mannjahren Erfahrung dran. Aber
die hast Du sicher auch ....Ich habe das schon richtig verstanden ...denke
ich...
Ralf Ertzinger
>> Das ist doch das gleiche Argument wie anderswo in diesem Thread mit dem
>> 20-Zeilen-Python-Proxy, oder? Du kannst doch Komplexitaet nicht dadurch
>> wegdiskutieren, dass Du sie in externe Programme/Libraries/foo steckst.
>
>Korrekt. Es lohnt sich aber die dahinter liegenden Python Bilbliotheken
>anzusehen, die sind auch recht kurz, im Gegensatz zu C.
Du plaedierst doch nicht ernstlich dafuer, saemtliche Programme in inter-
pretierten Sprachen neu zu implementieren, weil man sich da um Dinge wie
buffer overflows keine Gedanken machen muss, da das von der Sprachkonzep-
tion her schon nicht geht? Du diskutierst die Notwendigkeit fuer saubere
Programmierung mit riesigen Overheads weg, der dann wieder in C geschrie-
ben ist. Du verlagerst das Problem dahin, wo Du es nicht siehst.
>Irgendwo läuft immer eine Schleife, die Eingaben entgegennimmt, und diese
>Daten auf überlängen testet.
Aha.
>analysieren, was das Programm eigentlich tut. Oder hast Du verstanden,
>warum da die ersten Ziffern von Pi herauskommen ?
Das grundsaetzliche Prinzip ist klar. Die Implementation dagegen weniger.
Ich werde aber nicht meine Hand dafuer ins Feuer legen, dass die vorgese-
hene Anzahl von Stellen stimmt.
--
The I.S.O. standard unit of female pulchritude is the milli-helen. This
is the amount of beauty capable of causing the launching of a single ship.
Felix von Leitner
UND SCHON WIEDER BIST DU DEPP ZU BLÖD ZUM QUOTEN!
Guido, bisher konnte man das als renitente Sturheit gekoppelt mit
absoluter Inkompetenz werten. Ab jetzt ist es aktive Sabotage. Dies
ist deine letzte Warnung.
> Es ist eh nicht so ernst gemeint.
Was ist von wem nicht wie ernst gemeint? Wenn du anständige Quoten
würdest, könnte man dein Gefasel zumindest partiell mit Sinn füllen.
> Ich habe mir mal den Code von QMail angesehen. Ich verstehe auch
> nicht, warum der RFC 822 Parser nicht mit yacc/bison geschrieben
> wurde,
Weil man dann den Code nicht mehr lesen kann.
Nur faule Deppen benutzen bison, und Leute, für deren Grammatik ein Top
Down Parser nicht ausreicht.
> und jeder mit aufwändigem C und Pointern teilweise grandiose
> Pointerkonstruktionen erzeugt, deren Sicherheit mehr als fraglich ist.
Bullshit. Die einzige "Pointerkonstruktion" in qmail ist stralloc und
die ist trivial.
> Sinus Firewall unter Kernel 2.2 verwendet z.B. yacc für
> die "Stateful Inspection Machine", die läuft recht gut.
Aha, und wen kennst du, der das beurteilen könnte? Du selber bist ja
offensichtlich nicht in der Position.
> Es hat sich auch gezeigt, daß viele Parser, die mit Yacc/Flex oder
> BISON geschrieben wurden, zuverlässig liefen.
Was für eine Bullshit-Aussage.
> Einige Angriffe auf Exchange z.B. laufen über überlange Strings in dem
> Header der Mail, die halt nicht den typischen Mails entsprechen, jedoch die
> möglichen Freiheiten der Definition RFC 822 einer Mail phantasievoll
> ausnutzen. Bisher hat noch jeder Exchange seinen Geist aufgegeben, durch
> die Firewall hindurch.
Was für eine Bullshit-Aussage.
> Ich möchte nun hiermit nicht behaupten, daß QMail alle phantasievollen
> Varianten nicht kennt,
Ein inkompetenter Knallkopf würde in seinem Programm Sonderfälle für
irgendwelche bekannten Exploits einbauen. Qmail ist einfach sicher
programmiert. Klar geht dieser subtile Unterschied an einem IT-Bauern
wie dir voll vorbei, daher ja auch meine Ansage, daß du dir lieber einen
anderen Beruf suchst.
> jedoch finde ich für mich persönlich, daß der Parser
> vom Gefühl her viel zuwenige Anfragen und Verzweigungen hat.
"Ich verstehe es nicht, also muß es schlecht sein"
Tolle Argumentationskette, Guido. Und so überzeugend... NOT!
> Allein von den kombinatorischen Möglichkeiten her sind hier viel mehr
> Varianten möglich, als IF - Abfragen im Code enthalten sind.
Du willst dich mal mit Logik und Normalformen von Ausdrücken
beschäftigen und feststellen, daß es da äquivalente Umformungen gibt.
Dilettant!
> Ich habe mich in letzer Zeit daher viel mit Python und sog. Pattern
> (Ähnlich REGEXP, aber leistungsfähiger) beschäftigt, um vernünfitge Filter
> zu schreiben.....sehr komplex.
Oh, kein Zweifel. Für deine Verhältnisse ist das sicher außerordentlich
komplex. Es kommt ziemlich häufig vor, daß sich Dilettanten darauf
spezialisieren, Komplexität anzuhäufen. Sie überblicken das Fachgebiet
schon lange nicht mehr oder haben es noch nie durchblickt, und die
Defensivstrategie gegen die Enttarnung durch Fachleute ist dann einfach,
so abartig komplexe Bastellösungen zusammenzufummeln, daß der Aufwand
für eine Untersuchung den Aufwand für eine Reimplementation um
mindestens eine Größenordnung übersteigt. So glauben sie sicher sein zu
können, daß niemand den Aufwand treiben wird, ihren Schund als solchen
zu entlarven. Funktioniert auch echt oft. Angesichts so eines
Müllhaufens empfehlen nur Wahnsinnige ihrem Kunden nicht, das komplett
in die Tonne zu treten und neu zu machen.
Leider schmeißen auch MCSEs gerne funktionierende Installationen weg, um
sie dann durch einen Haufen dysfunktionalen Müll zu ersetzen.
> Ich möchte daher die Hindernisse für Hacker so schwierig, wie möglich
> gestalten, dazu gehört auch u.a. LIDS, OPENWALL Patches, chroot(). Sie
> bieten zwar, objetiv gesehen, keinen Schutz, jedoch geben sie mir die
> Möglichkeit, den Hacker/Cracker etwas länger zu beschäftigen, was
> hoffentlich einige dann abschreckt und den Betrieb aufrecht erhält. In der
> Praxis hat es bisher gut funktioniert.
Die wenigsten Server werden in ihrer Lebenszeit tatsächlich erfolgreich
penetriert, rein statistisch gesehen. Abgesehen von den IIS-Würmern
natürlich. Deine Aussage ist also keine.
> Danke für die nettere PM, ich suche stets noch sichere Alternativen für
> Webserver mit CGI-BIN und SQL ....
Webserver mit SQL? Warum nicht mit Himbeer-Geschmack?
Einen Webserver mit CGI-Support findest du bei http://www.fefe.de/fnord/
Felix
Rainer Weikusat
> Es ist eh nicht so ernst gemeint. Ich habe mir mal den Code von QMail
> angesehen. Ich verstehe auch nicht, warum der RFC 822 Parser nicht mit
> yacc/bison geschrieben wurde,
Warum sollte er? Mit Zeigeroperationen kann man wunderbar alles
mögliche sehr effizient parsen. Nur sollte man keine Fehler dabei
machen.
> und jeder mit aufwändigem C und Pointern teilweise grandiose
> Pointerkonstruktionen erzeugt, deren Sicherheit mehr als fraglich
> ist.
Was bitte heißt 'mehr als fraglich' (außer: 'Ich (also Du) steige da
nicht mehr durch').
> Sinus Firewall unter Kernel 2.2 verwendet z.B. yacc für
> die "Stateful Inspection Machine", die läuft recht gut.
Läuft sie oder läuft sie nicht?
> Es hat sich auch gezeigt, daß viele Parser, die mit Yacc/Flex oder
> BISON geschrieben wurden, zuverlässig liefen.
Es hat sich auch gezeigt, daß Parser ohne <whatever> zuverlässig
liefen. Nur miteinander hat das nichts zu tun.
> In u. a. Beispiel liefert das Programm PI auf ein paar Stellen, was
> ist jedoch, wenn man z.B. c=10200 setzt.
Dann verwandelst Du ein korrektes Programm in ein nicht mehr
korrektes. Damit 'beweist' Du (sofern das noch vonnöten ist) Dein
völliges Unverständnis der Materie, sonst aber nichts.
> Ein bisher korrekt laufendes Programm hat einen BufferOverflow.
Falsch. Du hast ein bisher funktionierendes Programm von Hand kaputt
gemacht. Hättest Du ein a=1/0 eingefügt, hättest Du denselben Effekt
mit weniger Aufwand erzielen können.
> IMHO muß man nicht nur die Korrektheit des Codes überprüfen, sondern auch
> jedwelche Kombination der Eingabemöglichkeiten auf Überlängen im Einzelnen
> und auch in Kombination checken.
Vernünftig geschriebene Programme sind imstande, alle Eingaben, mit
denen sie zu rechnen haben, korrekt zu verarbeiten. Das ist kein
Hexenwerk, sondern kommt Dir bloß so vor.
> Diese Zahl an Möglichkeiten halte ich für nicht überprüfbar.
Eine Überprüfung ist auch gar nicht notwendig. Du mußt lediglich die
impliziten Randbedingungen (wie Puffergrößen) explizit machen, dh
Eingaben, von denen das Programm ermitteln kann, daß es sie nicht
verarbeiten könnte, muß es auf eine geeignete Art und Weise ablehnen.
Hintergrundinformationen bietet Dir jedes Tutorial zum Thema 'sichere
CGI-Programmierung'.
> Einige Angriffe auf Exchange z.B. laufen über überlange Strings in dem
> Header der Mail, die halt nicht den typischen Mails entsprechen, jedoch die
> möglichen Freiheiten der Definition RFC 822 einer Mail phantasievoll
> ausnutzen. Bisher hat noch jeder Exchange seinen Geist aufgegeben, durch
> die Firewall hindurch.
Falls dem so ist, solltest Du Deinen Exchange-Server wegwerfen, denn
er ist Abfall.
> Ich möchte nun hiermit nicht behaupten, daß QMail alle phantasievollen
> Varianten nicht kennt,
Stimmt. Du möchtest in epischer Breite ausführen, daß Dir (ua)
'Eingabevalidierung' konzeptuell unbekannt ist.
> jedoch finde ich für mich persönlich, daß der Parser
> vom Gefühl her
Du sagtest bereits, das Du auf den ersten Blick nicht durchschaut
hast, was das Ding tut, und das Du es mit einer Analyse versuchst,
wird wohl niemand von Dir erwarten.
> Ich habe mich in letzer Zeit daher viel mit Python und sog. Pattern
> (Ähnlich REGEXP, aber leistungsfähiger) beschäftigt, um vernünfitge
> Filter zu schreiben.....sehr komplex.
Read: Das kann ich auch nicht.
Könntest Du die Aufzählung Deiner zahllosen Wissendefizite sowie die
fortwährende Demonstration Deiner Unwilligkeit, an ihrer Behebung zu
arbeiten, vielleicht etwas abkürzen?
--
near
distant
Felix von Leitner
> anzusehen, die sind auch recht kurz, im Gegensatz zu C.
Wie üblich laberst du Müll.
Guck dir den Speicherbedarf von einem fget und von einem python mit
http-get an. Tu es einfach. Na los. Ehrlich, tu es. Schau hin.
Stelle fest, daß python einen um den Faktor 10 größeren Speicherbedarf
hat. Und dann denke mal drüber nach, wie das sein kann, wenn
Python-Code laut deiner Aussage viel kleiner ist und auch die
Python-Libraries viel kürzer sind.
> Oder hast Du verstanden, warum da die ersten Ziffern von Pi
> herauskommen ?
Wenn dich das wirklich interessiert, wieso gehst du dann nicht in eine
Unibibliothek in deiner Nähe und fragst in der Bibliothek nach Büchern
über Verfahren zur Berechnung von \pi?
Guido Stepken
Warum nicht ? Es ist vielleicht einfacher, den ganzen Codemüll mal zu
entsorgen und ein PythonOS zu beginnen. Dann könnte ich jedenfalls besser
schlafen. Ich möchte nicht behaupten, daß python, perl oder php als solches
sicher wären, jedoch ist es sehr einfach, dort Längenbegrenzungen
einzubauen, die den Code nicht unlesbarer machen.
Die "saubere Programmierung" bzw. den Code review könnte man dann auf
wenige Bibliotheken beschränken.
Merkwürdigerweise ist der Python Code nicht langsam, Einige Spiele von
Lucasarts, Blender und viele RedHat Tools sind in Python geschrieben.
Ich weiß auch, daß PERL in der opensshlib (C) ein Problem hatte.....es ist
nur weniger zu analysieren ...
> Du plaedierst doch nicht ernstlich dafuer, saemtliche Programme in inter-
> pretierten Sprachen neu zu implementieren, weil man sich da um Dinge wie
> buffer overflows keine Gedanken machen muss, da das von der Sprachkonzep-
> tion her schon nicht geht? Du diskutierst die Notwendigkeit fuer saubere
> Programmierung mit riesigen Overheads weg, der dann wieder in C geschrie-
> ben ist. Du verlagerst das Problem dahin, wo Du es nicht siehst.
>
>>Irgendwo läuft immer eine Schleife, die Eingaben entgegennimmt, und diese
>>Daten auf überlängen testet.
>
> Aha.
>
>>analysieren, was das Programm eigentlich tut. Oder hast Du verstanden,
>>warum da die ersten Ziffern von Pi herauskommen ?
Es ist die Polynom-Reihenentwicklung des arctan .... pi = 4*RAD rechnen)