Hi,
Eine wirkungsvolle Abwehr gegen Portscans wäre doch einfach jede Anfrage mit SYN zu beantworten, so daß der Angreifer mit der Flut von 65535 offenen Ports konfrontiert wird.
Ist sowas mit iptables möglich?
Mit Portsentry kann man sowas machen, allerdings muss man jeden Port der offen erscheinen soll einzeln kommagetrennt angeben. Außerdem ist man dort auf 64 beschränkt.
Gruß, Martin
am Fri, dem 09.04.2004, um 18:21:06 +0200 mailte Martin folgendes:
Hi,
Eine wirkungsvolle Abwehr gegen Portscans wäre doch einfach jede Anfrage mit SYN zu beantworten, so daß der Angreifer mit der Flut von 65535
Du meinst SYN/ACK.
offenen Ports konfrontiert wird.
Ist sowas mit iptables möglich?
Ja, es gibt einModul dafür.
Aber das ist keine Abwehr von Portscans, höchstens eine asoziale Verhaltensweise. Und gewinnen tust Du damit nix, außer mehr Traffic. IMHO.
Andreas
Hallo,
@Andreas und Konrad: danke erstmal für eure Antworten
Ist sowas mit iptables möglich?
Ja, es gibt einModul dafür.
Name?
Toll, dann hat der Angreifer eine Liste von 1500 (Beispiel nmap) offenen Ports innerhalb von Sekunden und schickt weitere Requests an die Ports, die ihn interessieren. Gewinn: null Security, viel Traffic.
Sicher wird ein Angreifer dann weiterscannen, aber er muss sich dann was anderes überlegen. Beispielsweise Daemon Banner auslesen (z.B. mit nast). Durch den Portscann jedenfalls hat er 0 Informationsgewinn.
Ich stimme euch zu, dieser Spaß bringt keinen Gewinn an Security, mir gehts da einfach nur um ein bisschen Spielverderberei :-) Natürlich muss dafür die Firewallkonfiguration und die Resistenz der Server (Patches und saubere Konfiguration) stimmen.
Martin
am Sat, dem 10.04.2004, um 18:42:05 +0200 mailte Martin Knechtel folgendes:
Ist sowas mit iptables möglich?
Ja, es gibt einModul dafür.
Name?
TARPIT
Gibt es auf http://netfilter.org.
Andreas
On Friday 09 April 2004 18:21, Martin wrote:
Eine wirkungsvolle Abwehr gegen Portscans wäre doch einfach jede Anfrage mit SYN zu beantworten, so daß der Angreifer mit der Flut von 65535 offenen Ports konfrontiert wird.
Toll, dann hat der Angreifer eine Liste von 1500 (Beispiel nmap) offenen Ports innerhalb von Sekunden und schickt weitere Requests an die Ports, die ihn interessieren. Gewinn: null Security, viel Traffic.
So viele offene Ports schreien doch regelrecht "schlag mich! schlag mich!". Selbst wenn ich ein riesen Tranparent mit Zielscheiben mit mir rumschleppe, wird der Raudi im Park immernoch dorthin hauen, wo es wehtut (damit es jetzt richtig hinkt: z.B. Port 80).
Wie waere es damit: *nicht auf Ping reagieren (ca. 50% aller Attacken beginnen mit einem Ping-Scan) *Alle unbenutzten Ports reagieren gar nicht (der Angreifer belegt in diesem Fall haufenweise Ressourcen auf seinem Rechner, da er die Timeouts abwarten muss/will) *Falls Du einen Apachen nach aussen sichtbar hast: sorg' dafür dass er immer gepatcht ist und keine unnötigen Module geladen sind *Falls Du ssh laufen hast: verstecke es hinter Port-Knocking.
Konrad
am Sat, dem 10.04.2004, um 11:05:37 +0200 mailte Konrad Rosenbaum folgendes: Content-Description: signed data
On Friday 09 April 2004 18:21, Martin wrote:
Eine wirkungsvolle Abwehr gegen Portscans wäre doch einfach jede Anfrage mit SYN zu beantworten, so daß der Angreifer mit der Flut von 65535 offenen Ports konfrontiert wird.
Toll, dann hat der Angreifer eine Liste von 1500 (Beispiel nmap) offenen Ports innerhalb von Sekunden und schickt weitere Requests an die Ports, die ihn interessieren. Gewinn: null Security, viel Traffic.
ACK.
Wie waere es damit: *nicht auf Ping reagieren (ca. 50% aller Attacken beginnen mit einem Ping-Scan)
Krass Unsichtbar, gell? Erinnert an ZoneAlarm und Norton InSecurity, Stealth-Mode. Was soll das bringen?
*Alle unbenutzten Ports reagieren gar nicht (der Angreifer belegt in diesem Fall haufenweise Ressourcen auf seinem Rechner, da er die Timeouts abwarten muss/will)
Siehe oben.
*Falls Du einen Apachen nach aussen sichtbar hast: sorg' dafür dass er immer gepatcht ist und keine unnötigen Module geladen sind
ACK.
*Falls Du ssh laufen hast: verstecke es hinter Port-Knocking.
Kann man drüber nachdenken.
On Saturday 10 April 2004 11:27, Andreas Kretschmer wrote:
am Sat, dem 10.04.2004, um 11:05:37 +0200 mailte Konrad Rosenbaum
Wie waere es damit: *nicht auf Ping reagieren (ca. 50% aller Attacken beginnen mit einem Ping-Scan)
Krass Unsichtbar, gell? Erinnert an ZoneAlarm und Norton InSecurity, Stealth-Mode. Was soll das bringen?
Das hat bei mir 50% der Attacken auf Apache reduziert und damit den Traffic verringert. Das ist nur EINE Maßnahme. Die Liste war nicht als "oder", sondern als "und" gemeint.
*Alle unbenutzten Ports reagieren gar nicht (der Angreifer belegt in diesem Fall haufenweise Ressourcen auf seinem Rechner, da er die Timeouts abwarten muss/will)
Siehe oben.
Zugegeben, die meisten Portscanner erzeugen heute die Pakete selbst. Trotzdem muss das Tool sich merken, wo es schon gescannt hat. Das verbraucht Speicher. Wenn ich ein Netz von mehreren zehntausend Rechnern abscanne ist das sehr signifikant. Nochmal zugegeben, das kann man auf state-less optimieren, aber welcher Programmier(anfäng)er kann mit sowas schon korrekt umgehen (man schaue sich nur mal die hunderte von kaputten Webpräsenzen an).
Es hilft natürchlich nix gegen die Kits die direkt nach den Diensten suchen, die ich offen habe. Aber da ich ein anerkanntes Arschloch bin freut es mich schon, dass der Angreifer für mehrere Minuten nicht weiss (Windows benutzt TTL=128), ob etwas (von mir nicht benutztes) bei mir offen ist. ;-)
Abgesehen davon: warum zum Henker soll ich auf einem Port mit RST antworten, wenn ich dort gar nicht reden will? Wozu Traffic verschwenden?
Konrad
am Sat, dem 10.04.2004, um 14:17:23 +0200 mailte Konrad Rosenbaum folgendes:
Wie waere es damit: *nicht auf Ping reagieren (ca. 50% aller Attacken beginnen mit einem Ping-Scan)
Krass Unsichtbar, gell? Erinnert an ZoneAlarm und Norton InSecurity, Stealth-Mode. Was soll das bringen?
Das hat bei mir 50% der Attacken auf Apache reduziert und damit den Traffic verringert. Das ist nur EINE Maßnahme. Die Liste war nicht als "oder", sondern als "und" gemeint.
Nun, statistische Untersuchungen habe ich damit noch nicht gemacht, muß aber sagen, daß mein Eindruck ist, daß vielleicht 80% der Scans von verwirrten Wintendows auf 135/TCP reinkommt. Dicht gefolgt von den Filesharen.
Abgesehen davon: warum zum Henker soll ich auf einem Port mit RST antworten, wenn ich dort gar nicht reden will? Wozu Traffic verschwenden?
DROP ist kein Security-Mittel, kann aber sinnvoll sein, wenn man z.B. ISDN hat und Dial-on-Demand macht. In Verbindung mit einem Patch hilft es mir bei etlichen Installationen, echte Kosten zu sparen. Ansonsten gebe ich ein höfliches 'Leck mich am Arsch' mittels RST zurück ;-)
Andreas
Am Sat den 10 Apr 2004 um 02:17:23PM +0200 schrieb Konrad Rosenbaum:
On Saturday 10 April 2004 11:27, Andreas Kretschmer wrote:
am Sat, dem 10.04.2004, um 11:05:37 +0200 mailte Konrad Rosenbaum
Wie waere es damit: *nicht auf Ping reagieren (ca. 50% aller Attacken beginnen mit einem Ping-Scan)
Krass Unsichtbar, gell? Erinnert an ZoneAlarm und Norton InSecurity, Stealth-Mode. Was soll das bringen?
Das hat bei mir 50% der Attacken auf Apache reduziert und damit den Traffic verringert. Das ist nur EINE Maßnahme. Die Liste war nicht als "oder", sondern als "und" gemeint.
Was sind das denn für Attacken, die auf den Apachen abzielen? Ich hatte für ne Weile auch mal Pings abgestellt. Letztlich tut man sich damit aber keinen großen Gefallen, da man dadurch eh nicht unsichtbar wird.
*Alle unbenutzten Ports reagieren gar nicht (der Angreifer belegt in diesem Fall haufenweise Ressourcen auf seinem Rechner, da er die Timeouts abwarten muss/will)
Gerade bei dialup Verbindungen ist das blöd. Wenn z.B. vor dir ein Filesharing Benutzer die IP hatte, wirst du u.U. über einen langen Zeitraum mit Anfragen zugeschüttet, was sich durch einen RST leicht beheben lassen könnte.
<schnipp>
Abgesehen davon: warum zum Henker soll ich auf einem Port mit RST antworten, wenn ich dort gar nicht reden will? Wozu Traffic verschwenden?
s.o., weil diese Ersparnis wahrscheinlich gar nicht eintritt. Außerdem könnte man ja auch ein Limit für RST's mitgeben, damit erreichst du beides - Irrläufer über ihren Fehler informieren und dich selbst vor sinnlosen Antworten auf Scans bewahren.
Tschau,
andre
On Saturday 10 April 2004 16:07, Andre Schulze wrote:
Was sind das denn für Attacken, die auf den Apachen abzielen? Ich hatte für ne Weile auch mal Pings abgestellt. Letztlich tut man sich damit aber keinen großen Gefallen, da man dadurch eh nicht unsichtbar wird.
Welche, die einen IIS vermuten... ;-)
*Alle unbenutzten Ports reagieren gar nicht (der Angreifer belegt in diesem Fall haufenweise Ressourcen auf seinem Rechner, da er die Timeouts abwarten muss/will)
Gerade bei dialup Verbindungen ist das blöd. Wenn z.B. vor dir ein Filesharing Benutzer die IP hatte, wirst du u.U. über einen langen Zeitraum mit Anfragen zugeschüttet, was sich durch einen RST leicht beheben lassen könnte.
Abgesehen davon, dass Filesharing UDP verwendet. RST ist TCP. UDP sendet höchstens ein ICMP Port Unreachable.
Abgesehen davon: warum zum Henker soll ich auf einem Port mit RST antworten, wenn ich dort gar nicht reden will? Wozu Traffic verschwenden?
s.o., weil diese Ersparnis wahrscheinlich gar nicht eintritt. Außerdem könnte man ja auch ein Limit für RST's mitgeben, damit erreichst du beides - Irrläufer über ihren Fehler informieren und dich selbst vor sinnlosen Antworten auf Scans bewahren.
Limits? Was genau meinst Du? Das klingt eher nach einem IDS als einer IPTables Regel.
Konrad
am Sat, dem 10.04.2004, um 18:13:53 +0200 mailte Konrad Rosenbaum folgendes:
s.o., weil diese Ersparnis wahrscheinlich gar nicht eintritt. Außerdem könnte man ja auch ein Limit für RST's mitgeben, damit erreichst du beides - Irrläufer über ihren Fehler informieren und dich selbst vor sinnlosen Antworten auf Scans bewahren.
Limits? Was genau meinst Du? Das klingt eher nach einem IDS als einer IPTables Regel.
man iptables /limit
Lesen bildet ;-)
Andreas
lug-dd@mailman.schlittermann.de
-
Andre Schulze -
Andreas Kretschmer -
Konrad Rosenbaum -
Martin -
Martin Knechtel
-
Martin Knechtel