[linux-l] iptables (Eheamals: Fedora3 Firewall)

[Peter Ross]

Mike Dornberger wrote:
> On Wed, Nov 16, 2005 at 10:32:21AM +1100, Peter Ross wrote:
>> Was Du machst, ist das Erlauben aller ausgehenden Verbindungen. Das
>> macht ein gehacktes System zu einem phantastischen Relay. Alkle
>> ausgehende Ports sind offen.
>
> äh, ja und? Wenn ein Angreifer es geschafft hat, einen Prozeß zu kapern
>  hat er sowieso mindestens einen ausgehenden Port zur Verfügung und kann
> damit genug Unsinn anrichten.

Gehe mal davon aus, dass die meisten "Hijacker" keine Leute an der
Tastatur sind, sondern Skripte, eingesetzt zum Beispiel zum Spammen.

Da sehr viele Firewalls recht offen sind, sind die meist nicht besonders
intelligent geschrieben.

Es geht nicht zuallererst darum, den Nutzer zu beschraenken (das kann in
bestimmten Faellen noetig sein), sondern darum, all dem Virenzeug,
Spyware, Spamkram, das Leben schwer zu machen.

Du hast wohl recht, dass eine Linux-Buechse sicherer als das
Windows-Gekroese ist, aber immun gegens Kapern sind sie auch nicht.

Ich halte nicht viel davon, zu sagen "Ach was, mir passiert das doch
nicht" und Sicherheit nur halbherzig zu machen.

> Schlimmstenfalls erlangt er eh
> Root-Rechte und löscht einfach die Netfilter-Regeln.

init(1) - securelevel
3	   Network secure mode - same as highly secure mode, plus IP packet
	   filter rules (see ipfw(8), ipfirewall(4) and pfctl(8)) cannot be
	   changed and dummynet(4) or pf(4)configuration cannot be adjusted.

Okay, genug verwirrt.. das  war FreeBSD;-)

Abseitige Frage: bekommt man das mit SELinux hin?

> Naja, wenn Du Deinen Usern nicht vertraust, kannst Du ihnen damit ein
> paar Steine in den Weg legen, gewisse Dinge wie P2P nicht so einfach zu
> machen.
>
> Alle Zuordnungen Ports-Dienste sind ja nicht wirklich "in Stein
> gemeißelt ",
> sondern das, was in /etc/services steht sind die defaults. Du machst es
> Deinen Usern nur unnötig schwer, Dienste zu erreichen, die nicht auf
> Standard-Ports laufen.

Im Firmenumfeld gibt es Proxies, die diese Aufgabe erledigen. Inklusive
Logstatistik, um z.B. mitzubekommen, wenn eine Buechse 1000 e-Mails per
Stunde versendet. So ist Port 25 nach aussen z.B. nur offen fuer ein
Mailrelay, nicht fuer andere Rechner im LAN. Wenn da was ausser Kontrolle
geraet, sehe ich es in den Logs auf Applikationslevel.

Das Gleiche, wenn der Webproxy von einem Client kontinuierlich 1000
Requests bekommt.

Spaetestens, wenn Dein Netzwerk dicht ist, weil ein halbes Dutzend
Windosen nach Indien telephonieren wollen, freust Du Dich, dass Du ein
dichtes Netz und Logs hast.

Ich habe z.B. mal in ein Firmennetzwerk ein Dutzend Windows-2000-Rechner
einer aufgekauften Firma integriert. Die klopften ungewoehnlich viel an,
und ich konnte das ausfindig machen, dann mich an die Windows-Kisten
setzen und fand ein paar Services, die sich keiner erklaeren konnte. Nach
Abschaltung war ploetzlich Ruhe.

> Gib den Leuten eine halbwegs mächtige Scripting-Sprache oder nen
> Compiler und die cleveren Fangen eh an, Protokoll-Tunneling zu
> betreiben, zur Not über ICMP.

Sicher - wo ein Wille ist etc. Aber es geht nicht zuerst um
Nutzerbeschraenkung.

Und auf Home-Rechnern ist man selbst Chef ueber die Kiste, kann also auch
mal einen Port manuell aufmachen, wenn's denn klemmt.

> Auch machst Du es Dir als Admin unnötig schwer. Für jeden lokalen Service
> mußt Du mindestens eine --sport Regel definieren und für jeden Remote-
> Dienst
> mindestens eine --dport-Regel. Vergiß bei komplizierten Protokollen wie
> z. B. FTP dann nicht, daß es 2 Verbindungen gibt, eine nach außen, eine
> von außen kommend oder 2 nach außen, je nachdem ob aktiv oder passiv.

Ja, dafuer gibt es bei Linux's netfilter die Helferchen:-)

Und gegen komplizierte Regeln gibt es Subroutines.

tcp_out ()
{
   ip_tables .... -dport $1 SETUP # Sorry, Syntax nicht zur Hand
}

Im Hauptprogramm sthet dann nur
tcp_out ssh
tcp_out ftp
...
und unten dann die Regel, alle RELATED- und ESTABLISHED-OPakete
durchzulassen.

Die Prozedur schreibst Du einmal und dann ist's gut. Noetigenfalls ein
zweites, wwenn nach ipfwadm, ipchain und iptables mal wieder was neues
kommt, oder Du auf ein anderes OS umsteigst.

Gruss
Peter