Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Sinn und Zweck einer Firewall?!
42 views
Skip to first unread message
Tom H. Lautenbacher
Nov 1, 2011, 12:29:52 AM11/1/11
to
Hallo zusammen,
ich schütze mein Netzwerk durch eine Firewall auf dem Gateway (Endian
Linux via IP tables), als auch in Form von "Personal Firewalls" auf den
Netzwerkrechnern (Windows Kaspersky Intenet Security & Linux Iptapbles
z.B. via Gufw).
Sowohl auf dem Gateway, als auch auf den Clients war die Default-Policy
für ingoing als auch für outgoing stricktes "Deny".
In diese totale Blockade habe ich dann selektiv Löcher gebohrt für die
Dienste, die ich zulassen möchte, z.B. habe ich auf dem Gateway ein
Portforwarding für HTTP und FTP auf meinen Server in der DMZ
eingerichtet (und auch dessen personal Firewall passieren lassen), oder
ich habe auf allen Firewalls die gängigen Protokolle nach draußen
gelassen z.B. DNS, HTTP, etc.
Das Ganze artet in nicht unerheblichen Administrationsaufwand aus
(insbesondere die Reihenschaltung von Personal Firewalls und Firewall
auf dem Gateway, die immer im Douett konfiguriert werden müssen), gab
mir aber stets das wohlige Gefühl, ganz besonders sicher zu sein.
Und zwar fühlte ich mich vor 2 Dingen geschützt:
1. Von "Angriffen" von außen, die meine Gateway-Firewall abwehrt
2. Von "Nach-Hause-Funken" von eventuell eingeschleppten Trojanern auf
den Workstations.
Doch je länger ich mich mit der Materie beschäftige, desto weniger
sicher bin ich mir, ob das eigentlich alles wahrhaftig so sinnvoll ist,
was ich da mühevoll administriere.
Meine Überlegungen zu den beiden Themen:
1. Angriffe von außen: Vor diesen schützt in erster Linie meine
Gateway-Firewall, da sie alles Dropt, was nicht explizit gewährt wird.
Doch was würde passieren, wenn sie das nicht täte? Dann würde doch
sowieso alles vom IP-Stack abgewehrt werden, da ja gar nichts auf den
Ports lauscht?!
Es heißt, eine Firewall "verstecke" den Rechner. Doch tut sie das
wirklich? Ein gedropptes Paket ist ja kein echtes Verstecken. Ein echtes
Verstecken wäre es AFAIK, wenn der davorgeschaltete Rechner melden würde
"not existing host" oder ähnliches. Aber "einfach nicht antworten" ist
ja kein echtes Verstecken, sondern eher sehr verräterrisch!?
Welchen Schutz gibt mir meine Endian-Firewall auf dem Gateway denn
GENAU? Verhindert sie z.B. einen DNS-Angriff? Oder was genau ist der
zusätzliche Schutz?
2. Nach-Hause-Funken:
Das ist meine größte Sorge schlechthin: Dass ein User sich infiziert und
ab dem Moment alle daten nach Hause gefunkt werden, im schlimmsten Fall
sogar Daten, auf die der User via seiner Netzwerk-Shares zugriff hat.
Doch schützt mich das Absperren FAST aller Outgoing-Ports tatsächlich?
Manche Ports, z.B HTTP, DNS, ggf. auch SMB, DHCP, etc. MÜSSEN ja offen
bleiben, wenn der Rechner im Netzwerk sein soll (ansonsten könnte ich ja
auch das Kabel ziehen - dann bräuchte ich aber erst recht keine Firewall
mehr!).
Sobald ich aber Ports nach außen öffne, könnte ein halbwegs
intelligenter Trojaner doch einfach diesen nutzen, anstatt stumpf auf
dem verschlossenen Port zu beharren.
Skype ist ein gutes Beispiel dafür! Wenn alle Ports geschlossen sind,
weicht Skype auf Port 80 (HTTP) und 443 (HTTPS) aus und schickt seine
Daten einfach darüber! Nicht ohne Grund zählt Skype als Alptraum der
meisten Admins, da sie kaum verhindern können, dass User nach außen
durchdringen.
Wie hoch genau ist denn da noch der Schutz, den ich durch meine
doppelte-Outgoing-Brandschutzmauer da geschaffen habe, wenn jeder
Trojaner problemlos erst durch die Personal Firewall auf den Clients und
dann durch die Gateway-Firewall hindurchspaziert, z.B. via Port 80
(HTTP), 53 (DNS), 443 (HTTPS), 110 (POP), 25 (SMTP)?
Ich bekomme immer mehr den Anschein, ich mich vor Malware damit gar
nicht schütze.
Das Einzige, was ich mit solchen Firewalls offenbar bewerkstelligen
kann, ist, dass User auf ihren Workstations manche Dinge nicht ohne
Weiteres machen können, z.B. einen Bittorrent-Client auf dessen
Standardport betreiben, oder Ahnliches.
Aber selbst an Skype sieht man ja, dass das Programm nur clever genug
sein muss, und dann ist auch dieses Ziel konterkarriert.
Verstehe ich hier etwas grundlegend falsch?
Ich bin dankbar für jedes Feedback, Rat, Info, Meinung, etc.
Tom
ich schütze mein Netzwerk durch eine Firewall auf dem Gateway (Endian
Linux via IP tables), als auch in Form von "Personal Firewalls" auf den
Netzwerkrechnern (Windows Kaspersky Intenet Security & Linux Iptapbles
z.B. via Gufw).
Sowohl auf dem Gateway, als auch auf den Clients war die Default-Policy
für ingoing als auch für outgoing stricktes "Deny".
In diese totale Blockade habe ich dann selektiv Löcher gebohrt für die
Dienste, die ich zulassen möchte, z.B. habe ich auf dem Gateway ein
Portforwarding für HTTP und FTP auf meinen Server in der DMZ
eingerichtet (und auch dessen personal Firewall passieren lassen), oder
ich habe auf allen Firewalls die gängigen Protokolle nach draußen
gelassen z.B. DNS, HTTP, etc.
Das Ganze artet in nicht unerheblichen Administrationsaufwand aus
(insbesondere die Reihenschaltung von Personal Firewalls und Firewall
auf dem Gateway, die immer im Douett konfiguriert werden müssen), gab
mir aber stets das wohlige Gefühl, ganz besonders sicher zu sein.
Und zwar fühlte ich mich vor 2 Dingen geschützt:
1. Von "Angriffen" von außen, die meine Gateway-Firewall abwehrt
2. Von "Nach-Hause-Funken" von eventuell eingeschleppten Trojanern auf
den Workstations.
Doch je länger ich mich mit der Materie beschäftige, desto weniger
sicher bin ich mir, ob das eigentlich alles wahrhaftig so sinnvoll ist,
was ich da mühevoll administriere.
Meine Überlegungen zu den beiden Themen:
1. Angriffe von außen: Vor diesen schützt in erster Linie meine
Gateway-Firewall, da sie alles Dropt, was nicht explizit gewährt wird.
Doch was würde passieren, wenn sie das nicht täte? Dann würde doch
sowieso alles vom IP-Stack abgewehrt werden, da ja gar nichts auf den
Ports lauscht?!
Es heißt, eine Firewall "verstecke" den Rechner. Doch tut sie das
wirklich? Ein gedropptes Paket ist ja kein echtes Verstecken. Ein echtes
Verstecken wäre es AFAIK, wenn der davorgeschaltete Rechner melden würde
"not existing host" oder ähnliches. Aber "einfach nicht antworten" ist
ja kein echtes Verstecken, sondern eher sehr verräterrisch!?
Welchen Schutz gibt mir meine Endian-Firewall auf dem Gateway denn
GENAU? Verhindert sie z.B. einen DNS-Angriff? Oder was genau ist der
zusätzliche Schutz?
2. Nach-Hause-Funken:
Das ist meine größte Sorge schlechthin: Dass ein User sich infiziert und
ab dem Moment alle daten nach Hause gefunkt werden, im schlimmsten Fall
sogar Daten, auf die der User via seiner Netzwerk-Shares zugriff hat.
Doch schützt mich das Absperren FAST aller Outgoing-Ports tatsächlich?
Manche Ports, z.B HTTP, DNS, ggf. auch SMB, DHCP, etc. MÜSSEN ja offen
bleiben, wenn der Rechner im Netzwerk sein soll (ansonsten könnte ich ja
auch das Kabel ziehen - dann bräuchte ich aber erst recht keine Firewall
mehr!).
Sobald ich aber Ports nach außen öffne, könnte ein halbwegs
intelligenter Trojaner doch einfach diesen nutzen, anstatt stumpf auf
dem verschlossenen Port zu beharren.
Skype ist ein gutes Beispiel dafür! Wenn alle Ports geschlossen sind,
weicht Skype auf Port 80 (HTTP) und 443 (HTTPS) aus und schickt seine
Daten einfach darüber! Nicht ohne Grund zählt Skype als Alptraum der
meisten Admins, da sie kaum verhindern können, dass User nach außen
durchdringen.
Wie hoch genau ist denn da noch der Schutz, den ich durch meine
doppelte-Outgoing-Brandschutzmauer da geschaffen habe, wenn jeder
Trojaner problemlos erst durch die Personal Firewall auf den Clients und
dann durch die Gateway-Firewall hindurchspaziert, z.B. via Port 80
(HTTP), 53 (DNS), 443 (HTTPS), 110 (POP), 25 (SMTP)?
Ich bekomme immer mehr den Anschein, ich mich vor Malware damit gar
nicht schütze.
Das Einzige, was ich mit solchen Firewalls offenbar bewerkstelligen
kann, ist, dass User auf ihren Workstations manche Dinge nicht ohne
Weiteres machen können, z.B. einen Bittorrent-Client auf dessen
Standardport betreiben, oder Ahnliches.
Aber selbst an Skype sieht man ja, dass das Programm nur clever genug
sein muss, und dann ist auch dieses Ziel konterkarriert.
Verstehe ich hier etwas grundlegend falsch?
Ich bin dankbar für jedes Feedback, Rat, Info, Meinung, etc.
Tom
Dennis Herbrich
Nov 1, 2011, 4:06:45 AM11/1/11
to
Am 2011-11-01 schrieb Tom H. Lautenbacher:
> Hallo zusammen,
Moin moin!
> 1. Angriffe von außen: Vor diesen schützt in erster Linie meine
> Gateway-Firewall, da sie alles Dropt, was nicht explizit gewährt wird.
> Doch was würde passieren, wenn sie das nicht täte? Dann würde doch
> sowieso alles vom IP-Stack abgewehrt werden, da ja gar nichts auf den
> Ports lauscht?!
Richtig. Tendenziell gilt das DROPpen, also das Verwerfen von Paketen ohne
jedwede Reaktion, sogar als "asozial", weil es zum einen die Gegenstelle in
einen Timeout rennen lässt, und zum anderen die Netzstrecke mit wiederholten
Anfragen belastet. Die Gegenstelle kann nicht unterscheiden, ob das Paket
verloren oder bewusst ignoriert wird.
Nun könnte man im Sinne einer "Teergrube" argumentieren, dass das ja toll sei,
weil man so die bösen Angreifer aufhalten und deren Ressourcen binden könne,
was dann aber in aller Regel daran scheitert, dass eben diese Angreifer sich
nicht protokollkonform verhalten und eben NICHT mehrfach versuchen, eine
Verbindung herzustellen. Man trifft mit dieser Teergrube light also meistens
sich selbst, Kollegen oder Gegenstellen bei der Netzwerkdiagnose, die dann
ausgiebig fluchen.
Kurzum: Für Dich ist das Droppen von Verbindungen auf Adressen, an die sowieso
keine Dienste gebunden sind, lediglich mit Aufwand und potenziellen
Fehlerquellen verbunden, wie Du richtig erkannt hast.
> Es heißt, eine Firewall "verstecke" den Rechner. Doch tut sie das
> wirklich? Ein gedropptes Paket ist ja kein echtes Verstecken. Ein echtes
> Verstecken wäre es AFAIK, wenn der davorgeschaltete Rechner melden würde
> "not existing host" oder ähnliches.
Richtig. Und da der davorgeschaltete Rechner meistens nicht unter Deiner
Kontrolle steht, besteht diese Möglichkeit in der Regel nicht. Insbesondere
können Host-basierte Maßnahmen diesen Eindruck nicht erwecken, sofern man diese
nicht eine Gateway-Adresse spoofen läßt oder ähnlich kranke Maßnahmen ergreift.
> Aber "einfach nicht antworten" ist ja kein echtes Verstecken, sondern eher
> sehr verräterrisch!? Welchen Schutz gibt mir meine Endian-Firewall auf dem
> Gateway denn GENAU? Verhindert sie z.B. einen DNS-Angriff? Oder was genau ist
> der zusätzliche Schutz?
Die Szenarien, vor denen ein DROP hier schützt sind seeeehr überschaubar.
Eigentlich fällt mir nur der Fall ein, dass der TCP/IP-Stack derart fehlerhaft
ist, dass man mit speziellen Paketen einen Bug im TCP/IP-Stack selbst ausnutzt.
Dieser Bug muss dann in dem Code auftreten, der dafür zuständig ist, Pakete
abzuweisen, die an Adressen gehen, an die keine Dienste gebunden sind. Das
versuchst Du allerdings damit zu verhindern, dass statt dessen Code aufgerufen
wird, der die Paketfilter-Regeln auswertet und anwendet.
Nun kannst Du selbst entscheiden, welcher Code komplexer ist und eine höhere
Wahrscheinlichkeit birgt, fehlerhaft und remote angreifbar zu sein. Ich
persönlich setze dabei auf den seit Jahrzenten bewährten TCP/IP-Stack meines
Betriebssystems, anstatt auf irgendwelche womöglich noch externen Paketfilter,
die am besten noch closed-source vorliegen.
> 2. Nach-Hause-Funken: Das ist meine größte Sorge schlechthin: Dass ein User
> sich infiziert und ab dem Moment alle daten nach Hause gefunkt werden, im
> schlimmsten Fall sogar Daten, auf die der User via seiner Netzwerk-Shares
> zugriff hat.
Dagegen hilft kein Paketfilter, und selbst DPI nur bedingt. IDS sowieso
schonmal nicht. Dagegen hilft *nur* Host-basiertes Applikations- und
Berechtigungsmanagement, oder eine Art "Service-Gateway", der als
Applikationsproxy fungiert und ALLES, was das Netz verlässt, analysiert
und paranoid ablehnt, bzw. "neu verpackt". Bei HTML und DNS kann man das noch
regeln, um Tunneling zu vermeiden, aber bei HTTPS wird's schon eng, und sobald
man E-Mails rausläßt, ist's eigentlich vorbei, insbesondere wenn man sich vor
böswilligen Mitarbeitern zu schützen sucht. Stichwort Steganographie, ganz zu
Schweigen vor den Problemen unbewachten, physischen Zugriffs auf Clients.
Wie Du selbst schön ausführst, interessiert es moderne Malware einen feuchten
Dreck, was für Filter aktiv sind. Dann wird halt über DNS oder HTTP(S)
getunnelt, gerne auch "standardmäßig", damit ein eventuell hellhöriges IDS
nicht gleich anspringt. Auch Virenscanner sind nachweislich kein sicherer(!)
Schutz davor, dass Malware vom User aktiviert werden kann. Im Gegenteil, es
sind Fälle bekannt, in denen Fehler in der AV-Software selbst ausgenutzt
wurden, um Clients zu knacken. Sehr peinlich, das.
Man kann mit Filtern und AV-Software durchaus einen Batzen bekannter Malware
"abwehren". Grundsätzlich. Der Haken an der Sache ist, dass es stets Malware
gibt und geben wird, die NICHT erkannt werden kann, man also niemals *sicher*
ist mit AV-Software.
Dazu kommt, dass ein korrekt konfiguriertes System, das
entsprechend bewusst oder eingeschränkt genutzt wird, vor ganzen Klassen von
Malware geschützt ist, ganz ohne AV-Software. Je nach Aufwand und akzeptierten
Einschränkungen kann man so auch Systeme konstruieren, die komplett sicher vor
fremder Software sind, wobei das schnell auf "Stecker ziehen" hinausläuft. ;)
> Ich bekomme immer mehr den Anschein, ich mich vor Malware damit gar
> nicht schütze.
> Das Einzige, was ich mit solchen Firewalls offenbar bewerkstelligen
> kann, ist, dass User auf ihren Workstations manche Dinge nicht ohne
> Weiteres machen können, z.B. einen Bittorrent-Client auf dessen
> Standardport betreiben, oder Ahnliches.
> Aber selbst an Skype sieht man ja, dass das Programm nur clever genug
> sein muss, und dann ist auch dieses Ziel konterkarriert.
Das kommt der Sache recht nahe, fürchte ich. Mit dichten Filtern kann man die
"Stümper-Malware" abwehren und seine Kunden/Mitarbeiter schikanieren, aber
vollumfänglichen Schutz bringt das lange nicht.
> Verstehe ich hier etwas grundlegend falsch?
> Ich bin dankbar für jedes Feedback, Rat, Info, Meinung, etc.
Ganz im Gegenteil. Du hast das Grundproblem der Computersicherheit erkannt. :)
Die Lehrmeinung ist, dass man sich konkrete, schutzwürdige Szenarien überlegt
und dann geeignete Maßnahmen umsetzt, um diese abzudecken. Dabei sind Kriterien
der Produktivität natürlich zu berücksichtigen, vulgo: Die Leute müssen noch
ihre Arbeit machen können.
Grundsätzliche Dinge, die man eigentlich immer umsetzen kann, ist das
konsequente Beenden von unnötigen Diensten auf sämtlichen Rechnern im Netzwerk,
insbesondere den (Windows-)Clients, Deinstallation JEDWEDER nicht aktiv
genutzter Software auf den Rechnern, strenge Einschränkung von Benutzerrechten
besonders im Bezug auf Installation und Ausführung von Software, sowie
Manipulation von Systemdateien, und ggf. Verschlüsselung sensibler Daten und
Nutzung von echter 2-Factor-Authentication oder OTP.
Allein die Nutzung von beschränkten Benutzerrechten wehrt schon sehr viele
Angriffe auf Clients ab: Wenn ein Benutzer, und damit auch die von ihm
ausgeführte Malware, keine Systemdateien verändern darf, dann kann es auch die
Malware nicht, ohne vorher Systemrechte zu erlangen. Privilege Escalation
bleibt dann immer noch eine reale Gefahr, der man mit regelmäßigen Patches
entgegensteuern kann/muss. Eine Restgefahr bleibt allerdings auch dann noch,
so lange irgendeine Möglichkeit für den Benutzer besteht, Schadcode ausgesetzt
zu werden, und das ist leider bei Kommunikation immer der Fall. Man denke an
Exploits in PDF-Dateien, JPEGs oder im Browser. Dagegen hilft patchen, patchen,
patchen. Und wenn der Vendor das nicht gebacken bekommt, den Vendor zu
wechseln.
Als "Schutz" hilf auch eine solide Recovery in der Schublade zu haben, um ein
ggf. DOCH infiziertes Netzwerk in kürzester Zeit mit minimalem Datenverlust
wieder flott zu kriegen.
Es kommt stets individuell darauf an, was genau man wovor schützen will, und
welchen Aufwand und welche Einschränkungen man bereit ist, dafür in Kauf zu
nehmen. Verbrauchern empfehle ich z.B. für das gelegentliche Online-Banking die
Nutzung einer Live-CD; Analog dazu kann man die kritischen Teile eines Systems
auch von einem schreibgeschützten Datenträger abrufen. Das hilft SICHER vor
Manipulation durch Software, leider nicht vor Ausspähen.
Nunja, es ist schon viel gewonnen, wenn Du dich bewusst damit auseinandersetzt
und die verschiedenen Angriffsszenarien benennen kannst, vor denen Du dein
System schützen willst. Der Rest ist Politik.
> Tom
Grüße,
Dennis
> Hallo zusammen,
Moin moin!
> 1. Angriffe von außen: Vor diesen schützt in erster Linie meine
> Gateway-Firewall, da sie alles Dropt, was nicht explizit gewährt wird.
> Doch was würde passieren, wenn sie das nicht täte? Dann würde doch
> sowieso alles vom IP-Stack abgewehrt werden, da ja gar nichts auf den
> Ports lauscht?!
jedwede Reaktion, sogar als "asozial", weil es zum einen die Gegenstelle in
einen Timeout rennen lässt, und zum anderen die Netzstrecke mit wiederholten
Anfragen belastet. Die Gegenstelle kann nicht unterscheiden, ob das Paket
verloren oder bewusst ignoriert wird.
Nun könnte man im Sinne einer "Teergrube" argumentieren, dass das ja toll sei,
weil man so die bösen Angreifer aufhalten und deren Ressourcen binden könne,
was dann aber in aller Regel daran scheitert, dass eben diese Angreifer sich
nicht protokollkonform verhalten und eben NICHT mehrfach versuchen, eine
Verbindung herzustellen. Man trifft mit dieser Teergrube light also meistens
sich selbst, Kollegen oder Gegenstellen bei der Netzwerkdiagnose, die dann
ausgiebig fluchen.
Kurzum: Für Dich ist das Droppen von Verbindungen auf Adressen, an die sowieso
keine Dienste gebunden sind, lediglich mit Aufwand und potenziellen
Fehlerquellen verbunden, wie Du richtig erkannt hast.
> Es heißt, eine Firewall "verstecke" den Rechner. Doch tut sie das
> wirklich? Ein gedropptes Paket ist ja kein echtes Verstecken. Ein echtes
> Verstecken wäre es AFAIK, wenn der davorgeschaltete Rechner melden würde
> "not existing host" oder ähnliches.
Kontrolle steht, besteht diese Möglichkeit in der Regel nicht. Insbesondere
können Host-basierte Maßnahmen diesen Eindruck nicht erwecken, sofern man diese
nicht eine Gateway-Adresse spoofen läßt oder ähnlich kranke Maßnahmen ergreift.
> Aber "einfach nicht antworten" ist ja kein echtes Verstecken, sondern eher
> sehr verräterrisch!? Welchen Schutz gibt mir meine Endian-Firewall auf dem
> Gateway denn GENAU? Verhindert sie z.B. einen DNS-Angriff? Oder was genau ist
> der zusätzliche Schutz?
Eigentlich fällt mir nur der Fall ein, dass der TCP/IP-Stack derart fehlerhaft
ist, dass man mit speziellen Paketen einen Bug im TCP/IP-Stack selbst ausnutzt.
Dieser Bug muss dann in dem Code auftreten, der dafür zuständig ist, Pakete
abzuweisen, die an Adressen gehen, an die keine Dienste gebunden sind. Das
versuchst Du allerdings damit zu verhindern, dass statt dessen Code aufgerufen
wird, der die Paketfilter-Regeln auswertet und anwendet.
Nun kannst Du selbst entscheiden, welcher Code komplexer ist und eine höhere
Wahrscheinlichkeit birgt, fehlerhaft und remote angreifbar zu sein. Ich
persönlich setze dabei auf den seit Jahrzenten bewährten TCP/IP-Stack meines
Betriebssystems, anstatt auf irgendwelche womöglich noch externen Paketfilter,
die am besten noch closed-source vorliegen.
> 2. Nach-Hause-Funken: Das ist meine größte Sorge schlechthin: Dass ein User
> sich infiziert und ab dem Moment alle daten nach Hause gefunkt werden, im
> schlimmsten Fall sogar Daten, auf die der User via seiner Netzwerk-Shares
> zugriff hat.
schonmal nicht. Dagegen hilft *nur* Host-basiertes Applikations- und
Berechtigungsmanagement, oder eine Art "Service-Gateway", der als
Applikationsproxy fungiert und ALLES, was das Netz verlässt, analysiert
und paranoid ablehnt, bzw. "neu verpackt". Bei HTML und DNS kann man das noch
regeln, um Tunneling zu vermeiden, aber bei HTTPS wird's schon eng, und sobald
man E-Mails rausläßt, ist's eigentlich vorbei, insbesondere wenn man sich vor
böswilligen Mitarbeitern zu schützen sucht. Stichwort Steganographie, ganz zu
Schweigen vor den Problemen unbewachten, physischen Zugriffs auf Clients.
Wie Du selbst schön ausführst, interessiert es moderne Malware einen feuchten
Dreck, was für Filter aktiv sind. Dann wird halt über DNS oder HTTP(S)
getunnelt, gerne auch "standardmäßig", damit ein eventuell hellhöriges IDS
nicht gleich anspringt. Auch Virenscanner sind nachweislich kein sicherer(!)
Schutz davor, dass Malware vom User aktiviert werden kann. Im Gegenteil, es
sind Fälle bekannt, in denen Fehler in der AV-Software selbst ausgenutzt
wurden, um Clients zu knacken. Sehr peinlich, das.
Man kann mit Filtern und AV-Software durchaus einen Batzen bekannter Malware
"abwehren". Grundsätzlich. Der Haken an der Sache ist, dass es stets Malware
gibt und geben wird, die NICHT erkannt werden kann, man also niemals *sicher*
ist mit AV-Software.
Dazu kommt, dass ein korrekt konfiguriertes System, das
entsprechend bewusst oder eingeschränkt genutzt wird, vor ganzen Klassen von
Malware geschützt ist, ganz ohne AV-Software. Je nach Aufwand und akzeptierten
Einschränkungen kann man so auch Systeme konstruieren, die komplett sicher vor
fremder Software sind, wobei das schnell auf "Stecker ziehen" hinausläuft. ;)
> Ich bekomme immer mehr den Anschein, ich mich vor Malware damit gar
> nicht schütze.
> Das Einzige, was ich mit solchen Firewalls offenbar bewerkstelligen
> kann, ist, dass User auf ihren Workstations manche Dinge nicht ohne
> Weiteres machen können, z.B. einen Bittorrent-Client auf dessen
> Standardport betreiben, oder Ahnliches.
> Aber selbst an Skype sieht man ja, dass das Programm nur clever genug
> sein muss, und dann ist auch dieses Ziel konterkarriert.
"Stümper-Malware" abwehren und seine Kunden/Mitarbeiter schikanieren, aber
vollumfänglichen Schutz bringt das lange nicht.
> Verstehe ich hier etwas grundlegend falsch?
> Ich bin dankbar für jedes Feedback, Rat, Info, Meinung, etc.
Die Lehrmeinung ist, dass man sich konkrete, schutzwürdige Szenarien überlegt
und dann geeignete Maßnahmen umsetzt, um diese abzudecken. Dabei sind Kriterien
der Produktivität natürlich zu berücksichtigen, vulgo: Die Leute müssen noch
ihre Arbeit machen können.
Grundsätzliche Dinge, die man eigentlich immer umsetzen kann, ist das
konsequente Beenden von unnötigen Diensten auf sämtlichen Rechnern im Netzwerk,
insbesondere den (Windows-)Clients, Deinstallation JEDWEDER nicht aktiv
genutzter Software auf den Rechnern, strenge Einschränkung von Benutzerrechten
besonders im Bezug auf Installation und Ausführung von Software, sowie
Manipulation von Systemdateien, und ggf. Verschlüsselung sensibler Daten und
Nutzung von echter 2-Factor-Authentication oder OTP.
Allein die Nutzung von beschränkten Benutzerrechten wehrt schon sehr viele
Angriffe auf Clients ab: Wenn ein Benutzer, und damit auch die von ihm
ausgeführte Malware, keine Systemdateien verändern darf, dann kann es auch die
Malware nicht, ohne vorher Systemrechte zu erlangen. Privilege Escalation
bleibt dann immer noch eine reale Gefahr, der man mit regelmäßigen Patches
entgegensteuern kann/muss. Eine Restgefahr bleibt allerdings auch dann noch,
so lange irgendeine Möglichkeit für den Benutzer besteht, Schadcode ausgesetzt
zu werden, und das ist leider bei Kommunikation immer der Fall. Man denke an
Exploits in PDF-Dateien, JPEGs oder im Browser. Dagegen hilft patchen, patchen,
patchen. Und wenn der Vendor das nicht gebacken bekommt, den Vendor zu
wechseln.
Als "Schutz" hilf auch eine solide Recovery in der Schublade zu haben, um ein
ggf. DOCH infiziertes Netzwerk in kürzester Zeit mit minimalem Datenverlust
wieder flott zu kriegen.
Es kommt stets individuell darauf an, was genau man wovor schützen will, und
welchen Aufwand und welche Einschränkungen man bereit ist, dafür in Kauf zu
nehmen. Verbrauchern empfehle ich z.B. für das gelegentliche Online-Banking die
Nutzung einer Live-CD; Analog dazu kann man die kritischen Teile eines Systems
auch von einem schreibgeschützten Datenträger abrufen. Das hilft SICHER vor
Manipulation durch Software, leider nicht vor Ausspähen.
Nunja, es ist schon viel gewonnen, wenn Du dich bewusst damit auseinandersetzt
und die verschiedenen Angriffsszenarien benennen kannst, vor denen Du dein
System schützen willst. Der Rest ist Politik.
> Tom
Grüße,
Dennis
Message has been deleted
U.Mutlu
Nov 1, 2011, 4:22:36 PM11/1/11
to
Dennis Herbrich wrote, On 2011-11-01 09:06:
> Am 2011-11-01 schrieb Tom H. Lautenbacher:
>
>> 2. Nach-Hause-Funken: Das ist meine größte Sorge schlechthin: Dass ein User
>> sich infiziert und ab dem Moment alle daten nach Hause gefunkt werden, im
>> schlimmsten Fall sogar Daten, auf die der User via seiner Netzwerk-Shares
>> zugriff hat.
>
> Dagegen hilft kein Paketfilter, und selbst DPI nur bedingt. IDS sowieso
> schonmal nicht. Dagegen hilft *nur* Host-basiertes Applikations- und
> Berechtigungsmanagement, oder eine Art "Service-Gateway", der als
> Applikationsproxy fungiert
Ich entwickle seit einigen Wochen nebenbei an einer Applikationsbasierten Firewall
> Am 2011-11-01 schrieb Tom H. Lautenbacher:
>
>> 2. Nach-Hause-Funken: Das ist meine größte Sorge schlechthin: Dass ein User
>> sich infiziert und ab dem Moment alle daten nach Hause gefunkt werden, im
>> schlimmsten Fall sogar Daten, auf die der User via seiner Netzwerk-Shares
>> zugriff hat.
>
> Dagegen hilft kein Paketfilter, und selbst DPI nur bedingt. IDS sowieso
> schonmal nicht. Dagegen hilft *nur* Host-basiertes Applikations- und
> Berechtigungsmanagement, oder eine Art "Service-Gateway", der als
> Applikationsproxy fungiert
für Linux (erstmal für den eigenen Bedarf). So etwas wie ZoneAlarm,
jedoch für meinen Bedarf ohne GUI. Ich hatte, nachdem ich nix gefunden hatte,
angefangen eine eigene Lösung zu entwickeln aber es kommt immer was
anderes dazwischen so dass dieses Projekt sich leider in die Länge zieht.
BTW, Interessenten können mich gerne kontakten (info @ mutluit.com),
ich könnte für dieses Projekt ein Sponsor gut gebrauchen... :-)
Das mit "Service-GW" hatte ich mir auch schon überlegt, aber die Idee
dann doch verworfen, weil es ja mehr LAN-Traffic verursacht und alles
bestimmt verlangsamt.
Ich denke mit so einer Lösung kann man alle Trojaner, inkl. Staatstrojaner,
Stuxnet usw. am besten lokalisieren und dann entspr. Massnahmen ergreifen,
es reicht ja erstmal sie zu lokalisieren, Alarm zu schlagen (Log/eMail usw.),
und ihnen den Weg nach draussen zu versperren...
> und ALLES, was das Netz verlässt, analysiert
> und paranoid ablehnt, bzw. "neu verpackt". Bei HTML und DNS kann man das noch
> regeln, um Tunneling zu vermeiden, aber bei HTTPS wird's schon eng, und sobald
> man E-Mails rausläßt, ist's eigentlich vorbei, insbesondere wenn man sich vor
> böswilligen Mitarbeitern zu schützen sucht. Stichwort Steganographie, ganz zu
> Schweigen vor den Problemen unbewachten, physischen Zugriffs auf Clients.
>
> Wie Du selbst schön ausführst, interessiert es moderne Malware einen feuchten
> Dreck, was für Filter aktiv sind. Dann wird halt über DNS oder HTTP(S)
> getunnelt, gerne auch "standardmäßig", damit ein eventuell hellhöriges IDS
> nicht gleich anspringt.
www.mutluit.com
Burkhard Ott
Nov 1, 2011, 4:35:11 PM11/1/11
to
On Tue, 01 Nov 2011 21:22:36 +0100, U.Mutlu wrote:
>> Dagegen hilft kein Paketfilter, und selbst DPI nur bedingt. IDS sowieso
>> schonmal nicht. Dagegen hilft *nur* Host-basiertes Applikations- und
>> Berechtigungsmanagement, oder eine Art "Service-Gateway", der als
>> Applikationsproxy fungiert
>
> Ich entwickle seit einigen Wochen nebenbei an einer
> Applikationsbasierten Firewall für Linux (erstmal für den eigenen
> Bedarf). So etwas wie ZoneAlarm, jedoch für meinen Bedarf ohne GUI.
Ziel verfehlt.
>> Dagegen hilft kein Paketfilter, und selbst DPI nur bedingt. IDS sowieso
>> schonmal nicht. Dagegen hilft *nur* Host-basiertes Applikations- und
>> Berechtigungsmanagement, oder eine Art "Service-Gateway", der als
>> Applikationsproxy fungiert
>
> Ich entwickle seit einigen Wochen nebenbei an einer
> Applikationsbasierten Firewall für Linux (erstmal für den eigenen
> Bedarf). So etwas wie ZoneAlarm, jedoch für meinen Bedarf ohne GUI.
Darf man fragen wie das funktionieren soll?
Wenn das via userspace laeuft, knippst das jede Software, falls etwas
sinnig programmiert, dir das aus oder taeuscht Dir vor das alles i.O. ist.
Jeder Filter der auf der gleichen machine laeuft auf dem Du auch so
ruminstallierst, ist nicht geeignet Traffic/Netze ein/abzugrenzen (schon
rein Infrastructure technisch gesehen).
> BTW, Interessenten können mich
> gerne kontakten (info @ mutluit.com), ich könnte für dieses Projekt ein
> Sponsor gut gebrauchen... :-)
> Das mit "Service-GW" hatte ich mir auch schon überlegt, aber die Idee
> dann doch verworfen, weil es ja mehr LAN-Traffic verursacht und alles
> bestimmt verlangsamt.
> Ich denke mit so einer Lösung kann man alle Trojaner, inkl.
> Staatstrojaner, Stuxnet usw. am besten lokalisieren und dann entspr.
> Massnahmen ergreifen, es reicht ja erstmal sie zu lokalisieren, Alarm zu
> schlagen (Log/eMail usw.), und ihnen den Weg nach draussen zu
> versperren...
>> und ALLES, was das Netz verlässt, analysiert und paranoid ablehnt, bzw.
>> "neu verpackt". Bei HTML und DNS kann man das noch regeln, um Tunneling
>> zu vermeiden, aber bei HTTPS wird's schon eng, und sobald man E-Mails
>> rausläßt, ist's eigentlich vorbei, insbesondere wenn man sich vor
>> böswilligen Mitarbeitern zu schützen sucht. Stichwort Steganographie,
attachments. Allerdings wenn der msg pat verschlusselt ist, ist Ruhe.
Da kannst Du dann keine Unterscheidung treffen ob das eine saubere oder
unerwuenschte email ist.
Tunneln kann man mit jedem protocoll, die Gegenseite muss stimmen da
diese den Mull wieder zusammensetzten muss und den echten request
abfeuert.
>> ganz zu Schweigen vor den Problemen unbewachten, physischen Zugriffs
>> auf Clients.
>> Wie Du selbst schön ausführst, interessiert es moderne Malware einen
>> feuchten Dreck, was für Filter aktiv sind. Dann wird halt über DNS oder
>> HTTP(S) getunnelt, gerne auch "standardmäßig", damit ein eventuell
>> hellhöriges IDS nicht gleich anspringt.
mal sein eigenes verschluesseltes filesystem mit, oder booted vor Deinem
Kernel, oder hebt Dich in eine virtuelle Umgebung. Egal was Du dann da
filterst, Du kannst gar nicht sehen was einen Layer drunter damit
passiert.
cheers
Erhard Schwenk
Nov 1, 2011, 4:39:52 PM11/1/11
to
Am 01.11.2011 05:29, schrieb Tom H. Lautenbacher:
> Hallo zusammen,
>
> ich schütze mein Netzwerk durch eine Firewall auf dem Gateway (Endian
> Linux via IP tables), als auch in Form von "Personal Firewalls" auf den
> Netzwerkrechnern (Windows Kaspersky Intenet Security & Linux Iptapbles
> z.B. via Gufw).
Was erhoffst Du Dir von Letzteren?
> Hallo zusammen,
>
> ich schütze mein Netzwerk durch eine Firewall auf dem Gateway (Endian
> Linux via IP tables), als auch in Form von "Personal Firewalls" auf den
> Netzwerkrechnern (Windows Kaspersky Intenet Security & Linux Iptapbles
> z.B. via Gufw).
> Sowohl auf dem Gateway, als auch auf den Clients war die Default-Policy
> für ingoing als auch für outgoing stricktes "Deny".
> In diese totale Blockade habe ich dann selektiv Löcher gebohrt für die
> Dienste, die ich zulassen möchte, z.B. habe ich auf dem Gateway ein
> Portforwarding für HTTP und FTP auf meinen Server in der DMZ
> eingerichtet (und auch dessen personal Firewall passieren lassen), oder
> ich habe auf allen Firewalls die gängigen Protokolle nach draußen
> gelassen z.B. DNS, HTTP, etc.
Gewinn, aber evtl. anderweitige Probleme. REJECT wäre korrekt.
> Und zwar fühlte ich mich vor 2 Dingen geschützt:
> 1. Von "Angriffen" von außen, die meine Gateway-Firewall abwehrt
laufen, die von Außen angegriffen werden könnten? Warum?
> 2. Von "Nach-Hause-Funken" von eventuell eingeschleppten Trojanern auf
> den Workstations.
Kommunikation nach Außen möglich ist, kann eine Software auch "nach
Hause funken". Dazu reicht im Extremfall bereits die Möglichkeit,
DNS-Requests abzusetzen.
Der einzige wirklich wirksame Weg, eine Software am
Nach-Hause-Telefonieren zu hindern, ist, sie nicht (auf einem vernetzten
System) auszuführen.
> 1. Angriffe von außen: Vor diesen schützt in erster Linie meine
> Gateway-Firewall, da sie alles Dropt, was nicht explizit gewährt wird.
> Doch was würde passieren, wenn sie das nicht täte? Dann würde doch
> sowieso alles vom IP-Stack abgewehrt werden, da ja gar nichts auf den
> Ports lauscht?!
> Es heißt, eine Firewall "verstecke" den Rechner. Doch tut sie das
> wirklich?
> 2. Nach-Hause-Funken:
> Das ist meine größte Sorge schlechthin: Dass ein User sich infiziert und
> ab dem Moment alle daten nach Hause gefunkt werden, im schlimmsten Fall
> sogar Daten, auf die der User via seiner Netzwerk-Shares zugriff hat.
> Doch schützt mich das Absperren FAST aller Outgoing-Ports tatsächlich?
> Manche Ports, z.B HTTP, DNS, ggf. auch SMB, DHCP, etc. MÜSSEN ja offen
> bleiben, wenn der Rechner im Netzwerk sein soll (ansonsten könnte ich ja
> auch das Kabel ziehen - dann bräuchte ich aber erst recht keine Firewall
> mehr!).
> Sobald ich aber Ports nach außen öffne, könnte ein halbwegs
> intelligenter Trojaner doch einfach diesen nutzen, anstatt stumpf auf
> dem verschlossenen Port zu beharren.
> Skype ist ein gutes Beispiel dafür! Wenn alle Ports geschlossen sind,
> weicht Skype auf Port 80 (HTTP) und 443 (HTTPS) aus und schickt seine
> Daten einfach darüber! Nicht ohne Grund zählt Skype als Alptraum der
> meisten Admins, da sie kaum verhindern können, dass User nach außen
> durchdringen.
> Wie hoch genau ist denn da noch der Schutz, den ich durch meine
> doppelte-Outgoing-Brandschutzmauer da geschaffen habe, wenn jeder
> Trojaner problemlos erst durch die Personal Firewall auf den Clients und
> dann durch die Gateway-Firewall hindurchspaziert, z.B. via Port 80
> (HTTP), 53 (DNS), 443 (HTTPS), 110 (POP), 25 (SMTP)?
weil sie von lokal laufender Malware trivial zu manipulieren ist. Was
hindert den "Trojaner" daran, einfach für ein paar ms deren Regeln
anzupassen, bevor er "nach hause telefoniert"? Richtig: genau gar nichts.
> Ich bekomme immer mehr den Anschein, ich mich vor Malware damit gar
> nicht schütze.
> Das Einzige, was ich mit solchen Firewalls offenbar bewerkstelligen
> kann, ist, dass User auf ihren Workstations manche Dinge nicht ohne
> Weiteres machen können, z.B. einen Bittorrent-Client auf dessen
> Standardport betreiben, oder Ahnliches.
> Aber selbst an Skype sieht man ja, dass das Programm nur clever genug
> sein muss, und dann ist auch dieses Ziel konterkarriert.
> Verstehe ich hier etwas grundlegend falsch?
haben oder gar zu angreifern mutieren, hilft dagegen keine Firewall der
Welt. In begrenztem Umfang hilft es, den Usern schadensträchtige
Funktionalitäten wie z.B. das eigenmächtige Installieren von Software
wegzunehmen, ansonsten ist die Wirksamkeit technischer Mittel an dieser
Front so lange begrenzt, wie die Benutzer nicht als aktive Komponente
ins Sicherheitskonzept einbezogen sind.
--
Erhard Schwenk
Akkordeonjugend Baden-Württemberg - http://www.akkordeonjugend.de/
APAYA running System - http://www.apaya.net/
U.Mutlu
Nov 1, 2011, 5:11:10 PM11/1/11
to
Burkhard Ott wrote, On 2011-11-01 21:35:
> On Tue, 01 Nov 2011 21:22:36 +0100, U.Mutlu wrote:
>
>>> Dagegen hilft kein Paketfilter, und selbst DPI nur bedingt. IDS sowieso
>>> schonmal nicht. Dagegen hilft *nur* Host-basiertes Applikations- und
>>> Berechtigungsmanagement, oder eine Art "Service-Gateway", der als
>>> Applikationsproxy fungiert
>>
>> Ich entwickle seit einigen Wochen nebenbei an einer
>> Applikationsbasierten Firewall für Linux (erstmal für den eigenen
>> Bedarf). So etwas wie ZoneAlarm, jedoch für meinen Bedarf ohne GUI.
>
> Ziel verfehlt.
> Darf man fragen wie das funktionieren soll?
> Wenn das via userspace laeuft, knippst das jede Software, falls etwas
> sinnig programmiert, dir das aus oder taeuscht Dir vor das alles i.O. ist.
>
> Jeder Filter der auf der gleichen machine laeuft auf dem Du auch so
> ruminstallierst, ist nicht geeignet Traffic/Netze ein/abzugrenzen (schon
> rein Infrastructure technisch gesehen).
Sehe ich nicht so.
> On Tue, 01 Nov 2011 21:22:36 +0100, U.Mutlu wrote:
>
>>> Dagegen hilft kein Paketfilter, und selbst DPI nur bedingt. IDS sowieso
>>> schonmal nicht. Dagegen hilft *nur* Host-basiertes Applikations- und
>>> Berechtigungsmanagement, oder eine Art "Service-Gateway", der als
>>> Applikationsproxy fungiert
>>
>> Ich entwickle seit einigen Wochen nebenbei an einer
>> Applikationsbasierten Firewall für Linux (erstmal für den eigenen
>> Bedarf). So etwas wie ZoneAlarm, jedoch für meinen Bedarf ohne GUI.
>
> Ziel verfehlt.
> Darf man fragen wie das funktionieren soll?
> Wenn das via userspace laeuft, knippst das jede Software, falls etwas
> sinnig programmiert, dir das aus oder taeuscht Dir vor das alles i.O. ist.
>
> Jeder Filter der auf der gleichen machine laeuft auf dem Du auch so
> ruminstallierst, ist nicht geeignet Traffic/Netze ein/abzugrenzen (schon
> rein Infrastructure technisch gesehen).
Erst wenn der Schädling root-Rechte hätte könnte er das System manipulieren,
z.B. die iptables-Firewall deaktivieren.
Aber das kann man ja auch monitoren...
> gute Malware bringt auch gerne
> mal sein eigenes verschluesseltes filesystem mit, oder booted vor Deinem
> Kernel, oder hebt Dich in eine virtuelle Umgebung. Egal was Du dann da
> filterst, Du kannst gar nicht sehen was einen Layer drunter damit
> passiert.
Ich rede von Schutz für 'normal' laufende Systeme.
Burkhard Ott
Nov 1, 2011, 6:07:30 PM11/1/11
to
On Tue, 01 Nov 2011 22:11:10 +0100, U.Mutlu wrote:
>> Jeder Filter der auf der gleichen machine laeuft auf dem Du auch so
>> ruminstallierst, ist nicht geeignet Traffic/Netze ein/abzugrenzen
>> (schon rein Infrastructure technisch gesehen).
>
> Sehe ich nicht so.
> Erst wenn der Schädling root-Rechte hätte könnte er das System
> manipulieren, z.B. die iptables-Firewall deaktivieren. Aber das kann man
> ja auch monitoren...
Und wie installierst Du Software auf einem System?
>> Jeder Filter der auf der gleichen machine laeuft auf dem Du auch so
>> ruminstallierst, ist nicht geeignet Traffic/Netze ein/abzugrenzen
>> (schon rein Infrastructure technisch gesehen).
>
> Sehe ich nicht so.
> Erst wenn der Schädling root-Rechte hätte könnte er das System
> manipulieren, z.B. die iptables-Firewall deaktivieren. Aber das kann man
> ja auch monitoren...
Im Falle das man einen buffer overflow erzeugen kann, hat man sehr oft
auch Zugriff auf den Kernelspace, lassen wir da mal ne rootshell
raustropfen, fertig. Gleiches gilt natuerlich fuer userspace programme
(e.g. sudo).
Jede zusaetzliche Software bringt mehr Komplexibilitaet als auch
Angriffsvectoren mit sich, das ist einfach ein Fakt den mann nicht
umgehen kann, weder auf einem Gateway/firewall was auch immer, noch auf
einem Desktop/Worstation System. Kommt dann halt darauf an was da alles
rumorgelt.
> > gute Malware bringt auch gerne
> > mal sein eigenes verschluesseltes filesystem mit, oder booted vor
> > Deinem Kernel, oder hebt Dich in eine virtuelle Umgebung. Egal was Du
> > dann da filterst, Du kannst gar nicht sehen was einen Layer drunter
> > damit passiert.
>
> Also, das ist natürlich was anderes, aber ich denke das passiert
> bestimmt sehr sehr selten. Ich rede von Schutz für 'normal' laufende
> Systeme.
verschlusseltes welches im MBR (TDL4 kann das jetzt auch 64Bit und
knippst den Protector von Windows aus bevor Windows started), da gibts
noch ne ganze Reihe andere die sowas machen. Generell sind das aber die
schnuffigen die Dir richtig Schaden zufuegen, also Dein Geld verwalten.
Die Wuermer die Spam versende, oder Dich in ein Zonmienetz einladen, sind
da eher nicht ganz so schwerwiegend, da einfach zu entdecken.
In allen Faellen, ist sowas auch unter Linux moeglich und der Normal
Ubuntuuser wird auch alles brav installieren was man ihm vorsetzt,
solange es funktioniert. Notfalls den Traffic noch getunnelt und
verschluesselt, fertig.
cheers
Erhard Schwenk
Nov 1, 2011, 7:56:01 PM11/1/11
to
Am 01.11.2011 22:11, schrieb U.Mutlu:
> Burkhard Ott wrote, On 2011-11-01 21:35:
>> On Tue, 01 Nov 2011 21:22:36 +0100, U.Mutlu wrote:
>>
>>>> Dagegen hilft kein Paketfilter, und selbst DPI nur bedingt. IDS sowieso
>>>> schonmal nicht. Dagegen hilft *nur* Host-basiertes Applikations- und
>>>> Berechtigungsmanagement, oder eine Art "Service-Gateway", der als
>>>> Applikationsproxy fungiert
>>>
>>> Ich entwickle seit einigen Wochen nebenbei an einer
>>> Applikationsbasierten Firewall für Linux (erstmal für den eigenen
>>> Bedarf). So etwas wie ZoneAlarm, jedoch für meinen Bedarf ohne GUI.
>>
>> Ziel verfehlt.
>> Darf man fragen wie das funktionieren soll?
>> Wenn das via userspace laeuft, knippst das jede Software, falls etwas
>> sinnig programmiert, dir das aus oder taeuscht Dir vor das alles i.O.
>> ist.
>>
>> Jeder Filter der auf der gleichen machine laeuft auf dem Du auch so
>> ruminstallierst, ist nicht geeignet Traffic/Netze ein/abzugrenzen (schon
>> rein Infrastructure technisch gesehen).
> Sehe ich nicht so.
> Erst wenn der Schädling root-Rechte hätte könnte er das System
> manipulieren,
Local Privilege Escalation Exploits gibts praktisch ständig für alle
> Burkhard Ott wrote, On 2011-11-01 21:35:
>> On Tue, 01 Nov 2011 21:22:36 +0100, U.Mutlu wrote:
>>
>>>> Dagegen hilft kein Paketfilter, und selbst DPI nur bedingt. IDS sowieso
>>>> schonmal nicht. Dagegen hilft *nur* Host-basiertes Applikations- und
>>>> Berechtigungsmanagement, oder eine Art "Service-Gateway", der als
>>>> Applikationsproxy fungiert
>>>
>>> Ich entwickle seit einigen Wochen nebenbei an einer
>>> Applikationsbasierten Firewall für Linux (erstmal für den eigenen
>>> Bedarf). So etwas wie ZoneAlarm, jedoch für meinen Bedarf ohne GUI.
>>
>> Ziel verfehlt.
>> Darf man fragen wie das funktionieren soll?
>> Wenn das via userspace laeuft, knippst das jede Software, falls etwas
>> sinnig programmiert, dir das aus oder taeuscht Dir vor das alles i.O.
>> ist.
>>
>> Jeder Filter der auf der gleichen machine laeuft auf dem Du auch so
>> ruminstallierst, ist nicht geeignet Traffic/Netze ein/abzugrenzen (schon
>> rein Infrastructure technisch gesehen).
> Sehe ich nicht so.
> Erst wenn der Schädling root-Rechte hätte könnte er das System
> manipulieren,
Systeme, da brauchste nur mal Bugtraq oder andere einschlägige
Newsticker zu lesen. Wer sich ausschließlich darauf verläßt, die
vermeiden zu können, hat - muß man leider sagen - fast schon so gut wie
sicher verloren. Es gibt dutzende einfacher Methoden, von einem
Schädling mit Userrechten zu einem Schädling mit rootrechten zu werden -
vom Keylogger über local Exploits bis zu gefakten Systemfehlern.
> z.B. die iptables-Firewall deaktivieren.
> Aber das kann man ja auch monitoren...
verschiebt also das Problem nur auf eine weitere Metaebene, ohne es zu
lösen.
> > gute Malware bringt auch gerne
> > mal sein eigenes verschluesseltes filesystem mit, oder booted vor Deinem
> > Kernel, oder hebt Dich in eine virtuelle Umgebung. Egal was Du dann da
> > filterst, Du kannst gar nicht sehen was einen Layer drunter damit
> > passiert.
> Also, das ist natürlich was anderes, aber ich denke das passiert
> bestimmt sehr sehr selten.
Construction Kits. Das bedeutet, daß jeder ausreichend Technikaffine
14-jährige binnen Minuten fertige Bibliotheken und Toolsets zum
Zusammenklicken von Schädlingen finden kann, die genau sowas machen. Der
muß dazu nichtmal größere Mengen an Code schreiben.
> Ich rede von Schutz für 'normal' laufende Systeme.
Andreas Kohlbach
Nov 1, 2011, 9:32:10 PM11/1/11
to
Tom H. Lautenbacher wrote on 01. November 2011:
>
> ich schütze mein Netzwerk durch eine Firewall auf dem Gateway (Endian
> Linux via IP tables), als auch in Form von "Personal Firewalls" auf
> den Netzwerkrechnern (Windows Kaspersky Intenet Security & Linux
> Iptapbles z.B. via Gufw).
Ich habe 24/7 einen Rechner im Netz, der auch Dienste anbietet, und das
>
> ich schütze mein Netzwerk durch eine Firewall auf dem Gateway (Endian
> Linux via IP tables), als auch in Form von "Personal Firewalls" auf
> den Netzwerkrechnern (Windows Kaspersky Intenet Security & Linux
> Iptapbles z.B. via Gufw).
seit Jahren. Und seit Jahren *keine* iptables Regeln. Logs, ins Besondere
für ssh, sind zwar voll mit Versuchen, aber bisher scheint der Computer
noch meiner zu sein.
Und daran werde ich wohl auch nichts ändern.
--
Andreas (PGP Key available on public key servers)
13. If you get mad enough, you can fight even more fiercely than normal.
- Arcade Wisdom
Juergen P. Meier
Nov 2, 2011, 12:57:34 AM11/2/11
to
Tom H. Lautenbacher <use...@tom.lautenbacher.biz>:
Eine Firewall ist in erster Linie eine von vielen Massnahmen in einem
Sicherheitskonzept. Eine Massnahme mit einer klar bestimmten
Schutzfunktion vor einer klar defnierten Menge an Bedrohungen.
> Sowohl auf dem Gateway, als auch auf den Clients war die Default-Policy
> für ingoing als auch für outgoing stricktes "Deny".
Solange das aus den Anforderungen des Sicherheitskonzeptes an diese
Massnahme so folgt, ist das ja nicht verkehrt.
> In diese totale Blockade habe ich dann selektiv Löcher gebohrt für die
> Dienste, die ich zulassen möchte, z.B. habe ich auf dem Gateway ein
> Portforwarding für HTTP und FTP auf meinen Server in der DMZ
> eingerichtet (und auch dessen personal Firewall passieren lassen), oder
> ich habe auf allen Firewalls die gängigen Protokolle nach draußen
> gelassen z.B. DNS, HTTP, etc.
Das ist eine weit verbreitete und darum oftmals als Allgemeinfall
misverstandene spezifische Umsetzung einer Massnahme eines
Sicherheitskonzeptes.
> Das Ganze artet in nicht unerheblichen Administrationsaufwand aus
> (insbesondere die Reihenschaltung von Personal Firewalls und Firewall
> auf dem Gateway, die immer im Douett konfiguriert werden müssen), gab
> mir aber stets das wohlige Gefühl, ganz besonders sicher zu sein.
Schutzmassnahmen koennen zwar ein "Gefuehl von Sicherheit" vermitteln,
dass ist aber nicht deren Aufgabe. Und ja, bestimmte Massnahmen haben
einen hohen administrativen und operativen Aufwand - etwas dass im
Sicherheitskonzept natuerlich in die Kosten-Schaden-Wahrscheinlichkeit-
Aufwands-Abwaegung mit einfliesst, die in jedem guten
Sicherheitskonzept fuer die Massnahmen zur Abwehr von Bedrohungen
gemacht wird.
> Und zwar fühlte ich mich vor 2 Dingen geschützt:
> 1. Von "Angriffen" von außen, die meine Gateway-Firewall abwehrt
Die Bedrohungen vor denen diese Massnahme schuetzt heissen idR.
"versehentlich/unwissend laufende Dienste" oder "nicht korrekt
konfiurierbare Dienste und Systeme" sowie "defekte Systeme und
Dienste". Weil das Risiko hier ueblicherweise immer hoch genug
ist in obiger Abwaegung, dass sich eine Massnahme rentiert, gilt
diese Massnahme an einem Perimeter auch als "best practise".
> 2. Von "Nach-Hause-Funken" von eventuell eingeschleppten Trojanern auf
> den Workstations.
Dafor kann dich eine Firewall nicht schuetzen. Prinzipell wie
konzeptionell.
Die passenden Massnahmen fuer diese Bedrohung heissen "Content-Filter
ALG" in kombination mit Firewall die /jeden/ direkten Verkehr von innen
nach aussen unterbindet (totale Isolation des LAN) oder neuerdings
"Content-Aware Firewalls" - wobei erste Erfahrungen mit letzterem sehr
ernuechternd sind.
Ein IPS (Intrusion Prevention System) kann hier auch als wirksame
Hilfmassnahme* betrachtet werden - erfordert aber im Vergleich zu allen
anderen Massnahmen einen *ernormen* Betriebsaufwand - auch wenn dir
die teflonbeschichteten Hochglanzvertriebler der Marktfuehrer das
genaue Gegenteil weis machen wollen. Glaub ihnen kein Wort.
* Alleine keine ausreichenede Massnahme - konzeptionell, genau aus dem
selben Grund warum ein AV-SCanner keine ausreichende Massnahme gegen
die Bedrohung "infektion durch $SCHADPROGRAMM" darstellt.
Eine Firewall alleine hingegen /erlaubt/ prinzpiell Kommunikation
von innen nach aussen, ist also keine wirksame Schutzmassnahme gegen
diese Bedrohungen.
> Doch je länger ich mich mit der Materie beschäftige, desto weniger
> sicher bin ich mir, ob das eigentlich alles wahrhaftig so sinnvoll ist,
> was ich da mühevoll administriere.
Das Thema IT-Sicherheit ist genauso kompliziert wie alle anderen
Sicherheitsfelder. Es geht zwar idR. nicht um Menschenleben oder die
Gesundheit (wie in vielen anderen Branchen), aber oftmals genug um die
finanzielle Existenz.
Ein systematischer Ansatz ist zwingend erforderlich um auch nur die
Chance auf ein funktionierendes und erfolgreiches Sicherheitskonzept
zu haben.
Mittlerweile gibt es etablierte Formalisierungen (Common Criteria,
diverse Normen und Standards) die dir ueber Formalismen ermoeglichen
zu einem systematischen Vorgehen zu gelangen - aber alleine helfen die
genau so wenig wie ohne umfassendes Konzept mit Einzelmassnahmen zu
hantieren in der Hoffnung, dass die wenigen Bedrohungen, die du damit
konterst diejenegen sind, die angegriffen werden.
Letzteres hat sich in der Praxis regelmaessig nicht bewaehrt.
PS: eine der groesten Bedrohungen ist die Faulheit der Anwender -
insbesondere bei Anwendern mit technischen Privilegien (vulgo:
Admins). HIerzu ist es nicht immer leicht eine passende technische
Massnahme zu finden und man muss oft genug organisatorische und
administrative Massnahmen anwenden. Fuer Letzteres brauchst du in
Firmen ueblicherweise ein ausreichendes Mandat der Geschaeftsfuehrung.
> Meine Überlegungen zu den beiden Themen:
>
> 1. Angriffe von außen: Vor diesen schützt in erster Linie meine
> Gateway-Firewall, da sie alles Dropt, was nicht explizit gewährt wird.
> Doch was würde passieren, wenn sie das nicht täte? Dann würde doch
> sowieso alles vom IP-Stack abgewehrt werden, da ja gar nichts auf den
> Ports lauscht?!
Ah, du machst den ueblichen Denkfehler bei der Betrachtung von
Schutzmassnahmen: du suchst dir einen Einzelfall raus und versuchst
darueber den Nutzen der Schutzmassnahme zu bewerten.
Das ist ein Logikfehler.
Die Bedrohung, vor die diese spezielle Massnahme schuetzt ist hingegen
u.A. das versehentliche Starten eines unsicheren Dienstes/Programms
z.B. durch Fehlkonfiguration eines Systems, booten eines Systems im
Auslieferungszustand etc.pp.
> Es heißt, eine Firewall "verstecke" den Rechner. Doch tut sie das
Das ist grober Unsinn.
Falls "Obscurity" tatsaechlich Teil eines Sicherheitskonzeptes ist,
dann ist eine Firewall zwar durchaus ein Bestandteil der Massnahmen
zur Begegnung der entsprechenden Bedrohungen - alleine aber
keinesfalls ausreichend. Oftmals bewirkt eine Firewall den genauen
gegenteiligen Effekt den man sich - wenn man ohne entsprechend
ausgearbeitetes Sicherheitskonzept - "verstecken" will: sie zeigen
Angreifern mit bunt blinkender 20 Meter hoher Leuchtreklame darauf
hin, dass hier was versteckt werden soll.
> wirklich? Ein gedropptes Paket ist ja kein echtes Verstecken. Ein echtes
Richtig erkannt.
> Verstecken wäre es AFAIK, wenn der davorgeschaltete Rechner melden würde
> "not existing host" oder ähnliches. Aber "einfach nicht antworten" ist
Eben. Obscurity richtig umgesetzt beinhaltet das Vorgeben falscher
Tatsachen (Network unrechable, Host unreachable von einem nur als
Router zu identifizierenden Absender - das ist nur der Anfang) und ist
relativ kompliziet und extrem aufwaendig im Betrieb und schwer zu
Monitoren.
> ja kein echtes Verstecken, sondern eher sehr verräterrisch!?
Das halbgare "Verstecken" durch Blackholing ist in etwa mit einer 20m
hohen Leuchtreklametafel vor dem Haus vergleichbar auf der in bunten
blinkenden Lettern steht "Versteck von $NAME". Diese verhindert
vielleicht den direkten Blick auf das Haus, ist aber nicht wirklich
als Versteckmassnahme geeignet. Gleiches gilt fuer Firewalls.
> Welchen Schutz gibt mir meine Endian-Firewall auf dem Gateway denn
> GENAU? Verhindert sie z.B. einen DNS-Angriff? Oder was genau ist der
> zusätzliche Schutz?
Du zaeumst das Pferd von der falschen Seite aus auf.
Richtige Vorgehensweise: Du enumerierst die Bedrohungen, bewertest
diese bezueglich Risiko [Schaden, Wahrscheinlicheit [tricky!],
Einfachheit (feasibility)] und ueberlegst dir dann dazu die
entsprechenden MAssnahmen die diese Bedrohungen ausschalten/kompensieren
und Entscheidest unter Abwaegung obiger Parameter und der Kosten
(Investition, Aufwand Aufstezen+Betreiben+Warten)] den Nutzen fuer
dich.
Danach ist dann obige Frage automatisch aus den UEberlegungen des
Konzeptes beantwortet :)
Ganz einfach - der Schwierige Teil ist die Erfassung aller moeglichen
und denkbaren Bedrohungen sowie die Bewertung der Wahrscheinlichkeit -
hierzu braucht es Praxiserfahrung und ein Gespuer fuer den
Angriffsmarkt.
> 2. Nach-Hause-Funken:
> Das ist meine größte Sorge schlechthin: Dass ein User sich infiziert und
> ab dem Moment alle daten nach Hause gefunkt werden, im schlimmsten Fall
> sogar Daten, auf die der User via seiner Netzwerk-Shares zugriff hat.
> Doch schützt mich das Absperren FAST aller Outgoing-Ports tatsächlich?
Streiche das FAST. Zuverlaessig schuetzt nur das Blockieren /aller/
direkter Kommunikationsbeziehungen.
Zulaessige Kommunikation wird dann ueber Inhaltspruefende ALGs
(proxies) abgehandelt (klassisch) oder seit relativ kurzer Zeit ueber
"Application Aware Firewalls" - wobei letzteres praktisch fuer eine
ausreichende Einzelmassnahme IMO noch viel zu unausgereift ist.
> Manche Ports, z.B HTTP, DNS, ggf. auch SMB, DHCP, etc. MÜSSEN ja offen
> bleiben, wenn der Rechner im Netzwerk sein soll (ansonsten könnte ich ja
> auch das Kabel ziehen - dann bräuchte ich aber erst recht keine Firewall
> mehr!).
Dafuer gibt es dann den ALG, der die Verbindung auf Applikationsschicht
trennt und es ermoeglicht, den Inhalt der Kommunikation zu pruefen und
zu bewerten.
> Sobald ich aber Ports nach außen öffne, könnte ein halbwegs
> intelligenter Trojaner doch einfach diesen nutzen, anstatt stumpf auf
> dem verschlossenen Port zu beharren.
Die weniger intelligenten benutzen belieige Ports in der Hoffnung,
dass $ADMIN eine rein auf den Transport/Netzschichten arbeitende
Firewall (= Paketfilter) einsetzt, die alles, was ueber den
entsprechenden Port laeuft ungeachtet des Inhaltes durchlaesst.
Das sind die Mehrheit der aktuell aktiven Schadprogramme.
Eine nicht ganz so Grosse Gruppe misbraucht einfach ein ueblicherweise
erlaubtes Applikationsprotokoll (z.B. HTTP oder SMTP o.ae.) um
darueber huckepack (also als korrekte Protokollimplementierung) zu
tunneln. Bekanntestes Beispieler dafuer ist Skype (das durchaus ein
Schadprogramm nach klassischer Definition darstellt).
> Skype ist ein gutes Beispiel dafür! Wenn alle Ports geschlossen sind,
Aeh, ja. (ich hatte obiges schon geschrieben bevor ich so weit las ;)
> weicht Skype auf Port 80 (HTTP) und 443 (HTTPS) aus und schickt seine
> Daten einfach darüber! Nicht ohne Grund zählt Skype als Alptraum der
> meisten Admins, da sie kaum verhindern können, dass User nach außen
> durchdringen.
Dagegen hilft nur ein ALG mit Inhaltsfilter. Fuer HTTPS braucht es
einen SSL-Aufbrechenden Proxy - das koennen mittlerweile fast alle
komerziellen Anbieter auf dem Markt.
> Wie hoch genau ist denn da noch der Schutz, den ich durch meine
> doppelte-Outgoing-Brandschutzmauer da geschaffen habe, wenn jeder
Du betrachtest hier eine Bedrohung, gegen die ein Paketfilter nicht
die Passende Schutzmassnahme ist - und versuchst so den Nutzen der
Massnahme Paketfilter zu bewerten. Das ist natuerlich Falsch.
Du musst wenn dann schon die Bedrohungen betrachten, vor denen ein
Paketfilter schuetzt (siehe weiter oben).
Ein Fahrradschloss schuetzt dich ja auch nicht davor, dass jemand dein
Fahrrad mit einem Vorschlaghammer zertruemmert oder mit einem Messer
deine Reifen aufschlitzt.
> Trojaner problemlos erst durch die Personal Firewall auf den Clients und
Der grosse Vorteil einer "Personal Firewall" (korrekter ist der Begriff
"application firewall") ist, dass auf dem Host die Zuordnung
zwischen Applikation und Paket getroffen werden kann, also z.B. der
Paketfilter technisch in der Lage ist, ein /ausgehendes/ Paket an Zielport
6000 dem verursachenden Prozess zuzuordnen - und hier entsprechende
Regeln mit einbeziehugn der Prozesse/Tasks/Applikationen umzusetzen
z.B. also nur dem Chat-Client dies erlauben, einem anderen Programm
aber untersagen.
Das schuetzt zwar nicht vor Schadprogrammen, die erlaubte
Applikationen misbrauchen um ihre Kommunikation stellvertretend
abzuhandeln (beliebt ist das einklinken in den Internet Explorer oder
den Mailclient), aber dafuer ist das auch wieder nicht die passende
Massnahme ;)
> dann durch die Gateway-Firewall hindurchspaziert, z.B. via Port 80
> (HTTP), 53 (DNS), 443 (HTTPS), 110 (POP), 25 (SMTP)?
Am Gateway kann man die Zuordnung "Paket - Applikation" nicht mehr
treffen, daher scheidet das ganz aus als ort fuer SchutzMassnahmen
zu obigen Bedrohungen.
> Ich bekomme immer mehr den Anschein, ich mich vor Malware damit gar
> nicht schütze.
Nicht wirklich, nein.
> Das Einzige, was ich mit solchen Firewalls offenbar bewerkstelligen
> kann, ist, dass User auf ihren Workstations manche Dinge nicht ohne
> Weiteres machen können, z.B. einen Bittorrent-Client auf dessen
> Standardport betreiben, oder Ahnliches.
Korrekt.
> Aber selbst an Skype sieht man ja, dass das Programm nur clever genug
> sein muss, und dann ist auch dieses Ziel konterkarriert.
Auch das stimmt.
> Verstehe ich hier etwas grundlegend falsch?
Nein. Nur dein Ansatz zur Bewertung der Massnahmen ist falsch herum -
ansonsten hast du durchaus alles noetige Verstanden.
> Ich bin dankbar für jedes Feedback, Rat, Info, Meinung, etc.
HTH,
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
> ich schütze mein Netzwerk durch eine Firewall auf dem Gateway (Endian
> Linux via IP tables), als auch in Form von "Personal Firewalls" auf den
> Netzwerkrechnern (Windows Kaspersky Intenet Security & Linux Iptapbles
> z.B. via Gufw).
Vor welchen Bedrohungen genau schuetzt du was?
> Linux via IP tables), als auch in Form von "Personal Firewalls" auf den
> Netzwerkrechnern (Windows Kaspersky Intenet Security & Linux Iptapbles
> z.B. via Gufw).
Eine Firewall ist in erster Linie eine von vielen Massnahmen in einem
Sicherheitskonzept. Eine Massnahme mit einer klar bestimmten
Schutzfunktion vor einer klar defnierten Menge an Bedrohungen.
> Sowohl auf dem Gateway, als auch auf den Clients war die Default-Policy
> für ingoing als auch für outgoing stricktes "Deny".
Massnahme so folgt, ist das ja nicht verkehrt.
> In diese totale Blockade habe ich dann selektiv Löcher gebohrt für die
> Dienste, die ich zulassen möchte, z.B. habe ich auf dem Gateway ein
> Portforwarding für HTTP und FTP auf meinen Server in der DMZ
> eingerichtet (und auch dessen personal Firewall passieren lassen), oder
> ich habe auf allen Firewalls die gängigen Protokolle nach draußen
> gelassen z.B. DNS, HTTP, etc.
misverstandene spezifische Umsetzung einer Massnahme eines
Sicherheitskonzeptes.
> Das Ganze artet in nicht unerheblichen Administrationsaufwand aus
> (insbesondere die Reihenschaltung von Personal Firewalls und Firewall
> auf dem Gateway, die immer im Douett konfiguriert werden müssen), gab
> mir aber stets das wohlige Gefühl, ganz besonders sicher zu sein.
dass ist aber nicht deren Aufgabe. Und ja, bestimmte Massnahmen haben
einen hohen administrativen und operativen Aufwand - etwas dass im
Sicherheitskonzept natuerlich in die Kosten-Schaden-Wahrscheinlichkeit-
Aufwands-Abwaegung mit einfliesst, die in jedem guten
Sicherheitskonzept fuer die Massnahmen zur Abwehr von Bedrohungen
gemacht wird.
> Und zwar fühlte ich mich vor 2 Dingen geschützt:
> 1. Von "Angriffen" von außen, die meine Gateway-Firewall abwehrt
"versehentlich/unwissend laufende Dienste" oder "nicht korrekt
konfiurierbare Dienste und Systeme" sowie "defekte Systeme und
Dienste". Weil das Risiko hier ueblicherweise immer hoch genug
ist in obiger Abwaegung, dass sich eine Massnahme rentiert, gilt
diese Massnahme an einem Perimeter auch als "best practise".
> 2. Von "Nach-Hause-Funken" von eventuell eingeschleppten Trojanern auf
> den Workstations.
konzeptionell.
Die passenden Massnahmen fuer diese Bedrohung heissen "Content-Filter
ALG" in kombination mit Firewall die /jeden/ direkten Verkehr von innen
nach aussen unterbindet (totale Isolation des LAN) oder neuerdings
"Content-Aware Firewalls" - wobei erste Erfahrungen mit letzterem sehr
ernuechternd sind.
Ein IPS (Intrusion Prevention System) kann hier auch als wirksame
Hilfmassnahme* betrachtet werden - erfordert aber im Vergleich zu allen
anderen Massnahmen einen *ernormen* Betriebsaufwand - auch wenn dir
die teflonbeschichteten Hochglanzvertriebler der Marktfuehrer das
genaue Gegenteil weis machen wollen. Glaub ihnen kein Wort.
* Alleine keine ausreichenede Massnahme - konzeptionell, genau aus dem
selben Grund warum ein AV-SCanner keine ausreichende Massnahme gegen
die Bedrohung "infektion durch $SCHADPROGRAMM" darstellt.
Eine Firewall alleine hingegen /erlaubt/ prinzpiell Kommunikation
von innen nach aussen, ist also keine wirksame Schutzmassnahme gegen
diese Bedrohungen.
> Doch je länger ich mich mit der Materie beschäftige, desto weniger
> sicher bin ich mir, ob das eigentlich alles wahrhaftig so sinnvoll ist,
> was ich da mühevoll administriere.
Sicherheitsfelder. Es geht zwar idR. nicht um Menschenleben oder die
Gesundheit (wie in vielen anderen Branchen), aber oftmals genug um die
finanzielle Existenz.
Ein systematischer Ansatz ist zwingend erforderlich um auch nur die
Chance auf ein funktionierendes und erfolgreiches Sicherheitskonzept
zu haben.
Mittlerweile gibt es etablierte Formalisierungen (Common Criteria,
diverse Normen und Standards) die dir ueber Formalismen ermoeglichen
zu einem systematischen Vorgehen zu gelangen - aber alleine helfen die
genau so wenig wie ohne umfassendes Konzept mit Einzelmassnahmen zu
hantieren in der Hoffnung, dass die wenigen Bedrohungen, die du damit
konterst diejenegen sind, die angegriffen werden.
Letzteres hat sich in der Praxis regelmaessig nicht bewaehrt.
PS: eine der groesten Bedrohungen ist die Faulheit der Anwender -
insbesondere bei Anwendern mit technischen Privilegien (vulgo:
Admins). HIerzu ist es nicht immer leicht eine passende technische
Massnahme zu finden und man muss oft genug organisatorische und
administrative Massnahmen anwenden. Fuer Letzteres brauchst du in
Firmen ueblicherweise ein ausreichendes Mandat der Geschaeftsfuehrung.
> Meine Überlegungen zu den beiden Themen:
>
> 1. Angriffe von außen: Vor diesen schützt in erster Linie meine
> Gateway-Firewall, da sie alles Dropt, was nicht explizit gewährt wird.
> Doch was würde passieren, wenn sie das nicht täte? Dann würde doch
> sowieso alles vom IP-Stack abgewehrt werden, da ja gar nichts auf den
> Ports lauscht?!
Schutzmassnahmen: du suchst dir einen Einzelfall raus und versuchst
darueber den Nutzen der Schutzmassnahme zu bewerten.
Das ist ein Logikfehler.
Die Bedrohung, vor die diese spezielle Massnahme schuetzt ist hingegen
u.A. das versehentliche Starten eines unsicheren Dienstes/Programms
z.B. durch Fehlkonfiguration eines Systems, booten eines Systems im
Auslieferungszustand etc.pp.
> Es heißt, eine Firewall "verstecke" den Rechner. Doch tut sie das
Falls "Obscurity" tatsaechlich Teil eines Sicherheitskonzeptes ist,
dann ist eine Firewall zwar durchaus ein Bestandteil der Massnahmen
zur Begegnung der entsprechenden Bedrohungen - alleine aber
keinesfalls ausreichend. Oftmals bewirkt eine Firewall den genauen
gegenteiligen Effekt den man sich - wenn man ohne entsprechend
ausgearbeitetes Sicherheitskonzept - "verstecken" will: sie zeigen
Angreifern mit bunt blinkender 20 Meter hoher Leuchtreklame darauf
hin, dass hier was versteckt werden soll.
> wirklich? Ein gedropptes Paket ist ja kein echtes Verstecken. Ein echtes
> Verstecken wäre es AFAIK, wenn der davorgeschaltete Rechner melden würde
> "not existing host" oder ähnliches. Aber "einfach nicht antworten" ist
Tatsachen (Network unrechable, Host unreachable von einem nur als
Router zu identifizierenden Absender - das ist nur der Anfang) und ist
relativ kompliziet und extrem aufwaendig im Betrieb und schwer zu
Monitoren.
> ja kein echtes Verstecken, sondern eher sehr verräterrisch!?
hohen Leuchtreklametafel vor dem Haus vergleichbar auf der in bunten
blinkenden Lettern steht "Versteck von $NAME". Diese verhindert
vielleicht den direkten Blick auf das Haus, ist aber nicht wirklich
als Versteckmassnahme geeignet. Gleiches gilt fuer Firewalls.
> Welchen Schutz gibt mir meine Endian-Firewall auf dem Gateway denn
> GENAU? Verhindert sie z.B. einen DNS-Angriff? Oder was genau ist der
> zusätzliche Schutz?
Richtige Vorgehensweise: Du enumerierst die Bedrohungen, bewertest
diese bezueglich Risiko [Schaden, Wahrscheinlicheit [tricky!],
Einfachheit (feasibility)] und ueberlegst dir dann dazu die
entsprechenden MAssnahmen die diese Bedrohungen ausschalten/kompensieren
und Entscheidest unter Abwaegung obiger Parameter und der Kosten
(Investition, Aufwand Aufstezen+Betreiben+Warten)] den Nutzen fuer
dich.
Danach ist dann obige Frage automatisch aus den UEberlegungen des
Konzeptes beantwortet :)
Ganz einfach - der Schwierige Teil ist die Erfassung aller moeglichen
und denkbaren Bedrohungen sowie die Bewertung der Wahrscheinlichkeit -
hierzu braucht es Praxiserfahrung und ein Gespuer fuer den
Angriffsmarkt.
> 2. Nach-Hause-Funken:
> Das ist meine größte Sorge schlechthin: Dass ein User sich infiziert und
> ab dem Moment alle daten nach Hause gefunkt werden, im schlimmsten Fall
> sogar Daten, auf die der User via seiner Netzwerk-Shares zugriff hat.
> Doch schützt mich das Absperren FAST aller Outgoing-Ports tatsächlich?
direkter Kommunikationsbeziehungen.
Zulaessige Kommunikation wird dann ueber Inhaltspruefende ALGs
(proxies) abgehandelt (klassisch) oder seit relativ kurzer Zeit ueber
"Application Aware Firewalls" - wobei letzteres praktisch fuer eine
ausreichende Einzelmassnahme IMO noch viel zu unausgereift ist.
> Manche Ports, z.B HTTP, DNS, ggf. auch SMB, DHCP, etc. MÜSSEN ja offen
> bleiben, wenn der Rechner im Netzwerk sein soll (ansonsten könnte ich ja
> auch das Kabel ziehen - dann bräuchte ich aber erst recht keine Firewall
> mehr!).
trennt und es ermoeglicht, den Inhalt der Kommunikation zu pruefen und
zu bewerten.
> Sobald ich aber Ports nach außen öffne, könnte ein halbwegs
> intelligenter Trojaner doch einfach diesen nutzen, anstatt stumpf auf
> dem verschlossenen Port zu beharren.
dass $ADMIN eine rein auf den Transport/Netzschichten arbeitende
Firewall (= Paketfilter) einsetzt, die alles, was ueber den
entsprechenden Port laeuft ungeachtet des Inhaltes durchlaesst.
Das sind die Mehrheit der aktuell aktiven Schadprogramme.
Eine nicht ganz so Grosse Gruppe misbraucht einfach ein ueblicherweise
erlaubtes Applikationsprotokoll (z.B. HTTP oder SMTP o.ae.) um
darueber huckepack (also als korrekte Protokollimplementierung) zu
tunneln. Bekanntestes Beispieler dafuer ist Skype (das durchaus ein
Schadprogramm nach klassischer Definition darstellt).
> Skype ist ein gutes Beispiel dafür! Wenn alle Ports geschlossen sind,
> weicht Skype auf Port 80 (HTTP) und 443 (HTTPS) aus und schickt seine
> Daten einfach darüber! Nicht ohne Grund zählt Skype als Alptraum der
> meisten Admins, da sie kaum verhindern können, dass User nach außen
> durchdringen.
einen SSL-Aufbrechenden Proxy - das koennen mittlerweile fast alle
komerziellen Anbieter auf dem Markt.
> Wie hoch genau ist denn da noch der Schutz, den ich durch meine
> doppelte-Outgoing-Brandschutzmauer da geschaffen habe, wenn jeder
die Passende Schutzmassnahme ist - und versuchst so den Nutzen der
Massnahme Paketfilter zu bewerten. Das ist natuerlich Falsch.
Du musst wenn dann schon die Bedrohungen betrachten, vor denen ein
Paketfilter schuetzt (siehe weiter oben).
Ein Fahrradschloss schuetzt dich ja auch nicht davor, dass jemand dein
Fahrrad mit einem Vorschlaghammer zertruemmert oder mit einem Messer
deine Reifen aufschlitzt.
> Trojaner problemlos erst durch die Personal Firewall auf den Clients und
"application firewall") ist, dass auf dem Host die Zuordnung
zwischen Applikation und Paket getroffen werden kann, also z.B. der
Paketfilter technisch in der Lage ist, ein /ausgehendes/ Paket an Zielport
6000 dem verursachenden Prozess zuzuordnen - und hier entsprechende
Regeln mit einbeziehugn der Prozesse/Tasks/Applikationen umzusetzen
z.B. also nur dem Chat-Client dies erlauben, einem anderen Programm
aber untersagen.
Das schuetzt zwar nicht vor Schadprogrammen, die erlaubte
Applikationen misbrauchen um ihre Kommunikation stellvertretend
abzuhandeln (beliebt ist das einklinken in den Internet Explorer oder
den Mailclient), aber dafuer ist das auch wieder nicht die passende
Massnahme ;)
> dann durch die Gateway-Firewall hindurchspaziert, z.B. via Port 80
> (HTTP), 53 (DNS), 443 (HTTPS), 110 (POP), 25 (SMTP)?
treffen, daher scheidet das ganz aus als ort fuer SchutzMassnahmen
zu obigen Bedrohungen.
> Ich bekomme immer mehr den Anschein, ich mich vor Malware damit gar
> nicht schütze.
> Das Einzige, was ich mit solchen Firewalls offenbar bewerkstelligen
> kann, ist, dass User auf ihren Workstations manche Dinge nicht ohne
> Weiteres machen können, z.B. einen Bittorrent-Client auf dessen
> Standardport betreiben, oder Ahnliches.
> Aber selbst an Skype sieht man ja, dass das Programm nur clever genug
> sein muss, und dann ist auch dieses Ziel konterkarriert.
> Verstehe ich hier etwas grundlegend falsch?
ansonsten hast du durchaus alles noetige Verstanden.
> Ich bin dankbar für jedes Feedback, Rat, Info, Meinung, etc.
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
U.Mutlu
Nov 2, 2011, 4:06:26 AM11/2/11
to
Andreas Kohlbach wrote, On 2011-11-02 02:32:
> Tom H. Lautenbacher wrote on 01. November 2011:
>>
>> ich schütze mein Netzwerk durch eine Firewall auf dem Gateway (Endian
>> Linux via IP tables), als auch in Form von "Personal Firewalls" auf
>> den Netzwerkrechnern (Windows Kaspersky Intenet Security& Linux
> Tom H. Lautenbacher wrote on 01. November 2011:
>>
>> ich schütze mein Netzwerk durch eine Firewall auf dem Gateway (Endian
>> Linux via IP tables), als auch in Form von "Personal Firewalls" auf
>> Iptapbles z.B. via Gufw).
>
> Ich habe 24/7 einen Rechner im Netz, der auch Dienste anbietet, und das
> seit Jahren. Und seit Jahren *keine* iptables Regeln. Logs, ins Besondere
> für ssh, sind zwar voll mit Versuchen, aber bisher scheint der Computer
> noch meiner zu sein.
>
> Und daran werde ich wohl auch nichts ändern.
Das ist aber sehr leichtsinnig!
>
> Ich habe 24/7 einen Rechner im Netz, der auch Dienste anbietet, und das
> seit Jahren. Und seit Jahren *keine* iptables Regeln. Logs, ins Besondere
> für ssh, sind zwar voll mit Versuchen, aber bisher scheint der Computer
> noch meiner zu sein.
>
> Und daran werde ich wohl auch nichts ändern.
Überleg mal: 150 Login-Versuche (ssh) pro Sekunde (das ist ein real erlebter
Wert aus dem Log eines neu aufgesetzten Servers im Internet über eine nur
10 Mbps-Anbindung).
D.h. der Angreifer kann so am Tag 150*86400=12,96 Millionen Brute-Force-Versuche
starten, der müsste doch in wenigen Tagen/Wochen Erfolg haben...
Man muss als allererstes genau das erkennen und unterbinden,
d.h. wenn jemand schon sagen wir 5x mit falschen Login-Daten kommt,
dannn ist der definitiv ein Angreifer/Einbrecher und gehört gesperrt...
Mein Tip: benutze fail2ban oder ähnliches.
Erhard Schwenk
Nov 2, 2011, 4:33:05 AM11/2/11
to
bringt?
Der richtige Weg ist hier selbstverständlich, bei der SSH zwingend die
Public Key Authentifizierung einzuschalten. Passende Keys sind schnell
erzeugt, können auf einem USB-Stick auch unterwegs bequem verwendet
werden und machen Brute Force Angriffe bei geeigneter Länge praktisch
unmöglich.
Dennis Herbrich
Nov 2, 2011, 4:36:22 AM11/2/11
to
Am 2011-11-02 schrieb U.Mutlu:
> Überleg mal: 150 Login-Versuche (ssh) pro Sekunde (das ist ein real erlebter
> Wert aus dem Log eines neu aufgesetzten Servers im Internet über eine nur 10
> Mbps-Anbindung). D.h. der Angreifer kann so am Tag 150*86400=12,96 Millionen
> Brute-Force-Versuche starten, der müsste doch in wenigen Tagen/Wochen Erfolg
> haben...
Milchmädchenrechnung.
> Überleg mal: 150 Login-Versuche (ssh) pro Sekunde (das ist ein real erlebter
> Wert aus dem Log eines neu aufgesetzten Servers im Internet über eine nur 10
> Mbps-Anbindung). D.h. der Angreifer kann so am Tag 150*86400=12,96 Millionen
> Brute-Force-Versuche starten, der müsste doch in wenigen Tagen/Wochen Erfolg
> haben...
Die Versuche sind über willkürlich gewählte Benutzernamen verteilt, und kommen
von verschiedenen Quellen, die in aller Regel nicht zusammenarbeiten.
> Man muss als allererstes genau das erkennen und unterbinden,
> d.h. wenn jemand schon sagen wir 5x mit falschen Login-Daten kommt, dannn ist
> der definitiv ein Angreifer/Einbrecher und gehört gesperrt... Mein Tip:
> benutze fail2ban oder ähnliches.
Bereiche temporär sperren, liefern ihre DoS-Schnittstelle hingegen gleich an
jedes minderbemitteltes Scriptkiddie frei Haus. Gleiches gilt für die clevere
Idee Benutzer zu sperren, wenn mehrfach falsch eingeloggt wurde.
Klassischer Fall von Austreibung des Teufels mit dem Beelzebub. Oder eher
Austreibung eines tobenden Teenagers mit dem Selbstzerstörungsknopf an der
Außenwand.
Gruß,
Dennis
U.Mutlu
Nov 2, 2011, 5:57:00 AM11/2/11
to
Dennis Herbrich wrote, On 2011-11-02 09:36:
> Am 2011-11-02 schrieb U.Mutlu:
>> Überleg mal: 150 Login-Versuche (ssh) pro Sekunde (das ist ein real erlebter
>> Wert aus dem Log eines neu aufgesetzten Servers im Internet über eine nur 10
>> Mbps-Anbindung). D.h. der Angreifer kann so am Tag 150*86400=12,96 Millionen
>> Brute-Force-Versuche starten, der müsste doch in wenigen Tagen/Wochen Erfolg
>> haben...
>
> Milchmädchenrechnung.
> Die Versuche sind über willkürlich gewählte Benutzernamen verteilt, und kommen
> von verschiedenen Quellen, die in aller Regel nicht zusammenarbeiten.
Nein, es handelt sich um einen Täter der sich als root versucht hat sich so oft einzuloggen
> Am 2011-11-02 schrieb U.Mutlu:
>> Überleg mal: 150 Login-Versuche (ssh) pro Sekunde (das ist ein real erlebter
>> Wert aus dem Log eines neu aufgesetzten Servers im Internet über eine nur 10
>> Mbps-Anbindung). D.h. der Angreifer kann so am Tag 150*86400=12,96 Millionen
>> Brute-Force-Versuche starten, der müsste doch in wenigen Tagen/Wochen Erfolg
>> haben...
>
> Milchmädchenrechnung.
> Die Versuche sind über willkürlich gewählte Benutzernamen verteilt, und kommen
> von verschiedenen Quellen, die in aller Regel nicht zusammenarbeiten.
(natürlich kann er nicht wissen dass bei mir root-login als erstes disabled wird :-)
>> Man muss als allererstes genau das erkennen und unterbinden,
>> d.h. wenn jemand schon sagen wir 5x mit falschen Login-Daten kommt, dannn ist
>> der definitiv ein Angreifer/Einbrecher und gehört gesperrt... Mein Tip:
>> benutze fail2ban oder ähnliches.
>
> Server, die über fail2ban oder ähnliche Methoden Netzadressen oder sogar ganze
> Bereiche temporär sperren, liefern ihre DoS-Schnittstelle hingegen gleich an
> jedes minderbemitteltes Scriptkiddie frei Haus. Gleiches gilt für die clevere
> Idee Benutzer zu sperren, wenn mehrfach falsch eingeloggt wurde.
>
> Klassischer Fall von Austreibung des Teufels mit dem Beelzebub. Oder eher
> Austreibung eines tobenden Teenagers mit dem Selbstzerstörungsknopf an der
> Außenwand.
denn schlechtreden und miessmachen bringt doch niemanden voran.
U.Mutlu
Nov 2, 2011, 6:03:27 AM11/2/11
to
U.Mutlu wrote, On 2011-11-02 09:06:
> Andreas Kohlbach wrote, On 2011-11-02 02:32:
>> Tom H. Lautenbacher wrote on 01. November 2011:
>>>
>>> ich schütze mein Netzwerk durch eine Firewall auf dem Gateway (Endian
>>> Linux via IP tables), als auch in Form von "Personal Firewalls" auf
>>> den Netzwerkrechnern (Windows Kaspersky Intenet Security& Linux
>>> Iptapbles z.B. via Gufw).
>>
>> Ich habe 24/7 einen Rechner im Netz, der auch Dienste anbietet, und das
>> seit Jahren. Und seit Jahren *keine* iptables Regeln. Logs, ins Besondere
>> für ssh, sind zwar voll mit Versuchen, aber bisher scheint der Computer
>> noch meiner zu sein.
>>
>> Und daran werde ich wohl auch nichts ändern.
>
> Das ist aber sehr leichtsinnig!
> Überleg mal: 150 Login-Versuche (ssh) pro Sekunde (das ist ein real erlebter
> Wert aus dem Log eines neu aufgesetzten Servers im Internet über eine nur
> 10 Mbps-Anbindung).
FYI: diese Login-Attacke kam von der selben einen IP!...
> Andreas Kohlbach wrote, On 2011-11-02 02:32:
>> Tom H. Lautenbacher wrote on 01. November 2011:
>>>
>>> ich schütze mein Netzwerk durch eine Firewall auf dem Gateway (Endian
>>> Linux via IP tables), als auch in Form von "Personal Firewalls" auf
>>> den Netzwerkrechnern (Windows Kaspersky Intenet Security& Linux
>>> Iptapbles z.B. via Gufw).
>>
>> Ich habe 24/7 einen Rechner im Netz, der auch Dienste anbietet, und das
>> seit Jahren. Und seit Jahren *keine* iptables Regeln. Logs, ins Besondere
>> für ssh, sind zwar voll mit Versuchen, aber bisher scheint der Computer
>> noch meiner zu sein.
>>
>> Und daran werde ich wohl auch nichts ändern.
>
> Das ist aber sehr leichtsinnig!
> Überleg mal: 150 Login-Versuche (ssh) pro Sekunde (das ist ein real erlebter
> Wert aus dem Log eines neu aufgesetzten Servers im Internet über eine nur
> 10 Mbps-Anbindung).
> D.h. der Angreifer kann so am Tag 150*86400=12,96 Millionen Brute-Force-Versuche
> starten, der müsste doch in wenigen Tagen/Wochen Erfolg haben...
> Man muss als allererstes genau das erkennen und unterbinden,
> d.h. wenn jemand schon sagen wir 5x mit falschen Login-Daten kommt,
> dannn ist der definitiv ein Angreifer/Einbrecher und gehört gesperrt...
Dennis Herbrich
Nov 2, 2011, 6:49:12 AM11/2/11
to
Am 2011-11-02 schrieb U.Mutlu:
> Dennis Herbrich wrote, On 2011-11-02 09:36:
>> Am 2011-11-02 schrieb U.Mutlu:
>>> Überleg mal: 150 Login-Versuche (ssh) pro Sekunde (das ist ein real
>>> erlebter Wert aus dem Log eines neu aufgesetzten Servers im Internet über
>>> eine nur 10 Mbps-Anbindung). D.h. der Angreifer kann so am Tag
>>> 150*86400=12,96 Millionen Brute-Force-Versuche starten, der müsste doch in
>>> wenigen Tagen/Wochen Erfolg haben...
>>
>> Milchmädchenrechnung.
>> Die Versuche sind über willkürlich gewählte Benutzernamen verteilt, und
>> kommen von verschiedenen Quellen, die in aller Regel nicht zusammenarbeiten.
>
> Nein, es handelt sich um einen Täter der sich als root versucht hat sich so
> oft einzuloggen (natürlich kann er nicht wissen dass bei mir root-login als
> erstes disabled wird :-)
Wo, bitte, ist dann Dein Problem? Zugang gar nicht erst erlauben IST die
> Dennis Herbrich wrote, On 2011-11-02 09:36:
>> Am 2011-11-02 schrieb U.Mutlu:
>>> Überleg mal: 150 Login-Versuche (ssh) pro Sekunde (das ist ein real
>>> erlebter Wert aus dem Log eines neu aufgesetzten Servers im Internet über
>>> eine nur 10 Mbps-Anbindung). D.h. der Angreifer kann so am Tag
>>> 150*86400=12,96 Millionen Brute-Force-Versuche starten, der müsste doch in
>>> wenigen Tagen/Wochen Erfolg haben...
>>
>> Milchmädchenrechnung.
>> Die Versuche sind über willkürlich gewählte Benutzernamen verteilt, und
>> kommen von verschiedenen Quellen, die in aller Regel nicht zusammenarbeiten.
>
> Nein, es handelt sich um einen Täter der sich als root versucht hat sich so
> oft einzuloggen (natürlich kann er nicht wissen dass bei mir root-login als
> erstes disabled wird :-)
Methode der Wahl. Aber wir können gern das Szenario eines gezielten Angriffs
auf einen bekannten Benutzer betrachten, der sich grundsätzlich von überall
einloggen können soll, um dem Obscurity-Vorwurf, der hier mitschwingt, gleich
zu begegnen.
> Na dann erzähl uns doch mal von deiner Abwehrmethode, denn schlechtreden und
> miessmachen bringt doch niemanden voran.
<4eb0ffdb$0$6552$9b4e...@newsspool4.arcor-online.net>, bevor Du dich hier zum
Obst der Woche machst: Key Auth. Wahlweise OTP, und wenn man darauf steht noch
Limitierung auf Logins von bestimmten IP Bereichen in Form einer Whitelist,
aber das ist auch eher etwas für die Nerven als tatsächlicher sicher.
Ganz Harte können auch echte 2-Factor-Auth in Erwägung ziehen, aber das ist
nicht so handlich, dass ich es hier uneingeschränkt empfehlen würde.
Ganz konkret: Direkter remote root-Login ist abzuschalten, das hast Du ja auch
schon bemerkt. Ein klassisches "Daddelsystem" hat außer für den "Admin" und
seinen Kumpels sowieso keinen Shellzugriff vorgesehen, am allerwenigsten remote.
In diesem Szenario (ja, es ist unterdefiniert bis zum Erbrechen, aber ich
will's kurz halten) ist eine ausschließliche key-only authentication per SSH
nicht nur 100%ig sicher vor den bruteforcern, sondern auch problemlos umsetzbar.
Auch wenn es nicht mehr üblich ist, nehmen wir nun ein System an, auf dem neben
dem Adminzugriff noch normale Benutzer Shellzugriff per SSH, bzw. SFTP bekommen
sollen. Dann muss man, wie immer, eine Abwägung von Sicherheitsbedürfnis und
Komfort treffen. Hier *kann* es sinnvoll sein, mit OTP zu arbeiten, wenn man
dies für zweckmäßiger hält, als seinen Kunden key-auth zu erklären. Auch dann
sind bruteforcer einfach mal egal.
Wenn Du natürlich mit dem Fuß aufstampfst und forderst, dass man unbedingt
nur mit einem Kennwort von überall im Netz auf dein System können soll, dann
darfst Du dich auch gerne mit halbgaren "Schutzsystemen" umgeben, um ein
bereits im Kern unsicheres Konzept zu verteidigen. Mein Sicherheitskonzept
sieht das allerdings nicht vor. Ich bin bereit, den "Abstrich" zu machen,
mich nur per key einloggen zu können. Weniger Aufwand, keine gigabyte-großen
Logdateien, und ruhiger Schlaf. Bequemlichkeit war schon immer der größte Feind
der Sicherheit.
Provokativ formuliert: Wer für ein beliebig komfortables Szenario absolute
Sicherheit fordert, hat das Kernproblem nicht verstanden.
Grüße,
Dennis
U.Mutlu
Nov 2, 2011, 7:39:19 AM11/2/11
to
Und was unternimmst du gegen Hacker die deine WebDirectories durchforsten?
U.Mutlu
Nov 2, 2011, 7:45:23 AM11/2/11
to
Und was unternimmst du gegen Hacker die deine WebDirectories durchforsten?
und was gegen Spammer die versuchen dein System als Mail-Relay zu benutzen?
Keine (temp.) Sperrung solcher Hacker-IPs ?
Dann müssten deine Logs ja überlaufen :-)
U.Mutlu
Nov 2, 2011, 7:53:10 AM11/2/11
to
Und was unternimmst du gegen Hacker die deine WebDirectories durchforsten?
und was gegen Spammer die versuchen dein System als Mail-Relay zu benutzen?
Und was tust du gegen Portscans?
und was gegen Spammer die versuchen dein System als Mail-Relay zu benutzen?
Message has been deleted
Jens Mielke
Nov 2, 2011, 8:42:32 AM11/2/11
to
U.Mutlu schrieb:
> Und was unternimmst du gegen Hacker die deine WebDirectories durchforsten?
Dann wäre das System bereits kompromittiert. Was willst Du in diesem
Fall mit einem Paketfilter?
> und was gegen Spammer die versuchen dein System als Mail-Relay zu benutzen?
Den Mailserver sauber aufsetzen.
> Und was tust du gegen Portscans?
Nichts.
Gruß, Jens
> Und was unternimmst du gegen Hacker die deine WebDirectories durchforsten?
Fall mit einem Paketfilter?
> und was gegen Spammer die versuchen dein System als Mail-Relay zu benutzen?
> Und was tust du gegen Portscans?
Gruß, Jens
U.Mutlu
Nov 2, 2011, 9:40:06 AM11/2/11
to
Heiko Schlenker wrote, On 2011-11-02 13:30:
> * U.Mutlu<nos...@mutluit.com> schrieb:
> kein Paketfilter mehr.
Quatsch! Ihr habt doch keine Ahnung von Server-Administration! :-)
>> und was gegen Spammer die versuchen dein System als Mail-Relay zu
>> benutzen?
>
> Einsatz eines ordentlich konfigurierten Mailservers wie Postfix, Exim,
> Sendmail usw.
Wieder Quatsch!
>> Und was tust du gegen Portscans?
>
> Was tust Du gegen Leute, die Dein Haus angucken? ;-) Tipps:
> <http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html#Portscan>
> <http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html#Scans>
> <http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html#Trojanerports>
Hört auf Leute, ihr habt keine praktische Erfahrung mit richtiger
Server-Administration, stattdesen redet ihr nur theoretischen Müll.
> * U.Mutlu<nos...@mutluit.com> schrieb:
>> Und was unternimmst du gegen Hacker die deine WebDirectories durchforsten?
>
> Das System ist also bereits kompromittiert worden. Dann hülfe auch
>
> kein Paketfilter mehr.
Quatsch! Ihr habt doch keine Ahnung von Server-Administration! :-)
>> und was gegen Spammer die versuchen dein System als Mail-Relay zu
>> benutzen?
>
> Sendmail usw.
Wieder Quatsch!
>> Und was tust du gegen Portscans?
>
> <http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html#Portscan>
> <http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html#Scans>
> <http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html#Trojanerports>
Hört auf Leute, ihr habt keine praktische Erfahrung mit richtiger
Server-Administration, stattdesen redet ihr nur theoretischen Müll.
U.Mutlu
Nov 2, 2011, 9:48:06 AM11/2/11
to
Jens Mielke wrote, On 2011-11-02 13:42:
> U.Mutlu schrieb:
>
>> Und was unternimmst du gegen Hacker die deine WebDirectories durchforsten?
>
> Dann wäre das System bereits kompromittiert.
Wie kommst du denn da drauf?
> U.Mutlu schrieb:
>
>> Und was unternimmst du gegen Hacker die deine WebDirectories durchforsten?
>
> Dann wäre das System bereits kompromittiert.
Ich rede von Requests auf WebSeiten die es nicht gibt, der Angreifer sucht aber gezielt
nach bestimmten Datein von bestimmten WebApps, z.B. von phpMyAdmin...
> Was willst Du in diesem Fall mit einem Paketfilter?
>> und was gegen Spammer die versuchen dein System als Mail-Relay zu benutzen?
>
> Den Mailserver sauber aufsetzen.
>> Und was tust du gegen Portscans?
>
> Nichts.
Na, dann viel Spass! :-)
Ralph Lehmann
Nov 2, 2011, 11:11:48 AM11/2/11
to
Hallo zusammen!
Am 02.11.2011 14:40, schrieb U.Mutlu:
> Heiko Schlenker wrote, On 2011-11-02 13:30:
>> * U.Mutlu<nos...@mutluit.com> schrieb:
>>> Und was unternimmst du gegen Hacker die deine WebDirectories durchforsten?
>>
>> Das System ist also bereits kompromittiert worden. Dann hülfe auch
>> kein Paketfilter mehr.
>
> Quatsch! Ihr habt doch keine Ahnung von Server-Administration! :-)
Ich habe den Eindruck, dass der TB in letzter Zeit spürbar langsamer
wird, mal davon abgesehen, dass das Filter-Logfile gigantische Mengen an
Speicherplatz verschlingt. ;-)
Vermutlich wird in der TB Gruppe niemand helfen können - deshalb
F'up2dorthin, wo es passend ist°
Am 02.11.2011 14:40, schrieb U.Mutlu:
> Heiko Schlenker wrote, On 2011-11-02 13:30:
>> * U.Mutlu<nos...@mutluit.com> schrieb:
>>> Und was unternimmst du gegen Hacker die deine WebDirectories durchforsten?
>>
>> Das System ist also bereits kompromittiert worden. Dann hülfe auch
>> kein Paketfilter mehr.
>
> Quatsch! Ihr habt doch keine Ahnung von Server-Administration! :-)
wird, mal davon abgesehen, dass das Filter-Logfile gigantische Mengen an
Speicherplatz verschlingt. ;-)
Vermutlich wird in der TB Gruppe niemand helfen können - deshalb
F'up2dorthin, wo es passend ist°
Burkhard Ott
Nov 2, 2011, 11:44:09 AM11/2/11
to
On Wed, 02 Nov 2011 14:48:06 +0100, U.Mutlu wrote:
> Ich rede von Requests auf WebSeiten die es nicht gibt, der Angreifer
> sucht aber gezielt nach bestimmten Datein von bestimmten WebApps, z.B.
> von phpMyAdmin...
Und? Wenn nicht vorhanden gibts ne 404 Seite, falls vohanden und es
> Ich rede von Requests auf WebSeiten die es nicht gibt, der Angreifer
> sucht aber gezielt nach bestimmten Datein von bestimmten WebApps, z.B.
> von phpMyAdmin...
sollte nicht oeffentlich errichbar sein, kann man mehrere Massnahmen
treffen diese nur fuer bestimmte User zuzulassen.
>>> und was gegen Spammer die versuchen dein System als Mail-Relay zu
>>> benutzen?
>>
>> Den Mailserver sauber aufsetzen.
>
> Das ist Grundvoraussetzung und reicht noch lange nicht aus.
>>> Und was tust du gegen Portscans?
>>
>> Nichts.
>
> Also lässt du auch DoS-Attacken über dich ergehen ohne was dagegen zu
> unternehmen?... Na, dann viel Spass! :-)
desweiteren kannst Du mittels iptable auch keine DDOS Attacke abwehren.
cheers
Jens Mielke
Nov 2, 2011, 12:16:22 PM11/2/11
to
U.Mutlu schrieb:
> Ich rede von Requests auf WebSeiten die es nicht gibt, der Angreifer sucht aber gezielt
> nach bestimmten Datein von bestimmten WebApps, z.B. von phpMyAdmin...
Von ACLs hälst Du nichts?
> fail2ban (oder ähnliches) in Verbindung mit IP-banning...
Möglicher SelfDoS.
> Also lässt du auch DoS-Attacken über dich ergehen ohne was dagegen zu unternehmen?...
Ein Portscan ist kein DoS.
Gruß, Jens
> Ich rede von Requests auf WebSeiten die es nicht gibt, der Angreifer sucht aber gezielt
> nach bestimmten Datein von bestimmten WebApps, z.B. von phpMyAdmin...
> fail2ban (oder ähnliches) in Verbindung mit IP-banning...
> Also lässt du auch DoS-Attacken über dich ergehen ohne was dagegen zu unternehmen?...
Gruß, Jens
Ansgar -59cobalt- Wiechers
Nov 2, 2011, 1:25:36 PM11/2/11
to
Dennis Herbrich <herb...@veloxis.de> wrote:
> Gleiches gilt für die clevere Idee Benutzer zu sperren, wenn mehrfach
> falsch eingeloggt wurde.
Ebenfalls Bullshit. Ja, man KANN sich (bzw. seinen Benutzern) damit in
den Fuss schießen, wenn man's hinreichend dämlich konfiguriert. Muss man
aber nicht.
Sinnvollerweise setzt man für derartige Konfigurationen die Anzahl der
zulässigen Fehlversuche auf einen geeignet hohen Wert (irgendwas ab 50
aufwärts) und sperrt den Account bei Erreichen dieses Wertes nicht
vollständig, sondern für eine mehr oder weniger kurze Zeitspanne
(irgendwas zwischen 5 und 30 Minuten). Macht Brute-Force-Angriffe auf
halbwegs sinnvolle Passwörter/-phrasen aussichtslos und schont trotzdem
den Helldesk.
cu
59cobalt
--
"All vulnerabilities deserve a public fear period prior to patches
becoming available."
--Jason Coombs on Bugtraq
> Am 2011-11-02 schrieb U.Mutlu:
>> Man muss als allererstes genau das erkennen und unterbinden, d.h.
>> wenn jemand schon sagen wir 5x mit falschen Login-Daten kommt, dannn
>> ist der definitiv ein Angreifer/Einbrecher und gehört gesperrt...
>> Mein Tip: benutze fail2ban oder ähnliches.
>
> Server, die über fail2ban oder ähnliche Methoden Netzadressen oder
> sogar ganze Bereiche temporär sperren, liefern ihre DoS-Schnittstelle
> hingegen gleich an jedes minderbemitteltes Scriptkiddie frei Haus.
Da die Verbindungen über TCP laufen: Bullshit.
>> Man muss als allererstes genau das erkennen und unterbinden, d.h.
>> wenn jemand schon sagen wir 5x mit falschen Login-Daten kommt, dannn
>> ist der definitiv ein Angreifer/Einbrecher und gehört gesperrt...
>> Mein Tip: benutze fail2ban oder ähnliches.
>
> Server, die über fail2ban oder ähnliche Methoden Netzadressen oder
> sogar ganze Bereiche temporär sperren, liefern ihre DoS-Schnittstelle
> hingegen gleich an jedes minderbemitteltes Scriptkiddie frei Haus.
> Gleiches gilt für die clevere Idee Benutzer zu sperren, wenn mehrfach
> falsch eingeloggt wurde.
den Fuss schießen, wenn man's hinreichend dämlich konfiguriert. Muss man
aber nicht.
Sinnvollerweise setzt man für derartige Konfigurationen die Anzahl der
zulässigen Fehlversuche auf einen geeignet hohen Wert (irgendwas ab 50
aufwärts) und sperrt den Account bei Erreichen dieses Wertes nicht
vollständig, sondern für eine mehr oder weniger kurze Zeitspanne
(irgendwas zwischen 5 und 30 Minuten). Macht Brute-Force-Angriffe auf
halbwegs sinnvolle Passwörter/-phrasen aussichtslos und schont trotzdem
den Helldesk.
cu
59cobalt
--
"All vulnerabilities deserve a public fear period prior to patches
becoming available."
--Jason Coombs on Bugtraq
Helmut Hullen
Nov 2, 2011, 1:18:00 PM11/2/11
to
Hallo, Jens,
Du meintest am 02.11.11:
> U.Mutlu schrieb:
>> Ich rede von Requests auf WebSeiten die es nicht gibt, der Angreifer
>> sucht aber gezielt nach bestimmten Datein von bestimmten WebApps,
>> z.B. von phpMyAdmin...
> Von ACLs hälst Du nichts?
Viel besser wäre "mod-security".
>> fail2ban (oder ähnliches) in Verbindung mit IP-banning...
> Möglicher SelfDoS.
Für die ach so beliebten SSH-Scans empfehle ich nach wie vor
# ----------------- Skript-Teil ein -------------------
WAN=ppp+ eth1
IPTABLES_BIN=/usr/sbin/iptables
# diese beiden Variablen sind anzupassen
for Interf in $WAN; do
$IPTABLES_BIN -A INPUT -i $Interf -p tcp --dport 22 -m state --state NEW \
-m recent --set --name SSH
$IPTABLES_BIN -A INPUT -i $Interf -p tcp --dport 22 -m state --state NEW \
-m recent --rcheck --seconds 60 --hitcount 4 --rttl --name SSH \
-j REJECT --reject-with tcp-reset
$IPTABLES_BIN -A INPUT -i $Interf -p tcp --dport 22 -m state --state NEW \
-j ACCEPT
done
# Florian Frank in der "linuxmuster"-Mailingliste, 17. Sept. 2005
# pro Absender-IP max. 3 Verbindungsanfragen pro Minute; blockt Skript-Kiddies
# "rcheck" statt "update": Sven Geggus, 22. Sept. 05,
# de.comp.os.unix.networking.misc
# siehe auch
# http://www.heise.de/security/SSH-vor-Brute-Force-Angriffen-schuetzen--/artikel/142155/3
# ----------------- Skript-Teil aus -------------------
Kappt die Verbindung, wenn mehr als 4 Versuche binnen 60 Sekunden
auflaufen.
Und lässt sich auch für andere Ports als nur 22 einstellen.
Ok - das hakt (natürlich), wenn ein gewollter Automat derart hektisch anklopft.
Und es hakt auch bei langsamen Kiddy-Skripts (die ich in den letzten 12 Monaten zweimal erlebt; etwa alle 30 Sekunden ein neuer Versuch). Aber
da komme ich in die Gegend von tüdeligen erlaubten Benutzern, die sich immer wieder vertippen.
Abhilfe: weitere Regel
$IPTABLES_BIN -A INPUT -i $Interf -p tcp --dport 22 -m state --state NEW \
-m recent --rcheck --seconds 360 --hitcount 10 --rttl --name SSH \
-j REJECT --reject-with tcp-reset
Am Rande: Abbruch nach 3 oder 4 Misserfolgen ist auch an anderen Stellen eingestellt; da mault niemand.
Und bei SSH habe ich zusätzlich in "/etc/ssh/sshd_config"
PermitRootLogin without-password
eingestellt; da muss das Kiddy-Skript 2 Passwörter erraten oder sonstwie erschnüffelt haben, um "root"-Rechte zu bekommen.
Viele Gruesse!
Helmut
Du meintest am 02.11.11:
> U.Mutlu schrieb:
>> Ich rede von Requests auf WebSeiten die es nicht gibt, der Angreifer
>> sucht aber gezielt nach bestimmten Datein von bestimmten WebApps,
>> z.B. von phpMyAdmin...
> Von ACLs hälst Du nichts?
>> fail2ban (oder ähnliches) in Verbindung mit IP-banning...
> Möglicher SelfDoS.
# ----------------- Skript-Teil ein -------------------
WAN=ppp+ eth1
IPTABLES_BIN=/usr/sbin/iptables
# diese beiden Variablen sind anzupassen
for Interf in $WAN; do
$IPTABLES_BIN -A INPUT -i $Interf -p tcp --dport 22 -m state --state NEW \
-m recent --set --name SSH
$IPTABLES_BIN -A INPUT -i $Interf -p tcp --dport 22 -m state --state NEW \
-m recent --rcheck --seconds 60 --hitcount 4 --rttl --name SSH \
-j REJECT --reject-with tcp-reset
$IPTABLES_BIN -A INPUT -i $Interf -p tcp --dport 22 -m state --state NEW \
-j ACCEPT
done
# Florian Frank in der "linuxmuster"-Mailingliste, 17. Sept. 2005
# pro Absender-IP max. 3 Verbindungsanfragen pro Minute; blockt Skript-Kiddies
# "rcheck" statt "update": Sven Geggus, 22. Sept. 05,
# de.comp.os.unix.networking.misc
# siehe auch
# http://www.heise.de/security/SSH-vor-Brute-Force-Angriffen-schuetzen--/artikel/142155/3
# ----------------- Skript-Teil aus -------------------
Kappt die Verbindung, wenn mehr als 4 Versuche binnen 60 Sekunden
auflaufen.
Und lässt sich auch für andere Ports als nur 22 einstellen.
Ok - das hakt (natürlich), wenn ein gewollter Automat derart hektisch anklopft.
Und es hakt auch bei langsamen Kiddy-Skripts (die ich in den letzten 12 Monaten zweimal erlebt; etwa alle 30 Sekunden ein neuer Versuch). Aber
da komme ich in die Gegend von tüdeligen erlaubten Benutzern, die sich immer wieder vertippen.
Abhilfe: weitere Regel
$IPTABLES_BIN -A INPUT -i $Interf -p tcp --dport 22 -m state --state NEW \
-m recent --rcheck --seconds 360 --hitcount 10 --rttl --name SSH \
-j REJECT --reject-with tcp-reset
Am Rande: Abbruch nach 3 oder 4 Misserfolgen ist auch an anderen Stellen eingestellt; da mault niemand.
Und bei SSH habe ich zusätzlich in "/etc/ssh/sshd_config"
PermitRootLogin without-password
eingestellt; da muss das Kiddy-Skript 2 Passwörter erraten oder sonstwie erschnüffelt haben, um "root"-Rechte zu bekommen.
Viele Gruesse!
Helmut
Günter Frenz
Nov 2, 2011, 1:39:40 PM11/2/11
to
Am 02 Nov 2011 18:18:00 +0100
schrieb Hel...@Hullen.de (Helmut Hullen):
Vor der recent-Geschichte sollte man aber noch Anfragen von bekannten
IP-Adressen explizit zulassen, damit man sich nicht so schnell selbst
aussperrt oder eben geschickt ausgesperrt wird...
Und den REJECT vielleicht noch mit einem Rate-limit versehen, damit
nicht auch noch der Uplink verstopft...
Günter
schrieb Hel...@Hullen.de (Helmut Hullen):
IP-Adressen explizit zulassen, damit man sich nicht so schnell selbst
aussperrt oder eben geschickt ausgesperrt wird...
Und den REJECT vielleicht noch mit einem Rate-limit versehen, damit
nicht auch noch der Uplink verstopft...
Günter
Helmut Hullen
Nov 2, 2011, 1:49:00 PM11/2/11
to
Hallo, Günter,
Du meintest am 02.11.11:
>> Für die ach so beliebten SSH-Scans empfehle ich nach wie vor
>>
>> # ----------------- Skript-Teil ein -------------------
>>
>> WAN=ppp+ eth1
>> IPTABLES_BIN=/usr/sbin/iptables
>> # diese beiden Variablen sind anzupassen
...
> Vor der recent-Geschichte sollte man aber noch Anfragen von bekannten
> IP-Adressen explizit zulassen, damit man sich nicht so schnell selbst
> aussperrt oder eben geschickt ausgesperrt wird...
Dieses Skript benutzen ich und viele Kollegen inzwischen seit Jahren -
ausgesperrt hat sich damit insgesamt noch niemand.
Ok - wer es schafft, sich 4 Mal binnen 60 Minuten mit einem Vertipper im
Passwort anzumelden, der darf auch erst mal eine Pause machen.
> Und den REJECT vielleicht noch mit einem Rate-limit versehen, damit
> nicht auch noch der Uplink verstopft...
Meine Erfahrung: 0 bis 3 Versuche pro Tag. Da sollte keine Gefahr für
den Uplink bestehen.
Am Rande: ich lasse aus purer Neugier das Skript hier zuhause auch für
FTP laufen: bestenfalls 1 Treffer pro Monat.
Viele Gruesse!
Helmut
Du meintest am 02.11.11:
>> Für die ach so beliebten SSH-Scans empfehle ich nach wie vor
>>
>> # ----------------- Skript-Teil ein -------------------
>>
>> WAN=ppp+ eth1
>> IPTABLES_BIN=/usr/sbin/iptables
>> # diese beiden Variablen sind anzupassen
> Vor der recent-Geschichte sollte man aber noch Anfragen von bekannten
> IP-Adressen explizit zulassen, damit man sich nicht so schnell selbst
> aussperrt oder eben geschickt ausgesperrt wird...
ausgesperrt hat sich damit insgesamt noch niemand.
Ok - wer es schafft, sich 4 Mal binnen 60 Minuten mit einem Vertipper im
Passwort anzumelden, der darf auch erst mal eine Pause machen.
> Und den REJECT vielleicht noch mit einem Rate-limit versehen, damit
> nicht auch noch der Uplink verstopft...
den Uplink bestehen.
Am Rande: ich lasse aus purer Neugier das Skript hier zuhause auch für
FTP laufen: bestenfalls 1 Treffer pro Monat.
Viele Gruesse!
Helmut
Günter Frenz
Nov 2, 2011, 2:31:05 PM11/2/11
to
Am 02 Nov 2011 18:49:00 +0100
schrieb Hel...@Hullen.de (Helmut Hullen):
> Hallo, Günter,
>
> Du meintest am 02.11.11:
>
> >> Für die ach so beliebten SSH-Scans empfehle ich nach wie vor
> >>
> >> # ----------------- Skript-Teil ein -------------------
> >>
> >> WAN=ppp+ eth1
> >> IPTABLES_BIN=/usr/sbin/iptables
> >> # diese beiden Variablen sind anzupassen
>
> ...
>
> > Vor der recent-Geschichte sollte man aber noch Anfragen von
> > bekannten IP-Adressen explizit zulassen, damit man sich nicht so
> > schnell selbst aussperrt oder eben geschickt ausgesperrt wird...
>
> Dieses Skript benutzen ich und viele Kollegen inzwischen seit Jahren
> - ausgesperrt hat sich damit insgesamt noch niemand.
>
> Ok - wer es schafft, sich 4 Mal binnen 60 Minuten mit einem Vertipper
> im Passwort anzumelden, der darf auch erst mal eine Pause machen.
wenn da noch ein Nagios mit check_by_ssh zugreift, kann das schnell eng
werden. Aber die IP-Adresse kennt man ja...
Günter
schrieb Hel...@Hullen.de (Helmut Hullen):
> Hallo, Günter,
>
> Du meintest am 02.11.11:
>
> >> Für die ach so beliebten SSH-Scans empfehle ich nach wie vor
> >>
> >> # ----------------- Skript-Teil ein -------------------
> >>
> >> WAN=ppp+ eth1
> >> IPTABLES_BIN=/usr/sbin/iptables
> >> # diese beiden Variablen sind anzupassen
>
> ...
>
> > Vor der recent-Geschichte sollte man aber noch Anfragen von
> > bekannten IP-Adressen explizit zulassen, damit man sich nicht so
> > schnell selbst aussperrt oder eben geschickt ausgesperrt wird...
>
> Dieses Skript benutzen ich und viele Kollegen inzwischen seit Jahren
> - ausgesperrt hat sich damit insgesamt noch niemand.
>
> Ok - wer es schafft, sich 4 Mal binnen 60 Minuten mit einem Vertipper
> im Passwort anzumelden, der darf auch erst mal eine Pause machen.
werden. Aber die IP-Adresse kennt man ja...
Günter
Helmut Hullen
Nov 2, 2011, 2:39:00 PM11/2/11
to
Hallo, Günter,
Du meintest am 02.11.11:
Du meintest am 02.11.11:
>> Dieses Skript benutzen ich und viele Kollegen inzwischen seit Jahren
>> - ausgesperrt hat sich damit insgesamt noch niemand.
>>
>> Ok - wer es schafft, sich 4 Mal binnen 60 Minuten mit einem
>> Vertipper im Passwort anzumelden, der darf auch erst mal eine Pause
>> machen.
> wenn da noch ein Nagios mit check_by_ssh zugreift, kann das schnell
> eng werden. Aber die IP-Adresse kennt man ja...
Wenn ... trifft für die von mir betreuten Systeme nicht zu.
>> - ausgesperrt hat sich damit insgesamt noch niemand.
>>
>> Ok - wer es schafft, sich 4 Mal binnen 60 Minuten mit einem
>> Vertipper im Passwort anzumelden, der darf auch erst mal eine Pause
>> machen.
> wenn da noch ein Nagios mit check_by_ssh zugreift, kann das schnell
> eng werden. Aber die IP-Adresse kennt man ja...
Viele Gruesse!
Helmut
Juergen Ilse
Nov 3, 2011, 1:16:25 AM11/3/11
to
Hallo,
U.Mutlu <nos...@mutluit.com> wrote:
> Andreas Kohlbach wrote, On 2011-11-02 02:32:
>> Ich habe 24/7 einen Rechner im Netz, der auch Dienste anbietet, und das
>> seit Jahren. Und seit Jahren *keine* iptables Regeln. Logs, ins Besondere
>> für ssh, sind zwar voll mit Versuchen, aber bisher scheint der Computer
>> noch meiner zu sein.
>> Und daran werde ich wohl auch nichts ändern.
> Das ist aber sehr leichtsinnig!
Inwiefern? Sofern der Rechner so konfiguriert ist, dass er nur die Dienste
ueber Netz anbietet, die auch wirklich nemoetigt werden, wuerden irgend
welche iptables-Regeln welche zusaetzliche Sicherheit bieten?
Die angebotenen Dienste koennte man damit nicht ausfiltern ohne den Betrieb
zu stoeren, denn nach Vorraussetzung werden die Dienste ha benoetigt und
muessen daher erreichbar sein (im erwaehnten Fall z.B. ssh). Und nicht an-
gebotene Dienste muss man nicht filtern, denn der IP-Stack des Systems wird
eingehende Verbindungsversuche auch voellig ohne Paketfilter rejecten.
Wieso sollte das also "sehr leichtsinnig" sein?
> Überleg mal: 150 Login-Versuche (ssh) pro Sekunde (das ist ein real erlebter
> Wert aus dem Log eines neu aufgesetzten Servers im Internet über eine nur
> 10 Mbps-Anbindung).
> D.h. der Angreifer kann so am Tag 150*86400=12,96 Millionen Brute-Force-Versuche
> starten, der müsste doch in wenigen Tagen/Wochen Erfolg haben...
Nicht, sofern man nur Logins per ssh-Key zulaesst, mit hinreichenden
Keylaengen gearbeitet wird und keiner der keys kompromittiert wurde.
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.
U.Mutlu <nos...@mutluit.com> wrote:
> Andreas Kohlbach wrote, On 2011-11-02 02:32:
>> Ich habe 24/7 einen Rechner im Netz, der auch Dienste anbietet, und das
>> seit Jahren. Und seit Jahren *keine* iptables Regeln. Logs, ins Besondere
>> für ssh, sind zwar voll mit Versuchen, aber bisher scheint der Computer
>> noch meiner zu sein.
>> Und daran werde ich wohl auch nichts ändern.
> Das ist aber sehr leichtsinnig!
ueber Netz anbietet, die auch wirklich nemoetigt werden, wuerden irgend
welche iptables-Regeln welche zusaetzliche Sicherheit bieten?
Die angebotenen Dienste koennte man damit nicht ausfiltern ohne den Betrieb
zu stoeren, denn nach Vorraussetzung werden die Dienste ha benoetigt und
muessen daher erreichbar sein (im erwaehnten Fall z.B. ssh). Und nicht an-
gebotene Dienste muss man nicht filtern, denn der IP-Stack des Systems wird
eingehende Verbindungsversuche auch voellig ohne Paketfilter rejecten.
Wieso sollte das also "sehr leichtsinnig" sein?
> Überleg mal: 150 Login-Versuche (ssh) pro Sekunde (das ist ein real erlebter
> Wert aus dem Log eines neu aufgesetzten Servers im Internet über eine nur
> 10 Mbps-Anbindung).
> D.h. der Angreifer kann so am Tag 150*86400=12,96 Millionen Brute-Force-Versuche
> starten, der müsste doch in wenigen Tagen/Wochen Erfolg haben...
Keylaengen gearbeitet wird und keiner der keys kompromittiert wurde.
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.
Juergen P. Meier
Nov 3, 2011, 1:13:42 AM11/3/11
to
Helmut Hullen <Hel...@Hullen.de>:
> Ok - wer es schafft, sich 4 Mal binnen 60 Minuten mit einem Vertipper im
> Passwort anzumelden, der darf auch erst mal eine Pause machen.
Das ist eine Besonders Daemliche Idee[tm].
> Passwort anzumelden, der darf auch erst mal eine Pause machen.
Juergen Ilse
Nov 3, 2011, 1:24:07 AM11/3/11
to
Hallo,
U.Mutlu <nos...@mutluit.com> wrote:
> Und was unternimmst du gegen Hacker die deine WebDirectories durchforsten?
Entweder will ich die Daten public anbieten, dann stoert mich das nicht
(denn die Daten stehen dann im Netz um "durchforstet" werden zu koennen)
oder die Daten sind nicht fuer die Allgemeinheit bestimmt und ich biete
den Dienst daher konsequenterweise nicht zum Internet hin an.
U.Mutlu <nos...@mutluit.com> wrote:
> Und was unternimmst du gegen Hacker die deine WebDirectories durchforsten?
(denn die Daten stehen dann im Netz um "durchforstet" werden zu koennen)
oder die Daten sind nicht fuer die Allgemeinheit bestimmt und ich biete
den Dienst daher konsequenterweise nicht zum Internet hin an.
Juergen Ilse
Nov 3, 2011, 1:28:31 AM11/3/11
to
Hallo,
U.Mutlu <nos...@mutluit.com> wrote:
> Und was unternimmst du gegen Hacker die deine WebDirectories durchforsten?
Hatte ich schon beantwortet.
> und was gegen Spammer die versuchen dein System als Mail-Relay zu benutzen?
Eine vernueftige Mailserver-Konfiguration hilft dagegen (im Gegensatz zu
einem Paketfilter, der da i.a. eher weniger hilfreich ist).
> Keine (temp.) Sperrung solcher Hacker-IPs ?
Was sind denn "Hacker-IPs"?
> Dann müssten deine Logs ja überlaufen :-)
Man logged nur das, was einen auch potentiell interessiert.
U.Mutlu <nos...@mutluit.com> wrote:
> Und was unternimmst du gegen Hacker die deine WebDirectories durchforsten?
> und was gegen Spammer die versuchen dein System als Mail-Relay zu benutzen?
einem Paketfilter, der da i.a. eher weniger hilfreich ist).
> Keine (temp.) Sperrung solcher Hacker-IPs ?
> Dann müssten deine Logs ja überlaufen :-)
Juergen Ilse
Nov 3, 2011, 1:33:21 AM11/3/11
to
Hallo,
U.Mutlu <nos...@mutluit.com> wrote:
> Hört auf Leute, ihr habt keine praktische Erfahrung mit richtiger
> Server-Administration, stattdesen redet ihr nur theoretischen Müll.
Viele der Leute, die dir auch solche Antworten geben wuerden, verdienen
seit etlichen Jahren ihre Broetchen mit Server-Administration, Firewall-
Loesungen, EDV-Sicherheit oder EDV-Systemberatung.
U.Mutlu <nos...@mutluit.com> wrote:
> Hört auf Leute, ihr habt keine praktische Erfahrung mit richtiger
> Server-Administration, stattdesen redet ihr nur theoretischen Müll.
seit etlichen Jahren ihre Broetchen mit Server-Administration, Firewall-
Loesungen, EDV-Sicherheit oder EDV-Systemberatung.
Juergen Ilse
Nov 3, 2011, 1:49:40 AM11/3/11
to
Hallo,
Ich vermute, er hat noch nie eine ordentliche DDoS-Attacke gesehen ...
Vor Jahren hatte ich mal einen (nicht erfolgreichen) Angriff auf einen
Server gesehen, der mit ueber 35 MBit/s hereinkam (von mehr als 75000
IP-Adressen ueber 4 Uplinks zu unterschiedlichen Providern gleichzeitig).
Wie man mit seinen "Spielzeugmethoden" gegen so etwas erfolgreich angehen
sollte, ist mir voellig schleierhaft.
Ich habe auch schon mal gesehen, dass eine Cisco PIX 525 so mit Traffic
zugeschossen wurde, dass sie sich zum spontanen reboot entschlossen hat
(vermutlich Speicherprobleme, weil in so schneller Folge neue Connections
aufgebaut wurden, dass immer mindestens 200000 paralleke Connections ge-
tracked wurden und immer noch mehr aufzubauen versucht wurde, ... Ein
Umzug hinter eine PIX 535, die in jeder Hinsicht mehr Kapazitaeten hatte,
beseitigte damals das Problem).
Vor Jahren hatte ich mal einen (nicht erfolgreichen) Angriff auf einen
Server gesehen, der mit ueber 35 MBit/s hereinkam (von mehr als 75000
IP-Adressen ueber 4 Uplinks zu unterschiedlichen Providern gleichzeitig).
Wie man mit seinen "Spielzeugmethoden" gegen so etwas erfolgreich angehen
sollte, ist mir voellig schleierhaft.
Ich habe auch schon mal gesehen, dass eine Cisco PIX 525 so mit Traffic
zugeschossen wurde, dass sie sich zum spontanen reboot entschlossen hat
(vermutlich Speicherprobleme, weil in so schneller Folge neue Connections
aufgebaut wurden, dass immer mindestens 200000 paralleke Connections ge-
tracked wurden und immer noch mehr aufzubauen versucht wurde, ... Ein
Umzug hinter eine PIX 535, die in jeder Hinsicht mehr Kapazitaeten hatte,
beseitigte damals das Problem).
Helmut Hullen
Nov 3, 2011, 3:08:00 AM11/3/11
to
Hallo, Juergen,
Du meintest am 03.11.11:
>> Ok - wer es schafft, sich 4 Mal binnen 60 Minuten mit einem
>> Vertipper im Passwort anzumelden, der darf auch erst mal eine Pause
>> machen.
> Das ist eine Besonders Daemliche Idee[tm].
Ja ... ich habe im obigen Text den (falschen) Kompromiss zwischen "60
Sekunden" und "1 Minute" gewählt ...
Die von mir beschriebene Routine ist auf 60 Sekunden eingestellt.
Viele Gruesse!
Helmut
Du meintest am 03.11.11:
>> Ok - wer es schafft, sich 4 Mal binnen 60 Minuten mit einem
>> Vertipper im Passwort anzumelden, der darf auch erst mal eine Pause
>> machen.
> Das ist eine Besonders Daemliche Idee[tm].
Sekunden" und "1 Minute" gewählt ...
Die von mir beschriebene Routine ist auf 60 Sekunden eingestellt.
Viele Gruesse!
Helmut
Burkhard Ott
Nov 3, 2011, 11:37:54 AM11/3/11
to
On Thu, 03 Nov 2011 05:28:31 +0000, Juergen Ilse wrote:
>> Keine (temp.) Sperrung solcher Hacker-IPs ?
>
> Was sind denn "Hacker-IPs"?
SCNR
>> Keine (temp.) Sperrung solcher Hacker-IPs ?
>
> Was sind denn "Hacker-IPs"?
Die mit der kleine Axt an der Netzmaske.
cheers
Burkhard Ott
Nov 3, 2011, 11:41:07 AM11/3/11
to
On Wed, 02 Nov 2011 14:40:06 +0100, U.Mutlu wrote:
> Heiko Schlenker wrote, On 2011-11-02 13:30:
>> * U.Mutlu<nos...@mutluit.com> schrieb:
>>> Und was unternimmst du gegen Hacker die deine WebDirectories
>>> durchforsten?
>>
>> Das System ist also bereits kompromittiert worden. Dann hülfe auch kein
>> Paketfilter mehr.
>
> Quatsch! Ihr habt doch keine Ahnung von Server-Administration! :-)
Genau!
> Heiko Schlenker wrote, On 2011-11-02 13:30:
>> * U.Mutlu<nos...@mutluit.com> schrieb:
>>> Und was unternimmst du gegen Hacker die deine WebDirectories
>>> durchforsten?
>>
>> Das System ist also bereits kompromittiert worden. Dann hülfe auch kein
>> Paketfilter mehr.
>
> Quatsch! Ihr habt doch keine Ahnung von Server-Administration! :-)
All Hail Mutlu the god of Bit's and Bytes.
cheers
Andreas Kohlbach
Nov 3, 2011, 8:01:36 PM11/3/11
to
Juergen Ilse wrote on 03. November 2011:
>
> U.Mutlu <nos...@mutluit.com> wrote:
>> Andreas Kohlbach wrote, On 2011-11-02 02:32:
>>> Ich habe 24/7 einen Rechner im Netz, der auch Dienste anbietet, und das
>>> seit Jahren. Und seit Jahren *keine* iptables Regeln. Logs, ins Besondere
>>> für ssh, sind zwar voll mit Versuchen, aber bisher scheint der Computer
>>> noch meiner zu sein.
>>> Und daran werde ich wohl auch nichts ändern.
>> Das ist aber sehr leichtsinnig!
[...]
>
> U.Mutlu <nos...@mutluit.com> wrote:
>> Andreas Kohlbach wrote, On 2011-11-02 02:32:
>>> Ich habe 24/7 einen Rechner im Netz, der auch Dienste anbietet, und das
>>> seit Jahren. Und seit Jahren *keine* iptables Regeln. Logs, ins Besondere
>>> für ssh, sind zwar voll mit Versuchen, aber bisher scheint der Computer
>>> noch meiner zu sein.
>>> Und daran werde ich wohl auch nichts ändern.
>> Das ist aber sehr leichtsinnig!
>> Überleg mal: 150 Login-Versuche (ssh) pro Sekunde (das ist ein real erlebter
>> Wert aus dem Log eines neu aufgesetzten Servers im Internet über eine nur
>> 10 Mbps-Anbindung).
>> D.h. der Angreifer kann so am Tag 150*86400=12,96 Millionen Brute-Force-Versuche
>> starten, der müsste doch in wenigen Tagen/Wochen Erfolg haben...
>
> Nicht, sofern man nur Logins per ssh-Key zulaesst, mit hinreichenden
> Keylaengen gearbeitet wird und keiner der keys kompromittiert wurde.
zu erratenden, Usernamen erlaubt.
| AllowUsers isch_sage_den_nischt und_noch_wer_anners
so dass alle anderen User auf meinem System, inklusive root natürlich,
nicht dürfen, selbst wenn sie valide Accounts haben.
Und das seit Jahren, und ich scheine noch nicht gehackt worden zu sein,
und vermute das auch nicht in absehbarer Zeit.
--
Andreas (PGP Key available on public key servers)
You know you're a Redneck when
32. You think a quarter horse is that ride in front of K-Mart.
Andreas Cammin
Nov 4, 2011, 1:56:47 AM11/4/11
to
Am 02.11.2011 14:40, schrieb U.Mutlu:
>> Einsatz eines ordentlich konfigurierten Mailservers wie Postfix, Exim,
>> Sendmail usw.
>
> Wieder Quatsch!
Genaugenommen ist es für den Missbrauch eines Hosts als Mailrelay
>> Sendmail usw.
>
> Wieder Quatsch!
Voraussetzung, dass ein Mailserver darauf läuft.
Andreas
Andreas Cammin
Nov 4, 2011, 1:48:42 AM11/4/11
to
Am 02.11.2011 02:32, schrieb Andreas Kohlbach:
> Ich habe 24/7 einen Rechner im Netz, der auch Dienste anbietet, und das
> seit Jahren. Und seit Jahren *keine* iptables Regeln. Logs, ins Besondere
> für ssh, sind zwar voll mit Versuchen, aber bisher scheint der Computer
> noch meiner zu sein.
Ich hab schon mal erlebt wie eine Firewall durch multiple
> Ich habe 24/7 einen Rechner im Netz, der auch Dienste anbietet, und das
> seit Jahren. Und seit Jahren *keine* iptables Regeln. Logs, ins Besondere
> für ssh, sind zwar voll mit Versuchen, aber bisher scheint der Computer
> noch meiner zu sein.
ssh-Wörterbuchattacken komplett eingeknickt ist. Und die lief auf
potenterer Hardware als ich sie derzeit unter dem Schreibtisch stehen
habe. Das Opfer war aber auch vermutlich interessant genug um so einen
Aufwand zu rechtfertigen...
Andreas
Juergen Ilse
Nov 4, 2011, 3:28:45 AM11/4/11
to
Hallo,
... und zwar ein nicht hinreichend restriktiv konfigurierter Mailserver.
Waere der Mailserver hinreichend restriktiv konfiguriert, wuerde er (ganz
unabhaengig von irgendwelchen Firewalls) unauthorisiertes Mail-Relaying
nicht zulassen.
Waere der Mailserver hinreichend restriktiv konfiguriert, wuerde er (ganz
unabhaengig von irgendwelchen Firewalls) unauthorisiertes Mail-Relaying
nicht zulassen.
Message has been deleted
Erhard Schwenk
Nov 4, 2011, 8:44:53 PM11/4/11
to
Am 02.11.2011 14:48, schrieb U.Mutlu:
> Jens Mielke wrote, On 2011-11-02 13:42:
>> U.Mutlu schrieb:
>>
>>> Und was unternimmst du gegen Hacker die deine WebDirectories
>>> durchforsten?
>>
>> Dann wäre das System bereits kompromittiert.
>
> Wie kommst du denn da drauf?
> Ich rede von Requests auf WebSeiten die es nicht gibt, der Angreifer
> sucht aber gezielt
> nach bestimmten Datein von bestimmten WebApps, z.B. von phpMyAdmin...
Wenn es die Seiten nicht gibt, braucht man auch nichts dagegen zu tun.
> Jens Mielke wrote, On 2011-11-02 13:42:
>> U.Mutlu schrieb:
>>
>>> Und was unternimmst du gegen Hacker die deine WebDirectories
>>> durchforsten?
>>
>> Dann wäre das System bereits kompromittiert.
>
> Wie kommst du denn da drauf?
> Ich rede von Requests auf WebSeiten die es nicht gibt, der Angreifer
> sucht aber gezielt
> nach bestimmten Datein von bestimmten WebApps, z.B. von phpMyAdmin...
>> Was willst Du in diesem Fall mit einem Paketfilter?
> fail2ban (oder ähnliches) in Verbindung mit IP-banning...
>>> und was gegen Spammer die versuchen dein System als Mail-Relay zu
>>> benutzen?
>> Den Mailserver sauber aufsetzen.
> Das ist Grundvoraussetzung und reicht noch lange nicht aus.
>>> Und was tust du gegen Portscans?
>> Nichts.
> Also lässt du auch DoS-Attacken über dich ergehen ohne was dagegen zu
> unternehmen?...
DDoS-Attacken hilft ohnehin nur ein filternder Uplink.
--
Erhard Schwenk
Akkordeonjugend Baden-Württemberg - http://www.akkordeonjugend.de/
APAYA running System - http://www.apaya.net/
0 new messages