PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : spezifisch zur RedHat-Firewall....



pablovschby
29.04.03, 18:28
Guten Tag...

:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]diese 3zeilen schreibt mir redhat, egal bei welcher firewall-einstellung nach ausführung des graf. firewall-konfigurationsprogi's in die datei /etc/sysconfig/iptables....

nun erhielt ich den tipp, dass diese 3 zeilen tatsächlich ALLES DURCHLASSEn....die Frage: 1. stimmt das,falls nein, was machen die 3zeilen........... 2. wieso macht dann das graf. tool sowas.....3. dann wär das graf. tool ja keine firewall mehr, sondern eine firewall, die soweiso alles durchlässt, egal, was man eingibt

gruss&dnake
pablo

HangLoose
29.04.03, 18:38
hi

ganz kurz nur, muss gleich weg. ich kenne mich mit der RH-Lokkit nicht aus. poste mal bitte die ausgabe von iptables -L(als root).


Gruß HL

pablovschby
29.04.03, 18:43
Chain INPUT (policy ACCEPT)
target prot opt source destination
RH-Lokkit-0-50-INPUT all -- anywhere anywhere

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain RH-Lokkit-0-50-INPUT (1 references)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp dpt:http flags:SYN,RST,ACK/SYN
ACCEPT tcp -- anywhere anywhere tcp dpt:ftp flags:SYN,RST,ACK/SYN
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh flags:SYN,RST,ACK/SYN
ACCEPT tcp -- anywhere anywhere tcp dpt:telnet flags:SYN,RST,ACK/SYN
ACCEPT udp -- anywhere anywhere udp dpt:sunrpc
ACCEPT tcp -- anywhere anywhere tcp dpt:sunrpc flags:SYN,RST,ACK/SYN
ACCEPT all -- anywhere anywhere
ACCEPT udp -- ns10.cablecom.net anywhere udp spt:domain
ACCEPT udp -- ns5.cablecom.net anywhere udp spt:domain
ACCEPT udp -- ns11.cablecom.net anywhere udp spt:domain
ACCEPT udp -- ns4.cablecom.net anywhere udp spt:domain
REJECT tcp -- anywhere anywhere tcp flags:SYN,RST,ACK/SYN reject-with icmp-port-unreachable
REJECT udp -- anywhere anywhere udp reject-with icmp-port-unreachable
ok, das mag ja was sagen....aber grundlegend machen ja die 3zeilen irgendwas.....und das wäre doch eigentlich ne (klare) sache

gruss&danke
pablo

HangLoose
29.04.03, 18:47
hi

ich wollte nur sicher gehen, ob das wirklich die default policy war, die ich fett markiert hatte.

Chain INPUT (policy ACCEPT)
Chain FORWARD (policy ACCEPT)
Chain OUTPUT (policy ACCEPT)

deine default policy steht tatsächlich auf Accept. warum das so ist, kann ich dir leider nicht sagen, da ich mich wiegesagt mit der RH-Lokkit nicht auskenne.


Gruß HL

pablovschby
29.04.03, 18:51
Original geschrieben von HangLoose
deine default policy steht tatsächlich auf Accept. warum das so ist, kann ich dir leider nicht sagen, da ich mich wiegesagt mit der RH-Lokkit nicht auskenne. was???? warum das so ist, kann ich dir aber sagen!!!!!!!!!!!!!!!!!!!!!!!!!!............es ist so, dass ich das file /etc/sysconfig/iptables LÖSCHTE, JAWOHL... und dann das redhat-firewall tool ausführte...und diese tool das file neu schreiben liess.....ich erlaubte: 20,21,http,111............................ und das redhat-tool erlaubte hierbei AALLLEEESSS.......

somit ist das redhat-firewall tool keines, sondern ein tool, um seinen pc unsicherer zu machen.....(ich werde natürlich gerne dews besseren belehrt, aber alles deutet darauf hin..,.)

gruss&danke
pablo

Jasper
29.04.03, 19:10
Original geschrieben von pablovschby
nun erhielt ich den tipp, dass diese 3 zeilen tatsächlich ALLES DURCHLASSEn....die Frage: 1. stimmt das,falls nein, was machen die 3zeilen........... 2. wieso macht dann das graf. tool sowas.....3. dann wär das graf. tool ja

1. nein, das stimmt nicht. diese zeilen legen fest, was mit paketen passieren soll, auf die keine regeln zutreffen.

2. weil es in deinem fall egal ist. sieh dir die regeln an. ganz zum schluss werden alle pakete, die bis dahin durchgekommen sind mit einem sauberen 'reject-with icmp-port-unreachable' abgelehnt. ohne diese finalen regeln würde alles durchgelassen werden. viele lassen diese expliziten drop-regeln weg und setzen die default-policy auf DROP, d.h. alle pakete, für die es keine regel gibt werden gedroppt. das ist nicht korrekt, weil es zu retransmissionen kommt.

gedanken würde ich mir um folgende regel machen:

ACCEPT all -- anywhere anywhere

bei mir generiert lokkit so eine regeln _nicht_.

3. als sicherheitsnetz wäre es wünschenswert wenn die default-policy auf drop stehen würde. dennoch sollten pakete immer mit der korrekten icmp-meldung abgelehnt werden, wie es das tool richtig vormacht.

lokkit ist aber nur ein super-simple tool und für eine komplexere firewall-konfiguration nicht geeignet. hier ist fwbuilder o.ä. besser.

-j

pablovschby
29.04.03, 19:23
scheinbar ist bei dir eh schon alles erlaubt, deine default policy scheint jedenfalls auf Accept zu stehen.

# Firewall configuration written by lokkit
# Manual customization of this file is not recommended.
# Note: ifup-post will punch the current nameservers through the
# firewall; such entries will *not* be listed here.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]das hast ja du geschrieben,,,,,,in dem fall ist es falsch, oder...?*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]es werden alle pakette empfangen...auch die, die weitergeleitet werden, die die reinkommen wie auch rausgehen.....:RH-Lokkit-0-50-INPUT - [0:0]
-A INPUT -j RH-Lokkit-0-50-INPUT
-A RH-Lokkit-0-50-INPUT -p tcp -m tcp --dport 80 --syn -j ACCEPT
-A RH-Lokkit-0-50-INPUT -p tcp -m tcp --dport 21 --syn -j ACCEPT
-A RH-Lokkit-0-50-INPUT -p tcp -m tcp --dport 22 --syn -j ACCEPT
-A RH-Lokkit-0-50-INPUT -p tcp -m tcp --dport 23 --syn -j ACCEPT
-A RH-Lokkit-0-50-INPUT -i lo -j ACCEPT
-A RH-Lokkit-0-50-INPUT -p udp -m udp -s 62.2.17.60 --sport 53 -d 0/0 -j ACCEPT
-A RH-Lokkit-0-50-INPUT -p udp -m udp -s 62.2.24.162 --sport 53 -d 0/0 -j ACCEPT
-A RH-Lokkit-0-50-INPUT -p udp -m udp -s 62.2.17.61 --sport 53 -d 0/0 -j ACCEPT
-A RH-Lokkit-0-50-INPUT -p udp -m udp -s 62.2.24.158 --sport 53 -d 0/0 -j ACCEPTdie pakets werden akzeptiert, wenn sie hier zu dieser policy zutreffen, oder..?-A RH-Lokkit-0-50-INPUT -p tcp -m tcp --syn -j REJECT
-A RH-Lokkit-0-50-INPUT -p udp -m udp -j REJECT
COMMITund alle, die hier noch sind, werden mit der sauberen fehlermeldung....." 'reject-with icmp-port-unreachable' " abgelehnt.......der andere weiss, dass der port gesperrt ist und nicht die station das paket erst gar nicht empfangen hat....stimmts soweit..?

und eine firewall, die dann dropped, würde so aussehen:-A RH-Lokkit-0-50-INPUT -p tcp -m tcp --dport 21 --syn -j ACCEPTzuerst werden pakete akzeptiert, die die reinkommen sollen....und dann am ende:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]...werden alle pakete nicht empfangen/abgelehnt, die nicht explizit erlaubt sind.....stimmts...? wenn ja, hab ich echt heute was gelernt...

gruss&danke
pablo

HangLoose
29.04.03, 20:15
oha da hab ich ja wieder nen kapitalen bock erlegt ;). auf die letzten beiden regeln hab ich gar nicht geachtet.

@pablovschby


das hast ja du geschrieben,,,,,,in dem fall ist es falsch, oder...?

jo das ist falsch, warum hat jasper erläutert. deine letzten beiden regeln *fangen* alle pakete ab, zu denen es keine regel gibt.


und alle, die hier noch sind, werden mit der sauberen fehlermeldung....." 'reject-with icmp-port-unreachable' " abgelehnt.......der andere weiss, dass der port gesperrt ist und nicht die station das paket erst gar nicht empfangen hat....stimmts soweit..?

ja genau so ist es.



...werden alle pakete nicht empfangen/abgelehnt, die nicht explizit erlaubt sind.....stimmts...? wenn ja, hab ich echt heute was gelernt...

ja das stimmt soweit. man kann das ganze auch kombinieren. ich hab in meinem script zum beispiel am anfang des scriptes die default policy auf Drop gesetzt und am ende des scriptes werden alle pakete, für die es keine regel gibt, in eine spezielle log und reject chain geschickt und dort entsprechend behandelt. das ganze sieht dann ungefähr so aus.

.
.
.
$ipt -P INPUT DROP
$ipt -P FORWARD DROP
$ipt -P OUTPUT DROP
.
.
.
# MY_LOG
#_______________

$ipt -N MY_LOG
$ipt -A MY_LOG -p tcp -m limit --limit 7200/h -j LOG --log-prefix "REJECT TCP "
$ipt -A MY_LOG -p udp -m limit --limit 7200/h -j LOG --log-prefix "REJECT UDP "
$ipt -A MY_LOG -p icmp -m limit --limit 7200/h -j LOG --log-prefix "DROP ICMP "


# MY_REJECT-Chain
# MY_REJECT fuellen
#------------------------

$ipt -N MY_REJECT
$ipt -A MY_REJECT -p tcp -j REJECT --reject-with tcp-reset
$ipt -A MY_REJECT -p udp -j REJECT --reject-with icmp-port-unreachable
$ipt -A MY_REJECT -p icmp -j DROP
$ipt -A MY_REJECT -m limit --limit 7200/h -j LOG --log-prefix "REJECT OTHER "
$ipt -A MY_REJECT -j REJECT --reject-with icmp-proto-unreachable

# MY_LOGREJECT
#------------------------

$ipt -N MY_LOGREJECT
$ipt -A MY_LOGREJECT -j MY_LOG
$ipt -A MY_LOGREJECT -j MY_REJECT

.
.#Filterregeln#
.
$ipt -A INPUT -j MY_LOGREJECT
$ipt -A FORWARD -j MY_LOGREJECT
$ipt -A OUTPUT -j MY_LOGREJECT


ps: sorry für die panikmache ;)


Gruß HL

pablovschby
29.04.03, 20:20
wow,.....danke dir...........da gibts für mich sowieso noch einiges zu lernen in diese richtung.....erstmal apache drauf
gruss&danke
pablo

pablovschby
29.04.03, 20:28
ja das stimmt soweit. man kann das ganze auch kombinieren. ich hab in meinem script zum beispiel am anfang des scriptes die default policy auf Drop gesetzt und am ende des scriptes werden alle pakete, für die es keine regel gibt, in eine spezielle log und reject chain geschickt und dort entsprechend behandelt. das ganze sieht dann ungefähr so aus.versteh ich jetzt net, aber der grund is klar.....ich hab ja k.A.-----$ipt -P INPUT DROP
$ipt -P FORWARD DROP
$ipt -P OUTPUT DROP.es werden alle gedroppt............,.#Filterregeln#
.
$ipt -A INPUT -j MY_LOGREJECT
$ipt -A FORWARD -j MY_LOGREJECT
$ipt -A OUTPUT -j MY_LOGREJECTjene pakets, die "MY_LOGREJECT" erlaubt, werden durchgelassen....

*******e, ich les dadrüber besser noch was, jetzt begreif ich überhaupt nix mehr-....

deine iptables würde ja überhaupt nix durchlassen...? mit dem (hier als zweiter) aufgeführtem teil würdest du accepten, was "MY_LOGREJECT" akzeptiert, oder was...?

gruss&danke
pablo

p.s.: wenn du lust hast, könnteest du natürlch zu jedem linienpaar (wie hier die zwei teile) deinen kommentar zugeben, was wieso passiert...........aber nur, wenn du lust hast,.....für mich wär das nat. cool...

HangLoose
29.04.03, 21:15
hi

die default policy wird immer zuletzt ausgeführt, es spielt also eigentlich keine rolle, wo diese im script gesetzt ist. bei den filteregeln selbst ist das nicht so, da kommt es schon auf die position der regel an.

ich zäume das pferd mal von hinten auf. nachdem ein paket meine regeln durchlaufen hat und es keine gibt, die auf dieses paket zutrifft, *landet* das paket in diesem Block

$ipt -A INPUT -j MY_LOGREJECT
$ipt -A FORWARD -j MY_LOGREJECT
$ipt -A OUTPUT -j MY_LOGREJECT

angenommen, das paket trifft in der Input Chain ein und es findet sich keine regel, die dieses paket passieren lassen würde, dann wird das paket mit -j MY_LOGREJECT das paket an die userdefinierte regelkette MY_LOGREJECT weitergeleitet. Diese regelkette befindet sich weiter oben im script.

# MY_LOGREJECT
#------------------------

$ipt -N MY_LOGREJECT
$ipt -A MY_LOGREJECT -j MY_LOG
$ipt -A MY_LOGREJECT -j MY_REJECT

in dieser wiederum wird entschieden, das das paket einmal nach MY_LOG, zum loggen des abgelehnten paketes, geschickt wird und einmal nach MY_REJECT. in MY_REJECT wird dann entschieden, was mit dem paket passieren soll. handelt es sich z.b. um ein udp-paket wird ein *port-unreachable* verschickt und das paket fallengelassen.

# MY_REJECT-Chain
# MY_REJECT fuellen
#------------------------

$ipt -N MY_REJECT
$ipt -A MY_REJECT -p tcp -j REJECT --reject-with tcp-reset
$ipt -A MY_REJECT -p udp -j REJECT --reject-with icmp-port-unreachable
$ipt -A MY_REJECT -p icmp -j DROP
$ipt -A MY_REJECT -m limit --limit 7200/h -j LOG --log-prefix "REJECT OTHER "
$ipt -A MY_REJECT -j REJECT --reject-with icmp-proto-unreachable


ich hoffe, ich hab mich einigermaßen klar ausgedrückt ;). ich hänge mal mein gesamtes script an, dann wird es vermutlich etwas klarer.



Gruß HL

pablovschby
29.04.03, 21:51
angenommen, das paket trifft in der Input Chain ein und es findet sich keine regel, die dieses paket passieren lassen würde, dann wird das paket mit -j MY_LOGREJECT das paket an die userdefinierte regelkette MY_LOGREJECT weitergeleitet. Diese regelkette befindet sich weiter oben im script.das ist mal klaro...ok...
in dieser wiederum wird entschieden, das das paket einmal nach MY_LOG, zum loggen des abgelehnten paketes, geschickt wird und einmal nach MY_REJECT.ok...# MY_LOG
#_______________

$ipt -N MY_LOG
$ipt -A MY_LOG -p tcp -m limit --limit 7200/h -j LOG --log-prefix "REJECT TCP "
$ipt -A MY_LOG -p udp -m limit --limit 7200/h -j LOG --log-prefix "REJECT UDP "
$ipt -A MY_LOG -p icmp -m limit --limit 7200/h -j LOG --log-prefix "DROP ICMP " je nach dem, ob es ein tcp, udp oder ein icmp-paket ist, wirds dann so geloggt.........wo ist der pfad und name der log-datei definiert..?
in MY_REJECT wird dann entschieden, was mit dem paket passieren soll. handelt es sich z.b. um ein udp-paket wird ein *port-unreachable* verschickt und das paket fallengelassen.ok, alles auch klaro.....einmal zum loggen weitergegeben, einmal zum verwerfen weiter gegeben... # MY_LOGREJECT
#------------------------

$ipt -N MY_LOGREJECT
$ipt -A MY_LOGREJECT -j MY_LOG
$ipt -A MY_LOGREJECT -j MY_REJECTwow.............ok....dann ist mir auch wieder einiges klarer......heute morgen wusste ich grad mal, wie man iptables schreibt,,,,,

also, zur wiederholung...:$ipt -A INPUT -j MY_LOGREJECT
$ipt -A FORWARD -j MY_LOGREJECT
$ipt -A OUTPUT -j MY_LOGREJECT hier wird definiert, was mit den paketen passsiert, die nirgends bei einer policy durchgehen durften......der sagt mit -N = ketteneingang und mit A = kettenausgang....man könnte eine MY_LOGREJECT für eingehende, eine für ausgehende und eine für weiterzuleitende pakete erstellen....klar...........# MY_LOGREJECT
#------------------------

$ipt -N MY_LOGREJECT
$ipt -A MY_LOGREJECT -j MY_LOG
$ipt -A MY_LOGREJECT -j MY_REJECThier haben wir den eingang an sich...."$ipt -N MY_LOGREJECT" genannt....also MY_LOGREJECT.... # MY_REJECT-Chain
# MY_REJECT fuellen
#------------------------

$ipt -N MY_REJECT
$ipt -A MY_REJECT -p tcp -j REJECT --reject-with tcp-reset
$ipt -A MY_REJECT -p udp -j REJECT --reject-with icmp-port-unreachable
$ipt -A MY_REJECT -p icmp -j DROP
$ipt -A MY_REJECT -m limit --limit 7200/h -j LOG --log-prefix "REJECT OTHER "
$ipt -A MY_REJECT -j REJECT --reject-with icmp-proto-unreachableje nach paket-prot wird dann die fehlermeldung gegebenm......echt geile sache.....

# MY_LOGREJECT
#------------------------

$ipt -N MY_LOGREJECT
$ipt -A MY_LOGREJECT -j MY_LOG
$ipt -A MY_LOGREJECT -j MY_REJECT

# vom loggen ausschließen
#------------------------------

$ipt -A INPUT -p TCP --dport 4661:4665 -j MY_REJECT # edonkey Anfragen vom Logging ausschliessen
$ipt -A INPUT -p UDP --dport 4665 -j MY_REJECT # edonkey Anfragen vom Logging ausschliessen
$ipt -A INPUT -p UDP --dport 137 -j MY_REJECT # Netbios nicht loggen
$ipt -A INPUT -p UDP --dport 1214 -j MY_REJECT # Kazaa nicht loggen
$ipt -A INPUT -p TCP --dport 1214 -j MY_REJECT # Kazaa nicht loggen
$ipt -A INPUT -p UDP --dport 6970 -j MY_REJECT # udp vom realplayer nicht loggen
$ipt -A INPUT -p TCP --sport 80 -j MY_REJECT #webbugs etcalso.....sobald kein weiteres -N vorkommt...... gilt für alle folgenden -A der obenstehende eingang
$ipt -N MY_LOGREJECT oder.---......?

also edonkey paket wird daher nicht geloggt, bekommt aber auch keine Fehlermeldung, oder...?

$ipt -A MY_LOGREJECT -j MY_LOG
$ipt -A MY_LOGREJECT -j MY_REJECT und hier werden mit "-j" die ausgänge beschrieben, die zutreffen, wenn sonst unter dem eingang als ausgang nichts zutrifft, oder...? stehen hinter 2 ausgängen bei beiden "-j", so werden an beide (Ketten-)-eingänge das paket verschickt, oder...?

gruss&DANKE VIELMALS.....
pablovschby

HangLoose
29.04.03, 22:09
hi

um eine userdefinierte regelkette als target verwenden zu können, muss diese erstmal angelegt werden. das geschieht mit -N, z.b. hier

$ipt -N MY_LOG

mit -A wird eine filterregel eingefügt.


je nach paket-prot wird dann die fehlermeldung gegebenm......echt geile sache.....

jo ist ne feine sache ;), mit der man noch so einiges mehr machen kann. z.b.

iptables -A MY_LOG -p tcp --dport 22 -j LOG --log-prefix "ssh abgelehnt"



je nach dem, ob es ein tcp, udp oder ein icmp-paket ist, wirds dann so geloggt.........wo ist der pfad und name der log-datei definiert..?

kommt auf deinen logdämon drauf an. meistens syslog => /etc/syslogd.conf




also edonkey paket wird daher nicht geloggt, bekommt aber auch keine Fehlermeldung, oder...?

richtig => alle pakete mit *zielport* 4661:4665, *lösen* ein tcp-reset aus, werden aber nicht geloggt.


so muss noch was tun ;)


Gruß HL

pablovschby
29.04.03, 22:24
iptables -A MY_LOG -p tcp --dport 22 -j LOG --log-prefix "ssh abgelehnt" also, wenn 2 ausgänga mit parameter "-j" stehen, dann geht das paket, welches net erlaubt wurde, auf beide mit -j "bestückten" ausgängen raus, oder...?


kommt auf deinen logdämon drauf an. meistens syslog => /etc/syslogd.conf # MY_LOG
#_______________

$ipt -N MY_LOG
$ipt -A MY_LOG -p tcp -m limit --limit 7200/h -j LOG --log-prefix "REJECT TCP "
$ipt -A MY_LOG -p udp -m limit --limit 7200/h -j LOG --log-prefix "REJECT UDP "
$ipt -A MY_LOG -p icmp -m limit --limit 7200/h -j LOG --log-prefix "DROP ICMP "aber wo sagst du hier genau.....jawohl, log mir das wie heisst der befehl an sich...? ist das vielleicht einfach LOG...? kennt das iptables (vielleicht) einfach so...? aber eben,.......wenn du keine lust mehr hast, .....dann nur zu..musst mir da kein "online-kurs" zu iptables geben, wennde net willst.....

gruss&danke
pablo

p.s.: bist du dir überhaupt im klaren, was du gemacht hast...? hey, danke echt.....das ist wohl eine logische, effektive, aber eine wirkliche hammer-erklärung.......noch en bischen rumforschen und ich habs eigentlich....in en paar stunden....

HangLoose
30.04.03, 05:37
moin moin


also, wenn 2 ausgänga mit parameter "-j" stehen, dann geht das paket, welches net erlaubt wurde, auf beide mit -j "bestückten" ausgängen raus, oder...?

das target -j Log nimmt eine *sonderstellung* bei iptables ein, d.h. anders wie bei anderen targets ist Log nicht exclusiv und die behandlung des paketes endet nicht an dieser stelle, sondern wird mit der nächstfolgenden regel fortgesetzt.
bei den anderen targets ist die *reise* für ein paket, sofern eine regel zutrifft, zu ende.



aber wo sagst du hier genau.....jawohl, log mir das wie heisst der befehl an sich...? ist das vielleicht einfach LOG...? kennt das iptables (vielleicht) einfach so...?

iptables ist im kernel von linux implementiert. sobald jetzt eine loggingregel zutrifft, schickt der kernel eine entsprechende meldung an deinen logdämon. dieser sorgt dafür, das die meldung, je nach konfiguration, in das entsprechende file geschrieben wird.



ps: wenn dich das thema interessiert, kann ich dir folgendes buch empfehlen => "Das Firewall Buch" v. Wolfgang Barth, kostet allerdings ~ 45 euro


Gruß HL

pablovschby
30.04.03, 05:46
das target -j Log nimmt eine *sonderstellung* bei iptables ein, d.h. anders wie bei anderen targets ist Log nicht exclusiv und die behandlung des paketes endet nicht an dieser stelle, sondern wird mit der nächstfolgenden regel fortgesetzt.
bei den anderen targets ist die *reise* für ein paket, sofern eine regel zutrifft, zu ende.ja.....eben....also........somit wird auch, wenn mehrere ausgänge mit "-j" "bestückt" sind............das paket an alle diese chains weitergeleitet.....
gruss&danke
pablo

pablovschby
30.04.03, 14:48
ps: wenn dich das thema interessiert, kann ich dir folgendes buch empfehlen => "Das Firewall Buch" v. Wolfgang Barth, kostet allerdings ~ 45 euro ok, danke.....ich werd mir das sicher mal anschauen in der biblio...... aber da gibts doch sicher auch viel online, net...? man fragt sich manchmal eben schon, was die einten das gefühl haben, was der leser versteht......aber easy...
gruss&danke
pablo

pablovschby
30.04.03, 14:52
lokkit ist aber nur ein super-simple tool und für eine komplexere firewall-konfiguration nicht geeignet. hier ist fwbuilder o.ä. besser. und fwbuilder macht alles auch mit iptables, oder...?
gruss&danke
pablo

HangLoose
30.04.03, 15:06
moin

z.b hier => http://www.linuxguruz.com/iptables/

oder hier => http://www.linux-user.de/ausgabe/2002/05/030-firewall/firewall-4.html



und fwbuilder macht alles auch mit iptables, oder...?

ja ist imho nur ein frontend für iptables


Gruß HL

pablovschby
30.04.03, 15:35
ja ist imho nur ein frontend für iptablesfrontend=schnittstelle (is ja klar)
gruss&merci
pablo