Archiv verlassen und diese Seite im Standarddesign anzeigen : In meinem Firewall Skript gibt der DHCP Router keine Namen an meinem Linux Server
Ich habe mal einen Firewall Startskript gemacht der ist zwar nicht besonders aber besser kann ich es momentan nicht.Ich habe nur das Problem das mein Router dem Linux Server keinen Namen gibt.
Also schaut es euch mal an:
#! /bin/bash
iptables -F #Löschen der tabele
iptables -P OUTPUT DROP #Setzen der OUTPUT auf DROP
iptables -P INPUT DROP #Setzen der INPUT auf DROP
iptables -P FORWARD DROP #Setzen der FORWARD auf DROP
#-----------------------------------------------SSH-------------------------------------------------------#
iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT #Intern SSH
iptables -A INPUT -i eth0 -p tcp --sport 22 -j ACCEPT #Intern SSH
iptables -A OUTPUT -o eth0 -p tcp --dport 22 -j ACCEPT #Intern SSH
iptables -A OUTPUT -o eth0 -p tcp --sport 22 -j ACCEPT #Intern SSH
iptables -A INPUT -i ppp0 -p tcp --dport 22 -j ACCEPT #Extern SSH
iptables -A INPUT -i ppp0 -p tcp --sport 22 -j ACCEPT #Extern SSH
iptables -A OUTPUT -o ppp0 -p tcp --dport 22 -j ACCEPT #Extern SSH
iptables -A OUTPUT -o ppp0 -p tcp --sport 22 -j ACCEPT #Extern SSH
#----------------------------------------------Telnet-----------------------------------------------------#
iptables -A INPUT -i eth0 -p tcp --dport 23 -j ACCEPT #Intern Telnet
iptables -A INPUT -i eth0 -p tcp --sport 23 -j ACCEPT #Intern Telnet
iptables -A OUTPUT -o eth0 -p tcp --dport 23 -j ACCEPT #Intern Telnet
iptables -A OUTPUT -o eth0 -p tcp --sport 23 -j ACCEPT #Intern Telnet
iptables -A INPUT -i ppp0 -p tcp --dport 23 -j ACCEPT #Extern Telnet
iptables -A INPUT -i ppp0 -p tcp --sport 23 -j ACCEPT #Extern Telnet
iptables -A OUTPUT -o ppp0 -p tcp --dport 23 -j ACCEPT #Extern Telnet
iptables -A OUTPUT -o ppp0 -p tcp --sport 23 -j ACCEPT #Extern Telnet
#----------------------------------------------Swat-----------------------------------------------------#
iptables -A INPUT -i eth0 -p tcp --dport 901 -j ACCEPT #Intern Swat
iptables -A INPUT -i eth0 -p tcp --sport 901 -j ACCEPT #Intern Swat
iptables -A OUTPUT -o eth0 -p tcp --dport 901 -j ACCEPT #Intern Swat
iptables -A OUTPUT -o eth0 -p tcp --sport 901 -j ACCEPT #Intern Swat
iptables -A INPUT -i ppp0 -p tcp --dport 901 -j ACCEPT #Extern Swat
iptables -A INPUT -i ppp0 -p tcp --sport 901 -j ACCEPT #Extern Swat
iptables -A OUTPUT -o ppp0 -p tcp --dport 901 -j ACCEPT #Extern Swat
iptables -A OUTPUT -o ppp0 -p tcp --sport 901 -j ACCEPT #Extern Swat
#----------------------------------------------Http-----------------------------------------------------#
iptables -A INPUT -i eth0 -p tcp --dport 80 -j ACCEPT #Intern
iptables -A INPUT -i eth0 -p tcp --sport 80 -j ACCEPT #Intern
iptables -A OUTPUT -o eth0 -p tcp --dport 80 -j ACCEPT #Intern
iptables -A OUTPUT -o eth0 -p tcp --sport 80 -j ACCEPT #Intern
iptables -A INPUT -i ppp0 -p tcp --dport 80 -j ACCEPT #Extern
iptables -A INPUT -i ppp0 -p tcp --sport 80 -j ACCEPT #Extern
iptables -A OUTPUT -o ppp0 -p tcp --dport 80 -j ACCEPT #Extern
iptables -A OUTPUT -o ppp0 -p tcp --sport 80 -j ACCEPT #Extern
iptables -A INPUT -i eth0 -p udp --dport 80 -j ACCEPT #Intern
iptables -A INPUT -i eth0 -p udp --sport 80 -j ACCEPT #Intern
iptables -A OUTPUT -o eth0 -p udp --dport 80 -j ACCEPT #Intern
iptables -A OUTPUT -o eth0 -p udp --sport 80 -j ACCEPT #Intern
iptables -A INPUT -i ppp0 -p udp --dport 80 -j ACCEPT #Extern
iptables -A INPUT -i ppp0 -p udp --sport 80 -j ACCEPT #Extern
iptables -A OUTPUT -o ppp0 -p udp --dport 80 -j ACCEPT #Extern
iptables -A OUTPUT -o ppp0 -p udp --sport 80 -j ACCEPT #Extern
#----------------------------------------------DHCP Failover-----------------------------------------------------#
iptables -A INPUT -i eth0 -p tcp --dport 647 -j ACCEPT #Intern
iptables -A INPUT -i eth0 -p tcp --sport 647 -j ACCEPT #Intern
iptables -A OUTPUT -o eth0 -p tcp --dport 647 -j ACCEPT #Intern
iptables -A OUTPUT -o eth0 -p tcp --sport 647 -j ACCEPT #Intern
iptables -A INPUT -i ppp0 -p tcp --dport 647 -j ACCEPT #Extern
iptables -A INPUT -i ppp0 -p tcp --sport 647 -j ACCEPT #Extern
iptables -A OUTPUT -o ppp0 -p tcp --dport 647 -j ACCEPT #Extern
iptables -A OUTPUT -o ppp0 -p tcp --sport 647 -j ACCEPT #Extern
iptables -A INPUT -i eth0 -p udp --dport 647 -j ACCEPT #Intern
iptables -A INPUT -i eth0 -p udp --sport 647 -j ACCEPT #Intern
iptables -A OUTPUT -o eth0 -p udp --dport 647 -j ACCEPT #Intern
iptables -A OUTPUT -o eth0 -p udp --sport 647 -j ACCEPT #Intern
iptables -A INPUT -i ppp0 -p udp --dport 647 -j ACCEPT #Extern
iptables -A INPUT -i ppp0 -p udp --sport 647 -j ACCEPT #Extern
iptables -A OUTPUT -o ppp0 -p udp --dport 647 -j ACCEPT #Extern
iptables -A OUTPUT -o ppp0 -p udp --sport 647 -j ACCEPT #Extern
#---------------------------------------------DHCPv6-----------------------------------------------------#
iptables -A INPUT -i eth0 -p tcp --dport 546 -j ACCEPT #Intern
iptables -A INPUT -i eth0 -p tcp --sport 546 -j ACCEPT #Intern
iptables -A OUTPUT -o eth0 -p tcp --dport 546 -j ACCEPT #Intern
iptables -A OUTPUT -o eth0 -p tcp --sport 546 -j ACCEPT #Intern
iptables -A INPUT -i ppp0 -p tcp --dport 546 -j ACCEPT #Extern
iptables -A INPUT -i ppp0 -p tcp --sport 546 -j ACCEPT #Extern
iptables -A OUTPUT -o ppp0 -p tcp --dport 546 -j ACCEPT #Extern
iptables -A OUTPUT -o ppp0 -p tcp --sport 546 -j ACCEPT #Extern
iptables -A INPUT -i eth0 -p udp --dport 546 -j ACCEPT #Intern
iptables -A INPUT -i eth0 -p udp --sport 546 -j ACCEPT #Intern
iptables -A OUTPUT -o eth0 -p udp --dport 546 -j ACCEPT #Intern
iptables -A OUTPUT -o eth0 -p udp --sport 546 -j ACCEPT #Intern
iptables -A INPUT -i ppp0 -p udp --dport 546 -j ACCEPT #Extern
iptables -A INPUT -i ppp0 -p udp --sport 546 -j ACCEPT #Extern
iptables -A OUTPUT -o ppp0 -p udp --dport 546 -j ACCEPT #Extern
iptables -A OUTPUT -o ppp0 -p udp --sport 546 -j ACCEPT #Extern
#---------------------------------------------Samba-----------------------------------------------------#
iptables -A INPUT -i eth0 -p tcp --dport 139 -j ACCEPT #Intern
iptables -A INPUT -i eth0 -p tcp --sport 139 -j ACCEPT #Intern
iptables -A OUTPUT -o eth0 -p tcp --dport 139 -j ACCEPT #Intern
iptables -A OUTPUT -o eth0 -p tcp --sport 139 -j ACCEPT #Intern
iptables -A INPUT -i ppp0 -p tcp --dport 139 -j ACCEPT #Extern
iptables -A INPUT -i ppp0 -p tcp --sport 139 -j ACCEPT #Extern
iptables -A OUTPUT -o ppp0 -p tcp --dport 139 -j ACCEPT #Extern
iptables -A OUTPUT -o ppp0 -p tcp --sport 139 -j ACCEPT #Extern
iptables -A INPUT -i eth0 -p udp --dport 139 -j ACCEPT #Intern
iptables -A INPUT -i eth0 -p udp --sport 139 -j ACCEPT #Intern
iptables -A OUTPUT -o eth0 -p udp --dport 139 -j ACCEPT #Intern
iptables -A OUTPUT -o eth0 -p udp --sport 139 -j ACCEPT #Intern
iptables -A INPUT -i ppp0 -p udp --dport 139 -j ACCEPT #Extern
iptables -A INPUT -i ppp0 -p udp --sport 139 -j ACCEPT #Extern
iptables -A OUTPUT -o ppp0 -p udp --dport 139 -j ACCEPT #Extern
iptables -A OUTPUT -o ppp0 -p udp --sport 139 -j ACCEPT #Extern
iptables -A INPUT -i eth0 -p tcp --dport 137 -j ACCEPT #Intern
iptables -A INPUT -i eth0 -p tcp --sport 137 -j ACCEPT #Intern
iptables -A OUTPUT -o eth0 -p tcp --dport 137 -j ACCEPT #Intern
iptables -A OUTPUT -o eth0 -p tcp --sport 137 -j ACCEPT #Intern
iptables -A INPUT -i ppp0 -p tcp --dport 137 -j ACCEPT #Extern
iptables -A INPUT -i ppp0 -p tcp --sport 137 -j ACCEPT #Extern
iptables -A OUTPUT -o ppp0 -p tcp --dport 137 -j ACCEPT #Extern
iptables -A OUTPUT -o ppp0 -p tcp --sport 137 -j ACCEPT #Extern
iptables -A INPUT -i eth0 -p udp --dport 137 -j ACCEPT #Intern
iptables -A INPUT -i eth0 -p udp --sport 137 -j ACCEPT #Intern
iptables -A OUTPUT -o eth0 -p udp --dport 137 -j ACCEPT #Intern
iptables -A OUTPUT -o eth0 -p udp --sport 137 -j ACCEPT #Intern
iptables -A INPUT -i ppp0 -p udp --dport 137 -j ACCEPT #Extern
iptables -A INPUT -i ppp0 -p udp --sport 137 -j ACCEPT #Extern
iptables -A OUTPUT -o ppp0 -p udp --dport 137 -j ACCEPT #Extern
iptables -A OUTPUT -o ppp0 -p udp --sport 137 -j ACCEPT #Extern
#----------------------------------------------Domain-----------------------------------------------------#
iptables -A INPUT -i eth0 -p tcp --dport 53 -j ACCEPT #Intern
iptables -A INPUT -i eth0 -p tcp --sport 53 -j ACCEPT #Intern
iptables -A OUTPUT -o eth0 -p tcp --dport 53 -j ACCEPT #Intern
iptables -A OUTPUT -o eth0 -p tcp --sport 53 -j ACCEPT #Intern
iptables -A INPUT -i ppp0 -p tcp --dport 53 -j ACCEPT #Extern
iptables -A INPUT -i ppp0 -p tcp --sport 53 -j ACCEPT #Extern
iptables -A OUTPUT -o ppp0 -p tcp --dport 53 -j ACCEPT #Extern
iptables -A OUTPUT -o ppp0 -p tcp --sport 53 -j ACCEPT #Extern
iptables -A INPUT -i eth0 -p udp --dport 53 -j ACCEPT #Intern
iptables -A INPUT -i eth0 -p udp --sport 53 -j ACCEPT #Intern
iptables -A OUTPUT -o eth0 -p udp --dport 53 -j ACCEPT #Intern
iptables -A OUTPUT -o eth0 -p udp --sport 53 -j ACCEPT #Intern
iptables -A INPUT -i ppp0 -p udp --dport 53 -j ACCEPT #Extern
iptables -A INPUT -i ppp0 -p udp --sport 53 -j ACCEPT #Extern
iptables -A OUTPUT -o ppp0 -p udp --dport 53 -j ACCEPT #Extern
iptables -A OUTPUT -o ppp0 -p udp --sport 53 -j ACCEPT #Extern
Danke für die Hilfe
hi
dein script ist recht *eigenwillig*. du verwendest neben ssh zusätzlich noch telnet, warum? ausserdem gibst du samba *zum internet* hin frei. imho sollte man das tunlichst vermeiden.
zudem sind viele regeln überflüssig. um mal bei ssh zu bleiben. du möchtest von deinem client zu deinem router/paketfilter eine ssh verbindung aufbauen können.
client (port <1023) ===> server (port 22)
antwort vom server(port22) ===> client (port <1023)
im allgemeinen wird der nächstfreie port von 1023 abwärts vom client benutzt, und für jede ssh-verbindung ein eigener port, deshalb ist es sinnvoll einen portbereich zu definieren
int=eth0 #internes interface
p_ssh=1000:1023
iptables -A INPUT -i $int -p tcp --sport $p_ssh --dport 22 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o $int -p tcp --sport 22 --dport $p_ssh -m state --state ESTABLISHED,RELATED -j ACCEPT
ps: lass dir mal von harry's seite ein script generieren, da kannst du den aufbau studieren => http://www.harry.homelinux.org/index.php
Gruß HL
"iptables -A INPUT -i $int -p tcp --sport $p_ssh --dport 22 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT"
related würde in diesem fall doch die komplette firewall aushebeln ?
man connectet an den 22 port ( auch wenn man sich nicht einloggt ist die verbindung established ) und kann von dieser verbindung aus jeden beliebigen port auf dem rechner ansprechen ( RELATED )... oder ?
hi scare
related würde in diesem fall doch die komplette firewall aushebeln ?
hm, related bedeutet ja, das die pakete in beziehung zu einer offenen verbindung stehen. ob das bei ssh allerdings zwingend erforderlich ist, ist ne andere frage.
und kann von dieser verbindung aus jeden beliebigen port auf dem rechner ansprechen ( RELATED )... oder ?
meiner meinung nach nicht. alles was an einen port kommt, der nicht explizit erlaubt ist, wird fallengelassen. kommt natürlich auf die default policy an.
Gruß HL
"hm, related bedeutet ja, das die pakete in beziehung zu einer offenen verbindung stehen. ob das bei ssh allerdings zwingend erforderlich ist, ist ne andere frage..."
jo genau das mein ich ja... nur ob ich bei ssh authentifiziert bin oder beim "enter username & pw" - feld bin, macht bei der verbindung an sich keinen unterschied...
d.h. für itables ist is etablished.... dank der RELATED rule kann der ssh-client jetzte jeden port öffen den er will...
.... dank der RELATED rule kann der ssh-client jetzte jeden port öffen den er will...
kannst du das mal an einem konkreten beispiel zeigen, wie so ein *angriff* aussehen könnte. mir fehlt da wohl ein wenig die phantasie. also wie kann ich mit dem ssh-client einen beliebigen port öffnen, gern auch als PN ;).
Gruß HL
ok :)
also man nehme ein c programm...
öffnet da via socket eine verbindung an den port 22 des opfers....
damit hat mal für die iptables firewall eine ESTABLISHED verbindung zum port 22...
jetzt kann man von dem programm aus jeden beliebigen port beim server des opfers öffnen, da iptables alle verbindungen zu der ersten assoziiert, und sie dank RELATED durch lässt....
mit anderen worten... für das c programm hat ab dem zeitpunkt der connection an den port 22 der server des opfers keine firewall mehr...
aus diesem grund sollte man möglichst ohne RELATED in seiner fw auskomme, bzw. es dort verwenden wo man clients vertraut... z.b. bei dem weg von innen nach aussen (FORWARD)...
www.netfilter.org[/url]] :)
When a packet with the SYN+ACK flags set arrrives in response to a packet with SYN set the connection tracking thinks: "I have been just seeing a packet with SYN+ACK which answers a SYN I had previously seen, so this is an ESTABLISHED connection."
-
..., and RELATED meaning that the packet is starting a new connection, but is associated with an existing connection, such as an FTP data transfer, or an ICMP error.
hi
also man nehme ein c programm...
öffnet da via socket eine verbindung an den port 22 des opfers....
da scheitert es bei mir schon, von solchen sachen hab ich null plan :D
das ganze ist aber sehr interessant.
aus diesem grund sollte man möglichst ohne RELATED in seiner fw auskomme, bzw. es dort verwenden wo man clients vertraut... z.b. bei dem weg von innen nach aussen (FORWARD)...
um mal bei der ssh-rule von oben zu bleiben. das ganze ist ja eingeschränkt auf das interne interface => -i $int, ssh von aussen ist nicht erlaubt, kann man ohne das komplette script natürlich nicht wissen.
wie siehst du die verwendung von RELATED in folgenden regeln
#--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
# ausgehende Pakete bei bereits aufgebauter Verbindung erlauben
#-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
$ipt -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$ipt -A FORWARD -i $int -o $ext -m state --state ESTABLISHED,RELATED -j ACCEPT
#--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
# Rückkanal: eingehende Paket zu einer bestehenden Verbindung
#--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
$ipt -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$ipt -A INPUT -m state --state NEW,INVALID -j my_drop
$ipt -A FORWARD -i $ext -o $int -m state --state ESTABLISHED,RELATED -j ACCEPT
$ipt -A FORWARD -i $ext -o $int -m state --state NEW,INVALID -j my_drop
#------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
# HTTP
#-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
$ipt -A FORWARD -o $ext -m state --state NEW -p TCP --sport $p_high --dport http -j ACCEPT
ohne NEW, dürfte das doch kein problem sein, oder?
würdest du auf RELATED ganz verzichten? ich häng mal mein komplettes script an, eventuell findest du ja noch ne weitere schwachstelle
Gruß HL
$ipt -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
hebelt die ganze fw aus, sobald nur 1 einziger port nach aussen offen is, kann von dem port aus, wie oben beschrieben jeder port geöffnet werden...
RELATED braucht man im normalfall gar net, da man die ports selbst soweit einschränken kann... afaik klappt das nur bei ftp nicht so gut... da man entweder für aktiv oder passiv modus einmal RELATED braucht....
wenn man natürlich der absolute sicherheitsfanatiker ist, lässt man related komplett weg und nutz dann eben als client nur den passiv, bzw. als server nur den aktiv modus... ( wie ich :D )
bsp:
sshd ohne related:
exec_ipt -A INPUT -i $default_iface -p TCP -m state --state NEW --sport $ports_high --dport 22 -s $hostnet -d $default_ip -j $target
exec_ipt -A INPUT -i $default_iface -p TCP -m state --state NEW --sport $ssh_ports_high --dport 22 -s $hostnet -d $default_ip -j $target
ssh client ohne related:
exec_ipt -A FORWARD -i $default_iface -p TCP -m state --state NEW -s $hostnet --sport $ports_high --dport 22 -j $target
exec_ipt -A FORWARD -i $default_iface -p TCP -m state --state NEW -s $hostnet --sport $ssh_ports_high --dport 22 -j $target
falls interresse besteht kann ich ja auch mal meine firewall anhängen ;)
hi
erstmal thx für die interessanten info's. das problem mit RELATED war mir nicht bewußt, zumal in meinem schlauen büchlein nichts davon erwähnt wird, im gegenteil von RELATED wird reger gebrauch gemacht :)
hebelt die ganze fw aus, sobald nur 1 einziger port nach aussen offen is, kann von dem port aus, wie oben beschrieben jeder port geöffnet werden...
auf dem router/firewall selbst läuft kein weiterer dienst, alle ports sind zu.
RELATED braucht man im normalfall gar net, da man die ports selbst soweit einschränken kann... afaik klappt das nur bei ftp nicht so gut... da man entweder für aktiv oder passiv modus einmal RELATED braucht.... wenn man natürlich der absolute sicherheitsfanatiker ist, lässt man related komplett weg und nutz dann eben als client nur den passiv, bzw. als server nur den aktiv modus... ( wie ich )
hab ich mir auch schon gedacht, das das RELATED hauptsächlich für ftp interessant ist. da ich aber keinen passiven ftp-server betreibe, kann ich mir das RELATED wohl wirklich schenken.
falls interresse besteht kann ich ja auch mal meine firewall anhängen
immer her damit :)
Gruß HL
aba net schreien ;)
--
dazu gibbet dann noch ne firewall.conf in der die hosts einfach angegeben werden...
# =======================
#
# firewall - config file
#
# =======================
## firewall settings
# files
# hosts.allow file
file_hostsallow="/etc/hosts.allow"
# interfaces
iface_intern="eth0"
iface_extern="ppp0"
iface_secure="ipsec+"
iface_wlan="wlan0"
# hosts
# -local
home_pyx=`res_ip pyx.home.lan`
home_sid=`res_ip sid.home.lan`
home_lap=`res_ip scrat.home.lan`
home_ftp=`res_ip suck-it.home.lan`
home_ftp2=`res_ip ftp2.home.lan`
home_eltern=`res_ip eltern.home.lan`
intern_cyn=$(get_iface_ip $iface_intern)
wlan_cyn=$(get_iface_ip $iface_wlan)
# -ipsec
flo_router=`res_ip lachrouter.home.lan`
flo_client=`res_ip flo.home.lan`
ipsec_scrat=`res_ip scrat.vpn.home.lan`
# -virtual
virtual_webmail=`res_ip webmail.home.lan`
# -inet
inet_cyn=$(get_iface_ip $iface_extern)
inet_ptp=$(get_iface_ptp $iface_extern)
# -wlan
wlan_scrat=`res_ip scrat.wlan.home.lan`
# networks
network_cyn="192.168.0.0/24"
network_flo="172.18.0.0/16"
network_wlan="192.168.1.0/24"
# aliases
trusted_clients="$home_pyx $home_sid $home_lap $home_ftp $home_ftp2"
normal_clients="$trusted_clients $home_eltern"
bc_client="$home_sid"
# -wlan
wlan_clients="$wlan_scrat"
# ports
# -irc
irc_ports="6666:6673 31330"
# -hlsw
hlsw_ports="7130:7132"
# -teamspeak
tss_port="8767"
# -webmin
webmin_port="8989"
## virtual ips
# virtual hosts ("" or "interface1 IP1 type interface1 IP2 type interface2 IP1 type...") (sorted by iface)
# currently supported types: https
virtual_hosts="$iface_intern $virtual_webmail https"
## security options
# reject instead of drop (internal interface) ?
enable_intern_reject=1
# reject instead of drop (secure interface) ?
enable_secure_reject=1
# reject instead of drop (external interface) ?
enable_extern_reject=0
# reject instead of drop (wlan) ?
enable_wlan_reject=1
# block incoming portscans ? (0/1)
enable_portscan_protection=1
# allow internal portscans from... ? ("" or host/network list)
portscan_intern_allow_hosts="$home_pyx $home_sid $home_lap"
# allow ipsec portscans from... ? ("" or host/network list)
portscan_secure_allow_hosts=""
# allow external portscans from... ? ("" or host/network list)
portscan_extern_allow_hosts=""
# allow wlan portscans from... ? ("" or host/network list)
portscan_wlan_allow_hosts=""
## local ( server -> world ) settings
geht via
servicename_client_interface_enable= 0/1
## local services
gibt es 2 möglichkeiten:
servicename_interface_enable=0/1 # für das ganze inferface freigeben..
oder
servicename_interface_allow="host/network host/network ..."
## forward services
gibt es 2 möglichkeiten:
servicename_forward_interface_enable=0/1 # für das ganze inferface freigeben..
oder
servicename_forward_interface_allow="host/network host/network ..."
## dnat
dnat_interface_protocol0=tcp/udp/blubb
dnat_interface_dstport0=zielport/portrange
dnat_interface_fwhost0=forward to host
# optional
dnat_interface_fwport0=port # eine port range auf einen port mappen & weiterleiten
will man mehrere eingeben, muss man eben 0,1,2,3,4,etc in steigender reihenfolge verwenden :)
hi scrat
Heilige Jungfrau was für ein script :) :rolleyes:
bis ich das verstehe, wird wohl noch einiges an wasser die elbe runter fließen ;)
Gruß HL
hehe :)
is meine 4 te firewall.... langsam nähere ich mich der perfektion ;)
öffnet da via socket eine verbindung an den port 22 des opfers....
damit hat mal für die iptables firewall eine ESTABLISHED verbindung zum port 22...Ja
jetzt kann man von dem programm aus jeden beliebigen port beim server des opfers öffnen, da iptables alle verbindungen zu der ersten assoziiert, und sie dank RELATED durch lässt.... Nein. RELATED Pakete müssen zwar zu einer bestehnden Verbindung gehören, aber sofern es sich nicht um Fehlermeldungen handelt, wird ein weiteres Modul benötigt (z. B. ftp), ansonsten ist diese Verbindung nicht RELATED, sondern NEW.
RELEATED ist ein angenehmer weg um nicht alle ICMP Fehlernachrichten von Hand auswerten zu müssen.
siehe auch: http://www.netfilter.org/documentation/tutorials/blueflux/iptables-tutorial.html#STATEMACHINE
"wird ein weiteres Modul benötigt (z. B. ftp)"
das ftp conntrack modul hat nichts mit RELATED & co zu tun...
der ftp server schickt via PORT xxx cmd an den client, den port an welchen er für den datentransfer connecten soll ( im aktiv modus )... dieses command fängt er ab und öffnet den entsprechenden port in der firewall...
"Nein. RELATED Pakete müssen zwar zu einer bestehnden Verbindung gehören, aber sofern es sich nicht um Fehlermeldungen handelt, wird ein weiteres Modul benötigt (z. B. ftp), ansonsten ist diese Verbindung nicht RELATED, sondern NEW."
nein, einfaches beispiel: ftp passiv modus... (wird nicht vom conntrack_ftp modul behandelt !)
client hat eine verbindung an den port 21... und kann ( bei RELATED ) von dieser verbindung aus jeden port für den daten transfer öffnen ( zumindest jeden high port )...
"Do note that most TCP protocols and some UDP protocols that rely on this mechanism are quite complex and send connection information within the payload of the TCP or UDP data segments, and hence require special helper modules to be correctly understood."
ich denke conntrack module kommen immer erst zum einsatz, wenn normale firewall regeln das gewünschte ziel nicht erreichen können.... (z.b. ich kann mit reinen filter regeln nicht auf das ftp PORT command reagieren, etc.. )
dass RELATED nur conntrack module beeinflusst, kann ich nicht glauben, da ich etliche sachen probiert habe, bevor ich mit meiner firewall fertig war, und feststellen musste dass an einigen stellen related doch andere sachen beinflusst hat...
client hat eine verbindung an den port 21... und kann ( bei RELATED ) von dieser verbindung aus jeden port für den daten transfer öffnen ( zumindest jeden high port )... Das war AFAIK ein Fehler im ftp Netfilter Modul (siehe: http://www.netfilter.org/security/2001-04-16-ftp.html).
nein, einfaches beispiel: ftp passiv modus... (wird nicht vom conntrack_ftp modul behandelt !)
client hat eine verbindung an den port 21... und kann ( bei RELATED ) von dieser verbindung aus jeden port für den daten transfer öffnen ( zumindest jeden high port )... nein, das funktioneirt nicht. Probier es aus. Ohne zusätzliche Freigabe geht gar nichts, nichtmal ls.
ich denke conntrack module kommen immer erst zum einsatz, wenn normale firewall regeln das gewünschte ziel nicht erreichen können.... (z.b. ich kann mit reinen filter regeln nicht auf das ftp PORT command reagieren, etc.. ) Nein. Die zusätzlichen Module müssen sofort aktiv sein, wenn das PORT Kommando bei der FTP-Verbindung verpennt wird, kann der Paketfilter nachträglich nicht entscheiden ob es eine gewünschte Verbindung ist oder nicht.
dass RELATED nur conntrack module beeinflusst, kann ich nicht glauben, da ich etliche sachen probiert habe, bevor ich mit meiner firewall fertig war, und feststellen musste dass an einigen stellen related doch andere sachen beinflusst hat... Mach mal ein Paar Beispiele, bin gebannt gespannt :)
"nein, das funktioneirt nicht. Probier es aus. Ohne zusätzliche Freigabe geht gar nichts, nichtmal ls. "
passiv modus, stell bei deinem client die port range ein, forwarde die ports via ACCEPT, passiver ftp geht...
(das nur port 20, 21 freigeben nicht langt ist ja allein logisch)..
dein beispiel müsste anderes rum aussehn...
nehm conntrack ftp raus, lass deine RELATED rules drin... und falls du recht hast dürfte genau dann ftp nicht mehr gehn, bzw. nach nem insmod ipt_conntrack_ftp dann wieder gehn
aktiver kann logischerweise nicht gehn, da du nicht beeinflussen kannst welchen port dir der server zuweist, und ohne ftp-modul das "port cmd" nicht nutzen kannst...
"Nein. Die zusätzlichen Module müssen sofort aktiv sein, wenn das PORT Kommando bei der FTP-Verbindung verpennt wird, kann der Paketfilter nachträglich nicht entscheiden ob es eine gewünschte Verbindung ist oder nicht. "
??? das ist mir schon klar, darum ging es auch nicht ?
"Mach mal ein Paar Beispiele, bin gebannt gespannt "
:), die firewall hab ich vor ner weile geschrieben, einiges rumprobiert und rumgespielt bevor alles so lief... also puuuh *nachdenk* ;)
ich glaub ein bsp war ssh... hatte da ich rules gesehn:
exec_ipt -A OUTPUT -o $default_iface -p TCP -m state --state NEW,RELATED --sport $ports_high --dport 22 -s $default_ip -d $default_network -j $target
ohne related klappte nicht mehr als eine simultane verbindung...
mit
exec_ipt -A OUTPUT -o $default_iface -p TCP -m state --state NEW --sport $ssh_ports_high --dport 22 -s $default_ip -d $default_network -j $target
gehen dann wieder mehrere...
so weit ich mich erinner ;)
Ich weiss nicht, vielleicht reden wir aneinander vorbei:
Du warst doch der Ansicht, dass nur aufgrund der RELATED Regeln ftp funktionieren müsste.
nein, einfaches beispiel: ftp passiv modus... (wird nicht vom conntrack_ftp modul behandelt !)
client hat eine verbindung an den port 21... und kann ( bei RELATED ) von dieser verbindung aus jeden port für den daten transfer öffnen ( zumindest jeden high port )...
Aber das geht nicht so einfach, die ftp Verbindung kommt ohne NEW und ESTABLISHED zum Zuge und nicht aufgrund von RELATED. Aber wenn ich das ip_conntrack_ftp Modul lade, kann ich auch mit RELATED arbeiten und auf NEW verzichten :)
"Nein. Die zusätzlichen Module müssen sofort aktiv sein, wenn das PORT Kommando bei der FTP-Verbindung verpennt wird, kann der Paketfilter nachträglich nicht entscheiden ob es eine gewünschte Verbindung ist oder nicht. "
das ist mir schon klar, darum ging es auch nicht? Sondern? Der Text von dir,auf den ich mich bezog, sagte aber genau das aus.
PS:
ich denke conntrack module kommen immer erst zum einsatz, wenn normale firewall regeln das gewünschte ziel nicht erreichen können Connection Tracking kommt einmal eingeschaltet für jedes Paket zum Einsatz.
axo lol... da reden wir teilweise schon aneinander vorbei ;)
>ich denke conntrack module kommen immer erst zum einsatz, wenn normale firewall regeln >das gewünschte ziel nicht erreichen können
>--------------------------------------------------------------------------------
>Connection Tracking kommt einmal eingeschaltet für jedes Paket zum Einsatz.
ich meinte damit, dass ein modul erst geproggt wird, wenn man mit normalen firewall regeln das ziel nicht erreichen kann... :)
"Du warst doch der Ansicht, dass nur aufgrund der RELATED Regeln ftp funktionieren müsste. "
jein..
natürlich nachdem die verbindung an port 21 für NEW & ESTABLISHED durchgeht...
(habe ich keine established verbindung, kann RELATED nicht zutreffen :))
und in dem fall geht der test auch so einfach wie ich meinte ;)
moin moin
jetzt misch ich auch mal wieder ein ;)
ich meinte damit, dass ein modul erst geproggt wird, wenn man mit normalen firewall regeln das ziel nicht erreichen kann...
das geniale an connection tracking ist doch, das man den paketfilter dynamisch *gestalten* kann. bevor es dieses ftp-modul gab, um mal bei ftp zu bleiben, war es doch so, das man, sofern man einen passiven ftp-server betrieben hat, die highports offen halten mußte, damit eine verbindung vom client aus aufgebaut werden konnte. von der sicherheit her nicht grade optimal.
und jetzt kommt das ftp-modul ins spiel. der server teilt dem client doch in seiner antwort mit, welchen port er für die dataverbindung offen hält. diese antwort wird von dem ftp-modul *ausgelesen* und der paketfilter läßt dann die anfrage vom client, sofern der port mit dem *ausgelesenen* übereinstimmt (wahrscheinlich muss dabei noch einiges mehr mit dem eintrag in der tabelle übereinstimmen, bsw. source-ip könnte ich mir vorstellen), passieren. das ist in meinen augen was bei RELATED passiert.
was ich damit eigentlich sagen will, ohne dieses spezielle modul für ftp ist es nicht möglich, die data-verbindung nur mit einem RELATED in der regel zu realisieren. deshalb hab ich doch meine zweifel,
das man mit einem c program einfach so ports öffnen kann. hast du nicht lust solch ein teil zu schreiben, ich würde das gerne mal testen, hab aber von c keine ahnung ;)
wenn ich mit oben gesagtem auf dem holzweg bin, verbessert mich. man lernt ja gerne dazu ;)
@scrat
zu deinem beispiel nochmal. meine ssh regeln (für den router) sehen momentan so aus.
$ipt -A INPUT -i $int -s $intern -p tcp --sport 1024:65535 --dport ssh -m state --state NEW,ESTABLISHED -j ACCEPT
$ipt -A OUTPUT -o $int -d $intern -p tcp -dport 1024:65535 --sport ssh -m state --state ESTABLISHED -j ACCEPT
ich habe RELATED aus den regeln rausgeschmissen, kann aber trotzdem etliche ssh verbindungen zum router hin aufbauen.
bei der gelegenheit ist mir noch folgendes aufgefallen. eigentlich war ich der meinung, das der ssh-client die ports ab 1023 abwärts benutzt. ursprünglich hatte ich für diese ports auch eine variable definiert
p_ssh=1000:1023
allerdings kamen die anfragen dann nicht durch. ein blick in die log's zeigte mir dann, das der ssh-client highports benutzte. ist das ganze eine sache der konfiguration welche ports benutzt werden?
hab ssh mal mit -v gestartet und dabei ist mir folgende zeile aufgefallen
Rhosts Authentication disabled, originating port will not be trusted.
hängt das damit zusammen?
Gruß HL
puuhh... das ergibt irgendwie auch einen sinn :)
schein so als lernt man doch nicht aus ;)
bei gelegenheit teste ich das mal... (mit/ohne conntrack_ftp_modul), dann hab ich gewissheit..
zu ssh:
mein beispiel bezog sich auf:
router als ssh client, unter der vorraussetzung, dass ESTABLISHED verbindungen in der fw standartmässig durchgehn
"bei der gelegenheit ist mir noch folgendes aufgefallen. eigentlich war ich der meinung, das der ssh-client die ports ab 1023 abwärts benutzt. ursprünglich hatte ich für diese ports auch eine variable definiert"
"Rhosts Authentication disabled, originating port will not be trusted."
"hängt das damit zusammen?"
ich denke mal nicht. 1023 abwärts wäre unlogisch, da nur root ports unter 1024 öffnen darf...
"ist das ganze eine sache der konfiguration welche ports benutzt werden?"
hmm da bin ich überfragt, jedoch falls es keine config var zum einstellen dieser ports gibt, so gibt es zumindest in den ssh source headern eine #define blubb_ports xxxx:xxxx zeile bei der man die ports einschränken kann.... (suchen & neukompilieren ;))
hi scrat
puuhh... das ergibt irgendwie auch einen sinn :)
scheint so als lernt man doch nicht aus ;)
bei gelegenheit teste ich das mal... (mit/ohne conntrack_ftp_modul), dann hab ich gewissheit..
:) ob ich mit meinen *behauptungen* aber auch recht habe, steht wieder auf einem anderen blatt ;). ich kann das leider nicht selbst testen, da ich keinen ftp-server laufen hab.
zu ssh:
mein beispiel bezog sich auf: router als ssh client, unter der vorraussetzung, dass ESTABLISHED verbindungen in der fw standartmässig durchgehn
ups da ist mir wohl die output chain durch die lappen gegangen :D
hmm da bin ich überfragt, jedoch falls es keine config var zum einstellen dieser ports gibt, so gibt es zumindest in den ssh source headern eine #define blubb_ports xxxx:xxxx zeile bei der man die ports einschränken kann.... (suchen & neukompilieren )
hmm, falls das eine frage der compilierung ist, hab ich das wohl nicht mit angegeben, besser gesagt gentoo nicht. muss mir das ebuild zu ssh nochmal ansehen. danke für den tip :)
Gruß HL
ob ich mit meinen *behauptungen* aber auch recht habe, steht wieder auf einem anderen blatt . ich kann das leider nicht selbst testen, da ich keinen ftp-server laufen hab. Ja, das stimmt soweit und zudem benötigst du keinen ftp Server zum testen, dass contrack_ftp Modul ist auch für den Clientseitigen ftp Verkehr zuständig.
Gruß
Hi Jinto
gut das ich das nochmal getestet habe, bevor ich poste :D. das sind meine aktuellen regeln bezüglich ftp von innen nach aussen.
#---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
# FTP, OUT, CONTROL CONNECTION
#---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
$ipt -A FORWARD -o $ext -m state --state NEW -p TCP --sport $p_high --dport ftp -j ACCEPT
#--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
# FTP, OUT, passive DATA CONNECTION
#--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
$ipt -A FORWARD -o $ext -m state --state NEW -p TCP --sport $p_high --dport $p_high -j ACCEPT
ganz ehrlich, ich hätte anhand dieser regeln wetten können, das eine ftp-verbindung auch ohne ftp_conntrack modul zustande kommen würde. also erstmal mit rmmode ip_conntrack_ftp das modul rausgeschmissen. anschließend hab ich eine verbindung zum suse server aufgebaut, ging auch ohne probleme => irgendeine readme zum download ausgesucht => verbindung bricht ab
modul wieder geladen, download geht ohne probleme.
Gruß HL
$ipt -A FORWARD -o $ext -m state --state NEW -p TCP --sport $p_high --dport ftp -j ACCEPT
$ipt -A FORWARD -o $ext -m state --state NEW -p TCP --sport $p_high --dport $p_high -j ACCEPT
aeh, wenn du established connections durchlässt... muss zumindest passiver ftp gehn...
da der client die verbindung von nem highport auf einen highport des servers aufmacht, und nur dem server über die control connection sagt welchen port er will...
da du alles von high auf high forwardest sollte es doch ohne conntrack gehn ??
aktiv modus geht naturlich net, weil die connection vom ftp server aus geöffnet wird und in dem fall an der firewall hängen bleibt
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.