PL-Firewall oder andere Geheimnisse

[gewitter]

Wenn ich die PL-Firewall benutze geht kein FTP mehr. Weder der Server im Local_Net noch irgendein anderer ausserhalb ist ansprechbar. Ich habe OutFTP und OutTCP ftp angegben und auch sowohl als auch probiert. wenigstens müsste ja der interne server ansprechbar sein.

[trinity]

mal als "workaround" auf die schnelle:

${IPTABLES} -A INPUT -j ACCEPT -i $SCHNITTSTELLE_LAN -p tcp -m state --state NEW,ESTABLISHED,RELATED
${IPTABLES} -A OUTPUT -j ACCEPT -o $SCHNITTSTELLE_LAN -p tcp -m state --state ESTABLISHED,RELATED
damit wird jeglicher datenverkehr zwischen deinem lokalen netz und deinem router/server freigegeben.
$SCHNITTSTELLE_LAN musst du selber definieren bzw. deinem script anpassen. für eine enger gefasste regeln später mehr.

ps: sollen wir nun so eine art kurs (mit frage-antwort-spiel) machen?
sorry, das meine antwort so kurz. bin aber gerade schlecht gelaunt (und hab wenig zeit) weil meine festplatte gerade die daten verloren hat.

[gewitter]

tut mir leid wegen deiner daten. ich habe das mit dem ftp jetzt auch hingekriegt, indem ich die zweite funktion für ftp aus dem script auch aufrufe, also ftp-aktiv und -passiv. aber den workaround a la frage und antwort, fände ich schon geil, wenn du dazu lust hast. die firewall läuft ja jetzt so weit und da ist ja zeit in ruhe sich was neues auszudenken. aber mach erst mal deine festplatte klar, ich komme später mit einer frage rüber <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">

[trinity]

hi, das heut mittag war echt mein graus. Ausgerechnet die Platte auf der meine persönlichen Dateien lagen hat sich verabschiedet. Natürlich kein Backup. Jetzt nach langem hin und her läuft die Platte wieder (weiss nicht warum). Gleich mal ne Kopie persönlicher auf die andere Platten.


Ich dachte nicht unbedingt den workaround als Frage Antwort-Spiel, sondern überhaupt die Entstehung eines neuen Scripts (nicht allzu komplex, aber auch nicht zu schlecht). Ich dachte wir gehen mal folgendermassen voran:
- Du sagst wie du dein internes Netz aufgebaut hast (kannst dafür rein fiktive ip´s nehmen oder deine vorhandenen ist egal)
- Welcher Rechner soll wem welche Dienste anbieten.

Könnte dann also folgendermaßsen aussehen:
NETZDESIGN (so ähnlich ist zumndest bei mir):
<pre>
{INTERNET}--[FIREWALL/ipp0-dyn/eth1:192.168.0.1]--[SWITCH]
|___[COMPUTER1/eth0:192.168.0.2]
|___[COMPUTER2/eth0:192.168.0.3]
|___[COMPUTER3/eth0:192.168.0.4]
</pre>
DIENSTE:
<pre>
Firewall|Computer1|Computer2|Computer3:
Dienst Intranet Internet
squid x|-|-|- -|-|-|-
http x|-|-|- x|-|-|-
...
</pre>
x bedeutet beitet Dienst an. - bedeutet beitet den Dienst nicht an (für wen der Dienst Angeboten wird steht in den Tabellen Köpfen.

So und nun wie siehts dein Netz Dir aus? Lasset die Spiele beginnen.
natürlich wirst du hjb´s Script mindestens solange verwenden bis das hier fertig ist (hjb´s script ist recht übersichtlich gefällt mir wie gesagt recht gut) bzw. du dein eigenes Geschrieben hast. Was auch nicht schlecht wäre zu wissen sollen wir mit oder ohne connection tracking loslegen. connection tracking ist vielleicht für den Anfang etwas viel auf einmal.
Freue mich im übrigen über rege mithilfe (Stormbringers script würde mich übrigens auch sehr interessieren <img src="http://www.pl-forum.de/UltraBoard/Images/Happy.gif" border="0" align="middle">)

[gewitter]

ist ja gut, dass deine hd sich wieder beruhigt hat. <img src="http://www.pl-forum.de/UltraBoard/Images/Happy.gif" border="0" align="middle">

ansonsten sprechen wir beide vom gleichen. meine hardware-konfiguration sieht genauso aus wie deine. die anforderungen sollen sein:

1. das lokale netz soll von aussen her geschützt sein, die ports nicht erreichbar, der router nicht als gateway usw. benutzbar sein.
2. es soll ein proxy laufen, der zusätzlich die internen nutzer vor dem internet verschleiert.
3. intern soll ein http- und ftp-server auf dem router/proxy/gateway laufen, der wahlweise auch nach aussen geöffnet werden kann.
4. der proxy soll wahlweise nur mit passwort den zugang nach aussen gewähren dürfen.
5. auf dem proxy/router soll auch bind laufen und am liebsten auch dhcpd, um dynamische ip's zu verteilen beim booten ( oh je, jetzt wird's ne zumutung )
6. bind und dhcpd sollen aufeinander abgestimmt werden.
7. auf dem proxy/bind/http/ftp/dhcpd/gateway-rechner soll auch samba laufen, was wahlweise nach aussen geschaltet werden kann.
8. das alles soll in der firewall berücksichtigt werden und die erlaubten dienste sollen wie in der pl-firewall einfach zuschaltbar sein.

na, wenn das nicht zuviel verlangt ist, sollten jetzt noch mehrere teilnehmen, um eine solche konfiguration, die in meinen augen ein sprungbrett für grössere netze ist, mal in angriff zu nehmen. die schwierigkeit besteht in der erlangung der harmonie der einzelnen komponenten und darin das fw-script übersichtlich mit funktionen zu gestalten. wie schon gesagt, lief es bisher mit der fw alleine nicht 100% rund, es war immer irgendetwas was nicht lief. darum halte ich einen öffentlichen workshop auch nicht nur für mich als sehr lehrreich, ich denke auch andere könnten was lernen, kann mir ja keiner erzählen die SuSE-fw zu verstehen.

Noch zwei Fragen @Lutz:
Wieso hat dein Router eth1 und nicht eth0 wie die anderen?
Wie hast du die tabellarische ansicht hinbekommen? bei mir frisst das forum immer die leerzeichen.

[trinity]

so kommen wir also erstaml zur Rahmenabsteckung (und Erklärung einiger Punkte).
1. bedeutet generell ja nur, dass keiner deine intern angebotenen Dienste in Anspruch nehmen kann/soll. diesen Punkt werden wir ja hoffentlich mit iptables erledigen können. Wie die einzelnen Befehle hierfür aussehen könnten (ja könnten, weil das letztlich ja immer eine Frage von persönlichen Ansichten ist und auch viel Platz für Spielraum lässt)
2. Da wir nur private Internetadressen verwenden wollen, und auch kein Forwarding und NAT verwenden wollen, ist es für die Sicherheit erst einmal nicht ganz so tragisch, wenn squid die internen Netzdaten an die Webserver weiterleitet. später werden wir uns dann ein klein wenig mit den Einstellungen im Squid plagen (wenn iptables fertig ist) bzw. sollten dafür dann wohl eher einen separaten Thread eröffnen (man sollte es wie auf der Firewall handhaben: pro Maschine ein Dienst (privat natürlich totaler Overkill...)
3. welchen Webserver hättens denn gerne (muss er Scripte verarbeiten können, oder kommt nur statischer Content zum Einsatz)?
5. ich habe unter linux noch nie einen dhcpd aufgesetzt. mag aber dynamische ip Vergabe aus folgenden Gründen nicht so:
- mach das Filtern von bestimmten LAN-ip´s unmöglich (wenn ich die dhcp Adresse mit unbeschränkter Laufzeit angeben, brauch ich aber kein dhcp)
- server sollten sowieso fest zugewiesene ip´s haben, da sie sonst einem weiteren rechner (dem dhcpd) vertrauen müssten.
- die Auswertung der logfiles wird erschwert, welcher Rechner hatte wann welche ip?
Als Vorteil fällt mir nur ein: man braucht die IP-Adresse bei neuen Rechnern nicht eintragen (aber evtl. die vom dhcpd?) Falls jemand dazu was sagen möchte nur heraus damit (ganz besonders den Vorteilskatalog gilt es aufzustocken).
6. ich verwende keinen dns-server. habe mich deswegen auch noch nicht intensiv damit beschäftigt (zudem gibt es auch noch den digdns). für meine zwei Rechner brauche ich auch kein dns. Schon wieder ein Programm, dass evtl einen Fehler haben könnte. Bei Gelegenheit dazu wieder ein neuer Thread
7. du willst samba für das Internetfreigeben.
8. Das wird es. Zudem gefällt mir die Definition von Lutz Donnerhacke (das bin nicht ich) bezüglich Firewall ganz gut:
Als Firewall bezeichnet man ein organisatorisches und technisches Konzept zur Trennung von Netzbereichen, dessen korrekte Umsetzung und dauerhafte Pflege. Ein oft benutztes Instrument der Umsetzung ist ein Stück Hardware, das zwei physisch getrennte Netzbereiche genau so verbindet, wie es im Konzept zugelassen wird. Dieses Stück Hardware bezeichnet man als Firewall-Rechner/System oder verkürzt als Firewall.

Fangen wir also mal an:
#Variablen Deklarationen
IPT="/usr/sbin/iptables" # oder wo immer sich iptables auch befinden mag.
LAN_DEV="eth1"
INET_DEV="ppp0"
LAN_PCS="192.168.0.2/32 192.168.0.3/32 192.168.0.4/32" # man kann hier auch einfach nur eine IP, den LAN-IP Bereich eingeben (192.168.0.0/24)
LOCALE_DIENSTE="80 3128"
INET_DIENSTE=""

##hier werden bestimmte Internet-IP-Adressen definiert
NAMESERVER="" habe jetzt natürlich gerade die ip-DNS-Adressen von T-Online nicht zur Hand

## Hier beginnt der Bereich vordefinierter Funktionen, die später genutzt werden (derzeit leer)

##
$IPT -F # falls regeln existieren sollten, werden diese nun gelöscht.
$IPT -X # falls eigene Regelketten definiert wurden, landen diese auch in der tonne (ich selbst verwende keine selbstdefinierten Regelketten

# default policy: DROP wollte eigentlich REJECT verwenden (testen). funktionierte aber neulich nicht.
# evtl vergessenenes Kernelmdoul, oder nicht vorgesehen
$IPT -P INPUT DROP
$IPT -P FORWARD DROP
$IPT -P OUTPUT DROP

damit hätten wird also schonmal das wichtigste Grundgerüst geschaffen. Jetzt ist KEIN Netzwerkverkehr mehr möglich (wohl dem, der am Server eine Tastatur hat). Das einzige das noch besser schützt als obiges Firewall-Grundgerüst ist die scissor-firewall ein <!--http--><a href="http://web.ranum.com/pubs/a1fwall/index.htm" target="_blank">Adaptive Packet Destructive Filter</a><!--url-->

so nun warten wir mal ab, ob und welche Fragen und Kommentare kommen

@Thomas
zu den Fragen an mich, dass meine Firewall mit eth1 an dem LAN hängt war "halbwegs" ein versehen. da ich auswendig nicht mehr wusste, ob eth0 oder eth1 mit dem dsl-modem verbuden ist. aber meine "Firewall" ist auf jeden fall "dual-homed" (und ich glaube das war ein weiterer Grund warum ich eth1 hingeschrieben habe, zur Verdeutlichung). Sonst bräuchte ich keine Firewall. ich habe auch keinen switch, sondern derzeit nur einen hub.
Die Tabellarische Ansicht, habe ich dank Stormbringer unter dem Menüpunkt Hilfe gefunden (pre-formated text).

[gewitter]

#!/bin/bash

IPT="/usr/sbin/iptables" # oder wo immer sich iptables auch befinden mag.
LAN_DEV="eth+" # angeblich geht das so auch
INET_DEV="ippp+"
LOOPBACK="lo" # or your local naming convention
LAN_NET="192.168.0.0/24 # ist wegen der möglicherweise dyn. ip's sinnvoller, in dem bereich werden auch die dyn-ip's zugeteilt
LOCALE_DIENSTE="80 3128" #
INET_DIENSTE=""

NAMESERVER="any/0" # möglicherweise unterschiedliche provider?

## Hier beginnt der Bereich vordefinierter Funktionen, die später genutzt werden (derzeit leer)
#
# entsprechend des pl-fw-scripts richtige entscheidung localen durchfluss zu ermöglichen
AcceptLocal()
so:
{
${IPT} -A INPUT -j ACCEPT -i \! ${INET_DEV}
${IPT} -A OUTPUT -j ACCEPT -o \! ${INET_DEV}
${IPT} -A FORWARD -j ACCEPT -i \! ${INET_DEV} -o \! ${INET_DEV}
}
oder so:
{
$IPT -A INPUT -i $LOOPBACK -j ACCEPT
$IPT -A OUTPUT-i $LOOPBACK -j ACCEPT

$IPT -A INPUT -i $LAN_DEV -s $LAN_NET -j ACCEPT
$IPT -A OUTPUT -i $LAN_DEV -d $LAN_NET -j ACCEPT
$IPT -A FORWARD -i $LAN_DEV -o $LAN_NET -j ACCEPT

}
##
$IPT -F # falls regeln existieren sollten, werden diese nun gelöscht.
$IPT -X # falls eigene Regelketten definiert wurden, landen diese auch in der tonne, selbstdefinierten Regelketten halte ich aber für interessant

# default policy: DROP wollte eigentlich REJECT verwenden (testen). funktionierte aber neulich nicht.
# evtl vergessenenes Kernelmdoul, oder nicht vorgesehen
# drop wegen dem stealth gegenüber äusseren, verlangsamt u.a den portscan <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle"> auswertung fällt schwieriger aus.
$IPT -P INPUT DROP
$IPT -P FORWARD DROP
$IPT -P OUTPUT DROP

AcceptLocal

[trinity]

Hi Thomas

gleich mal ein paar Anmerkungen zu den Anpassungen:
gemäß unserer kleinen Grafik und unserem Definitionspunkt 1. Kann es in unserem Firewall Skript keine einzige FORWARD regel geben.
Die Aussage bezüglich von scans: Der Scan muss nicht zwangsläufig länger dauern, da man mehrere Ports gleichzeitig scannen kann. Zudem wird der Verbdingungsaufbau öfters versuch, und erzeugt so eine etwas höhere Last auf der eigenen Leitung. Kann man machen, muss man aber nicht. <img src="http://www.pl-forum.de/UltraBoard/Images/Happy.gif" border="0" align="middle">

Ich hatte auch vergessen, das du über einen anderen Provider als die Telekom ins Internet gehst. Trotzdem kann den eigenen Nameserver eintragen.

So kommen wir nun also mal zu einer meiner Funktionen (angelehnt an hjb´s Script), da du ja alle das komplette LAN freigegeben hast fällt Sie recht schlicht aus:
OUTTCP
{
# erwartet folgende übergabeparameter: INTERNETADRESSE ZIELPORT
# erlaubt alle ausgehenden tcp Verbindungen vom lokalen Rechner zu dem übergebenden Port
# und die ergebnisse aus dieser Anfrage
iptables -A OUTPUT -o $INET_DEV -p tcp -d $1 --dport $1 -j ACCEPT
iptables -A INPUT -i $INET_DEV -p tcp -d $1 --sport $1 ! --syn -j ACCEPT
}
OUTUDP
{
# erwartet folgende übergabeparameter: INTERNETADRESSE ZIELPORT
# erlaubt alle ausgehenden udp Verbindungen vom lokalen Rechner zu dem übergebenden Port
# und die ergebnisse aus dieser Anfrage
iptables -A OUTPUT -o $INET_DEV -p udp -d $1 --dport $1 -j ACCEPT
iptables -A INPUT -i $INET_DEV -p udp -d $1 --sport $1 ! --syn -j ACCEPT
}

so kommen wir nun zu ein paar weiteren Variablen:
#dienen dazu private Adressen bei ankommenden Paketen fitlern zu können
CLASS_A="10.0.0.0/8"
CLASS_B="172.16.0.0/12"
CLASS_C="192.168.0.0/16"

so kommen wir nun wieder zu einigen filtermassnahmen (geht direkt nach Acceptlocal) weiter:
# Fitlern aller eingehenden Verbdinungen mit privaten Internetadressen
# diese sind entweder wissentlich oder unwissentlich ins Internet versendet worden.
# um Probleme mit dem eigenen Netz zu vermeiden werden diese hier gefiltert
iptables -A INPUT -i $INET_DEV -s $CLASS_A -j DROP
iptables -A INPUT -i $INET_DEV -s $CLASS_B -j DROP
iptables -A INPUT -i $INET_DEV -s $CLASS_C -j DROP
#um nicht selbst ungültige Pakete ins Internet zu schicken filtern wir nun unsere Pakete auch
iptables -A OUTPUT -o $INET_DEV -s $LAN_NET -j DROP # evtl setzt man hier ein LOG um zu sehen, ob solche Pakete überhaupt existieren

# hier erlauben wir nun Anfragen an unseren DNS Server
OUTUDP $NAMESERVER 53

# hier erlauben wir nun unserem Squid Anfragen an Webserver
OUTTCP any/0 80

damit sollten nun die wichtigsten Dinge (sprich surfen) möglich sein.

[gewitter]

#!/bin/bash

IPT="/usr/sbin/iptables" # oder wo immer sich iptables auch befinden mag.
LAN_DEV="eth+" # das geht so auch
INET_DEV="ippp+"
LOOPBACK="lo" # local
LAN_NET="192.168.0.0/24 # ist wegen der möglicherweise dyn. ip's sinnvoller, in dem bereich werden auch die dyn-ip's zugeteilt
LOCALE_DIENSTE="80 3128" #
PROXY="192.168.0.99"
INET_DIENSTE=""

# so kommen wir nun zu ein paar weiteren Variablen:
# dienen dazu private Adressen bei ankommenden Paketen fitlern zu können
CLASS_A="10.0.0.0/8"
CLASS_B="172.16.0.0/12"
CLASS_C="192.168.0.0/16"

NAMESERVER="any/0" # möglicherweise unterschiedliche provider?

AcceptLocal()
{
${IPT} -A INPUT -j ACCEPT -i \! ${INET_DEV}
${IPT} -A OUTPUT -j ACCEPT -o \! ${INET_DEV}
#${IPT} -A FORWARD -j ACCEPT -i \! ${INET_DEV} -o \! ${INET_DEV}
}

OUTTCP()
{
# erwartet folgende übergabeparameter: INTERNETADRESSE ZIELPORT
# erlaubt alle ausgehenden tcp Verbindungen vom lokalen Rechner zu dem übergebenden Port
# und die ergebnisse aus dieser Anfrage
$IPT -A OUTPUT -o $INET_DEV -p tcp -d $1 --dport $2 -j ACCEPT
$IPT -A INPUT -i $INET_DEV -p tcp -s $1 --sport $2 ! --syn -j ACCEPT
# die ergebnisse kommen doch von -s
}

OUTUDP()
{
# erwartet folgende übergabeparameter: INTERNETADRESSE ZIELPORT
# erlaubt alle ausgehenden udp Verbindungen vom lokalen Rechner zu dem übergebenden Port
# und die ergebnisse aus dieser Anfrage
$IPT -A OUTPUT -o $INET_DEV -p udp -d $1 --dport $2 -j ACCEPT
$IPT -A INPUT -i $INET_DEV -p udp -s $1 --sport $2 ! --syn -j ACCEPT
# hier auch -s --sport
}

OUT_ICMP()
{
for i in $1; do
$IPT -A OUTPUT -i $INET_DEV -p icmp --icmp-type $i -j ACCEPT
done
}

IN_ICMP()
{
for i in $1; do
$IPT -A INPUT -i $INT_DEV -p icmp --icmp-type $i -j ACCEPT
done
}

OUTPROXY()
{
# erlaubt alle ausgehenden tcp Verbindungen vom lokalen Proxy zu dem übergebenden Port
# und die ergebnisse aus dieser Anfrage
$IPT -A OUTPUT -o $INET_DEV -p tcp -s $PROXY -d any/0 --dport 80 -j ACCEPT
$IPT -A INPUT -i $INET_DEV -p tcp -d $PROXY -s any/0 --sport 80 ! --syn -j ACCEPT
# kommen diese ergebnisse nicht vom source any?
# Frage: Auf welcher IP läuft der Proxy denn eigentlich? Von der ISDN-Karte? Dann kann man sich ja das hier sparen.
}

##
$IPT -F # falls regeln existieren sollten, werden diese nun gelöscht.
$IPT -X # falls eigene Regelketten definiert wurden, landen diese auch in der tonne (ich selbst verwende keine selbstdefinierten Regelketten

# default policy: DROP wollte eigentlich REJECT verwenden (testen). funktionierte aber neulich nicht.
# evtl vergessenenes Kernelmdoul, oder nicht vorgesehen
$IPT -P INPUT DROP
$IPT -P FORWARD DROP
$IPT -P OUTPUT DROP

AcceptLocal

# so kommen wir nun wieder zu einigen filtermassnahmen (geht direkt nach Acceptlocal) weiter:
# Filtern aller eingehenden Verbdinungen mit privaten Internetadressen
# diese sind entweder wissentlich oder unwissentlich ins Internet versendet worden.
# um Probleme mit dem eigenen Netz zu vermeiden werden diese hier gefiltert
$IPT -A INPUT -i $INET_DEV -s $CLASS_A -j DROP
$IPT -A INPUT -i $INET_DEV -s $CLASS_B -j DROP
$IPT -A INPUT -i $INET_DEV -s $CLASS_C -j DROP
#
# um nicht selbst ungültige Pakete ins Internet zu schicken filtern wir nun unsere Pakete auch
#
$IPT -A OUTPUT -o $INET_DEV -s $LAN_NET -j DROP # evtl setzt man hier ein LOG um zu sehen, ob solche Pakete überhaupt existieren
#
# entspricht vereinfacht dem EgressFilter der PL-FW!

# hier erlauben wir nun Anfragen an unseren DNS Server
OUTUDP $NAMESERVER 53

# hier erlauben wir nun __nur__ unserem Squid Anfragen an Webserver
OUTPROXY
# OUTTCP any/0 80

# ----------------------------------------------------------------------------
# ICMP

# To prevent denial of service attacks based on ICMP bombs, filter
# incoming Redirect (5) and outgoing Destination Unreachable (3).
# Note, however, disabling Destination Unreachable (3) is not
# advisable, as it is used to negotiate packet fragment size.

IN_ICMP "0 3 4 11 12"
OUT_ICMP "3 4 8 12"


# wie soll der squid ftp-anfragen behandeln?
# wenn ich keine forward-regeln benutze, wie bekomme ich die dienste, die nicht über den proxy laufen, raus?
# ICQ, LOPSTER, POP

[trinity]

Hi Thomas,
kommen wir zu den Fragen:
OUTPROXY:
# kommen diese ergebnisse nicht vom source any?
doch, die ergebnisse kommen von any, aber um diese Methode auch für andere Dinge nutzen zu können bei der Verbindungen auf bestimmte Adressen eingeschränkt werden habe ich es so "kompliziert" gemacht.

# Frage: Auf welcher IP läuft der Proxy denn eigentlich? Von der ISDN-Karte? Dann kann man sich ja das hier sparen.
stimmt. du must nur einfach die auskommentierte Version benutzen. Kannst es aber auch stehen lassen es ändert sich nichts.

# wie soll der squid ftp-anfragen behandeln?
dazu sind weitere regeln notwendig. Derzeit steht ja alles auf nichts ist erlaubt uasser surfen.

# wenn ich keine forward-regeln benutze, wie bekomme ich die dienste, die nicht über den proxy laufen, raus?
# ICQ, LOPSTER, POP
Alle Dienste, die keine Proxy Unterstützung haben fallen ohne forewarding aus. Das ist auch absolut so gewünscht, da wir ja nach einem einfachen Schema vorgegangen sind: alles was nicht ausfrücklich erlaubt wurde ist verboten.
Aus diesem Grund muss man sich bevor man loslegt ja auch überlegen, welche Dienste wie angeboten werden. Mein ICQ zu Haause unterstützt z. B. die Kommunikation über einen Proxy (allerdings nur auf dem ssl kanal, warum auch immer).
Für Mail habe ich selbst z. B. diverse Daemons laufen (bei mir zu Hause aufgrund von testzwecken). Damit wird die Kommunikation mit dem Internet grundsätzlich nur indirekt abgewickelt. Sollte man so etwas nicht wollen (ist verdammt unbequem), muss man sich die eine oder andere FORWARDING Regel definieren.

Da der interne Verkehr komplett freigegeben ist, ist mit dieser konfigintern auch dhcp, ftp und dns möglich.

Noch schnell ein paar Sätze zu den iptables Befehlen.
die ! --syn Option verhindert neue Verbindungen die von der entsprechenden Adresse/Device/Port kommen, diese Einschränkung haben wir nur auf Anfragen aus dem Internet gemacht.

Die Frage nach dem ftp-Zugang bezeiht sich auf das Internet, nehme ich an. Falls noch Fragen sind erstmal heraus damit. und ich muss mir erstnochmal die Verbindungdreihenfolge für ftp Anschauen.

[trinity]

Hi Thomas,

sorry für die lange wartepause. da anscheinend keine frgaen sind. nun noch zum schluus die fehlende antwort zu ftp.
für aktives ftp reicht das bereits vorhandene outtcp modul.
outtcp any/0 20
outtcp any/0 21
für passives ftp sind mehr verenkungen notig. dazu muss mann alle port über 1023 freigeben (für source und destination)
deswegen würde es sich hierfür empfehlen, auf connection tracking umzusteigen.

Wie du siehst, lässt sich nicht alles unter einen hut bringen.
grösstmögliche sicherheit steht inabsolutem widerspruch zu möglichst einfacher handhabung.

und nochmals sorry für die lange antwortzeit.
gruß
Lutz

[gewitter]

@Lutz:
ich muss mich entschuldigen wegen der langen wartezeit. ich bin im moment total von anderen dingen in anspruch genommen. daher will ich das thema in wenig ruhen lassen, bis ich wieder zeit habe die hier wachsende firewall auch zu testen. ich habe im moment nur drei fragen:

1. mir ist bei den anderen firewalls aufgefallen, dass bei den freigegebenen zielports die anfragen auch immer auf die eigenen unpriviligierten ports explicit beschränkt waren. wolltest du das nicht berücksichtigen?

2. ich habe in einer firewall masquerading befehle gesehen, wofür werden die gebraucht?

3. was hat es mit den parametern "-m state --state NEW,ESTABLISHED,RELATED" auf sich?

[trinity]

>daher will ich das thema in wenig ruhen lassen, bis ich wieder zeit habe die hier wachsende firewall auch zu testen
kein Problem, kennst ja diesen Thread <img src="http://www.pl-forum.de/UltraBoard/Images/Happy.gif" border="0" align="middle">

1. ich weiss jetzt leider nicht genau, was du meinst
a) Anfragen von Internetrechnern auf freigegebene Dienste
b) Anfragen von Intranetrechnern auf freigegebene Dienste
c) unpriviligierte Ports von fremdrechner/intranetrechner/firewallrechner?
2. die verwenden wahrscheinlich irgendein programm auf einem intranetrechner, dies pakete dieses programms routen sie direkt ins internet. Ist z. B. notwendig für Personen die keinen Proxy einsetzen etc.
3. diese parameter stellen eine der hauptänderungen beim übergang ipchains/iptables dar. sie dienen dem connection tracking, d.h. dein Computer merkt sich, ob das ankommende paket evtl. zu einer bestimmten verbindung gehört.
Die grundlegendste Änderung beim wechsel von ipchains auf iptables sind aber die neu angeordneten Filterketten deswegen sollte man es auch tunlichst vermeiden iptables-scripte in einer ipchains-umgebung zu verwenden (während der umgekehrte weg nicht weiter wild ist)

[gewitter]

zu 1:
als Beispiel

# HTTP server (80)
# ----------------
$IPTABLES -A INPUT -i $EXTERNAL_INTERFACE -p tcp \
--sport $UNPRIVPORTS \
--dport 80 -j ACCEPT

$IPTABLES -A OUTPUT -i $EXTERNAL_INTERFACE -p tcp ! -y \
--sport 80 \
--dport $UNPRIVPORTS -j ACCEPT

zu 2:
icq?

zu 3:
was heisst NEW,ESTABLISHED,RELATED?

[trinity]

1) Wenn du jemandem Anfragen an deinen Webserver erlaubst, macht es keinen unterschied ob der Port den der Anfragende benutzt über oder unter 1024 liegt. Deswegen berücksichtige ich soetwas normalerweise nicht. Ich habe mir bis jetzt auch noch nie die Mühe gemacht, zu testen, ob es tasächlich Anfragen gibt die von Ports <1024 kommen. Wäre mal interessant zu sehen. Muss aber noch ca. 2 Wochen darauf warten, bevor ich das testen kann.
Ähnlich sonnlos halte ich das Filtern von Adressen, die noch nicht von der IANA vergeben wurden. Da es ausser zusätzlicher arbeit keinen Sicherheitsgewinn bringt (unter umständen muss man dann nur lange nach Fehlern suchen, wo eigentlich keine sind PS: Gruß an Stormbringer <img src="http://www.pl-forum.de/UltraBoard/Images/Happy.gif" border="0" align="middle">)


2)
Ja, wenn man keinen Proxy hat, über den icq Verbindungen zum Server aufnehmen kann, ist MASQUERADING die einzige Möglichkeit.

3)
NEW: erlaubt/verbietet neue Verbindungen
ESTABLISHED: erlaubt/verbietet Verbindungen, die zu einer bereits bestehenden gehören (also alle Pakete nach einem dem Verbindungsaufbau mit NEW)
RELATED: sind alle Pakete, die (indirekt) zu einer bestehenden gehören aber nicht teil dieser bestehenden Verbdindung sind z.B. Fehlermeldungen (icmp).