Viren, Spyware, Datenschutz 11.214 Themen, 94.192 Beiträge

Hackerproblem im LAN

Shinji Ikari / 49 Antworten / Flachansicht Nickles

Hi!


Ich bin mit meinem Rechner in einem Lokalem Netzwerk und benutze die freeversion von der outpost firewall. Und meine Firewall blockt sehr viel Angriffe(portscanns/verbindungsversuche). Dabei hat es jemand wahrscheinlich durch einen Fehler von mir Zugriff auf meinem Rechner zu bekommen, denn ich hatte ausversehen eine Verbindung für scheinbar ie erlaubt. Und ein paar Stunden später hat sich jemand bei mir beschwer, dass ich bei ihm Portscans machen würde, was defintiv nicht ich seien kann, weil ich solche Progs nicht auf dem Rechner habe. Mein Fehler, der wahrscheinlich dazu führte wurde mir auch erst etwas später bewusst, als ich den rechner schon wieder runtergefahren hatte, aber outpost hatte am nächsten tag die anwendung iexplorer zweimal aufgeführt, einmal den "richtige" und einmal die falsche freigabe von mir. Dummerweise habe ich die sofort gelöscht, damit der nicht eventuell wieder sowas macht. Kann ich jetzt im Nachhinein noch irgendwie nachvollziehen, was genau der auf meinem Rechner gemacht hat???Denn der portscann war bestimmt nicht das einzige...


Und wie bekomme ich mein System vielleicht noch sicherer, denn nach pro stunde blockt outpost mindestens 3.000 "angriffe". Gibt es vielleicht auch Programme, mit denen man offene ports blockt/schliesst??


Denn ich hab auf dem Pc auchnoch das Problem, dass mir mIRC mit Invision bei dem localen portcheck, der bei jedem start gemacht wird, u.a. den prot 3456 als offen angibt. Aber weder Norton antivirus noch TrojanHunter haben etwas auf meinem PC entdeckt. Die Angabe von mIRC muss eigentlich richtig sein, denn auf meinem zweiten rechner(der nicht im Netzwerk ist) zeigt mir mIRC diesen Port nicht an.


 


Wie sollte ich eurer Meinung nach meinen Sachen noch absichern, damit mir in dem Netzwerk nicht wieder sowas passiert???


 


Ich hoffe ihr könnt mir wenigstens teilweise weiterhelfen :)

bei Antwort benachrichtigen
FULL ACK -IRON-
Rika xafford „ich hab jetzt lange überlegt, ob ich auf dieses posting noch antworten soll,...“
Optionen

Oh Mann, das artet langsam aus... Mache mal jemand in das Forum einen Zugriffscounter rein :-)

Ob's nun Fachtermini sind oder nicht, wenn ich annehmen muss, dass der Leser es nicht ohne weiteres versteht, erkläre ich es eben. Wenn der Leser sich dann näher mit der Sache auseinandersetzt, nutzt er früher oder später dann auch diese Termini...
Und wenn, dann drücke ich mich weniger falsch als viel mehr undeutlich aus... So viel dazu.

Das mit dem Tunneln ist doch ganz normal. Ich selbst tunnele PPP durch's Ethernet... Aber jetzt mal zu dieser Sache: Schon mal 'nen Linux-Kernel kompiliert? (Was für 'ne Frage...) Jede handelübliche Distri bietet dir beim make config die einzenlen Module an. Typischerweise auch das IP-Tunneling, der zugehörige Hilfetext lautet "Häufigste Anwendung ist das IP-durch-IP-Tunneling. Hört sich merkwürdig an, macht aber durchaus Sinn: ...." 'Ne gute Alternative zu PF/NAT, leider unterstützt T-Online es nicht. Was dir der große Bill über sein BS auch nicht erzählt hat: Obwohl es absolut keinen Sinn macht, unterstützen sämtliche Windowse ab 95 intern dem Empfang von IP und IGMP durch IP getunnelt. Und da hört für mich der Spass auch langsam auf: Diese Scheisse kann man leider nicht abstellen, noch kann mir irgendeiner erklären, warum's nicht ganz normal über RIP kommt. (Naja, der Bill denkt sich, RIP braucht keiner, deshalb ist der RIP-Dienst von Win2K/XP ja auch der fastletzte Dreck...)

Zu Punkt 2: Win9x/ME verträgt nicht viel, höchstens einige 100. WinNT macht etwa 500 mit, Win2K/XP vertragen mehrere 1000. Linux macht per Default 1024, aber man kann's auch auf 65535 hochschrauben. NIS hält etwa unter Win2K/XP 500 noch für angemessen, bei Win9X/ME lässt es maximal 200 zu. Und mit 'm FileSharing gibt's eigentlich kein Problem: Außer für dem Verbindungsaufbau zum einem Server wird ausschließlich UDP verwendet, und Connections bestehen dann in aller Regel auf einem TCP-ähnlichen Mechanismus, der auf UDP aufsetzt (naja, warum einfach, wenn's auch umständlich geht...)

Und das mit dem API-Zugriff ist doch ganz normal: Der eingeschränkte Benutzer kann ja nicht mal den ASPI-Layer direkt nutzen - es werden halt keine Geräte erkannt (mit NT-Bordmitteln kann man ja nicht mal 'ne Gruppe erstellen, die den Zugriff hat, hier braucht man Tools wie Nero BurnRights). Ebenso kann man keinen Speicher locken, keine SYS/VXD-Treiber laden, dass TAPI ist gesperrt usw.; man kann also zwar versuchen, Raw Sockets zu erstellen, aber bekommt nur Fehlermeldungen. Ebenso kann halt kein Trojaner einen eigenen Stack laden - der Stack müsste als Treiber implementiert werden, aber Treiberladen ist halt verboten...

Das mit den AOl-Proxies ist übrigens kein Argument... Die lassen wirklich jeden Scheiss durch.

bei Antwort benachrichtigen