Hilfe! Werden Angefriffen - Wie blocken?!

[Andy09]

Hi Leute,

ich hätte eben beinahe den Kaffee vor schreck in die Tastatur geschüttet. Meine Firewall-Log hat in der Regel so um die 400kb pro Tag. Heute (14:45) hat sie bereits eine größe von 4,5 Megabyte.

Ein blick hineingeworfen und, in der Tat, zwei verschiedene IPs bombadieren den Firewallrechner die ganze Zeit. Wie kann ich aber mit IPTABLES eine Regel einrichten das diese beiden IPs in Zukunft abgeblockt werden bzw. wie binde ich das in das SuSE2firewall2-Config-File rein!?!??!

Bitte helft mir..... :(

Gruß
Andy

[Thomas Engelke]

Aus dem Kopf, keine Garantie für korrekte Syntax:

iptables -i $INDEVICE -s $IP-ADRESSE -f DROP

AD!

[Andy09]

Hi Thomas,

danke schon mal, es kommt aber
Bad argument 'DROP'

Ich schau mal ob ich was in meinem Buch finde, ist schon mal ein Ansatz danke...

Gruß
Andy

[klemens]

iptables -A INPUT ... -j DROP

Wie schaun denn die Einträge aus? -- werden die "Angriffe" geblockt oder durchgelassen?
Hast Du eine statische IP? - sonst wähle Dich neu ins Internet ein (ev. ein paar Minuten warten) ...

[Andy09]

@klemens
nein, sie werden durchgelassen das PORT 80 (also zum drüberstehenden Webserver) :(

Das habe ich bis jetzt probiert, wo mache ich was falsch?!

(Source-IP habe ich mal 'unkenntlich' gemacht)
linux:/var/log # iptables -i eth1 -s a.b.x.y -f DROP
Bad argument `DROP'
Try `iptables -h' or 'iptables --help' for more information.
linux:/var/log # iptables -i eth1 -s a.b.x.y -f -j DROP
iptables v1.2.5: no command specified
Try `iptables -h' or 'iptables --help' for more information.
linux:/var/log # iptables -i eth1 -s a.b.x.y -j DROP
iptables v1.2.5: no command specified
Try `iptables -h' or 'iptables --help' for more information.
linux:/var/log # iptables -A -i eth1 -s a.b.x.y -j DROP
Bad argument `eth1'
Try `iptables -h' or 'iptables --help' for more information.
linux:/var/log #

also -A bedeutet wenn ich das jetzt richtig gelesen habe ANFÜGEN (neue Regel)
-i ist das Interface (Netzwerkkarte)
-s müsste SOURCE sein also IP Adresse des vermutlichen Angreifers
-f für Fragmentierte Pakete
-j ???
DROP gleich blocken...

Aber es funktioniert nicht (siehe Fehlermeldungen)...

Gruß
Andy

[Andy09]

Original geschrieben von klemens
Hast Du eine statische IP? - sonst wähle Dich neu ins Internet ein (ev. ein paar Minuten warten) ...
ich hab eine feste IP an dem zwei Rechner hintereinander hängen. Der erste ist die Linux-Firewall. Der zweite dann der Webserver und nur Port 80 darf durchgelassen werden und genau darauf wird mir seit gestern Abend Pakete rübergescheucht :(

Gruß
Andy

[klemens]

kann sein, dass die Netzwerkverbindung durch ein -related, established oder ähnliches schon geöffnet ist.

-> hab das mit -A INPUT nachher eingefügt .. schon gelesen ?

Tipp:

Internetverbindung trennen
Firewall neu starten
Regel hinzufügen

Internetverbindung neu erstellen

iptables -A INPUT -i eth1 -s a.b.x.y -j DROP

Ist eth1 wirklich richtig? Ev (z.b. bei DSL) kann es auch ppp0 sein.
Wenn der httpd dahinter ist musst du ev. auch bei iptables -t nat was machen ...

http://www.pl-forum.de/t_netzwerk/iptables.html

[hydronic]

Original geschrieben von Andy09
@klemens
nein, sie werden durchgelassen das PORT 80 (also zum drüberstehenden Webserver) :(

Das habe ich bis jetzt probiert, wo mache ich was falsch?!

(Source-IP habe ich mal 'unkenntlich' gemacht)
linux:/var/log # iptables -i eth1 -s a.b.x.y -f DROP
Bad argument `DROP'
Try `iptables -h' or 'iptables --help' for more information.
linux:/var/log # iptables -i eth1 -s a.b.x.y -f -j DROP
iptables v1.2.5: no command specified
Try `iptables -h' or 'iptables --help' for more information.
linux:/var/log # iptables -i eth1 -s a.b.x.y -j DROP
iptables v1.2.5: no command specified
Try `iptables -h' or 'iptables --help' for more information.
linux:/var/log # iptables -A -i eth1 -s a.b.x.y -j DROP
Bad argument `eth1'
Try `iptables -h' or 'iptables --help' for more information.
linux:/var/log #

also -A bedeutet wenn ich das jetzt richtig gelesen habe ANFÜGEN (neue Regel)
-i ist das Interface (Netzwerkkarte)
-s müsste SOURCE sein also IP Adresse des vermutlichen Angreifers
-f für Fragmentierte Pakete
-j ???
DROP gleich blocken...

Aber es funktioniert nicht (siehe Fehlermeldungen)...

Gruß
Andy

Hallo,

die Fehler hast du erhalten, weil du kein Protokoll angegeben hast.
Die Regel sollte, je nach Protokoll, so aussehen:

iptables -A INPUT -p TCP -s a.b.x.y -j DROP

-A für add,
-p für protocol,
-s für source,
-j für jump.

statt TCP kannst du auch noch weitere Protokolle blockieren, z.B. ICMP oder UDP, je nach Art des Angriffs.

gruss,
hydronic

[Andy09]

Original geschrieben von klemens
-> hab das mit -A INPUT nachher eingefügt .. schon gelesen ?
Ja hab ich, hatte aber auch nicht funktioniert weil ich Trottel das INPUT als "füg mal da deine eth1 ein" interpretiert hatte :D


Tipp:

Internetverbindung trennen
Firewall neu starten
Regel hinzufügen

Internetverbindung neu erstellen

ähm *hüstel* du hast schon verstanden das die Server im Rechenzentrum stehen :D


Ist eth1 wirklich richtig? Ev (z.b. bei DSL) kann es auch ppp0 sein.

Ist richtig ;)

Gruß
Andy

[klemens]

Original geschrieben von hydronic
Hallo,

die Fehler hast du erhalten, weil du kein Protokoll angegeben hast.


Wenn er die IP sperrt, sollte das IMHO reichen ... aber tcp 80 kann kein Fehler sein ;)


@Andy09

Schau Dir einmal /etc/sysconfig/SuSefirewall an.
Unter Punkt 15 kann man für bestimmte Source IP den Port umleiten -- Ev. auf einen ungenutzen Port umleiten --- (denke, dass ist kein Sicherheitsrisiko - wenn ja, bitte korrigieren) bzw. schau einmal, ob man da nicht auch in der httpd.conf was einstellen kann -- hab da was dunkel in Erinnerung ...

[klemens]

hm *hüstel* du hast schon verstanden das die Server im Rechenzentrum stehen

sorry ;)

[Andy09]

Original geschrieben von hydronic
Hallo,

die Fehler hast du erhalten, weil du kein Protokoll angegeben hast.
Die Regel sollte, je nach Protokoll, so aussehen:

iptables -A INPUT -p TCP -s a.b.x.y -j DROP

-A für add,
-p für protocol,
-s für source,
-j für jump.

statt TCP kannst du auch noch weitere Protokolle blockieren, z.B. ICMP oder UDP, je nach Art des Angriffs.

gruss,
hydronic
Hallo hydronic,

JETZT hats geklappt, daaaaanke!!!!! So, jetzt bin ich ja mal gespannt was passiert. Die Angriffe haben seit 14:48 Uhr schlagartig aufgehört, aber das ist auch schon vorher gewesen das mal für bis zu 2 Stunden ruhe war und dann ging es wieder los. Laut der Firewall-Config werden auch gedroppte Packete in der Log gespeichert.

Werde diesen Thread gleich mal ausdrucken und schön in meinen Linux-Ordner packen :)

Danke euch allen schon mal für die schnelle und konkrete Hilfe

Gruß
Andy

[Andy09]

Original geschrieben von klemens
Schau Dir einmal /etc/sysconfig/SuSefirewall an.
Unter Punkt 15 kann man für bestimmte Source IP den Port umleiten -- Ev. auf einen ungenutzen Port umleiten --- (denke, dass ist kein Sicherheitsrisiko - wenn ja, bitte korrigieren) bzw. schau einmal, ob man da nicht auch in der httpd.conf was einstellen kann -- hab da was dunkel in Erinnerung ...
Meinst du diesen Punkt hier?!

#
# 15.)
# Which accesses to services should be redirected to a localport on the
# firewall machine?
#
# This can be used to force all internal users to surf via your squid proxy,
# or transparently redirect incoming webtraffic to a secure webserver.
#
# Choice: leave empty or use the following explained syntax of redirecting
# rules, seperated by a space.
# A redirecting rule consists of 1) source IP/net, 2) destination IP/net,
# 3) protocol (tcp or udp) 3) original destination port and 4) local port to
# redirect the traffic to, seperated by a colon. e.g.:
# "10.0.0.0/8,0/0,tcp,80,3128 0/0,172.20.1.1,tcp,80,8080"
#
FW_REDIRECT=""


Die ist bei mir leer. Ist es denn sinnvoll einen anderen Port oder eine "tote" IP anzugeben?!

Gruß
Andy

[klemens]

ja, hab ich gemeint ;)

aber, wenns jetzt klappt, wird das der bessere Weg sein;)

[Andy09]

ich weiss noch nicht ob es geklappt hat. Ich hatte vor diesem Thread bei meinem Provider bzw. Hoster angerufen (wo die Server stehen) und eigentlich machte er nicht den Eindruck als könne er "mal eben so" die beiden IPs blocken, weil ja schließlich über und unter mir noch andere Kunden sind. Komischerweise (er wollte die IPs haben) hat es nach 5 Minuten aufgehört. Zufall?! Abwarten...

Gruß
Andy

[HangLoose]

moin moin

mal ne blöde frage => warum gehst du eigentlich davon aus, das es sich dabei um angriffe handelt?


nein, sie werden durchgelassen das PORT 80 (also zum drüberstehenden Webserver)



ist es nicht sinn und zweck das auf ein von dir ins netz gestellten webserver auch zugegriffen wird? was für pakete sind das denn genau?


Gruß HL

[Andy09]

Hi HangLoose :),

ahhh, mein Helfer als ich letztes Jahr ersten Kontakt mit der Firewall hatte :)

Ich kann dir ja nur mal einen kleinen Auszug aus der Firewall-Log mal zeichen:


Sep 5 13:46:48 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=209.189.242.149 DST=192.168.58.11 LEN=48 TOS=0x
Sep 5 13:46:48 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=209.189.242.149 DST=192.168.58.11 LEN=48 TOS=0x
Sep 5 13:46:48 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=209.189.242.149 DST=192.168.58.11 LEN=48 TOS=0x
Sep 5 13:46:48 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=62.203.153.129 DST=192.168.58.11 LEN=48 TOS=0x0
Sep 5 13:46:49 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=209.189.242.149 DST=192.168.58.11 LEN=48 TOS=0x
Sep 5 13:46:49 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=209.189.242.149 DST=192.168.58.11 LEN=48 TOS=0x
Sep 5 13:46:49 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=209.189.242.149 DST=192.168.58.11 LEN=48 TOS=0x
Sep 5 13:46:49 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=209.189.242.149 DST=192.168.58.11 LEN=48 TOS=0x
Sep 5 13:46:49 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=209.189.242.149 DST=192.168.58.11 LEN=48 TOS=0x
Sep 5 13:46:49 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=209.189.242.149 DST=192.168.58.11 LEN=48 TOS=0x
Sep 5 13:46:49 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=209.189.242.149 DST=192.168.58.11 LEN=48 TOS=0x
Sep 5 13:46:49 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=209.189.242.149 DST=192.168.58.11 LEN=48 TOS=0x
Sep 5 13:46:50 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=209.189.242.149 DST=192.168.58.11 LEN=48 TOS=0x
Sep 5 13:46:50 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=209.189.242.149 DST=192.168.58.11 LEN=48 TOS=0x
Sep 5 13:46:50 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=209.189.242.149 DST=192.168.58.11 LEN=48 TOS=0x
Sep 5 13:46:50 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=209.189.242.149 DST=192.168.58.11 LEN=48 TOS=0x
Sep 5 13:46:50 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=209.189.242.149 DST=192.168.58.11 LEN=48 TOS=0x
Sep 5 13:46:50 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=209.189.242.149 DST=192.168.58.11 LEN=48 TOS=0x
Sep 5 13:46:50 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=61.0.158.163 DST=192.168.58.11 LEN=48 TOS=0x08
Sep 5 13:46:52 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=209.189.242.149 DST=192.168.58.11 LEN=48 TOS=0x
Sep 5 13:46:53 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=209.189.242.149 DST=192.168.58.11 LEN=48 TOS=0x
Sep 5 13:46:53 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=209.189.242.149 DST=192.168.58.11 LEN=48 TOS=0x
Sep 5 13:46:53 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=209.189.242.149 DST=192.168.58.11 LEN=48 TOS=0x
Sep 5 13:46:54 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=209.189.242.149 DST=192.168.58.11 LEN=48 TOS=0x
Sep 5 13:46:55 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=209.189.242.149 DST=192.168.58.11 LEN=48 TOS=0x
Sep 5 13:46:55 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=209.189.242.149 DST=192.168.58.11 LEN=48 TOS=0x
Sep 5 13:46:56 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=209.189.242.149 DST=192.168.58.11 LEN=48 TOS=0x
Sep 5 13:46:56 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=209.189.242.149 DST=192.168.58.11 LEN=48 TOS=0x
Sep 5 13:46:56 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=209.189.242.149 DST=192.168.58.11 LEN=48 TOS=0x
Sep 5 13:46:56 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=209.189.242.149 DST=192.168.58.11 LEN=48 TOS=0x
Sep 5 13:46:56 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=209.189.242.149 DST=192.168.58.11 LEN=48 TOS=0x
Sep 5 13:46:56 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=209.189.242.149 DST=192.168.58.11 LEN=48 TOS=0x
Sep 5 13:46:56 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=209.189.242.149 DST=192.168.58.11 LEN=48 TOS=0x
Sep 5 13:46:56 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=209.189.242.149 DST=192.168.58.11 LEN=48 TOS=0x
Sep 5 13:46:56 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=209.189.242.149 DST=192.168.58.11 LEN=48 TOS=0x
Sep 5 13:46:57 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=66.77.73.173 DST=192.168.58.11 LEN=60 TOS=0x08
Sep 5 13:46:57 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=209.189.242.149 DST=192.168.58.11 LEN=48 TOS=0x
Sep 5 13:46:57 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=209.189.242.149 DST=192.168.58.11 LEN=48 TOS=0x
Sep 5 13:46:57 linux kernel: SuSE-FW-ACCEPT-REVERSE_MASQ IN=eth1 OUT=eth0 SRC=209.189.242.149 DST=192.168.58.11 LEN=48 TOS=0

Und so geht das den lieben langen ganzen Tag. Der Webserver ging immer mehr in die Knie und war teilweise überhaupt nicht mehr erreichbar.

Gruß
Andy

[HangLoose]

ahhh, mein Helfer als ich letztes Jahr ersten Kontakt mit der Firewall hatte :)



tja man trifft sich immer 2 mal im leben :D.


allerdings bin ich erstmal überfragt, was Suse mit "SuSE-FW-ACCEPT-REVERSE_MASQ" jetzt meint :confused:

ps.: du kannst ja mal die config der firewall anhängen


Gruß HL

[Andy09]

Hi,

nicht wundern, ist eine stark verkürzte Datei :D


FW_DEV_EXT="eth1"
FW_DEV_INT="eth0"
FW_DEV_DMZ=""
FW_ROUTE="yes"
FW_MASQUERADE="yes"
FW_MASQ_DEV="$FW_DEV_EXT"
FW_MASQ_NETS="0/0"
FW_PROTECT_FROM_INTERNAL="no"
FW_AUTOPROTECT_SERVICES="yes"
FW_SERVICES_EXT_TCP="68"
FW_SERVICES_EXT_UDP=""
FW_SERVICES_EXT_IP=""
FW_SERVICES_DMZ_TCP=""
FW_SERVICES_DMZ_IP=""
FW_SERVICES_INT_TCP="53"
FW_SERVICES_INT_UDP="53"
FW_SERVICES_INT_IP=""
FW_ALLOW_INCOMING_HIGHPORTS_TCP="no"
FW_ALLOW_INCOMING_HIGHPORTS_UDP="53 110"
FW_SERVICE_DNS="no"
FW_SERVICE_DHCLIENT="no"
FW_SERVICE_SQUID="no"
FW_SERVICE_SAMBA="no"
FW_FORWARS=""
#FW_FORWARD_MASQ="0/0,192.168.58.11,tcp,80 0/0,192.168.58.11,tcp,25 0/0,192.168.58.11,tcp,110 0/0,192.168.58.11,tcp,1433"
FW_FORWARD_MASQ="0/0,192.168.58.11,tcp,80 0/0,192.168.58.11,tcp,25 0/0,192.168.58.11,tcp,110"
FW_REDIRECT=""
FW_LOG_DROP_CRIT="yes"
FW_LOG_DROP_ALL="no"
FW_LOG_ACCEPT_CRIT="yes"
FW_LOG_ACCEPT_ADLL="no"
FW_LOG="--log-level warning --log-tcp-options --log-ip-option --log-prefix SuSE-FW"
FW_KERNEL_SECURITY="yes"
FW_STOP_KEEP_ROUTING_STATE="yes"
FW_ALLOW_PING_FW="yes"
FW_ALLOW_PING_DMZ="no"
FW_ALLOW_PING_EXT="no"
FW_LOG_ACCEPT_ALL="no"
FW_ALLOW_FW_TRACEROUTE="yes"


besteht die Möglichkeit die jeweilige IP hier einzutragen damit diese entweder komplett geblockt oder in einen "toten" Adress-Bereich ausser dem Webserver zu scheuchen?!?!?

Mit IPTABLES hat leider nicht geklappt, vor 20 Minuten ging es wieder los, aber diesmal recht kurz für ca. 15 Minuten. Das geht schon den ganzen Tag so :(

achja, die Datei stammt mehr oder weniger übrigens von dir :D

Gruß
Andy

[HangLoose]

besteht die Möglichkeit die jeweilige IP hier einzutragen damit diese entweder komplett geblockt oder in einen "toten" Adress-Bereich ausser dem Webserver zu scheuchen?!?!?



mit einem *reinen* iptablesscript wäre das ganze kein problem. bei iptables ist die reihenfolge der regeln schon wichtig. wenn du z.b. eine regel definierst, das der zugriff auf deinen webserver unabhängig von der source-ip erlaubt ist und dahinter eine regel kommt, die den zugriff einer bestimmten ip verwehrt, wird das ganze nicht funktionieren. die *verbotsregel* müßte vor der *allgemeinen regel stehen. nur als ergänzung => man könnte natürlich auch mit negation ! arbeiten.

bei der susefirewall ist das problem, das die eigentlichen regeln aus diesem configfile erstellt werden. wenn du jetzt eine separate regel hinzufügst (z.b durch einfaches eintippen in der shell), weißt du nicht ob diese regel überhaupt greift.

du kannst ja mal folgendes probieren

FW_FORWARD_MASQ="!209.189.242.149,192.168.58.11,tcp,80 0/0,192.168.58.11,tcp,25 0/0,192.168.58.11,tcp,110"


Gruß HL

[Andy09]

Hi,

dann hab ich das im Buch doch vorhin richtig gesehen. Ist schon krass, da hat man sich extra von SuSE Press "Das Firewall Buch" gekauft und blickt immer noch nicht so richtig durch :D

Da wurde an einer Stelle erklärt mit Auswechseln, hinten anfügen, irgendwo mitten drin einfügen. Aber wie soll ich etwas an der richtigen Stelle einfügen, wenn ich nicht weiss an welcher Stelle (Nummer) wer wo sitzt?! iptables -L -n ?!?!

Das mit dem !a.b.c.d werde ich glaub mal ausprobieren, ich gehe mal von aus, wenn es mehrere sind muss ich auch mehrere mit einem ! davor getrennt durch , eintragen und sie müssen VOR allem anderen eingetragen werden (also vor meiner Server-Adresse)...

Gruß
Andy

[HangLoose]

dann hab ich das im Buch doch vorhin richtig gesehen. Ist schon krass, da hat man sich extra von SuSE Press "Das Firewall Buch" gekauft und blickt immer noch nicht so richtig durch :D


das kommt schon noch ;). am leichtesten lernst du es, wenn du anfängst deine eigenen scripte zu schreiben.


Da wurde an einer Stelle erklärt mit Auswechseln, hinten anfügen, irgendwo mitten drin einfügen. Aber wie soll ich etwas an der richtigen Stelle einfügen, wenn ich nicht weiss an welcher Stelle (Nummer) wer wo sitzt?! iptables -L -n ?!?!


damit habe ich mich auch noch nicht beschäftigt, hab's bis jetzt noch nicht benötigt.



Das mit dem !a.b.c.d werde ich glaub mal ausprobieren, ich gehe mal von aus, wenn es mehrere sind muss ich auch mehrere mit einem ! davor getrennt durch , eintragen und sie müssen VOR allem anderen eingetragen werden (also vor meiner Server-Adresse)...



wie du das bei der susefirewall machen kannst, weiß ich auch nicht. bei einem eigenen script würde ich die ip's in eine variable packen und dann in der regel selbst mit einer kleinen if => then schleife arbeiten.


Gruß HL