Sicherheit im Netzwerk - Routerkonfiguration

[Capu]

Also ich kann nur von mir sprechen, bei mir läuft der f2b nicht auf der DS da diese nicht von aussen erreichbar ist (und das ist gut so). Bei mir läuft es auf einem normalen Linux-Root-Server der in nem RZ steht. Bei Jahlives könnte das anders aussehen da er anscheinend, so les ich das aus seiner Sig, ein alternatives BS einsetzt.

 

[itari]

Ich denke, es ist schon implizit klar, dass wir hier in diesem Thread Lösungen diskutieren, die etwas mit einem non-professional-Netzwerk zu tun haben, welches typisch für eine DiskStation ist, also vornehmlich den Routereinsatz in einem LAN, in dem auch dann eine DS eingebunden ist und mit den Mitteln und Möglichkeiten, die man dann zur Verfügung hat. Ich hätte mich jetzt also darüber gefreut, wenn es ein Skript (oder ähnliches) auf einer DS gäbe, dass den Router-Log lädt, parst und dann ggf. auch handelt ...

Itari

 

[Capu]

Auf der DS läuft ein Linux... Sofern die f2b Anforderungen erfüllt werden was sourcen und libs angeht zur Verfügung stehen, dann sollte eine Portierung machbar sein...
Ok, du willst einen Non-Professional-Netzwerk in der eine DS (mit DS und 0815-Router Mitteln) sicher als File- und Webserver im Internet betrieben werden kann? Das ist so gut wie nicht möglich. Dafür ist sowohl ein Router für den Heimnutzer, als auch die DS (was Linux, Apache, ... betrifft) zu rudimentär ausgestattet. Und wenn du Non-Professional sagst, dann kannst das von dir angesprochene Thema DMZ gleich weglassen... Denn ich denke du meinst eine echte DMZ und nicht so eine Pseudoding. Und ich denke niemand hier wird sich 2 Firewalls (ich meine richtige Firewalls inkl. IDS und zip und zap a la GeNUGate) und einen "großen" Router daheim hinstellen...

 

[jahlives]

@itari
aktivier den Syslog auf der DS und lass den Router auf die DS loggen. Ob es ein fail2ban Paket via ipkg gibt weiss ich ned, aber das es Python ist müsste sich das eigentlich installieren lassen. fail2ban kann wirklich sehr flexibel eingerichet werden. Bei wacht zudem noch ein Eigengewächs (Bash und PHP) über den fail2ban selber. fail2ban ist bei mir dafür zuständig Ersttäter relativ kurzzeitig zu sperren. Mein Eigengewächs übernimmt dann die Wiederholungstäter und blockt diese für immer weg (drum habe ich das Teil auch ban4ever genannt). Spätestens nach 1 Monat wenn das fail2ban Log rotiert wird, fliegen die "für immer gesperrten" IPs wieder raus und ban4ever beginnt wieder von neuem

 

[itari]

zu dem Non-Professional-Netzwerk ... damit meine ich nicht die Netzwerke in einer Firma *gg*, sondern die Netzwerke bei einem Provider oder Datenhoster, die davon leben, dass sie möglichst wenig Scherereien und Arbeit mit ihrer Technik haben.

zu dem Thema '2faul2ban' äh 'fail2ban' ... wie hilft das nun den Leuten dabei, zu verstehen, was wirklich wichtig ist bei einer Routerkonfiguration.

zu dem Thema 'DMZ' ... was ist eine 'echte' DMZ und was ein 'Pseudoding' ... schön wäre es, wenn man darüber ein paar Infos bekäme ... ich würde auch gerne etwas zu einer 'richtigen' Firewall erfahren (macht man das heute nicht mehr mit iptable unter Linux???) - nebenbei bemerkt: Intrusion Detection und Intrusion Prevention gehören nicht direkt zu den Leistungsmerkmalen einer Firewall (gemäß Wikipedia http://de.wikipedia.org/wiki/Firewall#Intrusion_Detection_und_Intrusion_Prevention_Systeme)

Itari

 

[jahlives]

@itari
k.A. ob fail2ban beim Verständnis eines Routers hilft. Habe aber gerade eben erfahren, dass ich in Zukunft viel mehr Freizeit haben werde und setze mich die Tage sicher mal daran und probiere den fail2ban auf der DS (Firmware) laufen zu lassen

 

[Capu]

DMZ:
Eine Pseudo-DMZ wird bei einigen Heim-Routern bereitgestellt und wird durch einen s.g. "Exposed Host" realisiert. Dabei wird dem Router die IP des gewünschten Rechners bekanntgegeben werden und alle Anfragen von draussen die nicht durch andere "Filterregeln", NAT oder Portweiterleitungen verteilt werden laufen bei diesem Exposed Host auf. Der Rechner ist quasi auf allen Ports von draussen direkt erreichbar.
Eine echte DMZ wird durch eine, besser zwei, Firewall(s) realisiert, die zwar den Zugriff von der WAN Seite z.B. auf einen Web Server erlauben, das interne Netz aber gegen Zugriffe von aussen komplett abschirmen.

(Bildquelle: Wikipedia)
Zugriffe aus dem internen Netz auf die Rechner der DMZ ist gestattet, umgekehrt aber in der Regel nicht.

Firewall:
Eine Firewall ist in der Regel mehr als ein Linux-Rechner mit iptables. Ein s.g. gehärtetes Betriebssystem bildet die Grundlage und wird durch Port-, IP- bzw. MAC-Adressenbassierte Filterregeln ergänzt. Eine weitere Ergänzung des Firewallsystems bildet die "Stateful Inspektion" die online die Datenpakete analysiert und so können DoS Attacken, SYN Flooding oder ein s.g. Ping of Death verhindert bzw. verworfen werden. Damit so ein System ausreichend Schutz für das dahinter liegende Netz bietet, funktioniert so eine FW nicht "out-of-the-box" sondern wird speziell auf die konkreten Erfordernisse angepasst und sollte/muss regelmäsig durch Update der Filterregeln usw. auf einem aktuellen Stand gehalten werden. Idealer Weise wird eine Firewall durch Intrusion Detection (IDS) und Intrusion Prevention Systeme (IPS) ergänzt, die Aufgrund von Zugriffs- und Komunikationsmustern Einbruchsversuche erkennen und verhindern können.
Problem des ganzen Themas... Es ist sehr komplex und füllt Bücher und viele schlaue Köpfe machen nichts anderes als sich mit diesem Thema zu beschäftigen. Eine nicht komplett durchdachte Implementierung einer Regel kann zur Folge haben das man sich zum einen selber aus- bzw. einsperrt oder zum anderen den kompletten Schutz zunichte macht da man unbeabsichtigt die Haustür dadurch geöffnet hat (und offen stehen lässt).

Beide Dinge, also DMZ und Firewalls, leicht verständlich und ohne viel Techniklatein zu erklären ist extrem schwer da zum Verständnis einiges an Wissen vorraussetzung ist... Zum Beispiel sollte man schon mal, um nur ein leichtes Beispiel zu nennen, vom s.g. 7-Schichten-Referenzmodell (OSI-Schichtenmodell - Open Systems Interconnection Reference Model) gehört haben ;-)

Um das auf das eigentliche Thema dieses Threads zu beziehen... Router & Sicherheit... Hier gibt es die schon hier mehrmals genannten allgemeingültigen Regeln (WPA2, "sicheres" Routerkennwort), das sind aber nur eine handvoll... Will man mehr und braucht man mehr, muss man sich selber mit dem kompletten Thema auseinandersetzen, da gibt es keine allgemeingültigen Tips mehr.

 

[itari]

Hi Capu, ich hab das Gefühl, dass wir hier in eine Art Wettstreit verfallen. Das ist von meiner Seite nicht beabsichtigt. Ich möchte gerne hier in diesem Thread für jedermann verständlich, die Möglichkeiten der Router-Sicherheit diskutieren und dabei die wichtigen Dinge ein wenig von den 'ich-weiß-nicht-warum-machs aber-trotzdem-weil-es-andere-gibt-die-es-auch-tun'-Geschichten abgrenzen.

Zur DMZ würde ich mir eine Diskussion wünschen, die zum einen erklärt, warum man sowas überhaupt macht (und warum ein 'exposed Host' fast das gleiche macht) und zum anderen, ob man dieses Feature sinnvoll in einem normalen LAN, wo eine DS mit drinnesteckt verwenden kann, z.B. ob man eine DS in die DMZ setzen sollte. Vielleicht gibt es ja jemanden, der seine DS in die DMZ gesetzt hat und kann uns über seine Beweggründe ein wenig erzählen.

Zur Firewall und iptables-Geschichte möchte ich anmerken, dass iptables (und die dazu gehörigen Kernel-Module, wenn sie denn vorhanden sind) 'stateful inspection' kann. Ich sehe also keine wirkliche Differenz zwischen 'iptables' und einer 'richtigen' Firewall, außer dass auf der DS nicht alle Kernel-Module per se vorhanden sind bzw. geladen werden. Und klar ist auch, dass eine Firewall nicht alles abfangen kann, was es an 'bösen' Datenpaketen so im Netz gibt, aber es wäre ja auch nicht richtig, sie so zu positionieren. Das wäre ja so, als würde man von einem Virenscanner erwarten, dass er auch andere Malware entdeckt, die gar keine Viren wären, sondern vielleicht Würmer oder Trojaner sind. Sich also darüber zu unterhalten ist wichtig, weil man damit das ein oder andere Mißverständnis aufklären kann und eben auch ein wenig Anwendungswissen verbreitet.

Itari

 

[Capu]

Nö... Wettstreit seh ich keinen... Vielleicht reden wir aber aneinander vorbei...

Um auf die Router zurück zu kommen... Was man machen sollte und warum und was man bleiben lassen kann hab ich schon geschrieben und der ein oder andere ergänzt. Alles was über die allgemein gültigen Tips hinaus geht sind Einzelfallentscheidungen ob sinnvoll oder nicht und sprengen den Rahmen eines allgemein gültigen Threads.

Nochmal zur DMZ... Man benutzt eine DMZ um Netzwerkdienste wie Webservices, FTP, Mail, Nameservices nach draussen (WAN) anzubieten, aber das interne Heim-/Firmennetz komplett gegen solche Abfragen abzuschotten... Nach aussen betrachtet bietet als das interne Netz solche Dienste gar nicht an, da die Firewall solche Anfragen an das interne Netz blockt... So hat man seine Daten im internen Netz abgeschottet, kann aber trotzdem o.g. Dienste anbieten (und auch von intern nutzen). Ein exposed host bietet zwar auch Netzwerkdienste nach aussen, befindet sich aber schon im internen Netz, also quasi im Sicherheitsbereich. Von daher als unsicher anzusehen.

Und nochmal zur Firewall... Der entschiedende Vorteil ist das die "richtige" Firewall eben nur das macht und nichts anderes... Sollte ich mir diesen Rechner zerschiessen oder durch eine Fehlkonfiguration nach aussen öffnen, mach ich das Ding platt und setz es neu auf bzw. spiel das letzte Backup zurück... Meine persönlichen Daten die auf einem anderen Server/Rechner/DS liegen sind davon aber (noch) nicht betroffen... Natürlich sollte man merken das die Firewall unter einer massiven Attacken steht oder schon gefallen ist. Dann kann ich das System aber immer noch vom Netz nehmen und habe die Verbindung nach draussen unterbrochen. Befindet sich die Firewall auf dem gleichen Rechner wie meine Daten, standen sie dem Angreifer direkt zur Verfügung.

Nachtrag:
Umkehrschluss zurück zur DS...

Packt man eine DS in eine DMZ?
Kann man tun, wenn man sie ausschliesslich als Webserver nutzt, und nicht als Fileserver für seine Daten.

Nutze ich meine DS als Fileserver UND als Webserver würde ich mir ganz genau überlegen ob ich das will, und man sollte sich im klaren sein das durch einen Fehler im Apache oder sonstige Sicherheitslücken ein Hacker direkt Zugriff auf meine Daten bekommen kann. Egal ob die DS in einer DMZ oder in internen Netz mit einer Portweiterleitung hinter dem Router steht. Ich würde es definitiv nicht machen...
Und Quellen für Sicherheitslücken gibt es genug... Apache, PHP, das CMS welches man nutzt usw...

 

[jahlives]

ack @ itari zwischen iptables oder eine "normalen" Kauffirewall bestehen keine nennenswerte Unterschiede. Paketfilter haben sie alle und stateful sind sie ja auch. Was mir aber noch wichtig erscheint bei diesem Thema: Das Firewallkonzept sollte mehrstufig sein. Ich weiss dazu gibt es andere Meinungen Auch würde ich bei einer (gut konfigurierten) Firewall nicht so sehr darauf setzen dass sie den Einbruch an sich verhindern kann. Wo aber Firewalls gut sind ist es darin eine Ausweitung des Bruchs zu verhindern. meist wird ja irgend ein unprivilegierter Account gekapert und der "Hacker" muss sich was nachladen aus dem Netz oder will sich auf andere Teilnehmer im LAN ausbreiten. Das kann eine gut konfigurierte Firewall aber sehr zuverlässig unterbinden.
Klar es ist sehr aufwändig eine Firewall so aufzusetzen, dass sie dies zuverlässig kann. Zudem gehört zur Sicherheit noch mehr dazu als nur eine Firewall z.B. eine restriktive Rechtevergabe und Absicherung der Applikationen. Bei allem nach dem gleichen Prinzip "So viel wie nötig und so wenig wie möglich"

Damit ich doch noch irgendwie den Bogen zum Thema (Router) hinkriege : Genau so wie eingehende Verbindungen reglementiert werden, sollte man auch ausgehende Verbindungen so gut wie möglich beschränken. Wenn man z.B. einen Mailserver im LAN hat, dann gibt es keinen Grund einem anderen Client als dem Server zu erlauben auf Port 25 ins Web zu gehen. man sollte dann also eine ausgehende Regel am Router erstellen. Zusätzlich sollte man aber trotzdem via Firewall auf dem Server sicherstellen, dass nur der User unter dem der Mailserver läuft überhaupt auf Port 25 kann

Gruss

tobi

 

[itari]

Meine persönlichen Daten die auf einem anderen Server/Rechner/DS liegen sind davon aber (noch) nicht betroffen... Natürlich sollte man merken das die Firewall unter einer massiven Attacken steht oder schon gefallen ist. Dann kann ich das System aber immer noch vom Netz nehmen und habe die Verbindung nach draussen unterbrochen. Befindet sich die Firewall auf dem gleichen Rechner wie meine Daten, standen sie dem Angreifer direkt zur Verfügung.

Dann machen wir einfach mal hier weiter.

Was bedeutet eigentlich, die Firewall ist angegriffen worden und gefallen ... dass alle Datenpakete jetzt 'ungefiltert' durchschlüpfen können ... das bestimmte Datenpakete durchschlüpfen können oder dass nichts mehr durchgelassen wird? Ist es nicht eher so, dass die Server, die von der Firewall geschützt werden, einfach nicht mehr erreichbar sind, weil z. B. die Leitung 'verstopft' wird?

Und was bedeutet, die Daten standen dem Angreifer direkt zur Verfügung ... bedeutet das, dass man auf einmal den Samba-Server gehackt hat oder eher, dass man sich als 'root'-benutzer eine Shell aufgemacht hat und alle Shell-Kommandos ausführen kann oder dass man nun den Webserver (Apachen) dazu verleitet, andere als die vorgesehenen Dateiverzeichnisse zu lesen oder zu modifizieren?

Hinterlassen intelligente Angriffe eigentlich Spuren oder sind sie nicht so gut getarnt, dass man sie gar nicht nachweisen kann? Wenn man aktuell von Bot-Netzwerken hört, dann ist das doch eher so, dass man davon gar nichts mitbekommt, wenn sie sich in einem Rechner oder in einen Browser eingenistet haben, oder?

Itari

 

[itari]

Genau so wie eingehende Verbindungen reglementiert werden, sollte man auch ausgehende Verbindungen so gut wie möglich beschränken. Wenn man z.B. einen Mailserver im LAN hat, dann gibt es keinen Grund einem anderen Client als dem Server zu erlauben auf Port 25 ins Web zu gehen. man sollte dann also eine ausgehende Regel am Router erstellen. Zusätzlich sollte man aber trotzdem via Firewall auf dem Server sicherstellen, dass nur der User unter dem der Mailserver läuft überhaupt auf Port 25 kann

Kannst du kurz erläutern, wie man das auf einer DS bzw. 0815-Router macht?

Itari

 

[jahlives]

Hinterlassen intelligente Angriffe eigentlich Spuren oder sind sie nicht so gut getarnt, dass man sie gar nicht nachweisen kann? Wenn man aktuell von Bot-Netzwerken hört, dann ist das doch eher so, dass man davon gar nichts mitbekommt, wenn sie sich in einem Rechner oder in einen Browser eingenistet haben, oder?

definiere intelligent Ich schätz mal ins Blaue, dass mehr als 80% aller Angriffe von Leuten kommen, die von technischen Hintergrund recht wenig verstehen. Solche Angriffe hinterlassen massig Spuren in den Logs (setzt natürlich auch ein entsprechendes Loglevel voraus). Die gezielten Angriffe von Profis, würde ich deinen "intelligenten Angriffe" gleichsetzen und bei solchen wird es schwer Spuren zu finden. Wenn überhaupt. Man kann es aber auch diesen gezielten Angriffen durch ein mehrstufiges Sicherheitskonzept schwerer machen Erfolg zu haben.
Wenn du einen Bot im LAN vermutest ist es imho am besten erstmal alle Ports ausgehend am Router zu sperren. Dann einen Verdächtigen (Computer, Tab oder what ever) nach dem anderen einzeln starten und ein paar Minuten laufen lassen. Dann die Logs am Router nach verdächtigen Verbindungsversuchen durchsuchen. Ist sehr aufwändig, aber imho am erfolgsversprechendsten ;-)

 

[itari]

definiere intelligent

Ich würde dann intelligentes Verhalten annehmen, wenn es ein sinnvolles Motiv gibt *gg*

Itari

 

[jahlives]

Kannst du kurz erläutern, wie man das auf einer DS bzw. 0815-Router macht?

Der 0815 Router muss natürlich auch Regeln für ausgehende Verbindungen unterstützen. Dann eine Regel Allow TCP Port 25 IP_DER_DS und danach ein DROP TCP 25
Und auf dem Server würde ich das mit zwei ip Tables Regel machen.

iptables -A OUTPUT -p tcp --dport 25 -m owner --uid postfix -j ACCEPT
iptables -A OUTPUT -p tcp --dport 25 -j DROP

bei der OUTPUT chain kann iptables den Erzeuger des Pakets ermitteln und kontrollieren

 

[Capu]

Was bedeutet eigentlich, die Firewall ist angegriffen worden und gefallen ... dass alle Datenpakete jetzt 'ungefiltert' durchschlüpfen können ... das bestimmte Datenpakete durchschlüpfen können oder dass nichts mehr durchgelassen wird? Ist es nicht eher so, dass die Server, die von der Firewall geschützt werden, einfach nicht mehr erreichbar sind, weil z. B. die Leitung 'verstopft' wird?

Und was bedeutet, die Daten standen dem Angreifer direkt zur Verfügung ... bedeutet das, dass man auf einmal den Samba-Server gehackt hat oder eher, dass man sich als 'root'-benutzer eine Shell aufgemacht hat und alle Shell-Kommandos ausführen kann oder dass man nun den Webserver (Apachen) dazu verleitet, andere als die vorgesehenen Dateiverzeichnisse zu lesen oder zu modifizieren?

Angriffe auf eine Firewall sieht man in den Logs recht schnell. Es wird halt versucht mit allerlei "Tricks" die Firewall zur Aufgabe zu zwingen... Sei es durch SYN Flooding, fragementierte Pakete, DoS Attacken, etc... Viele dieser Attacken passieren durch "dumme" Botnetze oder Scriptkiddies die ein vorgefertigtes Schema benutzen. Diese führen auch eher nicht zum Erfolg. Von "Hand" bzw. durch wirklich zielgerichtete Attacken und Nutzung von Exploids sieht das schon anders aus. Durch Programmierfehler im Kernel oder zugehörigen Programmteilen, die ja besonders in der Open-Source Welt recht schnell aufgedeckt, aber auch veröffentlich werden kann es so z.B. zu einem Buffer Overflow auf dem Firewall-Server kommen der es dem Angreifer erlauben könnte Konsolenzugriff zu bekommen... Sollte es soweit gekommen sein ist es natürlich für den Angreifer ein leichtes, sich ein Hintertürchen in der Firewall zu schaffen, das vom Administrator noch nicht mal bemerkt wird.
Von da kann der Angreifer sich dann auch Zugang zum Fileserver verschaffen und nach belieben Daten abziehen.

 

[itari]

die Firewall zur Aufgabe zu zwingen ... der es dem Angreifer erlauben könnte Konsolenzugriff zu bekommen

Das würde mich jetzt interessieren: Wie kann man eine Firewall zur Aufgabe zwingen bzw. was bedeutet das eigentlich? Die Firewall ist ja auf der DiskStation kein Programm (iptables ist ja nur ein Tool, um die Kernel-Funktionen bzw. der Netzwerkstacks zu konfigurieren) ... soll man das jetzt so verstehen, dass der Kernel stehen bleibt (aufgibt)? Und wie könnte man Konsolenzugriff erhalten, wenn kein telnetd oder sshd läuft.

Es wäre doch spannend, mal darzustellen, was und wo nun genau der Schaden entsteht bzw. welche Lücke sich genau für die schädlichen Datenpakete auftun.

Im Grunde entsteht ja keine Bedrohung durch Datenpakete aus dem Internet an und für sich; erst wenn diese Datenpakete Requests (Aufforderungen) enthalten, die ein Serverprogramm (Webserver, telnetd, ftpd usw.) ausführen soll und dabei die erlaubten Grenzen überschreitet, wird es gefährlich. Ohne ein solches Serverprogramm passiert ja erstmal gar nichts. Und wenn man das Serverprogramm zum Absturz bringt, dann ist eh die Kommunikation tot (also passiert da auch nichts). In meinen Augen entsteht bei Firmen dadurch Schaden, weil eine gewünschte Serverleistung einfach unterbleibt (Download-Server der Beta bei Synology geht nicht mehr ... das ist ärgerlich), aber es werden dabei keine unzulässigen Datenmanipulationen vorgenommen.

Oder es werden Daten von einen Webserver/Datenbankserver geladen, die eigentlich nur für eine spezielle Zielgruppe im Web verfügbar sein sollten (das sind ja meist die spektakulären Fällen, wo User-Accounts gehackt werden)

Oder es wird Link einer vom Webserver interpretierten Seite umgebogen und dabei ein unerwünschtes Skript im Browser ausgeführt (Trojaner) ... möglicherweise ist das ein Schaden für den User, aber ja nicht für den Webserver.

Lasst uns doch mal genau analysieren, was auf einer DS passieren könnte, wenn die DS-Firewall in Bedrängnis gerät. Ich denke, dass ist von Interesse, weil die meisten ja keine separate Firewall-Hardware nutzen bzw. über keinen Router mit integrierter und konfigurierbarer Firewall verfügen

Itari

 

[jahlives]

Ich glaube ehrlich gesagt ned, dass man eine Firewall einfach so "zur Aufgabe" zwingen kann. Unter der Voraussetzung dass die Firewall selber keinen Fehler in ihrem Code hat, halte ich das für schwierig. Eine (D)DOS Attacke kann eine Firewall leistungsmässig in die Knie zwingen, aber das heisst ned, dass die Pakete dann ungefiltert durchgehen würden. Sie werden schlicht nicht mehr verarbeitet und damit verworfen.
Ich denke direkte Angriffe auf Firewall lohnen sich nicht. Da ist es viel einfacher eine dahinter liegende Applikation z.B. Webserver oder Datenbankserver anzugreifen. Und dann diesen Bruch als Sprungbrett zu nutzen.
Als erstes wird ein Einbrecher wohl immer versuchen irgendwie an Schreibrechte zu kommen, hat er diese dann wird wohl versucht irgendeine Software zur Ausweitung der Rechte (exploits) nachzuladen. Und genau darum ist es so wichtig die Sicherheit immer mehrstufig zu sehen. Am Beispiel eines Webservers: Es ist äusserst "schlecht" wenn der Webserver User einfach pauschal Schreibrechte auf den DocRoot hat. Zudem sollte man immer sicherstellen, dass die User unter denen solche Server laufen möglichst wenig Rechte im Dateisystem selber haben. Blöd wäre z.B. wenn der User nobody busybox aufrufen könnte und man busybox gleich noch suid gesetzt hätte. Dabei kann einem die Firewall nicht wirklich helfen

 

[Capu]

Ich glaube ehrlich gesagt ned, dass man eine Firewall einfach so "zur Aufgabe" zwingen kann.

Na beschreib das mal das es jeder versteht wenn man eine FW überwindet... Deswegen hab ich das sehr vereinfacht ausgedrückt... Nen buffer overflow durch nen schlechten Kernel wäre z.B. ein Punkt... Ist halt extrem schwer ein Thema in einem Thread für alle verständlich auszudrücken über das man Bücher schreiben kann.

 

[jahlives]

Stimmt ich hätte besser schreiben sollen: Wenn System und FW keinen Fehler haben, ist es nicht so einfach. Trotzdem ist es wesentlich einfacher über eine andere Anwendung als der FW einzusteigen. Der Webserver bzw seine Anwendungsscripte haben um Welten mehr Lücken als der Kernel resp iptables. Der Klassiker wäre ein schlecht abgesichertes Upload Script. Oder Anwendungen wie Wikis und Blogs. Oder ganz allgemein veraltete Versionen von solchen Teilen.
Du hast natürlich Recht, dass auch der Kernel oder iptables selber Lücken haben können. Dem kannst du aber mit einem regelmässigem Update recht gut gegenhalten. Lücken beim Kernel - und die Firewall resp die netfilter sind Kernelbestandteil - werden in der Regel sehr schnell gefixt. Und die Distributoren bauen diese Fixes sehr schnell ein. Leider gilt das nur für echte Distris. Bei der Firmware der DS bist du darauf angewiesen, dass Synology das schnell einbaut. War auch mit ein Grund weshalb ich mir ein Debian auf der DS installiert habe

Gruss

tobi