Logischer Standort Firewall?

#16 Falls du mit der PFW nur die Programme auf ihre echtheit überprüfen willst
versuchs doch mal hiermit http://maxcomputing.narod.ru/ssme.html

Eine andere möglichkeit wäre die Benutzerrechte so einzurichten das nur Winrout
oder was du auch immer brauchst gestartet werden kann
__________
°<- Vorsicht Trollköder und Trollfalle -> {_}

#17 Jetzt habe ich ein wunderschönes Bildchen gezeichnet (.jpg-Format), um das Ganze mal etwas deutlicher darzustellen und kann es hier nicht einbinden.
Wer kann mir da mal schnell helfen, damit wir diese Diskussion auf einer Basis weiterführen können?

rebooter

#18 So, durch die nette Hilfe von Robert kann ich nun mangels eigenem Webspace das Bild doch zum Vorschein bringen:



So sieht meine Vorstellung des Router- bzw. Gateawy-Rechners mit installierten Server-Applikationen und Firewall Tiny PF 2 und WinRoute 4.2 aus. Bei dem logischen Standort der Tiny PF2 bin ich mir da nicht so sicher, der Standort des WinRoute jedoch stimmt (alleine schon laut Beschreibung des Teils).

Gibt es dazu irgendwelche Anmerkungen in Bezug auf die Sinnhaftigkeit? Man bedenke, dass hier also ein Packet-Filter über WinRoute für jeden Adapter einzeln und ein Application- Filter auf Betriebssystem-Protokoll-Ebene zum Einsatz kommt.

Oder stimmen die Abfolgen der Datenwege vielleicht ganz und gar nicht?
(was ich zu bezweifeln wage, jedoch: nobody's perfect )

Bin gespannt auf eure Antworten.

Bis dahin

rebooter

#19 Ich denke, dass Tiny bzw. KerioFW zumindest teilweise noch vor WinRoute sitzt (und vor dem TCP/IP-Stack sowieso, oder?) Jedenfalls werden bei mir die WinRoute'schen DNS-Anfragen und der Proxy-Verkehr von der Kerio kontrolliert.
Nur der NAT-Verkehr läuft komplett an Kerio vorbei, sofern man "is running on gateway" aktiviert hat. Andernfalls blockt Kerio die NAT-Antworten als "Ack packet attack"... (dies war bei Tiny noch anders, da sie diese "Angriffsform" nicht kannte.)
__________
"Scheinsicherheit" - wie leicht lassen sich Viren- und Trojanerscanner austricksen?

#20 @forge77:

Zitate aus der WinRoute-Doku:

"WinRoute arbeitet unterhalb des TCP-Stack auf der IPSec-Ebene. Mit anderen Worten, es fängt ausgehende und eingehende Pakete ab, BEVOR sie auf Ihren Computer gelangen können."

"WinRoute "umschliesst" NDIS auf spezifische Weise, so dass der gesamte TCP/IP-Verkehr vom Treiber der Netzwerkkarte auf die Engine umgeleitet wird, bevor er zum Datenstapel (Stack) für die Netzwerkkommunikation des eigentlichen Betriebssystems gelangt."

Eine Zeichnung aus der Doku (sieht bescheiden aus, ich weiss. Aber man kann es erkennen!?):

------------------------------------------------
| WinRoute (Proxy, Mail, DNS, DHCP-Server) |
------------------------------------------------
| windows sockets |
------------------------------------------------
| TCP/IP Protocol |
------------------------------------------------
| WinRoute inspection module |
| (anti-spoofing, packet filter, NAT) |
------------------------------------------------
| network | | WAN | | ... |
| adapter | | subsystem | | ... |
| driver | --------------- | ... |
------------ |modem | ISDN | | ... |
| network | ---------------- ----
| adapter |
------------

Die Tiny PF kann also nicht vor WinRoute sitzen; es sei denn, sie wäre ein Netzwerkkarten-Treiber oder das Interface selbst. Sollte Tiny PF auf der gleichen Ebene sitzen wie WinRoute, dann gäbe es große Probleme beim gleichzeitigen Einsatz der beiden Software-Stücke.
Genau danach hatte ich Dich eigentlich gefragt, als Du meintest, dass bei Dir beide auf dem gleichen Rechner laufen.

Die Tiny PF soll ja als Application Filter funktionieren. Daher läuft dieses Stück Software (wenn ich da nicht etwas ganz falsch verstanden habe) auf der Anwendungsschicht des ISO/OSI-Schichtenmodells; nämlich dort, wo auch die Anwendungen selber laufen wie z.B. eMail-, Proxy-, Fax- und Web-Server.

Ob die Tiny PF dann vor, hinter, oder sogar auf gleicher Ebene mit dem TCP/IP-Stack läuft ist genau das was ich wissen will (siehe Titel des Threads: Logischer Standort Firewall?). Daran schließen sich somit zwei (nein... drei!)Fragen an:
1. verhält sich die Firewall in Bezug auf ihren logischen Standort unterschiedlich?
2. was passiert, wenn ich sie (angenommen, sie läuft als reiner Application filter auf oberster ISO/OSI-Schicht) AUCH als Paketfilter konfiguriere (ich brauche dafür doch nur eine einzige Rule im PacketFilter zu erstellen, oder?): rutscht sie dann INSGESAMT in den Schichten nach unten oder ist diese Software so arrangiert, das vercshiedene Teile auf verschiedenen Schichten laufen können?
3. was bedeutet eigentlich die Option "running on gateway" genau unter Beachtung des Schichtenmodells? Was ändert sich damit?

Ja, ich weiss: haufenweise Fragen, ratloses Kopfschütteln allerorten. Oder vielleicht nicht; wo ist der Wissende unter uns "try-and-fail"-Genies?

Erneut verschärften Dank für eure rege Teilnahme und die Bereitschaft, sich den Kopf zu zerbrechen.

rebooter

P.S.:
Kann es vielleicht sein, dass die Tiny PF wirklich auf gleicher Ebene wie WinRoute's Paketfilter läuft (siehe "Bildchen" oben)? Dann bräuchte man doch die WinRoute-Geschichte eigentlich gar nicht, oder? Es müsste sich dann nur herausfinden lassen, wie man von Tiny PF aus BEIDE Netzwerkkarten getrennt abhandeln kann.

#21 Das Bild aus der WinRoute-Hilfe passt doch mit meinen o.g. Erfahrungen gut zusammen: Der NAT-Verkehr läuft an Tiny/Kerio vorbei, aber nicht der WinRoute-Proxy- und -DNS-Verkehr.
Also liegt Tiny/Kerio _zwischen_ den beiden WinRoute-"Teilen" (genau: zwischen TCP/IP-Stack und NAT-WinRoute.)
OK, das sind nur Spekulationen... ich hab nicht wirklich viel Ahnung davon...

Zu "running on gateway": ich glaube, bei der Tiny konnte man auch ohne diese Option einen Router/Gateway betreiben. Erst das o.g. Problem ("Ack Packet Attack") macht die Option in der Kerio wirklich notwendig.

Den Paketfilter von WinRoute habe ich überhaupt nicht konfiguriert, da ich auf allen Clients eine Application-Firewall habe. Imho macht der Paketfilter in einem Heimnetzwerk auch nicht viel Sinn.

Benötigst du WinRoute eigentlich als (Soft-)Router? Oder was waren deine genauen Beweggründe?
__________
"Scheinsicherheit" - wie leicht lassen sich Viren- und Trojanerscanner austricksen?

#22 Ich brauche eigentlich einen Packet Filter und einen Application Filter. Der Packet Filter holt alles an Netzwerkverkehr raus, das nicht zugelassen ist (Rules für Heimat-IPs, RAS-IPs und entsprechende Ports der Anwendung), und zwar sowohl für den inneren Verkehr (es könnte ja doch irgendwas im Netz hausen, das da nicht hingehört und will heimtelefonieren) als auch für den äußeren (damit die bösen Jungs draussen bleiben müssen).
Nun läuft die Sache erstmal auf IP-Basis und Portbasis.

Da es aber möglich ict, von aussen eine IP vorzutäuschen, die im inneren Netz vorhanden ist (Spoofing) sollte auch dieser täuschende Verkehr draussen bleiben bzw. im Netz gar nicht erst existieren. Daher möcht ich die Application Filter-Eigenschaft zusätzlich nutzen, um zu gewährleisten, dass nur die zugelassenen Anwendungen auch mit der zugelassenen IP und dem entsprechenden Port Netzwerktraffic erzeugen können.
Sollte also ein Trojaner im Inhouse-Netz z.B. einen Mailserver vortäuschen, so wird über die MD5-Signatur des Application Filter festgestellt: nö, der darf nicht!

Und zu allem Überfluss wird die ganze Geschichte trotzdem noch von einem recht guten Intrusion Detector gemeldet (weil ich keinen Bock drauf habe, ständig Anfragen der Firewall zu beantworten; daher stelle ich die Rules ein und der ganze Rest ist eben gesperrt). So weiss ich also was los ist und kann was unternehmen.

Damit ich dann sagen kann: jetzt ist es perfekt (ich weiss: 100% gibt es nicht... nee, schon klar ) kommt auf jede Maschine im LAN ein guter Virenscanner, der zusätzlich auch den Internet- und Mail-Verkehr auf der Maschine selbst prüft.

Dann bleibt nur noch das Problem mit dem Tunneling.
Das kriege ich zwar nicht in den Griff, habe aber ausgeschlossen, das da irgendwas Großartiges passieren kann.

So, jetzt habe ich 'nen Plan. Und bei der Ausführung kommt dann das Problem, das Du ganz oben lesen kannst:

Logischer Standort Firewall?

Denn ich kann an allen Softwareteilen einstellen was ich will: wenn der Verkehr daran vorbei läuft, dann ist die ganze Sache taub und ich falle genau auf die Tücke rein, vor der auch hier im Board immer gewarnt wird (zurecht):
Falsche Sicherheit durch falsche Konfiguration!
(siehe alleine schon den Thread "Sygate doch die beste Firewall!!!"; zeigt doch, wie blauäugig die meisten an das Thema rangehen, oder?)

Es nutzt wohl alles nix:
Ich muss mir die ganze Sch...-Doku von Tiny PF2 (oder auch 4?) und WinRoute in Englisch reinziehen. Angefangen habe ich ja schon (und zwar reichlich!), aber ich glaube, dass ich ohne meine ganzen TCP/IP-Bücher und Troubleshooting Network-Guides usw. blablabla doch nicht weiterkomme. Und wer weiss, ob ich es damit wirklich komplett rauskriege. Sieht jedenfalls schlecht aus.

Wahrscheinlich will keiner, das so ein Spezialistenwissen an die "Normalos" weitergegeben wird, sonst würden wir ja alle den - trotz enormer Konjunkturschwäche in dieser Branche (wieder fünf Entlassungen in unserem Laden im letzten Monat ) -hochbezahlten Spezialisten das Wasser abgraben.

Mal sehen:
Murphy hat bestimmt auch dazu was Passendes zu bieten.

rebooter

P.S.: schreibe übrigens schon seit vier Stunden den gesamten Verkehr im Netz, auch den von außerhalb mit, um vielleicht durch reines "Probieren" an die Lösung zu kommen.
Hat jemand Erfahrungen oder ein gutes Tool (für umme) zur nachher nötigen Analyse des Trace? Sonst wirds echt mühselig, mehrere tausend Pakete auseinanderzudröseln.

#23 Genau für solche Anforderungen wurden sogenannte Stateful-Inspection-Firewalls ( http://www.different-thinking.de/sif.php ) entwickelt. Da wird eben erkannt, daß der Verkehr den ein Trojaner auf Port 25 verursacht kein SMTP-Traffic ist und somit gesperrt wird.

Es ist auch immer die Frage wann die PFW gestartet wird. Je später während des Systemstarts, desto schlechter, Normalerweise sollte nach dem Laden des TCP/IP Stacks und noch vor allen Netzgeräten der PFW Dienst gestartet werden.

Noch was: eine PFW ist kein Applicationsfilter - es ist ein Paketfilter, der pro Anwendung konfiguriert wird - und nicht pro Netzwerkdevice. Ein Aplikationsfiler ist eine SIF!

R.
__________
powered by http://different-thinking.de - Netze, Protokolle, Sicherheit, ...

#24

Zitat

Noch was: eine PFW ist kein Applicationsfilter - es ist ein Paketfilter, der pro Anwendung konfiguriert wird

Ja,genau, deshalb verstehe ich auch nicht so ganz, warum du überhaupt einen weiteren Paketfilter (neben Tiny/Kerio) einrichten willst, rebooter.
Homephoning und (outbound) Trojaner z.B. kannst du, wenn überhaupt, nur durch eine App.-FW (vielleicht auch SIF) stoppen, aber nicht durch einen Paketfilter.
Nochmal zur Kombo WinRoute+Tiny: WinRoute verhindert durch NAT, dass ungewollte Severdienste (z.B. Backdoor-Trojaner) von außen angesprochen werden können. Außerdem würden das zusätzlich die auf den Netzwerk-Clients installierten Tiny's verhindern (doppelt hält besser... )
Gegen ungewollten Outbound-Verkehr von innerhalb des Netzwerks (Homephoning, Trojaner) helfen, wenn überhaupt, nur Tiny's auf den Clients.
Der WinRoute-Paketfilter ist hier imho nutzlos, weil Homphone/Trojaner sowieso Port 80 nehmen würden.

Aber vielleicht willst du auf deinen Netzwerk-Clients gar keine Tiny's installieren? Dann wirds problematisch...
__________
"Scheinsicherheit" - wie leicht lassen sich Viren- und Trojanerscanner austricksen?

#25 @forge77:
Die Tiny PF sitzt genau an der selben Stelle wie WinRoute... auf niedrigster Ebene! Das sehe ich jetzt erst, nachdem ich die Doku schon zig Mal gelesen, aber dabei wohl doch nur überflogen habe .

@Robert:
Danke für Deinen Hinweis.
Nachdem ich mich nun auf der von Dir angegebenen Seite schlau gemacht habe (ist die nicht sogar von Dir?), kann ich Folgendes ausführen:
Grundsätzlich ist die Stateful Inspection Firewall (SIF) doch dazu gedacht, den Traffic ins und vom an den Router angeschlossene(n) LAN zu überwachen und entsprechend der Regeln zu filtern. Das wäre für mich gut, um das Tunneling zu unterbinden (siehe Antwort an forge77, die lange zuletzt ).

In meinem Anwendungsfall hat kein Netzwerkteilnehmer direkt mit dem Internet zu tun. Alles läuft über entsprechende Software-Server (daher bin ich mir mit den Ausdrücken "Gateway" und "Router" auch nicht so sicher in Bezug auf den skizzierten Rechner, der als eierlegende Wollmilchsau im Netz steht):

http und ftp:
Es läuft ein Proxy-Server, der diese beiden Protokolle durchleitet.
Vielleicht werden die auch noch getrennt, sodass es wieder ein neues Stück Software braucht

SMTP und POP3:
Das geht über den eigenständigen Mailserver, der sich auch auf der Gateway-Maschine befindet (ich nenne sie jetzt einfach so; glaub' das haut hin).

Fax:
Brauche ich wohl nicht viel zu sagen, oder? Läuft auch auf dem Gateway...

Webserver:
Apache oder IIS 5 ? Das ist noch nicht klar, ansonsten gibt es von dort keinen Traffic ins LAN, sondern nur ins bzw. aus dem WAN.

RAS-Einwahl:
SICHERHEITSLOCH in Bezug auf die obigen Ausführungen!
Da läuft die Zugriffskontrolle ja nun mal ganz anders: der Traffic wird nicht von innen (sprich: LAN) initiiert wie z.B. beim http-Proxy, sondern muss von aussen kommen und auf ganz anderer Ebene zugelassen werden (Authentifizierung über PAP, CHAP, MS-CHAP, IPSec (vielleicht kommt doch noch ein VPN, probiert wird's auf jeden Fall irgendwann)). Nach dieser dusseligen Authentifizierung kommt dann wieder der Firewall-Krempel ins Spiel: darf der Verkehr auch durch das Gateway? usw.
Hier ist der Ansatzpunkt für meine Überlegungen mit WinRoute zu sehen, weil WinRoute in der Lage ist, für beide Netzwerkkarten getrennt(!) Rules zu verwalten und zu verarbeiten.
Rückruf wird nicht verwendet, da sich die Nummern dauernd ändern. Und wenn ich die Remoteänderung der Rückrufnummer zulasse, kann ich auch gleich ohne Rückruf vom RAS-Server arbeiten, ausserdem kommt es wesentlich billiger.

Jetzt zu meinem Ausdrucksfehler (der es hoffentlich nur ist):
Es handelt sich bei der Tiny PF2 natürlich nicht um eine Application Firewall im Sinne der Verwandtschaft mit einer SIF. Vielmehr geht es mir um den MD5-Fingerprint, den die Tiny von allen Anwendungen nehmen kann, die LOKAL auf dem Gateway laufen. Und das sind ja die einzigen Instanzen im Netzwerk, die Connect zum Internet haben können. Alle Rechner im LAN haben weder Modems noch ist irgendsowas Krankes wie ICS installiert. Dadurch will ich sicherstellen, dass nur die auf dem Gateway laufenden Applikationen zum Internet kontaktieren können und damit auch nur diese überwacht werden müssen.

Wenn ich das jetzt alles so zusammenzähle, bekomme ich bei der Rechnung
1 + 1 = ? eine 2 heraus. Oder ist es doch irgendwas Krummes wie zweieinhalb oder so?

Mein Problem stellt sich eigentlich nach wie vor nur in folgender Frage dar:
Wo steht die Firewall logisch?
Ich kann das auch umformulieren:
Wo gibt es eine Software, die sowohl auf unterster Ebene als Paketfilter und auf oberer Ebene als MD5-Fingerprint-Filter arbeitet?
Denn mit der Lösung WinRoute und TinyPF2 bin ich noch nicht so glücklich, weil die beide nebeneinander laufen müssten (im Layer betrachtet).

I need help!

Mit den grössten Hoffnungen und einem dicken Dankeschön (ich habe trotzdem so einiges gelernt!):

rebooter

#26 Warum brauchst du einen MD5 check du installierst einfach nur vertauenswürdrige Sachen auf der Gateway und nur das allernötigste.
Dann brauchst du keine Personal Firewall mehr.
Wenn du dein System per Md5 auf Änderung überprüfen willst, würde ich ein anderes spezielles Tool dafür benutzen. Das z.B. täglich alle Daten auf veränderung scannt
__________
°<- Vorsicht Trollköder und Trollfalle -> {_}

#27 @forge77:
Sorry, habe wohl zu lange geschrieben und daher nicht mitbekommen, das da schon wieder ein Beitrag ist.

Zuerst mal will ich auf allen LAN-Clients keine zusätzliche FW haben. Es langt grade, wenn auf dem Gateway die Konfiguration immer schön brav im Auge behalten werden muss.

Dann will ich eigentlich auch NAT nicht verwenden. Das Problem mit den IPs, die aus dem LAN ins Internet kontaktieren, habe ich mit den Proxys bereits erschlagen; aus dem Proxy kommt ja nur die Gateway-Adresse als anfragende Adresse ins Internet.

Die Kombi Tiny PF2 / WinRoute will ich nur aus den im vorigen Beitrag genannten Gründen einsetzen:
1. Paketfilter zur Sicherung Datenverkehr auf IP-Adressen-, UDP-Port- und TCP-Port-Ebene
2. MD5-Fingerprint

Mit 1. kommt nix rein, was auf andere Weise rein will als zugelassen. Mit 2. kann nix von draussen so tun, als dürfte es über die zugelassenen Verbindungen rein, da MD5 genau weiss, wer auf diesem Port überhaupt lauschen darf. Andere Anwendungen kriegen somit (sofern es sie überhaupt gibt, das will ich ja schließlich vermeiden) sofort den Maulkorb.

Ungewollter Outbound-Verkehr von innerhalb des Netzwerks kann sich nur durch die Proxys durchtunneln; direkte Verbindung is' nich'.
Das ist eine Schwachstelle, zugegeben.
Wenn ich mir das aber so recht überlege, würde ein Trojaner doch versuchen, direkt vom LAN-Client z.B. zur Adresse a.b.c.d:x zu connecten?
Und dieser Traffic läuft ja schon nicht, wenn es sich nicht um einen zugelassenen Port inbound von Seiten des Gateways handelt. Also müsste z.B. der Port 80 genommen werden, der als well-known-port meist frei ist. Ist er aber hier nicht, weil der Connect zum http-Proxy auf ganz anderen Ports läuft (auch nicht die üblichen wie 8080, 4480 usw.).
Also käme der Traffic über den LAN-Adapter ins Gateway, dort an den Paketfilter und der weist ihn ab und vernichtet das Paket. Gleichzeitig spricht der Intrusion Detector an und meldet ein deutliches "Hoppla!".

Stimmt das so wiet, wie ich das hier beschreibe oder ist das nur Wunschdenken?

rebooter

#28 @spunki:
Sorry, schon wieder einen verpasst!

Das ist es ja gerade:
Es werden nur die nötigen Applikationen auf dem Gateway installiert. Das sind aber doch so einige, weil das Gateway als einziger (!) Mittler zwischen den Welten LAN und WAN=Internet arbeiten soll.

Wenn nun aber eine Anwendung über das Tunneling doch auf den Rechner kommt, wäre es doch ganz schick festzustellen, ob diese Anwendung auch auf diesem Port rausconnecten darf oder nicht. Und wenn es nicht die ursprüngliche Anwendung ist, die einen Connect auf einem auch noch zugelassenen Port versucht, wird das geblockt, da der MD5-Fingerprint nicht stimmt.
Ende des Trojaners, Intrusion Detector sagt Bescheid und: weg mit dem Dreck!

Darum die MD5-Geschichte, denn sonst habe ich da keine Lösung. Vor allem keine, die ich bezahlen kann (man denke nur an solche scharfen Sachen wie DMZ und deren Kumpels...).

rebooter

#29 Mmh, so recht verstehe ich das nicht ganz. Ok, versuchen wir das mal aufzudrieseln:

Auf dem Gateway läuft eine Menge X von Applikationen. Diese sind vertrauenswürdig - also was kann passieren:

- 1. es installiert jemand irgendwelches Software - das sollte nicht passieren, da jeder der auf dem Gateway was installiert standrechtlich erschossen wird - dies kann aber auch durch die Installation von Überwachungssoftware verhindert werden (Appsense) - bzw. sogar über einfache GroupPolicies

- 2. eine der Serverdienste wird durch einen Exploit oder was weiß ich befallen - dabei wird aber in den seltensten Fällen das eigentliche Programm modifiziert, sondern einfach nur genutzt bzw. zum Absturz gebracht

- 3. über Mail oder irgendwas kommt ein Trojaner auf den Rechner - geht eigentlich nicht

Also, wozu noch MD5`?

R:
__________
powered by http://different-thinking.de - Netze, Protokolle, Sicherheit, ...

#30 Das frag ich mich auch...
Rebooter, du scheinst zu denken, ein Trojaner o.ä. könnte "irgendwie" über die einfache Internet-Anbindung auf den Gateway gelangen.
Aber ein Trojaner ist nichts weiter als ein "Programm", welches du quasi selbst installieren musst (natürlich unbewusst der Schadwirkung.)
Andere Wege über evtl. Sicherheitslücken, die nicht schon lange gepatcht wurden, sind derzeit nicht bekannt.

Also kannst du eigentlich ausschließen, dass ein Trojaner auf dein Gateway gelangt, wenn du Roberts "Vorschriften" befolgst (was ich für meinen Teil nicht so wirklich mache...hüstl )
__________
"Scheinsicherheit" - wie leicht lassen sich Viren- und Trojanerscanner austricksen?