Iptables

[Verwijderd]

Beste mensen,

ZIE VORIGE TOPIC SVP.

Problemen met Qmail

Hallo mensen daar ben ik weer.

Inmiddels paar weken verder. ben een heel eind gekomen. complete iptables vuurmuur opgezet.
Deze werkt prima zelfs net iets tegoed!

Het probleem:

Ik maak dus gebruik van iptables. ook draai ik samba, wanneer mijn firewall is gestart kan ik vanaf een host niet naar mijn server toe browsen via de hostname. voorbeeld \\server\map kan ik niet bereiken. wat wel lukt is \\ipadres\map\
Zodra ik mijn firewall stop zijn deze problemen verholpen.

Kan iemand mij helpen?

Groet

[Cyphax]

Je zou eens wat meer info moeten geven.
De rules bijvoorbeeld, post die eens. Anders wordt het natte-vinger-werk.

[Verwijderd]

hm vaag, zou zeggen dat er iets mis is met de nameserver en niet de iptables.

een restart van nmbd/smbd al gedaan neem ik aan?

[Nitroglycerine]

Zorg dat de DNS de match tussen IPadres en hostnaam kan maken. Hiervoor kun je eenvoudig een DNS server op je firewall/samba server opzetten. Er zijn verschillende, duidelijk uitgelegde, HOW-TO's beschikbaar op het internet.

Succes!

[Verwijderd]

Ja zeker, wanneer ik iptables stop dan kan ik de netwerkschijf (share) gewoon bereiken.

Wordt nogal een hele post wanneer ik de rules post....

[Nitroglycerine]

Verwijderd schreef op dinsdag 15 november 2005 @ 09:36:
Ja zeker, wanneer ik iptables stop dan kan ik de netwerkschijf (share) gewoon bereiken.

Wordt nogal een hele post wanneer ik de rules post....

DNS verkeer wordt dus niet toegestaan als je je IPtables firewall aan hebt staan. Maak hier eens een regel voor, poort 53.

[Verwijderd]

Helaas staan deze er al in:

$IPT -A udp_inbound -p UDP -s 0/0 --destination-port 53 -j ACCEPT
$IPT -A udp_outbound -p UDP -s 0/0 --destination-port 53 -j ACCEPT
$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 53 -j ACCEPT
$IPT -A tcp_outbound -p TCP -s 0/0 --destination-port 53 -j ACCEPT

Strange?

[Verwijderd]

het lijkt op een DNS probleem imho. kan je wel de servernaam pingen (als je ping block met je muurtje moet hij wel nog je naam kunnen resolven)? zo niet: check je DNS

trouwens, heb je niet perongeluk de DNS service geblokt met je vuurmuur?

[Nitroglycerine]

Probeer de volgende iptables firewallregels eens (sla je huidige wel eerst even op):

code:

#!/bin/bash

INT_DEV="eth1"
EXT_DEV="eth0"

EXT_IP=$(ifconfig ${EXT_DEV} | grep "inet" | awk '{print $2}' | awk -F: '{print $2}')
#echo -e External IP ${EXT_IP} 
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

#Voorbeeldregels, in dit geval regels om ftp-verkeer naar de firewall toe toe te staan
#iptables -A INPUT tcp --dport 21 -j ACCEPT
#iptables -A OUTPUT tcp --sport 21 -j ACCEPT
#iptables -A INPUT tcp --dport 20 -j ACCEPT
#iptables -A OUTPUT tcp --sport 20 -j ACCEPT

#Accepteer alles wat vanaf het interne netwerk komt, en sluis dat door naar buiten
iptables -A INPUT -i eth1 -j ACCEPT
iptables -A OUTPUT -o eth1 -j ACCEPT
iptables -A FORWARD -o eth1 -j ACCEPT
iptables -A FORWARD -i eth1 -j ACCEPT

echo "1" > /proc/sys/net/ipv4/ip_forward

Dit is een eenvoudige weergave van mijn firewall regels, en die werkt prima. Ook DNS aanvragen worden gehonoreerd. Samba draait ook op die bak, en die is intern te gebruiken.

[Verwijderd]

Oke dan, ga ik proberen kan er nu helaas niet bij maar je hoort ervan.

thnx iig.

Groeten!

[TrailBlazer]

wat vaak heel handig is om te troubleshooten is boven je eerste drop statement per chain dit neer te zetten

code:

$IPT -A INPUT -j LOG --log-prefix Input-log

ff per chain aanpassen dus.
In je dmesg zie je dan wat gedenied wordt

[Verwijderd]

Kan je een voorbeeldje geven?

In welke logfile kan ik deze terug vinden?

[Nitroglycerine]

Als je geen logfile aangeeft wordt het allemaal in de syslog (var/log/syslog.log) gestopt.

[nzyme]

hoezo is dit een DNS probleem //naam/share is toch netbios

ofwel 137:139 danwel 445 opzetten

[Verwijderd]

137,138 & 445 staan open en 139 niet.

$IPT -A udp_inbound -p UDP -s 0/0 --destination-port 137 -j ACCEPT
$IPT -A udp_inbound -p UDP -s 0/0 --destination-port 138 -j ACCEPT

[TrailBlazer]

Verwijderd schreef op dinsdag 15 november 2005 @ 11:15:
Kan je een voorbeeldje geven?

doe ik toch

[Lethalis]

Verwijderd schreef op dinsdag 15 november 2005 @ 11:43:
137,138 & 445 staan open en 139 niet.

139 dicht?

[Verwijderd]

uhm ja!

[nzyme]

op udp staan ze open, maar moet dat niet tcp zijn en 445 is toch hetzelfde (nouja....) als 137:139 ?

[weijl]

137,138 udp ; 139, 445 tcp.
dat klopt wel.

en toch blokkeert iptables een benodige port.
ik heb last van hetzelfde probleem.

ik ga vanavond eens troubleshooten; ik post mijn uitkomst hier.
mocht er al eerder een oplossing zijn hier dan komt dat weer mooi uit voor mij

dalijk eerst naar een ouderavond, gaan we het fijn over mijn toekomst hebben..

TrailBlazer schreef op dinsdag 15 november 2005 @ 11:08:
wat vaak heel handig is om te troubleshooten is boven je eerste drop statement per chain dit neer te zetten

code:

$IPT -A INPUT -j LOG --log-prefix Input-log

ff per chain aanpassen dus.
In je dmesg zie je dan wat gedenied wordt

moet dat niet $IPT -A OUTPUT -j LOG --log-prefix Output-log zijn?

---------------

Goed, zoals het nu lijkt worden de udp poorten _toch_ geblokkeerd.
Naast de netbios 137,138 werkt ook een ntpd server niet hier.
Vreemd, erg vreemd.
ik gooi ze al helemaal los dmv $IPT -A INPUT -i eth0 -p udp -j ACCEPT ; $IPT -A OUTPUT -o eth0 -p udp -j ACCEPT

wacht momenteel op een nmap -sU scan, zal de laptop@win er ook eens bij pakken.
niet afwachtende wat nmap zegt werkt het nu wel op de laptop.
alle udp poorten los knallen (INPUT) is dus een optie.

maar in mijn geval dus niet.

---------------

Zorg dat je geen IP's instelt, hier loopt het bij mij op vast bij zowel netbios als ntpd.
Zodra ik em de vrije hand geef hierin werkt het wel.
dus '-s 1.2.3.4 -d 4.3.2.1' gewoon weglaten (in mijn geval _was_ dit ingevult).

met de volgende rules werkt het hier:

code:

$IPT -A INPUT -i eth0 -p udp --dport 137:138 -j ACCEPT
$IPT -A INPUT -i eth0 -p tcp --dport 139 -j ACCEPT
$IPT -A INPUT -i eth0 -p tcp --dport 445 -j ACCEPT

$IPT -A OUTPUT -o eth0 -p udp --sport 137:138 -j ACCEPT
$IPT -A OUTPUT -o eth0 -p tcp --sport 139 -j ACCEPT
$IPT -A OUTPUT -o eth0 -p tcp --sport 445 -j ACCEPT

[ Voor 85% gewijzigd door weijl op 15-11-2005 22:32 ]

[nzyme]

^^ dat is toch ook gewoon de hele oplossing

ofwel:
INKOMEND verkeer op ETH0 wat over UDP komt met als BESTEMMING 137:139 is TOEGESTAAN
INKOMEND verkeer op ETH0 wat over TCP komt met als BESTEMMING 139 is TOEGESTAAN
INKOMEND verkeer op ETH0 wat over TCP komt met als BESTEMMING 445 is TOEGESTAAN

.en.

UITGAAND verkeer op ETH0 wat over UDP gaat met als BRON 137:139 is TOEGESTAAN
UITGAAND verkeer op ETH0 wat over TCP gaat met als BRON 139 is TOEGESTAAN
UITGAAND verkeer op ETH0 wat over TCP gaat met als BRON 445 is TOEGESTAAN

jaja, ben sinds kort weer helemaal thuis in de iptables

[weijl]

Hellraizer schreef op dinsdag 15 november 2005 @ 22:52:
^^ dat is toch ook gewoon de hele oplossing

ofwel:
INKOMEND verkeer op ETH0 wat over UDP komt met als BESTEMMING 137:139 is TOEGESTAAN
INKOMEND verkeer op ETH0 wat over TCP komt met als BESTEMMING 139 is TOEGESTAAN
INKOMEND verkeer op ETH0 wat over TCP komt met als BESTEMMING 445 is TOEGESTAAN

.en.

UITGAAND verkeer op ETH0 wat over UDP gaat met als BRON 137:139 is TOEGESTAAN
UITGAAND verkeer op ETH0 wat over TCP gaat met als BRON 139 is TOEGESTAAN
UITGAAND verkeer op ETH0 wat over TCP gaat met als BRON 445 is TOEGESTAAN

jaja, ben sinds kort weer helemaal thuis in de iptables

ghehe
JA! met volle borst.

ik had echter een rule waarin ik aangaf dat mijn ip 172.16.38.x is en dat 'het internet' 0.0.0.0/0 is.
($IP & $UNIVERSE), hierdoor liep het bij mij iig mis.
maar infeite heb je gelijk :+:+