Portscan erkannt?

    • Larloch
      Larloch
      Bronze
      Dabei seit: 26.12.2006 Beiträge: 1.339
      Hallo Leute,

      krieg seit paar Stunden dauernd Nachrichten von bitdefender, dass er irgendwelche portscans erkannt hat und geblockt. kommt immer hin und wieder vor, aber heute isses krass oft.

      was ist das eigentlich und muss ich mir sorgen machen? =)
  • 26 Antworten
    • Kilania
      Kilania
      Bronze
      Dabei seit: 23.04.2007 Beiträge: 7.880
      Original von Larloch
      Hallo Leute,

      krieg seit paar Stunden dauernd Nachrichten von bitdefender, dass er irgendwelche portscans erkannt hat und geblockt. kommt immer hin und wieder vor, aber heute isses krass oft.

      was ist das eigentlich und muss ich mir sorgen machen? =)
      Es gibt einige Programme welche nur über spezielle Ports kommunizieren können. z.B. ein FTP Server über Port 21.
      Damit ein FTP Server also laufen könnte, müsstest du Port 21 freigeben - deiner Firewall sagen: "Port 21 darf hier rein"

      Ein Portscan tut im Prinzip nichts anderes als rauszufinden ob deine Firewall eben manche Ports zulässt.
      Falls es kein Fehlalarm ist, ist dies sicherlich nicht sondern positiv

      Ein Portscan kann z.B. gemacht werden um evt. Schwächen von einem System zu finden oder freie Ports für div. böse Tools. Aber will dir ja keine Angst machen - war nur ein Beispiel. Aber falls das wirklich wer an dir macht ists schon bedenklich.
    • Petathebest
      Petathebest
      Bronze
      Dabei seit: 22.02.2006 Beiträge: 2.634
      Ist ganz normal. Jeder PC wird andauernd auf freie Ports gescannt. Da hilft nur ein Router, der den Ping nicht beantwortet.
    • DB120
      DB120
      Bronze
      Dabei seit: 22.09.2007 Beiträge: 25
      ICMP Echo Replies ausmachen in Windows.
    • Apfelbuch
      Apfelbuch
      Bronze
      Dabei seit: 21.05.2007 Beiträge: 448
      Diese Standardmeldungen werden von Personal-"Firewalls" in wohl zufälliger Zeit und in dramatisierter Form ausgegeben, um dem User das Gefühl zu geben, er würde die Software unbedingt brauchen und muss sie auf jeden Fall weiter bezahlen.

      Unverstellbar, was passiert wäre, wenn deine Firewall diesen heimtückischen "Portscanversuch" (was ich bezweifle) nicht geblockt hätte!

      Und an die ICMP-Hasser: Security through obscurity ist ungefähr so, wie die Haustür unverändert zu lassen, aber in der Farbe der Mauer zu streichen.
    • DB120
      DB120
      Bronze
      Dabei seit: 22.09.2007 Beiträge: 25
      Das sind aber mehr oder weniger nur einfache TCP-Scans von Bots, die dann meistens gleich ganze Subnets abscannen. Du bist nur einer von vielen Tausend. Ausserdem werden die sicherlich keine Stealth-Methoden verwenden, zumal du es nicht merken würdest und zweitens dauert diese Art von Scan viel zu lange und sie ist völlig ungeeignet für mulitple scans. Einfache connect() TCP-Scans kann man mit dem ausschalten von ICMP-Replies beseitigen. Je nachdem, ob der Threadersteller potenziell gefährliche offene Ports hat, die er dann so verstecken würde, kann man wohl noch zusätzlich von "Security through obscurity" sprechen.
    • Larloch
      Larloch
      Bronze
      Dabei seit: 26.12.2006 Beiträge: 1.339
      hatte gerade nen merkwürdige bluescreen message, dann abstutz, nun waren alle cookies weg

      will da jemand das ich meine pw's überall neu eingebe?


      [ja, ich benutze cookies, allerdings nur auf irgendwelchen internetforum mit billigen passwörtern, wo 0 schaden entsehen kann]


      hab mir jedenfalls mal dieses keylogger shield aus dem andren fred geholt

      tjatja, die panik :D
    • pokersille
      pokersille
      Bronze
      Dabei seit: 28.01.2008 Beiträge: 565
      Original von DB120
      Das sind aber mehr oder weniger nur einfache TCP-Scans von Bots, die dann meistens gleich ganze Subnets abscannen. Du bist nur einer von vielen Tausend. Ausserdem werden die sicherlich keine Stealth-Methoden verwenden, zumal du es nicht merken würdest und zweitens dauert diese Art von Scan viel zu lange und sie ist völlig ungeeignet für mulitple scans. Einfache connect() TCP-Scans kann man mit dem ausschalten von ICMP-Replies beseitigen. Je nachdem, ob der Threadersteller potenziell gefährliche offene Ports hat, die er dann so verstecken würde, kann man wohl noch zusätzlich von "Security through obscurity" sprechen.
      Erklär mir mal genau, was stealth-metohden sein sollen, die man nich als scan erkennt. afaik geht das nicht. nen zombiescan sieht für victim genauso aus wie nen normaler scan, nur dass man nicht die ip des eigentlichen scanners bekommt. und fin, xmas oder nullscan ist auch erkennbar. weiss nur net ob jede firewall das kann.
      Und zu dem statement mit den connect()-scans (die nur absolute scriptkiddies machen), würd ich behaupten, du hast dich grad gelevelt. denk mal drüber nach und erklär mir, was es da bringen soll icmp-replies zu deaktivieren.
      in nem it-forum hätt ich jetzt ne neue signatur.
    • DB120
      DB120
      Bronze
      Dabei seit: 22.09.2007 Beiträge: 25
      Original von pokersille
      Original von DB120
      Das sind aber mehr oder weniger nur einfache TCP-Scans von Bots, die dann meistens gleich ganze Subnets abscannen. Du bist nur einer von vielen Tausend. Ausserdem werden die sicherlich keine Stealth-Methoden verwenden, zumal du es nicht merken würdest und zweitens dauert diese Art von Scan viel zu lange und sie ist völlig ungeeignet für mulitple scans. Einfache connect() TCP-Scans kann man mit dem ausschalten von ICMP-Replies beseitigen. Je nachdem, ob der Threadersteller potenziell gefährliche offene Ports hat, die er dann so verstecken würde, kann man wohl noch zusätzlich von "Security through obscurity" sprechen.
      Erklär mir mal genau, was stealth-metohden sein sollen, die man nich als scan erkennt. afaik geht das nicht. nen zombiescan sieht für victim genauso aus wie nen normaler scan, nur dass man nicht die ip des eigentlichen scanners bekommt. und fin, xmas oder nullscan ist auch erkennbar. weiss nur net ob jede firewall das kann.
      Und zu dem statement mit den connect()-scans (die nur absolute scriptkiddies machen), würd ich behaupten, du hast dich grad gelevelt. denk mal drüber nach und erklär mir, was es da bringen soll icmp-replies zu deaktivieren.
      in nem it-forum hätt ich jetzt ne neue signatur.

      Ohh man. Ich bräuchte Stunden um alles zu erklären, mit all dem Halbwissen aufzuräumen. Bist du zufällig Informatikstudent?


      Erklär mir mal genau, was stealth-metohden sein sollen, die man nich als scan erkennt.

      One problem, from the perspective of the attacker attempting to scan a port, is that services listening on these ports log scans. They see an incoming connection, but no data, so an error is logged. There exist a number of stealth scan techniques to avoid this. A stealth scan is a kind of scan that is designed to go undetected by auditing tools.

      Obviously, this is a race between the hacker and firewall vendors - what are considered stealth scans now may not be so in a few months once the firewall vendor becomes aware of such techniques.
      Angespannte Stimmung? Gegenfrage: Bist du ein Skript-Kiddie mit Halbwissen?


      Und zu dem statement mit den connect()-scans (die nur absolute scriptkiddies machen), würd ich behaupten, du hast dich grad gelevelt.
      Das ist einfach nur Non Sequitur.



      denk mal drüber nach und erklär mir, was es da bringen soll icmp-replies zu deaktivieren. in nem it-forum hätt ich jetzt ne neue signatur.
      Du weißt schon das ICMP ein Protokoll ist? Dein Host gibt keine Response mehr auf Requests. (Port-Is-Unreachable, usw). Such dir mal jemand auf deinem Level. Und wenn du gleich dabei bist mich zu Flamen, dann schau dir noch gleich mein alten SRC an. Findest sicher paar Fehler. (klick)
    • TheSmile
      TheSmile
      Bronze
      Dabei seit: 16.03.2007 Beiträge: 893
      eins zu null für DB
    • pokersille
      pokersille
      Bronze
      Dabei seit: 28.01.2008 Beiträge: 565
      Original von DB120
      One problem, from the perspective of the attacker attempting to scan a port, is that services listening on these ports log scans. They see an incoming connection, but no data, so an error is logged. There exist a number of stealth scan techniques to avoid this. A stealth scan is a kind of scan that is designed to go undetected by auditing tools.

      Obviously, this is a race between the hacker and firewall vendors - what are considered stealth scans now may not be so in a few months once the firewall vendor becomes aware of such techniques.
      Ich denk mal du meinst mit stealth-scans xmas,fin und co. Die sind aber definitiv detectable. Ich weiß halt nicht, ob homefirewalls das machen. Aber es ist möglich.

      Und ja, ich weiß was icmp ist. Aber die muss man nicht zwangsweise in nem portscanner auswerten. entweder es kommt nen ack vorm timeout oder halt nicht. that's the way it goes.
    • Pokerboydd
      Pokerboydd
      Bronze
      Dabei seit: 03.05.2007 Beiträge: 1.813
      Original von pokersille
      entweder es kommt nen ack vorm timeout oder halt nicht. that's the way it goes.
      Eben nicht zwangsläufig.

      Zudem fallen unter "Stealth" nicht nur Art und Reihenfolge der TCP Pakete, sondern z.B. auch Zeitabstände etc...

      Wenn eine Firewall (hier dann wohl eher schon ein Intrusion Detection System) ein einziges SYN an einen Port x, auf welches hernach kein ACK folgt, als Portscan bezeichnet, dann isses ziemlich schlecht. Aber wieviele Pakete pro Zeiteinheit meldet man nun als Scan?

      Im allg. halte ich von Portscans nichts, das ist wie Klingelschilder lesen, und imho völlig legitim. Die FIrewalls die ich administriere loggen verworfene Pakete nichtmal.

      Was mich eher wundert: warum bekommt OP Portscans? Gibt es noch Leute die nicht hinter nem NAT device sitzen? Oder spielt jmd im LAN?
    • pokersille
      pokersille
      Bronze
      Dabei seit: 28.01.2008 Beiträge: 565
      Naja, das mit dem völlig legitim ist in der rechtsprechung auch nicht mehr ganz so. Ich halte scans aber auch für legitim. wie soll man denn sonst socks-proxies u.ä. finden?

      Aber warum ich von nem offenem port keinen ack bekommen soll, versteh ich schonwieder nicht. angenommen der laufende dienst hat keinen adressfilter. aus welchem grund, ausser netzüberlastung, soll da kein ack kommen?

      Zu den stealth-methoden würde ich sagen, dass es definitv richtig ist, dass homefirewalls da nicht viel erkennen. ich wollte eher betonen, dass es theoretisch möglich ist ne layer4-firewall zu basteln, die fragmented scans und was es da sonst noch so gibt erkennt. ich weiss leider nicht genau, was in ids davon umgesetzt wird. aber ich denk mal scans sind da eh weniger interessant. ich glaub heutzutage entsteht der größte wirtschaftliche schaden durch ddos-angriffe, von irgendwelchen botnets, gegen die man ohnehin schwer was machen kann.
    • Pokerboydd
      Pokerboydd
      Bronze
      Dabei seit: 03.05.2007 Beiträge: 1.813
      Bei nem offenen Port hast du recht, da kommt ein ACK, ich sprach eher von closed Ports. Da dropt entweder jemand das Paket (d.h. kein ACK und damit Timeout) oder es gibt ein sauberes Reject (ICMP Port unrechable)...

      Ich glaube das ist aber ein Unterschied den Homefirewalls nicht kennen.
    • pokersille
      pokersille
      Bronze
      Dabei seit: 28.01.2008 Beiträge: 565
      Jetzt bin ich völlig verwirrt. Auf nen syn würde ich niemals nen icmp erwarten. eher ack (bei offenen) oder rst bzw. timeout (bei geschlossenen). ich spreche hier die ganze zeit von tcp-scans. die icmp's sollten meiner meinung nach nur bei udp eine rolle spieln. das ist ja genau der punkt, den ich vorher kritisiert hab, dass icmp mit connect-scans und syn-scans nix zu tun hat. Aber es gibt ja hier im Forum noch einen, der mehr weiß als wir alle zusammen. Wär nett, wenn er sich auch nochmal dazu äußern würde. Wird er aber wahrscheinlich nicht machen, weil er ja der Meinung ist, dass wir nicht auf seinem level sind.

      Hab's jetzt auch mal im wireshark angeschaut, weil ihr mich so verunsichert habt. es kommt rst! timeout wär sicherlich auch noch ne möglichkeit, sollte aber eher selten sein.
    • Pokerboydd
      Pokerboydd
      Bronze
      Dabei seit: 03.05.2007 Beiträge: 1.813
      Mein fehler, bei einem TCP ist es natürlich kein ICMP port unreachable sondern ein RST.
    • DB120
      DB120
      Bronze
      Dabei seit: 22.09.2007 Beiträge: 25

      Aber es gibt ja hier im Forum noch einen, der mehr weiß als wir alle zusammen. Wär nett, wenn er sich auch nochmal dazu äußern würde. Wird er aber wahrscheinlich nicht machen, weil er ja der Meinung ist, dass wir nicht auf seinem level sind.
      Du bezeichnest mich fiktiv als Skript-Kiddie, behauptest meine Aussagen sind Müll, indem du Teile davon in deine Signatur packen willst. *rolleyes*
      Ausserdem war das kein Plural.


      ich spreche hier die ganze zeit von tcp-scans. die icmp's sollten meiner meinung nach nur bei udp eine rolle spieln.
      ICMP is im eigentlichen Sinne kein eigenes Protokoll, sondern eher ein Helper bzw. Bestandteil des IP-Protokolls. Es dient zum Austausch von Fehler- und Informationsmeldungen bei IP-, TCP- und UDP-Protokollen.


      Original von pokersille
      Jetzt bin ich völlig verwirrt. Auf nen syn würde ich niemals nen icmp erwarten. eher ack (bei offenen) oder rst bzw. timeout (bei geschlossenen).
      Wenn der Port gefiltert ist, dann gibt es ein Timeout oder vermutlich die Fehlerhafte ICMP "Destination unreachable" Message. Bei einem ACK-Paket ist das zumindestens der Fall.


      EDIT: Vielleicht war das auch ein Missverständnis. (Weil der erste Text nicht sonderlich gut formuliert war). Jetzt hast du mich natürlich schon geflamed und die ruhige Diskussion zerstört. Find ich persönlich schade, aber naja was solls.
    • pokersille
      pokersille
      Bronze
      Dabei seit: 28.01.2008 Beiträge: 565
      Ok, dann werd ich mal versuchen mit Missverständnissen aufzuräumen und wieder ne anständige Diskussion aus dem Thread zu machen.

      Ich werd mal versuchen die wichtigsten Aussagen zusammenzufassen.

      Du sagtest implizit, dass das Abschalten von ICMP-replies TCP-scanns erschwert. Diese Aussage halte ich in der Tat für Müll. Aber sowas kann jedem mal passieren. Du bist sicher der Ansicht, dass ich dir dafür noch ne Erklärung schuldig bin. Also fang ich mal von ganz vorne an.
      Beispiel ganz simpler syn-scan:
      Erstmal sendet der scanner nen syn. Wenn er hier an einen geschlossen Port sendet, kommt ein rst zurück oder es kommt ein timeout, falls da irgendwas gefiltert wird. Das icmp, was du meinst (typ = 03h, code = 03h -> Port unreachable) ist ausschließlich für UDP-Pakete, die nicht zugestellt werden können. Beim offenen Port kommt halt nen ack.
      Wenn jemand viele Rechner scannt, wird er vorher meist nen Ping an den zu scannenden Rechner senden. Da spielt ICMP natürlich wieder ne Rolle (typ = 8, code = 0 -> echo request), aber das hat ja nix mit dem eigentlichen scan zu tun.

      Wenn's dagegen noch Einwände gibt, dikutier ich natürlich gerne anständig weiter.


      Achso, kleine Anmerkung noch zum aktuellen Post. ICMP kann nicht bestandteil von IP sein. ICMP wird über IP versendet. Und für TCP wird auch kein ICMP gebraucht, höchstens indirekt. ICMP ist helper für IP und hilft bei TCP, da TCP über IP versendet wird.
    • DB120
      DB120
      Bronze
      Dabei seit: 22.09.2007 Beiträge: 25

      Du sagtest implizit, dass das Abschalten von ICMP-replies TCP-scanns erschwert. Diese Aussage halte ich in der Tat für Müll. Aber sowas kann jedem mal passieren.
      Technisch gesehen wird natürlich nichts verändert oder erschwert. Normal wird halt eine normale (Echo)-Anfrage gemacht (PING) bevor die eigentliche Aktion erfolgt. Wenn der Zombie keine Antwort bekommt, dann springt er zum nächsten potenziellen Target weiter. Wie würdest du es den bezeichnen?


      Beispiel ganz simpler syn-scan:
      Erstmal sendet der scanner nen syn. Wenn er hier an einen geschlossen Port sendet, kommt ein rst zurück oder es kommt ein timeout, falls da irgendwas gefiltert wird.
      Das stimmt nicht ganz. ACK/SYN kommt wenn der Port offen ist. RST, wenn er non-listening ist. ICMP unreachable oder ein Timeout, wenn er gefiltert ist. Du verwechelst das sicher mit dem Reset-Paket bei geschlossenen TCP-Ports.



      Das icmp, was du meinst (typ = 03h, code = 03h -> Port unreachable) ist ausschließlich für UDP-Pakete, die nicht zugestellt werden können. Beim offenen Port kommt halt nen ack.
      Im endeffekt ist es egal, ob ein TCP-Reset-Paket oder ein Port Unreachable kommt. Und ja, wenn der Port gefiltert ist, dann spielt ICMP eine Rolle, weil du dann ein Timeout oder Destination Unreachable bekommst. Darum sollte man diese Message nicht abschalten, da du sonst immer auf ein Timeout warten musst. RST, wenn der Port nicht gefiltert ist.


      Wenn jemand viele Rechner scannt, wird er vorher meist nen Ping an den zu scannenden Rechner senden. Da spielt ICMP natürlich wieder ne Rolle (typ = 8, code = 0 -> echo request), aber das hat ja nix mit dem eigentlichen scan zu tun.
      Das gehört halt zu dem Scan Vorgang dazu. Sicherlich kann man auch force scannen aber will man sich darüber jetzt streiten?


      Achso, kleine Anmerkung noch zum aktuellen Post. ICMP kann nicht bestandteil von IP sein. ICMP wird über IP versendet. Und für TCP wird auch kein ICMP gebraucht, höchstens indirekt. ICMP ist helper für IP und hilft bei TCP, da TCP über IP versendet wird.
      Das Internet Control Message Protocol (ICMP) ist Bestandteil des Internet Protocols (IP). Es wird aber als eigenständiges Protokoll behandelt, das zur Übermittlung von Meldungen (z. B. bei Fehlern) über IP dient.
    • pokersille
      pokersille
      Bronze
      Dabei seit: 28.01.2008 Beiträge: 565
      Ok, gehn wir das ganze mal durch.

      Du zählst also den initialen Ping zum scan. Ok, dann ist deine Aussage nicht ganz falsch, aber missverständlich. Über das was danch kommt sind wir uns offensichtlich einig. Ich bin nicht der Meinung, dass der immer gemacht werden muss. Oft sucht man nur nach einem Dienst und da hat das keinen Sinn. Ich bring da mal ein Beispiel, was ich vor ner Weile häufiger gemacht hab. Bei meine ISP sind vor einiger Zeit mehr oder weniger regemäßig die DNS abgeschmiert. Da ich aber noch die Adresse von nem Klasse B Netz im Kopf hab, wo es einen DNS gibt, hab ich dann das Netz nach TCP-53 gescannt. Bei sowas lässt man natürlich den ping vorher weg, weil der länger dauert, als der eigentliche syn-scan.
      Beim Zombiescan, ist es allgemein sinnlos nen ICMP-echo zu machen. Ich bräucht mir ja nicht die Mühe machen nen Zombiescan zu machen, wenn ich vorher dann doch meine IP hinschicke. Nen Zombiescan ohnehin nur geeignet, falls man einen bekannten Rechner scannt. Und von dem sollte man schon wissen, dass er on ist.
      Ich sollte an dieser Stelle evtl mal. klarstellen, was ich unter nem Zombiescan (auch Idlescan) verstehe: Der Scanner sendet einen Syn an den Zombie, der Zombie, sendet ein ,syn/ack. Aus dem IP-Header des syn/ack wird nun die IPID gespeichert. Nun sendet der Scanner ein syn an Victim, setzt dabei aber in den IP-Header die Adresse von Zombie als source ein. Victim sendet jetzt bei geschlossenem Port ein RST an Zombie, oder bei offenem Port ein syn/ack, was den Zombie dzu veranlasst ein rst an victim zu senden. Nun sendet scanner wieder ein syn an zombie und fragt somit die neue IPID ab. Ist die IPID um 2 größer, war der port mit hoher Wahrscheinlichkeit offen, ist sie um 1 größer war er mit hoher Wahrscheinlichkeit geschlossen. ist die noch größer, muss man den ganzen spaß nochmal machen, weil zombie dann noch anderen traffic hatte, der den scan behindert hat. In der Praxis wird's dadurch sehr langsam. Der Vorteil eines solchen scans besteht halt darin, dass die IP des Scanners nicht bei Victim ankommt und den würde man zunichte machen, wenn man vorher nen icmp-echorequest an Victim sendet. Ein weiteres Problem ist, dass das Timing äußerst schwierig ist und man keine exakten Aussagen bekommt.

      nächster punkt:
      Ja, selbstverständlich sind beim offenen Port syn- und ack-flag gestetzt. Hab ich nen bissel schludrig geschrieben.
      RST ist erstmal standard bei ports ohne dienst, hab's getestet. bei irgendwelchen rechnern mit firewalls sollte ein anständiger scanner nicht zwingend auf ein icmp warten, sondern selbst nen timeout machen. Ich zweifle eigentlich daran, dass bei tcp-scans überhaupt nen icmp ausgelöst werden kann. Proof it! Mach nen wiresharkscreenshot, oder noch besser mach nen testsystem und poste die ip, damit man selbst testen kann. Ich kann's leider aus Hardwaremangel nicht machen.

      Naja, ICMP als Bestandteil von IP zu bezeichnen find ich nicht so toll. Ich seh's als eigenständiges (mini)Protokoll über IP. Es wir schließlich im Datenfeld von IP versandt. Sonst könnt ich ja auch behaupten TCP oder UDP wäre Bestandteil von IP, oder IP bestandteil von Ethernet oder Token Ring, was auch irgendwie schwachsinnig ist. Die Gemeinsamkeit ist halt, dass sie auf dem gleichen Layer liegen und IP ohne ICMP nen bisschen störungsanfällig wäre.

      Ich find's aber toll, dass wir doch noch ne anständige Diskussion zustande bekommen haben.
    • 1
    • 2