IPtables: Alles Blocken (Stealth)
Hallo zusammen, kennt einer von euch eine FW Regel im IPtables um a) alles von eth1 (Internet) zu blocken b) Die Ports nicht blocken, sondern auf Stealth (reject?) stellen c) Port xxx aus dem Internet ins Netzwerk zu lassen Danke schonmal und bis dann Stefan
On Wed, 13 Nov 2002, Stefan Eggert wrote:
kennt einer von euch eine FW Regel im IPtables um
a) alles von eth1 (Internet) zu blocken
iptables -I INPUT 1 -i eth1 -j DROP iptables -I FORWARD 1 -i eth1 -j DROP
b) Die Ports nicht blocken, sondern auf Stealth (reject?) stellen
iptables -I INPUT 1 -i eth1 -j REJECT iptables -I FORWARD 1 -i eth1 -j REJECT
c) Port xxx aus dem Internet ins Netzwerk zu lassen
iptables -I FORWARD 1 -i eth1 -o eth0 -j ACCEPT # ist zusammen mit a) und/oder b) aber unsinnig
a) alles von eth1 (Internet) zu blocken
iptables -I INPUT 1 -i eth1 -j DROP iptables -I FORWARD 1 -i eth1 -j DROP
b) Die Ports nicht blocken, sondern auf Stealth (reject?) stellen
iptables -I INPUT 1 -i eth1 -j REJECT iptables -I FORWARD 1 -i eth1 -j REJECT
c) Port xxx aus dem Internet ins Netzwerk zu lassen
iptables -I FORWARD 1 -i eth1 -o eth0 -j ACCEPT # ist zusammen mit a) und/oder b) aber unsinnig
Hi!! Erstmal danke für die schnelle hilfe. Vohaben so: Erst will ich alle Ports rejecten Danach will ich dann die Ports einzeln Konfigurieren bzw. durchlassen. z.B. Port 22. Alles andere soll auf diesem Interface von draußen nach drinnen reject werden. Schönen Gruß Stefan
On Wed, 13 Nov 2002, Stefan Eggert wrote:
a) alles von eth1 (Internet) zu blocken
iptables -I INPUT 1 -i eth1 -j DROP iptables -I FORWARD 1 -i eth1 -j DROP
b) Die Ports nicht blocken, sondern auf Stealth (reject?) stellen
iptables -I INPUT 1 -i eth1 -j REJECT iptables -I FORWARD 1 -i eth1 -j REJECT
c) Port xxx aus dem Internet ins Netzwerk zu lassen
iptables -I FORWARD 1 -i eth1 -o eth0 -j ACCEPT # ist zusammen mit a) und/oder b) aber unsinnig
Vohaben so:
Erst will ich alle Ports rejecten Danach will ich dann die Ports einzeln Konfigurieren bzw. durchlassen.
z.B. Port 22. Alles andere soll auf diesem Interface von draußen nach drinnen reject werden.
das macht man anders, z.B. so: iptables -P INPUT DROP # Vorsicht, das ist evtl. der Ast auf dem .. iptables -P FORWARD DROP iptables -I FORWARD -i eth1 -p tcp --sdport 22 -j ACCEPT Achim
das macht man anders, z.B. so: iptables -P INPUT DROP # Vorsicht, das ist evtl. der Ast auf dem .. iptables -P FORWARD DROP iptables -I FORWARD -i eth1 -p tcp --sdport 22 -j ACCEPT
Hallo Achim, wennich dann das erste auf iptables -i eth1 -P INPUT DROP setze, sollte er doch nun nur alle anfragen von Device eth1 blocken, eth0 (LAN) gnadenlos durchlassen. Stefan
On Wed, 13 Nov 2002, Stefan Eggert wrote:
das macht man anders, z.B. so: iptables -P INPUT DROP # Vorsicht, das ist evtl. der Ast auf dem .. iptables -P FORWARD DROP iptables -I FORWARD -i eth1 -p tcp --sdport 22 -j ACCEPT
Hallo Achim,
wennich dann das erste auf iptables -i eth1 -P INPUT DROP setze, sollte er doch nun nur alle anfragen von Device eth1 blocken, eth0 (LAN) gnadenlos durchlassen.
AFAIK geht das nicht, einfach ausprobieren. Die Chain ist nicht ans Interface gebunden, nur die Rules dafuer. Achim
Am Dienstag, 12. November 2002 20:59 schrieb Achim Hoffmann:
On Wed, 13 Nov 2002, Stefan Eggert wrote:
das macht man anders, z.B. so: iptables -P INPUT DROP # Vorsicht, das ist evtl. der Ast auf
Das ist die Default-Regel (Basis _P_olicy), das heißt, das wird mit allen Paketen gemacht, für die keine spezielle Regel der betreffenden Chain zutrifft. Sollte man immer so setzen!
dem .. iptables -P FORWARD DROP
Dito für FORWARD. Diese Regel steht aber immer am Ende einer Regelkette (auch wenn sie zuerst gesetzt wird).
iptables -I FORWARD -i eth1 -p tcp --sdport 22 -j ACCEPT
Warum --sdport? Und warum 22?
Hallo Achim,
wennich dann das erste auf iptables -i eth1 -P INPUT DROP setze, sollte er doch nun nur alle anfragen von Device eth1 blocken, eth0 (LAN) gnadenlos durchlassen.
AFAIK geht das nicht, einfach ausprobieren. Die Chain ist nicht ans Interface gebunden,
Hä?
nur die Rules dafuer.
Nur, wenn ich es angebe. -- Gruß MaxX
Stefan Eggert wrote:
das macht man anders, z.B. so: iptables -P INPUT DROP # Vorsicht, das ist evtl. der Ast auf dem .. iptables -P FORWARD DROP iptables -I FORWARD -i eth1 -p tcp --sdport 22 -j ACCEPT
wennich dann das erste auf iptables -i eth1 -P INPUT DROP setze, sollte er doch nun nur alle anfragen von Device eth1 blocken, eth0 (LAN) gnadenlos durchlassen.
'-i' im zusammenhang mit '-P' geht nicht. micha
Am Mittwoch, 13. November 2002 21:35 schrieb Stefan Eggert:
a) alles von eth1 (Internet) zu blocken
iptables -I INPUT 1 -i eth1 -j DROP iptables -I FORWARD 1 -i eth1 -j DROP
Falsch, er will ja alles _von_ eth1 blocken und nicht _zu_ eth1.
b) Die Ports nicht blocken, sondern auf Stealth (reject?) stellen
iptables -I INPUT 1 -i eth1 -j REJECT iptables -I FORWARD 1 -i eth1 -j REJECT
c) Port xxx aus dem Internet ins Netzwerk zu lassen
iptables -I FORWARD 1 -i eth1 -o eth0 -j ACCEPT
Falsch, wo bleibt der Port?
# ist zusammen mit a) und/oder b) aber unsinnig
Wieso?
Hi!!
Erstmal danke für die schnelle hilfe. Vohaben so:
Erst will ich alle Ports rejecten
Dann ist alles dicht.
Danach will ich dann die Ports einzeln Konfigurieren bzw. durchlassen.
Geht nicht mehr, ist ja schon alles dicht.
z.B. Port 22. Alles andere soll auf diesem Interface von draußen nach drinnen reject werden.
Wird ja schon (Siehe oben) ---> man iptables! -- Gruß MaxX
Stefan Eggert wrote:
kennt einer von euch eine FW Regel im IPtables um
a) alles von eth1 (Internet) zu blocken
IPTABLES -A INPUT -i eth1 -j REJECT
b) Die Ports nicht blocken, sondern auf Stealth (reject?) stellen
stealth gibt es nicht.
c) Port xxx aus dem Internet ins Netzwerk zu lassen
Am Dienstag, 12. November 2002 20:31 schrieb Michael Meyer:
Stefan Eggert wrote:
kennt einer von euch eine FW Regel im IPtables um
a) alles von eth1 (Internet) zu blocken
IPTABLES -A INPUT -i eth1 -j REJECT
Flachs! -o eth1 muss es heißen (zumindest bei der Vorgabe).
b) Die Ports nicht blocken, sondern auf Stealth (reject?) stellen
stealth gibt es nicht.
c) Port xxx aus dem Internet ins Netzwerk zu lassen
'http://www.netfilter.org/documentation/index.html'
micha
-- Gruß MaxX
Matthias Houdek wrote:
kennt einer von euch eine FW Regel im IPtables um
a) alles von eth1 (Internet) zu blocken
IPTABLES -A INPUT -i eth1 -j REJECT
Flachs! -o eth1 muss es heißen (zumindest bei der Vorgabe).
er will nicht das aus dem internet via eth1 irgendwas reinkommt. zumindest habe ich die frage so verstanden. da macht '-o' wenig sinn. man iptables: | -o, --out-interface [!] [name] | | Optional name of an interface via which a packet is going to be | sent (for packets entering the FORWARD, OUTPUT and POSTROUTING | chains). micha
Am Mittwoch, 13. November 2002 00:54 schrieb Michael Meyer:
Matthias Houdek wrote:
kennt einer von euch eine FW Regel im IPtables um
a) alles von eth1 (Internet) zu blocken
IPTABLES -A INPUT -i eth1 -j REJECT
Flachs! -o eth1 muss es heißen (zumindest bei der Vorgabe).
er will nicht das aus dem internet via eth1 irgendwas reinkommt. zumindest habe ich die frage so verstanden.
da macht '-o' wenig sinn.
man iptables: | -o, --out-interface [!] [name] | | Optional name of an interface via which a packet is going to be | sent (for packets entering the FORWARD, OUTPUT and POSTROUTING | chains).
Eben, er will alles von eth1 blocken, nicht zu eth1. Und es betrifft natürlich auch die OUTPUT-Chain und nicht INPUT. -- Gruß MaxX
lieber Matthias, entschuldige dass ich etwas direkt werde, aber deine letzen 3 Postings zu diesem Thema waren, na sagen wir mal vorsichtig, unueberlegt. Die Zitate spare ich mir ... 1. was "von" bzw. "zu" eth1 bedeutet ist kontextabhaengig, d.h. ob ich von aussen auf die Firwall schaue oder auf der Firewall selbst sitzte, oder ob die Firewall ein Router ist. Aller Antworten hatten wohl den gleichen Kontext angenommen wie der Fragende, nur du siehst es anders (was nicht unbedingt verkehrt ist, aber darum anzunehmen dass das alle so sehen ist FALSCH, nicht die anderen Antworten). Im Kontext von iptables bedeutet "aussen" immer vor dem Interface, also auf dem Kabel, und "innen" tcp/ip-Treiber. Zwischen "aussen" und "innen" arbeitet iptables. Bei der FORWARD Chain ist es geringfuehgig anders. 2. -P und -i sind inkompatible, weil -P die Chain (oder sagen wir genauer: die letzte Regel der Chain) bearbeitet. waehrend -i auf genau eine Regel innerhalb der Chain zutrifft. Statt "Hä?" zu schreiben also besser: man iptables ;-) 3. die Regel mit --sport 22 wurde angegeben weil explizit nach ssh gefragt wurde, schau einfach ins Archiv 4. klar ist der Rechner zu wenn man -P INPUT DROP macht, aber nur wenn keine weiteren Regeln angegeben werden. Das ist ein wesentlicher Unterschied zu iptables -A INPUT -j DROP und wenn du meine Beispiele anschaust, dann siehst du, dass ich nicht -A, sondern immer -I verwendet habe! Wenn dir -A -I und -P unklar ist: man iptables Damit sind die Regeln nicht unsinnig, sondern sie machen ungefaehr (oder vielleicht sogar genau) das was gefragt wurde. Achim
Am Mittwoch, 13. November 2002 09:48 schrieb Achim Hoffmann:
lieber Matthias, entschuldige dass ich etwas direkt werde, aber deine letzen 3 Postings zu diesem Thema waren, na sagen wir mal vorsichtig, unueberlegt. Die Zitate spare ich mir ...
1. was "von" bzw. "zu" eth1 bedeutet ist kontextabhaengig, d.h. ob ich von aussen auf die Firwall schaue oder auf der Firewall selbst sitzte, oder ob die Firewall ein Router ist. Aller Antworten hatten wohl den gleichen Kontext angenommen wie der Fragende, nur du siehst es anders (was nicht unbedingt verkehrt ist, aber darum anzunehmen dass das alle so sehen ist FALSCH, nicht die anderen Antworten). Im Kontext von iptables bedeutet "aussen" immer vor dem Interface, also auf dem Kabel, und "innen" tcp/ip-Treiber. Zwischen "aussen" und "innen" arbeitet iptables. Bei der FORWARD Chain ist es geringfuehgig anders.
Sicher, es ist Ansichtssache. Als Firewall betrachte ich das System, iptables ist keine Firewall. Und da ist "von eth1" das, was von diesem NIC kommt. Aber er meinte es wirklich anders; ich hab auch ehrlich gesagt nicht viel drüber nachgedacht, was er damit bezwecken wollte, denn es würde nicht viel Sinn machen.
2. -P und -i sind inkompatible, weil -P die Chain (oder sagen wir genauer: die letzte Regel der Chain) bearbeitet. waehrend -i auf genau eine Regel innerhalb der Chain zutrifft. Statt "Hä?" zu schreiben also besser: man iptables ;-)
Das ist richtig, und ich hab einfach nicht genau gelesen. Ich sollte einfach in schlaftrunkenem Zustand die Liste meiden (oder vielleicht gleich den Computer? ;-)
3. die Regel mit --sport 22 wurde angegeben weil explizit nach ssh gefragt wurde, schau einfach ins Archiv
Find ich nicht, ist aber auch egal.
4. klar ist der Rechner zu wenn man -P INPUT DROP macht, aber nur wenn keine weiteren Regeln angegeben werden. Das ist ein wesentlicher Unterschied zu iptables -A INPUT -j DROP und wenn du meine Beispiele anschaust, dann siehst du, dass ich nicht -A, sondern immer -I verwendet habe! Wenn dir -A -I und -P unklar ist: man iptables
Richtig, aber er wollte ja _erst_ mal alles dicht machen, mit -P <chain> DROP mach ich alles dicht, was bis hierher in dieser Chain noch keine Regel gefunden hat. Das ist ein kleiner, aber feiner Unterschied.
Damit sind die Regeln nicht unsinnig, sondern sie machen ungefaehr (oder vielleicht sogar genau) das was gefragt wurde.
Die Frage ist, ob das auch von Stefan alles verstanden wurde. Denn nichts ist IMHO schlimmer, als mit Halbwissen einen Paketfilter zu installieren und dann zu meinen, man habe seinen PC mit einer geilen Firewall sicher(er) gemacht. Zunächst sollte man sich im Klaren darüber werden, wie die Kommunikation über halbwegs funktioniert. Dann sollte man sich Gedanken darüber machen, was an Kommuniaktion überhaupt laufen kann - und was ich davon auf welchem Interface mit welchen Regeln erlauben will. Und dann kann man entscheiden, wie welche Regeln gesetzt werden sollen. Deine angegebenen Regeln sind unsinnig, denn sie machen höchstens ungefähr das, was gefragt wurde. Ist aber keine Kritik an deinen Regeln, denn die Fragestellung war schon nicht eindeutig. Alles in allem ist das aber ein sehr interessantes Thema und ich kann Stefan nur empfehlen, sich intensiv mit der Materie zu befassen. Das Script in der Mail von Joerg Henner ist ganz interesant, aber wirklich ehrlich durchkämpfen und verstehen. -- Gruß MaxX
Nachtrag: (Siehe unten) Am Mittwoch, 13. November 2002 19:47 schrieb Matthias Houdek:
Am Mittwoch, 13. November 2002 09:48 schrieb Achim Hoffmann:
lieber Matthias, entschuldige dass ich etwas direkt werde, aber deine letzen 3 Postings zu diesem Thema waren, na sagen wir mal vorsichtig, unueberlegt. Die Zitate spare ich mir ...
1. was "von" bzw. "zu" eth1 bedeutet ist kontextabhaengig, d.h. ob ich von aussen auf die Firwall schaue oder auf der Firewall selbst sitzte, oder ob die Firewall ein Router ist. Aller Antworten hatten wohl den gleichen Kontext angenommen wie der Fragende, nur du siehst es anders (was nicht unbedingt verkehrt ist, aber darum anzunehmen dass das alle so sehen ist FALSCH, nicht die anderen Antworten). Im Kontext von iptables bedeutet "aussen" immer vor dem Interface, also auf dem Kabel, und "innen" tcp/ip-Treiber. Zwischen "aussen" und "innen" arbeitet iptables. Bei der FORWARD Chain ist es geringfuehgig anders.
Sicher, es ist Ansichtssache. Als Firewall betrachte ich das System, iptables ist keine Firewall. Und da ist "von eth1" das, was von diesem NIC kommt. Aber er meinte es wirklich anders; ich hab auch ehrlich gesagt nicht viel drüber nachgedacht, was er damit bezwecken wollte, denn es würde nicht viel Sinn machen.
2. -P und -i sind inkompatible, weil -P die Chain (oder sagen wir genauer: die letzte Regel der Chain) bearbeitet. waehrend -i auf genau eine Regel innerhalb der Chain zutrifft. Statt "Hä?" zu schreiben also besser: man iptables ;-)
Das ist richtig, und ich hab einfach nicht genau gelesen. Ich sollte einfach in schlaftrunkenem Zustand die Liste meiden (oder vielleicht gleich den Computer? ;-)
3. die Regel mit --sport 22 wurde angegeben weil explizit nach ssh gefragt wurde, schau einfach ins Archiv
Find ich nicht, ist aber auch egal.
4. klar ist der Rechner zu wenn man -P INPUT DROP macht, aber nur wenn keine weiteren Regeln angegeben werden. Das ist ein wesentlicher Unterschied zu iptables -A INPUT -j DROP und wenn du meine Beispiele anschaust, dann siehst du, dass ich nicht -A, sondern immer -I verwendet habe! Wenn dir -A -I und -P unklar ist: man iptables
Richtig, aber er wollte ja _erst_ mal alles dicht machen, mit -P <chain> DROP mach ich alles dicht, was bis hierher in dieser Chain noch keine Regel gefunden hat. Das ist ein kleiner, aber feiner Unterschied.
Übrigens finde ich -I ohne Angabe eines konkreten Ortes nicht sehr günstig, -A ist da übersichtlicher, denn die Regeln werden dann in der Reihenfolge abgearbeitet, in der man sie eingegeben hat. Macht irgendwie mehr Sinn, finde ich. -I ist eher dafür gedacht, nachträglich (z.B. nach einem bestimmten Ereignis) eine bestimmte Regel zusätzlich an eine definierte Stelle in die Chain einzufügen. Aber wem sag ich das ;-)
Damit sind die Regeln nicht unsinnig, sondern sie machen ungefaehr (oder vielleicht sogar genau) das was gefragt wurde.
Die Frage ist, ob das auch von Stefan alles verstanden wurde. Denn nichts ist IMHO schlimmer, als mit Halbwissen einen Paketfilter zu installieren und dann zu meinen, man habe seinen PC mit einer geilen Firewall sicher(er) gemacht.
Zunächst sollte man sich im Klaren darüber werden, wie die Kommunikation über halbwegs funktioniert. Dann sollte man sich Gedanken darüber machen, was an Kommuniaktion überhaupt laufen kann - und was ich davon auf welchem Interface mit welchen Regeln erlauben will. Und dann kann man entscheiden, wie welche Regeln gesetzt werden sollen.
Deine angegebenen Regeln sind unsinnig, denn sie machen höchstens ungefähr das, was gefragt wurde. Ist aber keine Kritik an deinen Regeln, denn die Fragestellung war schon nicht eindeutig.
Alles in allem ist das aber ein sehr interessantes Thema und ich kann Stefan nur empfehlen, sich intensiv mit der Materie zu befassen. Das Script in der Mail von Joerg Henner ist ganz interesant, aber wirklich ehrlich durchkämpfen und verstehen.
-- Gruß MaxX
Matthias Houdek wrote:
kennt einer von euch eine FW Regel im IPtables um
a) alles von eth1 (Internet) zu blocken
IPTABLES -A INPUT -i eth1 -j REJECT
Flachs! -o eth1 muss es heißen (zumindest bei der Vorgabe).
er will nicht das aus dem internet via eth1 irgendwas reinkommt. zumindest habe ich die frage so verstanden.
da macht '-o' wenig sinn.
man iptables: | -o, --out-interface [!] [name] | | Optional name of an interface via which a packet is going to be | sent (for packets entering the FORWARD, OUTPUT and POSTROUTING | chains).
Eben, er will alles von eth1 blocken, nicht zu eth1. Und es betrifft natürlich auch die OUTPUT-Chain und nicht INPUT.
nein, ich denke _du_ verstehst die frage falsch. er will das alles vom internet geblockt wird. das device das 'ins internet zeigt' ist bei ihm eth1. aber vieleicht klärt Stefan uns einfach auf, wie die frage gemeint war, und wir können aufhören darüber zu spekulieren. micha
nein, ich denke _du_ verstehst die frage falsch. er will das alles vom
internet geblockt wird. das device das 'ins internet zeigt' ist bei ihm eth1. aber vieleicht klärt Stefan uns einfach auf, wie die frage gemeint war, und wir können aufhören darüber zu spekulieren.
Hallo zusammen, hier nochmal genauer: also ich habe eine Firewall welche als Gateway funktioniert. eth0 ist mein LAN eth1 ist mein Internet. Ich möchte im Prinzip meine Firewall auf dem Interface eth1 so abschotten, das es nichts (aus dem Internet) durchlässt oder annimmt. Danach möchte ich einzelne Ports freigeben, welche auf meinen Server über eth1 ausdem Internet zugreifen dürfen. (z.B. ssh) Hoffe das ist ok so!! Bis dann, Stefan+
On Don, 14 Nov 2002, Stefan Eggert wrote:
also ich habe eine Firewall welche als Gateway funktioniert.
eth0 ist mein LAN eth1 ist mein Internet.
Ich möchte im Prinzip meine Firewall auf dem Interface eth1 so abschotten, das es nichts (aus dem Internet) durchlässt oder annimmt. Danach möchte ich einzelne Ports freigeben, welche auf meinen Server über eth1 ausdem Internet zugreifen dürfen. (z.B. ssh)
Hier mal ein erster Ansatz für dich: http://uni-unfug.de/scripts/firewall.no-routing Alles andere kannst du dir aus den HowTo's und MAN-Pages zusammen stellen. Gruss, -- Jörg Henner Fon: +49 (7 11) 48 90 83 - 0 ETES - EDV-Systemhaus GbR Fax: +49 (7 11) 48 90 83 - 50 Libanonstrasse 58 A * D-70184 Stuttgart Web: http://www.etes.de ______________________________________ Inflex - eMail Scanning and Protection Queries to: postmaster@etes.de
Stefan Eggert wrote:
nein, ich denke _du_ verstehst die frage falsch. er will das alles vom
internet geblockt wird. das device das 'ins internet zeigt' ist bei ihm eth1. aber vieleicht klärt Stefan uns einfach auf, wie die frage gemeint war, und wir können aufhören darüber zu spekulieren.
hier nochmal genauer:
also ich habe eine Firewall welche als Gateway funktioniert.
eth0 ist mein LAN eth1 ist mein Internet.
Ich möchte im Prinzip meine Firewall auf dem Interface eth1 so abschotten, das es nichts (aus dem Internet) durchlässt oder annimmt. Danach möchte ich einzelne Ports freigeben, welche auf meinen Server über eth1 ausdem Internet zugreifen dürfen. (z.B. ssh)
Hoffe das ist ok so!!
'http://www.adsl4linux.de/howtos/lan/chapter5.php#5.2' 'http://www.linuxfaq.de/f/cache/382.html' 'http://www.netfilter.org/documentation/index.html'. micha
Am Donnerstag, 14. November 2002 16:46 schrieb Stefan Eggert:
nein, ich denke _du_ verstehst die frage falsch. er will das alles vom
internet geblockt wird. das device das 'ins internet zeigt' ist bei ihm eth1. aber vieleicht klärt Stefan uns einfach auf, wie die frage gemeint war, und wir können aufhören darüber zu spekulieren.
Hallo zusammen,
hier nochmal genauer:
also ich habe eine Firewall welche als Gateway funktioniert.
eth0 ist mein LAN eth1 ist mein Internet.
Ich möchte im Prinzip meine Firewall auf dem Interface eth1 so abschotten, das es nichts (aus dem Internet) durchlässt oder annimmt. Danach möchte ich einzelne Ports freigeben, welche auf meinen Server über eth1 ausdem Internet zugreifen dürfen. (z.B. ssh)
Hoffe das ist ok so!!
Gut, das sieht doch schon etwas klarer aus. Ich präzisiere mal weiter: Du willst prinzipiell keinen Datenverkehr zulassen, den du nicht ausdrücklich erlaubt hast: (zuvor natürlich iptables laden und Kernel-Parameter setzen ;-) iptables -P INPUT -j DROP iptables -P OUTPUT -j DROP iptables -P FORWARD -j DROP (da du ja 2 Netzwerkkarten hast) Diese Regeln werden immer ausgeführt, wenn innerhalb der entsprechenden Regelkette nichts anderes für das jeweilige Datenpaket greift. Dann solltest du auf jeden Fall die Netzwerkkarte lo freigeben (ja, die gibt es auch, die sollte man nicht vergessen *g*): iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT Wenn du jetzt auch jeglichen Datenverkehr ins und iptables -A INPUT -i lo -j ACCEPT aus dem LAN erlauben willst, dann das Gleiche noch einmal, aber mit eth0 anstatt lo. Und jetzt kannst du anfangen, weitere Regeln zu setzen, wobei du sinnvoller weise auch darauf achten solltest, ob es sich um Pakete aus neuen (NEW) oder bestehenden (ESTABLISHED bzw. RELATED) Verbindungen handelt. Denn einfach keine Pakete von außen rein zu lassen wäre auch falsch, wenn man Antworten auf eigene Anfragen zu einem Verbindungsaufbau erhalten will. Hier hilft dir einschlägige Literatur weiter. -- Gruß MaxX, Quotenossi und Plenker(er) 8-)
Matthias Houdek wrote:
iptables -P INPUT -j DROP iptables -P OUTPUT -j DROP iptables -P FORWARD -j DROP (da du ja 2 Netzwerkkarten hast)
Diese Regeln werden immer ausgeführt, wenn innerhalb der entsprechenden Regelkette nichts anderes für das jeweilige Datenpaket greift.
warum immer 'drop'? 'http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html#Deny' micha
Am Mittwoch, 13. November 2002 21:42 schrieb Michael Meyer:
Matthias Houdek wrote:
iptables -P INPUT -j DROP iptables -P OUTPUT -j DROP iptables -P FORWARD -j DROP (da du ja 2 Netzwerkkarten hast)
Diese Regeln werden immer ausgeführt, wenn innerhalb der entsprechenden Regelkette nichts anderes für das jeweilige Datenpaket greift.
warum immer 'drop'? 'http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html#Deny'
Ich kenne diesen Streit um DENY und REJECT. Ich persönlich halte ein REJECT nur bei einigen Diensten für wirklich sinnvoll, was ich dann explizit auch anweise. Oder schickst du auch auf jede Art von Werbung eine freundliche Karte mit dem Hinweis. dass du sie nicht möchtest? Es ist letztendlich für die innere Funktionalität egal, also meinetwegen auch REJECT. Wie man halt möchte, es gibt in dieser Frage IMHO keine eindeutig richtige Lösung. -- Gruß MaxX
Matthias Houdek wrote:
warum immer 'drop'? 'http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html#Deny'
Ich kenne diesen Streit um DENY und REJECT. Ich persönlich halte ein REJECT nur bei einigen Diensten für wirklich sinnvoll, was ich dann explizit auch
welche dienste sind das? und vor allem welche nicht? und warum ist dort ein `drop` besser?
anweise. Oder schickst du auch auf jede Art von Werbung eine freundliche Karte mit dem Hinweis. dass du sie nicht möchtest?
mir fällt es schwer, unerwünschte werbung mit dem wunsch nach aufbau einer verbindung zu vergleichen. warum sollte ich dem anfragenden nicht mitteilen das auf dem port, zu dem er sich verbinden möchte, nichts ist?
Es ist letztendlich für die innere Funktionalität egal, also meinetwegen auch REJECT. Wie man halt möchte, es gibt in dieser Frage IMHO keine eindeutig richtige Lösung.
doch, reject als default ... ;-) micha
Am Donnerstag, 14. November 2002 16:08 schrieb Michael Meyer:
Matthias Houdek wrote:
warum immer 'drop'? 'http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html#Deny'
Ich kenne diesen Streit um DENY und REJECT. Ich persönlich halte ein REJECT nur bei einigen Diensten für wirklich sinnvoll, was ich dann explizit auch
welche dienste sind das? und vor allem welche nicht? und warum ist dort ein `drop` besser?
Fast alle, und ein DROP finde ich besser, weil es den Traffic minimiert. Nicht viel, aber die Masse macht es. Kritisch wird es IMHO nur dort, wo aufgrund der nichtbeantworteten Anfrage während eines langen Timeouts ggf. anderes blockiert wird.
anweise. Oder schickst du auch auf jede Art von Werbung eine freundliche Karte mit dem Hinweis. dass du sie nicht möchtest?
mir fällt es schwer, unerwünschte werbung mit dem wunsch nach aufbau einer verbindung zu vergleichen.
Unerwünschte Werbung ist auch nichts anderes als der ungezielte Wunsch nach einem Verbindungsaufbau.
warum sollte ich dem anfragenden nicht mitteilen das auf dem port, zu dem er sich verbinden möchte, nichts ist?
Warum sollte ich reagieren, wenn jemand ungefragt auf einem für die allgemeinen Kommunikationsdienste unüblichen Port versucht, meinen Rechner zu erreichen. Wer versucht, mir direkt eine Mail zuzustellen, eine Telnet-Verbindung aufzubauen oder einen FTP- oder HTTP-Connect probiert, bekommt auch eine Antwort, dass das (zur Zeit) nicht geht. Aber Anfragen auf allen 65335 Ports zu beantworten ...
Es ist letztendlich für die innere Funktionalität egal, also meinetwegen auch REJECT. Wie man halt möchte, es gibt in dieser Frage IMHO keine eindeutig richtige Lösung.
doch, reject als default ... ;-)
Wenn das für dich die richtige Lösung ist ... -- Gruß MaxX
On Wed, 13 Nov 2002, Michael Meyer wrote:
Matthias Houdek wrote:
iptables -P INPUT -j DROP iptables -P OUTPUT -j DROP iptables -P FORWARD -j DROP (da du ja 2 Netzwerkkarten hast)
Diese Regeln werden immer ausgeführt, wenn innerhalb der entsprechenden Regelkette nichts anderes für das jeweilige Datenpaket greift.
warum immer 'drop'? 'http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html#Deny'
oder: REJECT vs. DROP/DENY wenn man Firewalls (auch ein Packetfilter ist eine Firewall im weiten Sinn, gell Matthias:), einrichtet muss man sehr pedantisch und paranoid sein, frei nach Murphy: das unwahrscheinlichste passiert zuerst. Also wird alles weggeschmissen was unerwuenscht ist. CRacker muss dann erstmal Aufwand treiben um festzustellen, dass da was ist (z.B. ein Packetfilter). Wenn der ein REJECT kriegt, dann hat er den sicheren Beweis dass er weiter- machen kann (auf diesem Port), genau das was ein Scan rausfinden will ! Security by Obscurity ist zwar nicht zu empfehlen, aber in diesem Fall ist es ein zusaetzlicher Schutz, zumin. vor dusseligen Script-Kiddies. Und paranoid wie ich bin, versendet eine Firewall niemals ICMP, und erlaubt es auch nicht (wer wissen will warum schaut sich dazu an wie diverse Trojaner kommunizieren, z.B. BackOrifice). AFAIK ist ICMP heute im Internet obsolete, allenfalls in geschlossenen Netzen zur inter-router-kommunikation sinnvoll. Erst wenn Sicherheit kein Thema (mehr) ist denke ich darueber wieder nach. Achim
Achim Hoffmann wrote:
iptables -P INPUT -j DROP iptables -P OUTPUT -j DROP iptables -P FORWARD -j DROP (da du ja 2 Netzwerkkarten hast)
Diese Regeln werden immer ausgeführt, wenn innerhalb der entsprechenden Regelkette nichts anderes für das jeweilige Datenpaket greift.
warum immer 'drop'? 'http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html#Deny'
oder: REJECT vs. DROP/DENY
genau.
wenn man Firewalls (auch ein Packetfilter ist eine Firewall im weiten Sinn, gell Matthias:), einrichtet muss man sehr pedantisch und paranoid sein, frei nach Murphy: das unwahrscheinlichste passiert zuerst.
eine firewall ist ein konzept. ein packetfilter ist immer nur ein teil dieses konzeptes.
Also wird alles weggeschmissen was unerwuenscht ist. CRacker muss dann erstmal Aufwand treiben um festzustellen, dass da was ist (z.B. ein Packetfilter). Wenn der ein REJECT kriegt, dann hat er den sicheren Beweis dass er weiter- machen kann (auf diesem Port), genau das was ein Scan rausfinden will !
Security by Obscurity ist zwar nicht zu empfehlen, aber in diesem Fall ist es ein zusaetzlicher Schutz, zumin. vor dusseligen Script-Kiddies.
auch bei einem drop/deny ist sofort erkennbar das dort etwas am anderen ende ist. schaue dir dazu mal 'http://logi.cc/linux/reject_or_deny.php3' an.
Und paranoid wie ich bin, versendet eine Firewall niemals ICMP, und erlaubt es auch nicht (wer wissen will warum schaut sich dazu an wie diverse Trojaner kommunizieren, z.B. BackOrifice). AFAIK ist ICMP heute im Internet obsolete, allenfalls in geschlossenen Netzen zur inter-router-kommunikation sinnvoll. Erst wenn Sicherheit kein Thema (mehr) ist denke ich darueber wieder nach.
was ist mit ping,traceroute,fragmentation-needed etc? es gab zu icmp mal einen interessanten thread in d.c.s.m. http://groups.google.de/groups?ie=ISO-8859-1&as_umsgid=aj3bsp%24180d8g%241%40ID-24860.news.dfncis.de&lr=&hl=de micha
On Thu, 14 Nov 2002, Michael Meyer wrote:
Achim Hoffmann wrote:
oder: REJECT vs. DROP/DENY
genau.
Also wird alles weggeschmissen was unerwuenscht ist. CRacker muss dann erstmal Aufwand treiben um festzustellen, dass da was ist (z.B. ein Packetfilter). Wenn der ein REJECT kriegt, dann hat er den sicheren Beweis dass er weiter- machen kann (auf diesem Port), genau das was ein Scan rausfinden will !
Security by Obscurity ist zwar nicht zu empfehlen, aber in diesem Fall ist es ein zusaetzlicher Schutz, zumin. vor dusseligen Script-Kiddies.
auch bei einem drop/deny ist sofort erkennbar das dort etwas am anderen ende ist. schaue dir dazu mal 'http://logi.cc/linux/reject_or_deny.php3' an.
so ein Quatsch (dieser Satz). Unter dem Link ist nichts zu finden was meiner Aussage widerspricht. Bei DROP ist gar nichts erkennbar, es ist nicht zu unterscheiden von "Rechner unter dieser IP laeuft nicht" oder "IP ungueltig" oder "keine listener auf diesem port" (ausser die Firewall ist bezgl. DROP angreifbar). Du wirfst einen Stein in ein schwarze Loch, was siehst/hoerst du? Nichts. Darunter kann man sich dann alles vorstellen, natuerlich auch das Gegenteil. Selbst wenn ein anderer Port unter dieser IP (irgendwie) antwortet, ist das noch kein Hinweis, dass da wirklich ein Rechner ist (Stichwort NAT, port-NAT). Erst wenn ICMP ins Spiel kommt kriegt man evtl. mehr Hinweise, aber genau das habe *ich* ja unterbunden ;-)
Und paranoid wie ich bin, versendet eine Firewall niemals ICMP, und erlaubt es auch nicht (wer wissen will warum schaut sich dazu an wie diverse Trojaner kommunizieren, z.B. BackOrifice). AFAIK ist ICMP heute im Internet obsolete, allenfalls in geschlossenen Netzen zur inter-router-kommunikation sinnvoll. Erst wenn Sicherheit kein Thema (mehr) ist denke ich darueber wieder nach.
was ist mit ping,traceroute,fragmentation-needed etc?
ping: siehe Kommentar bzgl. Trojaner. Obsolete (oder nur nice-to-have) traceroute: geht auch mit UDP fragmentation-needed: betreibt noch jemand ernsthaft Server deren Hardware so antiquiert ist? Einwand ist aber berechtigt. Achim
Achim Hoffmann wrote:
auch bei einem drop/deny ist sofort erkennbar das dort etwas am anderen ende ist. schaue dir dazu mal 'http://logi.cc/linux/reject_or_deny.php3' an.
so ein Quatsch (dieser Satz). Unter dem Link ist nichts zu finden was meiner Aussage widerspricht. Bei DROP ist gar nichts erkennbar, es ist nicht zu unterscheiden von "Rechner unter dieser IP laeuft nicht" oder "IP ungueltig" oder "keine listener auf diesem port" (ausser die Firewall ist bezgl. DROP angreifbar). Du wirfst einen Stein in ein schwarze Loch, was siehst/hoerst du? Nichts. Darunter kann man sich dann alles vorstellen, natuerlich auch das Gegenteil.
ok Achim, schnellkurs für dich: gilt so nur für TCP. kein packetfilter und kein dienst: | SYN wird gesendet, als antwort bekommst du ein RST. packetfilter mit reject: | SYN wird gesendet, als antwort bekommst du ein ICMP 'port unreachable'. | mit iptables ist es möglich ebenfalls ein RST zurück zu senden. packetfilter mit drop/deny: | es gibt keinerlei antwort. die ausbleibende antwort ist der schlüssel. wenn der rechner wirklich nicht da wäre, würdest du von einem router _davor_ ein ICMP 'destination-unreachable' zurück bekommen. das identifiziert den rechner als 'am netz' und das dort ein packetfilter läuft. deshalb wird zum thema 'ACCEPT (or no firewall)' auf der seite, dessen link ich mitgeschickt hatte, auch gesagt: | "The response to the syn-packet (S) is a connection reset (R). This is | clearly different from what you get from an ipchains firewall."
Selbst wenn ein anderer Port unter dieser IP (irgendwie) antwortet, ist das noch kein Hinweis, dass da wirklich ein Rechner ist (Stichwort NAT, port-NAT). Erst wenn ICMP ins Spiel kommt kriegt man evtl. mehr Hinweise, aber genau das habe *ich* ja unterbunden ;-)
Achim, im ernst, das ist unsinn.
Und paranoid wie ich bin, versendet eine Firewall niemals ICMP, und erlaubt es auch nicht (wer wissen will warum schaut sich dazu an wie diverse Trojaner kommunizieren, z.B. BackOrifice). AFAIK ist ICMP heute im Internet obsolete, allenfalls in geschlossenen Netzen zur inter-router-kommunikation sinnvoll. Erst wenn Sicherheit kein Thema (mehr) ist denke ich darueber wieder nach.
was ist mit ping,traceroute,fragmentation-needed etc?
ping: siehe Kommentar bzgl. Trojaner. Obsolete (oder nur nice-to-have) traceroute: geht auch mit UDP fragmentation-needed: betreibt noch jemand ernsthaft Server deren Hardware so antiquiert ist? Einwand ist aber berechtigt.
fragmentation-needed hat nichts mit hardware zu tun. 'http://www.little-idiot.de/firewall/zusammen-57.html' micha
Am Mittwoch, 13. November 2002 21:11 schrieb Stefan Eggert:
Hallo zusammen,
kennt einer von euch eine FW Regel im IPtables um
a) alles von eth1 (Internet) zu blocken
Also keinerlei Pakete dürfen den Rechner ins Internet verlassen? iptables -A OUTPUT -o eth1 -j DROP und falls auch keine Weiterleitungen über eine andere Netzwerkkarte raus nach eth1 gehen sollen, dann zusätzlich: iptables -A FORWARD -o eth1 -j DROP
b) Die Ports nicht blocken, sondern auf Stealth (reject?) stellen
Was meinst du mit "Die Ports nicht blocken"?
c) Port xxx aus dem Internet ins Netzwerk zu lassen
iptables -A INPUT -i eth1 -p TCP --sport xxx -j ACCEPT (für UDP dann analog, wofür du das auch immer brauchst (?)) Steht auch prima in man iptables. -- Gruß MaxX
participants (5)
-
Achim Hoffmann -
Joerg Henner -
Matthias Houdek -
Michael Meyer -
Stefan Eggert