Firewall, Antivier ?!

S

Strizh

0
Hallo,
ich hätte da mal eine grundsätzlich Frage. Ich habe eine sehr kleine Anwendung geschrieben (Client) die ausgeführt einfach das Verzeichnis ausließt und es anschließend an mich (Server) zuschickt per Internet. Nun macht die Anwendung nix böses an sich. Aber grundsätzlich hätte ich auch Daten auslesen und weiter schicken können und eig. alles mögliche machen.

Nun frage ich mich wie das mit der Firewall überhaupt ist, die reagiert auf ausgehende Verbindungen ja überhaupt nicht? Und Antivir Software würde das Prog. auch nicht erkennen.

Also scheint das ganze eig. problemlos zu funktionieren? Ab welchem Punkt oder wann würde diese Anwendung erkannt werden ?

Gruß
 
Also sofern Du nicht über bestimmte Ports sendest, würdest Du bei einigen meiner Systeme Probleme bekommen was zu verschicken.
Die Firewall kann auch Verbindungen aus dem internen Netz blockieren.

Was die Antiviren-Software angeht. Die analysiert nicht nur nach bekannten Viren, sondern auch nach bestimmten Mustern im Code. Ich bin da ehrlich gesagt nicht so tief drin in der Materie, da ich von Antiviren-Software nur wenig halte, aber hier sind schon einige Beiträge in denen gut erklärt wurde wie die Antiviren-Software mit bestimmten heuristischen Verfahren auch "unbekannte" Viren und Trojaner finden kann.
Erklärt dann auch warum manchmal alte Spiele von mir als Viren erkannt werden ;)
 
Danke für die Antwort, inwiefern würde ich Probleme bei deinem System kriegen?
Sind die Ports für ausgehende Verbindungen gesperrt?
Weiß einer wieso diese dann per default normalerweise offen sind?

Gruß
 
Zuletzt bearbeitet:
In meinem Fall sind nur bestimmte Ports für ausgehende Verbindungen von einigen Systemen offen.

Per Default ist eigentlich immer alles zu.

Ich weiß nun nicht mit welchen Firewalls Du getestet hast. Die Firewalls in den meisten privaten Routern sind so eingestellt, dass sie ausgehende Verbindungen nicht blocken, da man den Endnutzern nicht zutraut (vermutlich zurecht) zu entscheiden welche Ports sie benötigen und welche nicht.
 
Liaf hat gesagt.:
Die Firewalls in den meisten privaten Routern sind so eingestellt, dass sie ausgehende Verbindungen nicht blocken, da man den Endnutzern nicht zutraut (vermutlich zurecht) zu entscheiden welche Ports sie benötigen und welche nicht.
Zum Vergrößern anklicken....

Sie sind wohl eher so eingestellt, weil ausgehende Ports zumeist dynamisch vom System zugeteilt werden und nicht von der Applikation oder dem User.

Allerdings fragen die meisten Firewalls für Desktop-Systeme den User, ob er ausgehende Verbindungen eines bestimmten Programms zulassen will, wenn dieses das erste Mal gestartet wird. Auch manche Antiviren-Tools haben ähnliche Funktionalitäten. Aber theoretisch ist eines ausgehende Verbindung nicht als Angriffsversuch zu betrachten, zumindest nicht auf einem Desktop-System, das in Verbindung mit dem Internet verwendet wird.
 
Bei Firewalls gibt es für die Verbindung vom internen Netzwerk in ein Externes eigentlich zwei Ansätze.
  • All deny
  • All open/access
Die meisten Router mit Firewall setzen hier auf all open, weil es für den Enduser einfacher ist, wenn er sich nicht darum kümmern muss einzelne Ports zu öffnen. Von Firmen eingesetzte Firewalls setzen im Normalfall auf All deny. Hier werden dann explizit die benötigten Ports und Protokolle geschalten.

Auf meiner IPFire sind auch nur die Ports offen, die ich benötige. Hat etwas gedauert, bis alle benötigten Ports gefunden und geöffnet wurden, aber jetzt läuft das ganze wie am Schnürchen.
 
bitmuncher hat gesagt.:
Sie sind wohl eher so eingestellt, weil ausgehende Ports zumeist dynamisch vom System zugeteilt werden und nicht von der Applikation oder dem User.
Zum Vergrößern anklicken....

Kommt ganz darauf an worauf die ausgehenden Verbindungen geprüft werden.
Bei mir werden die Zielports geprüft. Also zum Beispiel lasse ich nur Port 80 und 443 als Zielport zu. Da spielt der Port den das System im internen Netz wählt weniger eine Rolle ;)
 
Ich sprach ja auch von ausgehenden Verbindungen und nicht von ausgehenden Ports.

Ich hätte vielleicht genauer sagen sollen welche Ports ich meine.
 
Für ausgehende Verbindungen werden normalerweise irgendwelche hohen Ports gewählt.

Und hier bin ich nicht sicher:
Können nicht mehrere ausgehende Verbindungen den gleichen Port benutzen?
Zb. Port 80 ?
 
Liaf hat gesagt.:
Also zum Beispiel lasse ich nur Port 80 und 443 als Zielport zu. Da spielt der Port den das System im internen Netz wählt weniger eine Rolle ;)
Zum Vergrößern anklicken....
Zumindest die "Low-Budget"[0] - Malwarevariationen (Stealer/Bots) setzen schon seit Jahren auf Webpanels (sicherer als FTP Upload und problemloser/sicherer als Mailversand) ;)

[0] da bei Malware leider die Bezeichnung nicht beigefügt wird, lässt sich bei den üblichen "ihre_rechnung.pdf.exe" nicht sagen, ob es sich um "Profi" oder "Kinder"-Bots handelt. Aber auch hier wird oft versucht, Daten über HTTP zu übermitteln oder nachzuladen.
 
Jo, das war auch nicht so gemeint, dass man damit sicher wäre ;)
Ich kontrolliere hier auch nicht alles. Ich habe nur zwei Systeme deren ausgehende Verbindungen gefiltert werden und bei denen sind nicht Port 80 und 443 erlaubt ;) das war mehr ein Beispiel, dass Firewalls nicht immer alles von Intern nach Extern erlauben.
 
Darüber hinaus kann man ja als C&C-Server auf Port 80 oder 443 jeden Service anbieten, den man möchte. Es muss ja kein http/https sein.
Da bräuchte man schon Deep-Packet-Inspection, was bei TLS verschlüsselten Verbindungen schwierig wird, denn die kann man wie https aussehen lassen.

Ausgehende Verbindungen werden meist deshalb standardmäßig erlaubt, weil auf einem durschnittlichen Desktop-System alles mögliche ins Internet verbindet.
Es gibt ja diese aufgeblasenen HIPS-Systeme (Outpost Firewall, Zonealarm,..) da kommen dann ständig Popups um nachzufragen ob die Verbindung in Ordnung ist und der durchschnittliche Benutzer ist bei den meisten Meldungen einfach überfragt.
Wenn dann zum Beispiel der Network-Location-Awareness Service von Windows ins Internet verbinden will und der User hat erst einmal keine Ahnung was das sein soll und blockt diesen Dienst, dann wundert er sich hinterher warum der WLAN-Connection-Manager meldet, dass die Verbindung ins Internet fehlgeschlagen ist, obwohl das tadellos funktioniert.
 
Testing levels - www.matousec.com (auch wenn die Seite nicht unabhängig ist - die Tests sind recht nett, zahlreich und open source ).
Die Seite gibt es im übrigen schon seit Jahren, ebenso die Testsuite ;)

Und viele "Entscheidungen", bestimmten Traffik durchzulassen sind afaik auch "by design" so - z.B Durchlassen von DNS Queries KIS Fails DNSTester - Kaspersky Lab Forum oder WebDav-Traffik bei KIS (und vielen anderen).
"by design" heißt, dass man z.B in seinem Programm über UNC-Pfad "servername\myfile" Dateien öffnet und diese Anfragen vom System über Webdav-Mini-Redirector aka "WebClient"-Dienst umgeleitet/umgesetzt werden. Die Verbindung "nach Außen" geht also von einem Windows-Dienst aus - diese(n) per Default zu sperren kann den Nutzer leicht verärgern/das System unbrauchbar machen, daher lässt man es ;).
Die WebDav-"Lücke" kenne ich z.B seit 2006 und nutze sie, um ab und zu xrayn mit seinem KIS-Kult zu ärgern ;). Beim letzten Test (vor 1-1.5 Jahren) gingen WebDav-Anfragen immer noch durch KIS, Comodo und Outpost durch (andere nicht getestet).
Aber psst - das sind Dinge, die gar nicht in das "mit uns sind Sie absolut sicher" Werbekonzept der Schlangenöl "Sicherheit"-Verkäufer passen :)
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben