PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Firewall auf nem Router. Andere PC's sicher ?



MatzeG2002
19.01.03, 14:10
Hallo liebes Forum,

ich habe mal ne Frage zu "Firewall auf Router".
Ich habe Mandrake 9.0 auf meinem Router und die Shorewall laufen.
Mein workstation-PC geht über diesen Router ins Netz.

Jetzt meine Frage: Wie sicher ist mein PC im internen Netzwerk ?

Ich habe schon bei verschiedenen Online-Scannern die Sicherheit überprüfen lassen.
Es wird dann immer die IP meines Routers angezeigt, heißt das, das mein workstation PC von außen
gar nicht sichtbar ist ? Diese Scanner sagen immer das alles sicher ist. Kann man das glauben ?

Sorry, ich weiß schon unzählige Threads in diesem Forum, aber ich habe das ganze noch nicht so ganz verstanden.
Darf ich euch mal mein Firewallscript posten damit ihr es anschaut ?
Ich bin irgendwie misstrauisch, da ich mit Linux erst seit kurzem ins Netz gehe. :(

Danke schonmal.

Gruß Matze

PS : Eigentlich will ich nur: http, https, pop, smtp, ftp, icq, internet radio(xmms). :eek:

HangLoose
19.01.03, 15:50
moin moin


Ich habe schon bei verschiedenen Online-Scannern die Sicherheit überprüfen lassen. Es wird dann immer die IP meines Routers angezeigt, heißt das, das mein workstation PC von außen gar nicht sichtbar ist ? Diese Scanner sagen immer das alles sicher ist. Kann man das glauben ?

vom internet aus gesehen, sieht es so aus als wenn alle *anfragen* von deinem router kommen. stichwort masquerading => die pakete die von deiner workstation kommen, werden quasi maskiert mit der öffentlichen ip vom router, da ein webserver (im inet) mit der internen ip deiner workstation nichts anfangen kann und du nur eine öffentliche ip besitzt. von daher ist deine workstation in gewissem sinne schon unsichtbar.


Jetzt meine Frage: Wie sicher ist mein PC im internen Netzwerk ?

das kommt auf die einstellungen deiner firewall/paketfilters an, sowie auf die richtige konfiguration etwaiger dienste, die du anbietest.
als beispiel, du hast auf deiner workstation eine webserver laufen, der vom inet aus erreichbar ist. wenn dieser webserver jetzt schlecht konfiguriert ist oder du hast vergessen ein security patch einzuspielen, dann ist ein angriff schon möglich.
angenommen es gibt für deinen webserver einen exploid, der es einem angreifer erlaubt root rechte zu erlangen, dann hast du ein problem ;). der angreifer kam dann nämlich ganz *legal* durch deinen paketfilter/firewall <= zugriffe vom inet aus auf den webserver sind ja erlaubt.


anderes beispiel => du hast deinen paketfilter so *eingestellt*, das aus dem lan heraus jegliche verbindung erlaubt ist. rein darf dagegen nur, was zu einer von innen gestarteten verbindung gehört. wenn du dir jetzt einen trojaner einfängst, der von sich aus eine verbindung ins inet aufbaut, so wird diese vom paketfilter ohne weiteres *durchgelassen*


Gruß HL

MatzeG2002
19.01.03, 16:38
Hi Hangloose,

also Dienste biete ich nicht an. ( Mail, Web oder sonstige Server.)


anderes beispiel => du hast deinen paketfilter so *eingestellt*, das aus dem lan heraus jegliche verbindung erlaubt ist. rein darf dagegen nur, was zu einer von innen gestarteten verbindung gehört. wenn du dir jetzt einen trojaner einfängst, der von sich aus eine verbindung ins inet aufbaut, so wird diese vom paketfilter ohne weiteres *durchgelassen*
Wie finde ich das heraus ? Habe die Shorewall unter Mandrake laufen.
Habe unter "drakconf" -> "Firewall" alles deaktiviert. ( Kein ssh, kein apache gar nichts kann von außen benutzt werden.)
Aber wie richtet "drakconf" --> "Internetverbindung teilen" die Firewall für interne PC's ein ?
Haben die freie Hand nach "draußen" ?

Danke für deine Hilfe.

Gruß Matze

HangLoose
19.01.03, 18:28
hi


Wie finde ich das heraus ? Habe die Shorewall unter Mandrake laufen.

ich kenne mich mit der shorewall nicht aus. im prinzip ist die shorewall aber nichts anderes, wie eine gui für iptables, denke ich zumindest. das heißt, die angaben die du machst, werden in entsprechende iptables rules umgesetzt.

mit iptables -L kannst du dir die rules anzeigen lassen und mit iptables-save > rules.txt werden die regeln ins file rules.txt geschrieben.


Habe unter "drakconf" -> "Firewall" alles deaktiviert. ( Kein ssh, kein apache gar nichts kann von außen benutzt werden.)

wie gesagt, kenne mich mit der shorewall nicht aus. beispiel 1 dürfte aber bei dir dann nicht möglich sein.


Aber wie richtet "drakconf" --> "Internetverbindung teilen" die Firewall für interne PC's ein ? Haben die freie Hand nach "draußen" ?

ich denke ja. es wird wohl von innen alles erlaubt sein.


Gruß HL

MatzeG2002
19.01.03, 18:41
Danke HL,

hast du mir vieleicht ein paar iptables-Rules die es dem internen Netz verbieten
Packete zu senden die nicht erlaubt sind ?
In die Shorewall einbauen bekomm ich dann hin.

Gruß Matze

HangLoose
19.01.03, 19:01
hi


hast du mir vieleicht ein paar iptables-Rules die es dem internen Netz verbieten Packete zu senden die nicht erlaubt sind ?

das wäre imho der falsche weg. man verbietet nicht einzelne sachen, sondern man verbietet erstmal alles, um anschließend die sachen die man benötigt *freizugeben*. andernfalls besteht die gefahr, das man etwas übersehen hat.

ich muss hier aber mal was klarstellen. wenn du deinen gesunden menschenverstand einsetzt, wozu zum beispiel prüfen der md5 summen oder kein installieren von software aus *obskuren* quellen zählt etc., bist du eigentlich auf der sicheren seite.

ausserdem solltest du dir die doku zur shorewall mal genau ansehen. bei der susefirewall ist es zum beispiel möglich auch den zugriff von innen einzuschränken. ich denke, das sollte bei der shorewall auch möglich sein.

wenn nicht würde ich dir vorschlagen, kauf dir ein buch über iptables und erstelle dein eigenes script ;) auf folgender seite findest du auch einen guten einstieg in das thema => http://www.linux-user.de/ausgabe/2002/05/030-firewall/firewall-4.html


Gruß HL

MatzeG2002
19.01.03, 19:04
Ok ich werde es mir merken. :(
Danke

Gruß Matze

fatality
27.02.03, 15:14
Um nochmal auf die Sache mit dem Trojaner zurück zu kommen..

Ich hab bei mir Suse 8.1 mit der SuseFirewall2 installiert!
Die Firewall ist auch so eingestellt, das sie jeglichen Zugriff von innen erlaubt, also aus dem Lan. Wenn ich mir jetzt einen Trojaner einfangen würde und dieser sendet Daten ins Internet z.b die Ip, kann der "Angreifer" dann einfach zu zu mir über einen port connecten (wie z.b in SubSeven), der nicht am Router für die Ausenwelt freigegeben ist ???

Das "einzige" was dir in diesem Fall passieren kann ist doch eigentlich "nur" , daß irgendwelche empfindlichen Daten wie Passwörter usw rausgeschickt werden, aber deinen rechner kann er so doch nicht übernehmen oder ?

gruß fatality

HangLoose
27.02.03, 15:44
hi

das kommt drauf an wie *clever* dieser trojaner ist. so ohne weiteres kann er keinen port *aufmachen* und dort lauschen.

um mal bei subseven zu bleiben. der lauscht z.b am port 6711, welcher normalerweise von deiner firewall geblockt sein dürfte. damit würde eine verbindungsanfrage natürlich scheitern. es gibt aber auch trojaner, die an priviligierten ports lauschen können. nehmen wir mal an der trojaner lauscht an port 80 und du hast einen webserver, der vom inet erreichbar ist. somit würde deine firewall anfragen durchlassen. allerdings braucht der trojaner imho root-rechte dafür, wobei ich mir nicht sicher bin, ob es überhaupt möglich ist, das 2 dienste auf ein und demselben port lauschen. ganz so einfach ist es also nicht.

ps: wenn ich müll gepostet habe, bitte verbessern


Gruß HL

fatality
27.02.03, 15:51
Ich werde den zugriff vom internen Netz wohl doch lieber auf bestimmt Dienste beschränken..


Danke

gruß fatality

linuxhanz
28.02.03, 13:39
Wie sicher ist mein PC im internen Netzwerk ?


Wenn was durchkommt bleibt immer ein Restrisiko.
Und solche Meldungen: linux kernel: user before screen is a security problem





das kommt drauf an wie *clever* dieser trojaner ist. so ohne weiteres kann er keinen port *aufmachen* und dort lauschen.

Genau um ein Port zu öffnen braucht ein Trojaner Root Rechte
Um ein RAW-Socket aufzumachen ebenfalls. btw. braucht es IMMER ? ein RAW
Socket um eine Verbindung zu öffnen?




dafür, wobei ich mir nicht sicher bin, ob es überhaupt möglich ist, das 2 dienste auf ein und demselben port lauschen. ganz so einfach ist es also nicht.



Der müsste clever sein. Ein Webserver der ab und zu Anfragen beantwortet und dann
alles ab nach

cytrox
28.02.03, 15:50
Original geschrieben von fatality

Die Firewall ist auch so eingestellt, das sie jeglichen Zugriff von innen erlaubt, also aus dem Lan. Wenn ich mir jetzt einen Trojaner einfangen würde und dieser sendet Daten ins Internet z.b die Ip, kann der "Angreifer" dann einfach zu zu mir über einen port connecten (wie z.b in SubSeven), der nicht am Router für die Ausenwelt freigegeben ist ???

Das "einzige" was dir in diesem Fall passieren kann ist doch eigentlich "nur" , daß irgendwelche empfindlichen Daten wie Passwörter usw rausgeschickt werden, aber deinen rechner kann er so doch nicht übernehmen oder ?


Doch, denn der Paketfilter verbietet ja nicht, das überhaupt Pakete von aussen nach innen geschickt werden können (sonst könntest du überhaupt keine TCP Protokolle mehr verwenden, also auch nicht mehr surfen usw.), sondern nur, dass keine SYN's mehr von aussen durchgelassen werden, also von aussen keine Verbindung aufgebaut werden kann, nur noch von innen.
Pakete von aussen, die zu einer von innen initiierten Verbindung gehören (bei iptables mit "-m state --state ESTABLISHED,RELATED") werden durchgelassen.
Also können solche Paketfilerregeln nur verhindern, dass ein Trojaner an einem Port auf Verbindungen von aussen lauscht, aber gegen welche, die selbst von innen Kontakt zu einem Rechner im Internet aufbauen, sind sie machtlos.
Man kann die Gefahr zwar einschränken, indem man von innen nicht alles durchlässt, sondern nur Packete an
bestimmete Rechner/Ports, zum Beispiel destination port 25 wird nur für den Mail Server zugelassen, usw, aber wenn der Trojaner als destination port 80 verwendet, ist man auch machtlos, denn diesen port kann man nciht auf bestimmete Rechner begrenzen, wenn man normal surfen will.
Dem könnte man dann wiederum mit einem Application Level Gateway beikommen, das alle TCP Sessions mit einem Destionation Port 80 auf Protokollebene unersucht, und alles sperrt, was nicht nach "normalem" http aussieht, aber dass könnte man dann wieder umgehen, indem man SSL vewendet, denn wenn der Traffic verschlüsselt ist, kann er auch nicht untersucht werden, muss aber durchgelassen werden, da viele Seiten nun mal SSL verwenden.
Man könnte auch nur bestimmten Programmen erlauben, einen Socket mit destination Port 80 zu öffnen (geht mit vielen Linux Kernelsecurity Patches, z.B. Medusa DS9), so dass nur noch der Webbrowser auf diesen Port nach aussen kommt, aber nicht mehr ein Trojaner, aber auch dass könnte dann sicher umgangen werden, und so weiter..

Kurz gesagt, 100%ige Sicherheit kann man nie erreichen, aber man kann zumindest die Gefahren einschränken, und die Schranken für einen Angreifer höher legen.

Gruss, cytrox

linuxhanz
28.02.03, 15:56
und alles sperrt, was nicht nach "normalem" http aussieht


Das kann z.B. Snort mit der Option http_decode_port_80 in Snort.conf



# http_decode: normalize HTTP requests
# ------------------------------------
# http_decode normalizes HTTP requests from remote
# machines by converting any %XX character
# substitutions to their ASCII equivalent. This is
# very useful for doing things like defeating hostile
# attackers trying to stealth themselves from IDSs by
# mixing these substitutions in with the request.
# Specify the port numbers you want it to analyze as arguments.
#
# Major code cleanups thanks to rfp
#
# unicode - normalize unicode
# iis_alt_unicode - %u encoding from iis
# double_encode - alert on possible double encodings
# iis_flip_slash - normalize \ as /
# full_whitespace - treat \t as whitespace ( for apache )
#
# for that GID:
# SID Event description
# ----- -------------------
# 1 UNICODE attack
# 2 NULL byte attack

preprocessor http_decode: 80 unicode iis_alt_unicode double_encode iis_flip_slash full_whitespace

# rpc_decode: normalize RPC traffic
#






trotzdem Wenn Port 80 besetzt ist __KANN__ theoretisch der troj da doch nicht lauschen?

Harry
28.02.03, 16:05
Original geschrieben von linuxhanz
Genau um ein Port zu öffnen braucht ein Trojaner Root Rechte
Das gilt nur für die privilegierten Ports (also bis einschließlich 1023). Für die Reservierung/Aktivierung der anderen Ports (1024-65535) benötigt man keine root-Rechte.

Harry

linuxhanz
28.02.03, 16:08
man lernt nie aus :)

Hier noch ein Link wegen Snort:


http://online.securityfocus.com/archive/96/250781/2002-01-14/2002-01-20/0

Man kann damit nämlich VIELE Daten erzeugen. Bei Strich A tippe ich mal auf
ALL.




2. snort -A fast -l ./log -d -i eth2 -c ./snort.conf (for 1 minute)
> -generated ~1600 alerts of which 99% were ICMP Dest. Unreachables. The
other >1% were Bad Traffic (loopback source address). There is much web,
dns, scans >and other stuff in this traffic.
> "Snort analyzed 762866 out of 1110037 packets, dropping 347171 (31.276%)
>packets."
> -This was with the default ruleset (884 rules).

cytrox
28.02.03, 18:08
Original geschrieben von linuxhanz

trotzdem Wenn Port 80 besetzt ist __KANN__ theoretisch der troj da doch nicht lauschen?

Nur mit Root-Rechten, per RAW/PACKET-Socket, per LKM, das sich in den Netzwerk-Code des Kernels einklinkt, oder ganz einfach indem der ganze Apache durch einen mit Backdoor ersetzt wird.

Aber ich meinte nicht einen Trojaner, der auf dem übernommenen System einen Server Socket auf Port 80 öffnet, sondern einen, der als Client einen anderen Rechner im Internet auf Port 80 kontaktet, und dagegen sind Packetfilter ohne Protokol-Inspektion machtlos, sofern surfen erlaubt ist.

http_decode von snort normalisiert nur http requests an WebServer, um bestimmte Methoden, ein IDS bei einem Angriff auf einen Webserver auszutricksen, unmöglich zu machen. Siehe hierzu z.B. hier (http://www.wiretrip.net/rfp/pages/whitepapers/whiskerids.html).

Gruss, cytrox

linuxhanz
01.03.03, 13:57
Ok als client ja.

Das whisper ist ja schon fast kriminell. (bezieht sich bes. auf die scandbs)
Demnächst brauchen wir gar keine Skriptkiddies mehr, weil die Skripte alles
allein machen.

Schade ich dachte Snort würde ALLES was nach http-Verkehr auschaut
dekodieren. Aber es steht ja deutlich 80 da. *grummel*