Linux Firewall Lösung

[Gast Fros]

Ich arbeite zur Zeit mit einem Kommilitonen an einer Firewall-Lösung mit dem Schwerpunkt Voice-over-IP-Security.

Wir haben uns für uns für die Firewall-Lösung von Astaro entschieden. Da Astaro uns zum Einem kostenlos einen Key bereit gestellt hat und zum Anderen relativ einfach für kleine bzw. mittelständische Unternehmen zu konfigurieren ist.

(Im VoIP-Netz arbeitet sowohl ein Asterisk-Server (mit Remote-SSH-Zugriff), ein Sipgate-Server, ein PKI/DLS-Server, ein SER-Server und ein RAS-Server, sowie ein DNS-Server; einige Server arbeiten zusätzlich mit AES- bzw TrippleDES-Verschlüsselung)

Meine Frage diesbezüglich ist, dass die Firewall bereits mit Hilfe von einigen Tools von Backtrack (basierend auf Slackware) getestet haben. Die Firewall diesen "Standart"-Angriffen stand hielt und nun weiter testen wollen, wie verwundbar die Firewall ist.

Zusätzlich ist zu bedenken, dass wir aus einem VPN-Netz auf die Firewall zugreifen, da das Hochschulnetz als WAN herhalten muss, da wir nicht die Hochschul-Firewall, sondern unsere Firewall testen wollen.

Auf eine DMZ haben wir verzichtet, da dies zum einen einen zusätzlichen Firewall-Key benötigt (und somit zusätzliche Kosten bei den Unternehmen bedeuten würde) und zum anderen wenig Sinn macht, da die meisten benötigten Client-Protokolle sowieso durchs Server-Netz "durchgeschleift" werden müssen. Unsere Firewall Lösung sieht daher vor, dass die Server in einem eigenem IP-Bereich arbeiten und die Clients (VoIP-Telefone) in einem anderen IP-Bereich arbeiten.

Wenn jemand zusätzliche Testtools hätte, ohne dabei ins LAN einzugreifen, wäre ich ihm sehr dankbar.

Bearbeitet 29. Mai 2009 von Fros

[KobaYashi]

hallo,

ich verstehe das nicht ganz daher muss ich mal nachfragen. Ihr versucht also zu testen wie leicht oder wie schwer die Firewall zu ueberwinden ist?

[Gast Fros]

jup genau

[KobaYashi]

Was soll die Firewall denn genau verhindern?

[Gast Fros]

Neben der Netzwerk Sicherheit (Paketfilter, NAT und Eindringschutz) und soll sie eben vorallem für VoIP-Sicherheit sorgen (Kommunikation über das SIP-Protokoll).

Mit der Zielsetzung, dass ein kleines/mitteles Unternehmen VoIP-Telefonie betreiben kann, ohne es dem Angreifer all zu leicht zu machen die Telefonate abzuhören/mit zu protollieren. Zusätzlich soll es auch noch möglich sein, dass die Firewall allgemeine Aufgaben (Web-Security mit HTTP/S- und FTP-Profilen, Mail-Security und Contentfilter) bei Bedarf erledigen kann.

Die Mail-Security wird bei uns zum Beispiel nicht genutzt, da wir eben keinen Mail-Server haben. Alles andere haben wir zur beispielhaften Darstellung aktiviert, auch wenn einige im Labor zum Beispiel stört, dass sie kein ICQ etc. mehr nutzen können, wird aber eben bei Unternehmen selten genutzt.

Nach Möglichkeit soll auch zusätzlich noch der sichere site-to-site VPN-Zugang bei uns an der Hochschule ermöglicht werden (IPsec, SSL und Certificate Management) und Remote Access (auch wieder IPSec, SSL, Certificate Management und L2TP over IPSec). Die letzten beide Punkte sind jedoch nicht so wichtig, da sie zum einen eben auch wieder Sicherheitsrisiken mit sich bringen nur nicetohave sind.

Wie schon gesagt, es soll halt einfach nicht so einfach sein, dass die Telefonate abhörbar sind, bzw. dass die Telefonanlage lahmgelegt werden kann.

Bearbeitet 29. Mai 2009 von Fros

[KobaYashi]

eieiei.. das ding soll ja echt ne Menge koennen.

Vorab, die groesst moegliche Sicherheit wird wohl nur moeglich sein wenn du innerhalb eines geschlossenen VPNs mit SRTP arbeitest. Alles was nach draussen geht muesstest du mit deinem SIP Anbieter sprechen und die Verbindung zu ihm auch via SRTP verschluesseln lassen, falls er sowas anbietet.

Generell ist es ja so, dass eine Firewall ja nicht vor fehlerhaften Applikationen oder dummheit der Nutzer schuetzt. Zum nutzen von ICQ muss man nur Zugriff nach aussen ueber einen Webbrowser haben. Auch sollte man bedenken, dass applicationen wie z.b. Netmeeting sich wahllos Ports fuer die Kommunikation aussuchen. Generell alles zu schliessen kann also auch zu ungewollten Einschraenkungen fuehren. Ich denke im Prinzip ist wohl der zusaetzliche Einsatz eines Proxys sicher nicht verkehrt. Selbst geschriebene Regeln koennen viele deiner Punkte abwickeln.

[Gast Fros]

Die Firewall steht ja soweit und ist konfiguriert, wir wollen eben nur noch weiter testen, wie sicher sie ist. Die ganzen oben genannten Server (außer der DNS-Server) sind für RTP-Sicherheit zuständig, sind alles verschiedene Sicherheitskonzepte pro Server, also das ist nicht unsere Aufgabe, unsere Aufgabe beschränkt sich jediglich auf die Firewall, dass auf die Server nicht ohne weiteres zugegriffen werden kann.

Ich hatte eben gehofft, dass noch jemand ein gutes Tool hat, mit dem man die Firewall testen kann, wir haben eben bereits einige Tools von der Backtrack Distribution getestet, aber die stellt eben allein über 300 Tools zu Verfügung, was allein von der Anzahl einfach zuviel ist jedes Tool drüberlaufen zu lassen.

[KobaYashi]

Naja im Prinzip ist es einfacher sich Exploits fuer die Applikationen zu besorgen anstatt zu versuchen eine Firewall auszuhebeln. Sowas macht doch niemand.

Das koennte dann vielleicht dein Ansatzpunkt sein.

[DerUnf4ssbare]

hehe jetzt schaltet koba in den gangstermode.

schnell die rechner vom netz!

[Gast Xorphitius]

Neben der Netzwerk Sicherheit (Paketfilter, NAT und Eindringschutz) und soll sie eben vorallem für VoIP-Sicherheit sorgen (Kommunikation über das SIP-Protokoll).

Mit der Zielsetzung, dass ein kleines/mitteles Unternehmen VoIP-Telefonie betreiben kann, ohne es dem Angreifer all zu leicht zu machen die Telefonate abzuhören/mit zu protollieren. Zusätzlich soll es auch noch möglich sein, dass die Firewall allgemeine Aufgaben (Web-Security mit HTTP/S- und FTP-Profilen, Mail-Security und Contentfilter) bei Bedarf erledigen kann.

Die Mail-Security wird bei uns zum Beispiel nicht genutzt, da wir eben keinen Mail-Server haben. Alles andere haben wir zur beispielhaften Darstellung aktiviert, auch wenn einige im Labor zum Beispiel stört, dass sie kein ICQ etc. mehr nutzen können, wird aber eben bei Unternehmen selten genutzt.

Nach Möglichkeit soll auch zusätzlich noch der sichere site-to-site VPN-Zugang bei uns an der Hochschule ermöglicht werden (IPsec, SSL und Certificate Management) und Remote Access (auch wieder IPSec, SSL, Certificate Management und L2TP over IPSec). Die letzten beide Punkte sind jedoch nicht so wichtig, da sie zum einen eben auch wieder Sicherheitsrisiken mit sich bringen nur nicetohave sind.

Wie schon gesagt, es soll halt einfach nicht so einfach sein, dass die Telefonate abhörbar sind, bzw. dass die Telefonanlage lahmgelegt werden kann.

Hmm, ich fürchte, du wirfst hier verschiedene Dinge gemeinsam in einem Topf, die man differenzierter betrachten muss. Was du ansprichst, ist eigentlich ein IT-Sicherheitskonzept, welches naturgemäß mehrere Bestandteile hat - sprich mit einer Firewall als eierlegende Wollmichsau, wirst Du das Problem nicht erschlagen können. Gehen wir mal der Reihenfolge nach durch:

Sicherheit Zugang:

- physische Sicherheit

- Authentifikation von Netzteilnehmern bereits auf Port-Basis (am Switch) mittels 802.1x und EAP

Traffic-Steuerung

- Firewall/Router: zur Steuerung der Datenpakete zwischen einzelnen Netzsegmenten und Systemen (dienen also nur zur Abschottung, Reduzierung der Risiken von DOS-Attacken wie Flooding und malformed TCP/IP-Paketen) z.B. mit IPTables, Shorewall und Co.

- Trennung von Sprach- und Datennetz durch getrennte VLANs

Vertraulichkeit der übertragenen Daten

- bei VoIP sollten sowohl das Signalisierungsprotokoll (SIP o. H.323) als auch der RTP-Stream (also die eigentliche Sprachübertragung) verschlüsselt (TLS o. SRTP) werden (von den marktgängigen Lösungen wird dies auch eigentlich generell untersützt)

- sichere Administrationsprotokolle (SSL wenn WebInterface, SSH usw.)

- unsichere Schnittstellen sollten abgeschaltet werden können

--> sind als Grundanforderung an die VoIP-Lösung/Software zu definieren

- Schutzmaßnahmen bei Clients mit Softphones (Virenschutz, Personal Firewall)

Serversicherheit

- Anwendungsserver bzw. deren Konfiguration (inkl. OS) sind/ist entsprechend zu härten

Sicherheit Internetzugang (Web-Security):

- ProxyServer mit entsprechenden Filtern (Viren, URL-/Content-Blocking) z.B. mit Squid + DansGuardian oder SquidGuard + ClamAV

- Mailserver mit Viren-/Spamfilter z.B. mit Postfix + Amavis + ClamAV + SpamAssassin

Fazit: Sicherheit ist ein gesamtheitlicher Ansatz, den Du nicht auf ein Produkt abwälzen kannst. Eine Firewall nutzt Dir gar nix, wenn die Dienste, die du zwingend durchlassen musst, unsicher konfiguriert sind!

P.S.: Wenn Du genaueres wissen möchtest, können wir uns gerne mal auf nem Voice-Server treffen. Ich prüfe (bin IT-Revisor) derzeit z.B. die VoIP-Einführung in unserer Firma.

Bearbeitet 29. Mai 2009 von Xorphitius

[Gast Xanthum]

... auch wenn einige im Labor zum Beispiel stört, dass sie kein ICQ etc. mehr nutzen können, wird aber eben bei Unternehmen selten genutzt.

Da musste ich kurz lachen ;-) Ich kenne eine Firma die für Datenausfallsicherheit im Bankensektor zuständig ist und dort benutzen die ICQ für die Hauskommunikation .....

Ist an sich schon traurig und gehört wohl nicht so recht zu dem Thema, aber ich dachte mal ich werde es fix los ;-)

Gruß

Xanthum

[Gast Fros]

Wie gesagt, das Labor befasst sich ausschließlich mit der VoIP-Security, meine Aufgabe beschränkt sich jedoch nur auf die Firewall. Dass die Server richtig konfiguriert sind, nehmen wir als gegeben an, da sich damit eine Vielzahl anderer Mitarbeiter beschäftigt. Dass wir nur ein kleines Zahnrad in der Kette sind, dessen bin ich mir bewusst

Bearbeitet 29. Mai 2009 von Fros

[Gast Xorphitius]

Weitere geeignete Testtools könnten sein:

- SANE

- Nessus

- Kaine&Abel

- WireShark

Insbesondere letztere beide können recht gut mit VoIP-Streams umgehen (beachte aber die deutsche Rechtslage)

Ein rein logische Trennung des Sprach- und Datennetzes auf IP-Ebene ist nur eingeschränkt wirksam. Die Trennung von Sprach- und Datennetz sollte per VLAN erfolgen, das schränkt die Möglichkeiten von ARP-Spoofing am Switch etwas ein.

802.1x mit EAP (also Port-Security am Switch) macht dann Sinn, wenn man sehr gute Kontrolle über die Softwarekonfiguration der Clients im lokalen Netz besitzt. Dürfen die User jedoch auf authorisierten Clients nach Belieben Software installieren - ist ein erheblicher Teil dieses Schutzes unwirksam (Stichwort: Innentäter - die statistisch mit die größte Gruppe der Schadensverursacher stellen).

Sehr viel wirksamer hingegen ist die Verschlüsselung von Signalisierung- und Medientransportprotokoll. Dies ist jedoch kein Thema der Firewall sondern ein Thema der VoIP-Server und -Clients.

[Gast Fros]

Ok, vielen Dank. Kain&Abel und Wireshark verwenden wir schon, wobei man hierzu ja auch wieder Zugang ins LAN benötigt.

Bin mir zwar nicht sicher, ob ich VLAN richtig verstehe, aber wir hatten den Punkt auch schon disskutiert, das würde ja im Unternehmensumfeld zum Beispiel bedeuten, dass man einem Client-PC und einem Client-Telefon am Arbeitsplatz die selbe IP zuweist und alle Pakete automatisch dem PC zuweist, außer es sind Telefonate. Seh ich das richtig?

Wir hatten eben unter dem Umstand beschlossen, dass wir darauf verzichten können, da wir eben nur Telefone als Clients haben und sonst nur Server im Netz stehen.

Zumdem sind bei uns die Telefone physikalisch von den Servern getrennt (sprich 3 Netzwerkkarten und 2 Switches im Betrieb).

Ich seh da leider noch nicht den Sinn von VLAN, aber wie gesagt, da bin ich noch net so firm.

802.1x mit EAP (also Port-Security am Switch) macht dann Sinn, wenn man sehr gute Kontrolle über die Softwarekonfiguration der Clients im lokalen Netz besitzt.

Joa das scheint so ne Art Registrierungsserver zu sein und zumindest im Bereich der IP Telefone haben wir da den RADIUS ACCESS Server der vrmtl genau das macht, und Software installieren ist wieder das Problem dass wir keine ClientPCs haben.

Vielen Dank nochmal

[Gast Xorphitius]

Darf ich fragen, im Rahmen welchen Studienganges Du mit dieser Fragestellung beschäftigt bist? Das würde helfen, Dein Know-How besser einschätzen zu können.

Zum VLAN:

Man weist nie zweimal im Netz die gleich IP zu - da würde man mit der Dokumentation wahnsinnig werden mal ganz abgesehen von den technischen Problemen sobald es zum Routing kommt

Du kennst die Technik des ARP-Spoofings? Im Prinzip ist es recht einfach den Traffic eines Servers/Clients an einem Switch mit Hilfe "gängiger" Tools auf Deinen Rechner umzuleiten (und damit mitzuschneiden).

Deswegen ist die oberste Priorität allen vertraulichen Netzwerkverkehr zu verschlüsseln. Bei VoIP also Signalisierung UND Medientransport (der eigentlich Voicestream). Ersteres wird durch den Server geregelt, zweiteres muss zwischen den Clients erfolgen (nach erfolger Vermittlung der Verbindung durch den Signalisierungsserver kommunizieren die Clients direkt miteinander).

Wozu ist nun VLAN nützlich. Nun das ist quasi so, als ob Du für Sprachnetz und für das Datennetz jeweils einen getrennten Switch hättest. D.h. es ist "unmöglich" Daten im Sprachnetz vom Datennetz heraus mitzusniffen unhd umgekehrt. (vom jeweiligen Switch aus gesehen)

Das ganz macht insbesondere dann Sinn, wenn gleichzeitig 802.1x (EAP) also Client-Auth bereits am Switchport zum Einsatz kommen. Ein potentieller Angreifer hat dann bereits erhebliche Schwierigkeiten überhaupt ins Netz zu kommen. Damit das ganze seine volle Wirkung entfaltet, ist es natürlich notwendig, dass auf den Client-PCs im Netz keine fremde Software installiert werden darf.

Wir hatten eben unter dem Umstand beschlossen, dass wir darauf verzichten können, da wir eben nur Telefone als Clients haben und sonst nur Server im Netz stehen.

Das ist unlogisch und entspricht nicht der Praxis. Üblicherweise stehen in einem Unternehmen auch PCs, die normalerweise auf Fileshares und Druckerservices zugreifen sowie Mail und Internetzugang.

Last but not least - Gesprächsangebot steht noch immer und dürfte vermutlich effektiver sein.