RootForum Community

Hallo zusammen,

scheinbar läuft bei mir BlockHosts jetzt wunschgemäß! Allerdings werden die Verbindungen, die geblockt wurden, zwar in iptables hinterlegt, aber eben nicht gänzlich geblockt. So ergibt "iptables --list blockhosts --numeric" folgende Ausgabe, nach der die IP gesperrt sein müsste! Ist aber nicht der Fall:

---
Chain blockhosts (1 references)
target prot opt source destination
DROP all -- 79.209.106.127 0.0.0.0/0
---

Die Notify-E-Mail zeigt immer die "geblockte" IP an und diese wird zudem beobachtet. Allerdings zeigen die vielen weiteren Versuche, dass die IP nicht geblockt wird. Doch dies kann nichts mit BlockHosts zu tun haben, sondern der Wurm muss irgendwie in Verbindung mit iptables zu suchen sein, oder?

---
Blocking hosts:
79.209.106.127 Watching hosts:
79.209.106.127 count: 55 updated at: 2008-03-29 14:05:01 CET
Log messages:
blockhosts 2.3.1 started: 2008-03-29 14:05:01 CET ... loaded /etc/hosts.allow, starting counts: blocked 1, watched 1 ... loading log file /var/log/auth.log, offset: 848868 ... loading log file /var/log/mail.err, offset: 39734 ... discarding all host entries older than 2008-03-29 02:05:01 CET
Notice: count=55, blocking host: 79.209.106.127 ... final counts: blocked 1, watched 1
---

Vielen Dank für Eure Überlegungen zu dieser Problematik!

Hahni

Bitte.

Damit man überhaubt sieht ob diese Customer "lockhosts" Chain überhaubt angespochen wird.
Sieht nähmlich so aus, als wenn es keinen verweiß von der "Input" chain auf diese gäbe.....

Hier die Ausgabe:

---
Chain INPUT (policy DROP)
target prot opt source destination
DROP tcp -- anywhere 127.0.0.0/8
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere
DROP all -- BASE-ADDRESS.MCAST.NET/4 anywhere
PUB_IN all -- anywhere anywhere
PUB_IN all -- anywhere anywhere
PUB_IN all -- anywhere anywhere
PUB_IN all -- anywhere anywhere
DROP all -- anywhere anywhere
blockhosts all -- anywhere anywhere

Chain FORWARD (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
DROP all -- anywhere anywhere

Chain INT_IN (0 references)
target prot opt source destination
ACCEPT icmp -- anywhere anywhere
DROP all -- anywhere anywhere

Chain INT_OUT (0 references)
target prot opt source destination
ACCEPT icmp -- anywhere anywhere
ACCEPT all -- anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
PUB_OUT all -- anywhere anywhere
PUB_OUT all -- anywhere anywhere
PUB_OUT all -- anywhere anywhere
PUB_OUT all -- anywhere anywhere

Chain PAROLE (11 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere

Chain PUB_IN (4 references)
target prot opt source destination
ACCEPT icmp -- anywhere anywhere icmp destination-unreachable
ACCEPT icmp -- anywhere anywhere icmp echo-reply
ACCEPT icmp -- anywhere anywhere icmp time-exceeded
ACCEPT icmp -- anywhere anywhere icmp echo-request
PAROLE tcp -- anywhere anywhere tcp dpt:ftp
PAROLE tcp -- anywhere anywhere tcp dpt:ssh
PAROLE tcp -- anywhere anywhere tcp dpt:smtp
PAROLE tcp -- anywhere anywhere tcp dpt:domain
PAROLE tcp -- anywhere anywhere tcp dpt:www
PAROLE tcp -- anywhere anywhere tcp dpt:pop3
PAROLE tcp -- anywhere anywhere tcp dpt:https
PAROLE tcp -- anywhere anywhere tcp dpt:10000
PAROLE tcp -- anywhere anywhere tcp dpt:22
PAROLE tcp -- anywhere anywhere tcp dpt:mysql
ACCEPT udp -- anywhere anywhere udp dpt:domain
DROP icmp -- anywhere anywhere
DROP all -- anywhere anywhere

Chain PUB_OUT (4 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere

Chain blockhosts (1 references)
target prot opt source destination
---

Chain INPUT (policy DROP)
target prot opt source destination
DROP tcp -- anywhere 127.0.0.0/8
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere
DROP all -- BASE-ADDRESS.MCAST.NET/4 anywhere
PUB_IN all -- anywhere anywhere
PUB_IN all -- anywhere anywhere
PUB_IN all -- anywhere anywhere
PUB_IN all -- anywhere anywhere
DROP all -- anywhere anywhere
blockhosts all -- anywhere anywhere

Du merkst was ?
Dann schau mal in die Doko wie die Chains abgearbeitet werden. Und wann die Bearbeitung in einer chain aufhört.
Stelle dann fest das du in der Input chain in der Dritten Zeile ALLES reinlässt was bis da noch nicht gedroppt wurde und
damit die Restlichen Regeln überflüssig macht und diese auch nicht weiter beachtet werden.

Darüberhinaus hast du mehrfach die gleichen Regeln, hast chains die nicht benutzt werden und regelen für chains
hinterlegt die unsinnig sind (oder benötigst du wirklich die Forward cahain weil du zwischen zwei netzen Routetst ?)

Alles im allen ein gutes Beispiel warum hier anfragen zu Paketfilterung nichtgerne gesehen sind.

nein, die brauch ich eigentlich nicht! mir wäre es auch garnicht aufgefallen, wenn ich nicht die probleme mit blockhosts habe. und leider (das gebe ich ganz ehrlich zu) habe ich keine ahnung von iptables :oops:

habe ich keine ahnung von iptables

Genau das Disqualifiziert dich doch sowas überhaubt zu benutzen.
Klingt hart ist aber auch genauso gemeint.
Irgentwelche "PseudoHighSecurity" Scripte die Dir ein gutes bauch gefühl geben sollen,
aber nichteinmal im eignen umfeld greifen sind überflüssig.
Sieht für mich (kenn und nutze so gegraffel allerdings selber nicht) als wenn da noch das eine
oder andere "Security" Script deine IP Tables vergwaltigt.

An deiner Stelle würde ich den ganzen Mist entfernen und mich mit der Absicherung meiner
Dienste beschäftigen und nich auf etwas Bauen das ich nicht verstehe. [-o<

Such mal hier im Forum nach Iptables, und lies mal in den Links die dort so stehen.
Du wirst schnell merken, das das alles nur "scheinheilige" Sicherheit bringt.
Weil du im Prinzip die Standart einfalltore garnicht schliessen willst (z.B Port 80, unsicheres PHP)

das kann man so nicht sagen! wie eingangs gesagt, setze ich ispconfig ein und mir ist schon sehr an sicherheit gelegen. für mich, aber auch für die kunden! und die firewall-regeln wurden von ispconfig so gesetzt!

für mich, aber auch für die kunden!

Als "Anbieter" solltest du dein Handwerk und die dazugehörigen Tools kennen und verstehen.
Schau dir einmal die Stickies ("Liebe Firewall Freunde", "Deny Hosts...") hier an http://www.rootforum.org/forum/viewforum.php?f=41

das kann man so nicht sagen! wie eingangs gesagt, setze ich ispconfig ein und mir ist schon sehr an sicherheit gelegen. für mich, aber auch für die kunden! und die firewall-regeln wurden von ispconfig so ges

Sicherheit fängt beim Verständnis für eine Sache oder einen Ablauf an.
Deine IP-Tables Chains sind nun mal Müll. Da nützt es auch wenig wenn diese
von ISP-Config, BlakWhole oder Patrick McHard geschrieben wurde.
Alte Binsenweisheit, viele Scripte verderben das Ergebnis.

Ich habe mal deine Regeln zusammengefasst, vielleicht dämmerst dann.
Das sind bei dir also ca. 50 Zeilen Firewall Script.
Dein Sicherheit zugewinn beträgt also in etwa -0%
und das du den LOCALHOST Verkehr drops ist nicht dienlich für Interne Geschichten
die über Lokalhost laufen (Spam Software, interne SQL über die IP statt dem socket)

Wenn wir das als Fehler ansehen kommen wir auf folgenden Code:
Das sind im übrigen auch die Default Einstellungen....

kann man vom vorherigen stand (auch wenn es dir nicth sinnvoll erscheint) eine kopie machen? wenn ja, wie? und wie könnte diese wieder eingespielt werden?

man iptables-save

wenn ich dich richtig verstehe, scheint dies eh nicht erforderlich zu sein... :lol:

"iptables-save -c > /root/iptables-save" ist mein schlüssel, richtig?

Außerdem wurden die Sachen so durch die Bastille-Firewall eingetragen! :roll:

Denn sie wussten nicht, was sie tun...

Wenn die abgeschaltet ist, sehen die Einstellungen so aus, wie von dir beschrieben. Also wird Bastille schon wissen, was es tut?

Also: wenn ich Bastille deaktivere, dann sieht es mit "iptables -L" wie folgt aus:

---
Chain INPUT (policy ACCEPT)
target prot opt source destination
blockhosts all -- anywhere anywhere

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain blockhosts (1 references)
target prot opt source destination
DROP all -- e179092128.adsl.alicedsl.de anywhere
---

Ist das nun schlüssiger/sinnvoller?

Bei mir sieht es so aus: Ist das nun gut oder böse?

Risikoreicher?

Huhu,

ich finde es nett, dass du mir so geduldig und ausführlich schreibst! Da habe ich direkt wieder etwas gelernt! Allerdings kann man ja über iptables eben auch Tools wie BlockHosts laufen lassen, die eben Brute-Force-Attacken unterbinden können.

Dass dies ein Sicherheitsrisiko darstellen mag (wegen Software-Fehlern) leuchtet mir durchaus ein. Aber SSH würde beispielsweise jedes Mal einen neuen Login-Versuch zulassen.

Sowohl fail2ban als auch BlockHosts setzen auf iptables auf! Ein anderes System als dieses ist mir eben nicht bekannt. Dir vielleicht? :?:

Viele Grüße

Hahni

hahni wrote:ich finde es nett, dass du mir so geduldig und ausführlich schreibst!

Das ist wirklich eine Ausnahme...

hahni wrote:Da habe ich direkt wieder etwas gelernt!

...welche sich langsam auszahlt.

hahni wrote:Allerdings kann man ja über iptables eben auch Tools wie BlockHosts laufen lassen, die eben Brute-Force-Attacken unterbinden können.

Falsch, die Attacken bleiben, nur die Logs sind minimal sauberer. Also kein Gewinn.

hahni wrote:Sowohl fail2ban als auch BlockHosts setzen auf iptables auf! Ein anderes System als dieses ist mir eben nicht bekannt. Dir vielleicht? :?:

Wenn man solche Dienste auf unübliche Ports >1025 verlegt erreicht man das Gleiche: Weniger Müll im Log bei gleichem Risiko.

hahni wrote:Ein anderes System als dieses ist mir eben nicht bekannt. Dir vielleicht? :?:

TCPWrapper mit hosts.{allow,deny}, sofern der sshd dagegen gelinkt ist, was meistens der Fall ist. Kommt ganz ohne Netfilter aus.

DenyHosts bastelt mit TCPWrapper herum. Ist aber letztendlich genauso eine (Self-)DoS-Gefahr wie alle anderen Aussperrer.

Joe User wrote:Bei mir sieht es so aus:

Code: Select all

~ # iptables -L
-su: iptables: command not found

Ist das nun gut oder böse?

Ich weiß nicht... warum hast Du dann netfilter in Deiner (Muster-) Kernel-Konfiguration aktiv? 8)

jfreund wrote:Ich weiß nicht... warum hast Du dann netfilter in Deiner (Muster-) Kernel-Konfiguration aktiv? 8)

Notwehr ;) Weil meine Beispielkonfigurationen tatsächlich von anderen genutzt werden und ich mir das Gejammer nach einem "emerge iptables" ersparen möchte...