IPTables, ik vat m niet meer... ?

[Passenger]

ok, dit is hoe mijn iptables script er nu uitziet... ik heb m voor t gemak even zo eenvoudig mogelijk gehouden...

code:

#!/bin/sh

IPTABLES="/usr/sbin/iptables"
modprobe ip_tables

$IPTABLES -F
$IPTABLES -F INPUT
$IPTABLES -F OUTPUT
$IPTABLES -F FORWARD
$IPTABLES -F -t mangle
$IPTABLES -F -t nat
$IPTABLES -X

$IPTABLES -P INPUT ACCEPT
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -P FORWARD ACCEPT

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

$IPTABLES -t nat -A POSTROUTING -o eth0 -j MASQUERADE

$IPTABLES -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to 192.168.0.4

$IPTABLES -A INPUT -i lo -j ACCEPT

$IPTABLES -A INPUT -i eth0 -d 0/0 -p tcp --dport 80 -j ACCEPT

$IPTABLES -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Ik moet eerlijk bekennen dat de regeltjes uit een iptablesscriptje komen dat ik niet zelf gemaakt heb... (ik heb overigens niet het script klakkeloos overgenomen, maar heb er enkele regeltjes uitgevist...)

Wat is het probleem...
Ik heb hier in mijn netwerk 192.168.0.1 als router, en 192.168.0.4 als webserver. Als ik vanaf 192.168.0.1 naar 192.168.0.4 ga (via lynx of whatever) kom ik keurig netjes op die bak terecht. Maar als ik via ssh op een machine zit die BUITEN mijn lokale netwerk staat, kan ik niet via lynx op mijn webserver terecht komen... Ik typ netjes in lynx mn ip-adres in, en hij blijft maar staan op: "Making HTTP connection to xxx.xx.xxx.xxx."

Heeft iemand nou enig idee waar de fout zit? Of kan de fout ook bij het configureren van apache zitten?
Ik snap t iig niet meer

[Verwijderd]

zou je dit niet kunne vragen bij Network Troubleshooting?

[Passenger]

Op zaterdag 01 september 2001 17:10 schreef CheapAss het volgende:
zou je dit niet kunne vragen bij Network Troubleshooting?

ik zat te twijfelen ik d8 iptables, in NOS... maar toch NT? kan een modje m dan misschien even moven?

[MAZZA]

Dit vind ik wel linux anders hoor. Maargoed:

Lees dit eens door en dan vooral dit

[Passenger]

Op zaterdag 01 september 2001 17:31 schreef MAZZA het volgende:
Dit vind ik wel linux anders hoor. Maargoed:

Lees dit eens door en dan vooral dit

dat heb ik al vaker gedaan, maar ik begrijp dr gewoon geen snars van waarom DIT script NIET werkt...

[Verwijderd]

$IPTABLES -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to 192.168.0.4

Ik zou hier nog een -d $ext_ip bijzetten.
$ext_ip is dan je externe ipadres.
Als dat niet helpt zou ik het eigenlijk niet weten. Het lijkt me ok.

Nadat deze connectie door de PREROUTING chain gegaan is, zal hij door de FORWARD chain gaan, als ik het goed heb.
Deze regel:
$IPTABLES -A INPUT -i eth0 -d 0/0 -p tcp --dport 80 -j ACCEPT
kan dus van INPUT naar FORWARD veranderd worden.
Dit zal geen verschil maken in principe, omdat de default policy van de FORWARD chain al op ACCEPT staat.

[Verwijderd]

Oh, en nog iets, wat het waarschijnlijk wel zal zijn:
$IPTABLES -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to 192.168.0.4

Van die 192.168.0.4 zou ik 192.168.0.4:80 maken.
Je forward hem door naar poort 80 van die computer.
Gek, ik zou verwachten dat als je geen poort specificeerd, dat hij dan bij default dezelfde poort pakt.
Misschien niet dan.

Laat je even weten of dit helpt?

[Passenger]

ook dit werkt niet... ik begin me nu toch sterk af te vragen of het wel aan ipchains ligt...
maar er begint me nog een ander gevoel te bekruipen... misschien iets dat ik over t hoofd heb gezien... Blokkeert chello poortje 80 soms heel per ongeluk misschien toch wel?

[Verwijderd]

Geef de uitvoer van het "route -n" commando eens.
Je Iptables regels zijn niks mis mee nemalijk. Op de overbodige ACCEPT rules na dan. (Die zijn hier niet nodig, omdat je een default ACCEPT policy op alle chains hebt . Het is aan te raden om hier default DENY van te maken, zodra het werkt ).

Ik gok eigenlijk dat er een foutje in de routeringstabel van 192.168.0.4 zit. Kan je vanaf die machine namelijk wel internet IP's pingen etc
Gebruik anders eens tcpdump op beide machines om te kijken wat er precies gebeurt met de pakketjes.

[Passenger]

Op zondag 02 september 2001 13:16 schreef nelske het volgende:
Geef de uitvoer van het "route -n" commando eens.
Je Iptables regels zijn niks mis mee nemalijk. Op de overbodige ACCEPT rules na dan. (Die zijn hier niet nodig, omdat je een default ACCEPT policy op alle chains hebt . Het is aan te raden om hier default DENY van te maken, zodra het werkt ).

Ik gok eigenlijk dat er een foutje in de routeringstabel van 192.168.0.4 zit. Kan je vanaf die machine namelijk wel internet IP's pingen etc
Gebruik anders eens tcpdump op beide machines om te kijken wat er precies gebeurt met de pakketjes.

route is volgens mij niets mis mee...

code:

Kernel IP routing table
Destination     Gateway    Genmask     Flags Metric Ref    Use Iface
192.168.0.0     0.0.0.0    255.255.255.0   U     0  0     0 eth1
***.**.***.0    0.0.0.0    255.255.255.0   U     0  0     0 eth0
0.0.0.0    ***.**.***.*    0.0.0.0     UG    0  0     0 eth0

en alles werkt verder prima... kan mooi vanaf alle machines die achter de router staan surfen, en vanaf de router kan ik iedere bak pingen, dus dat lijkt me geen probleem... ik ga nu nog ff je tcpdump-tip proberen...

[Passenger]

zoals ik verwacht had, levert ook tcpdump niet veel op... wat ik doe is: ik maak een ssh sessie naar mijn hostingprovider van mijn domein.. vanaf hier probeer ik met lynx naar mn chello-ip te komen, maar als ik op mn router in tcpdump oplet, komt er geen http aanvraag binnen... laat staan dat het op mn webserver terecht komt...

weet iemand heel toevallig of chello soms inkomend http verkeer blockt ivm code red?

[MAZZA]

Mijn poging dan...

code:

iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth0 -j DNAT -to-destination 192.168.0.4:80

[Verwijderd]

Op zondag 02 september 2001 17:08 schreef Tu-Tone het volgende:
zoals ik verwacht had, levert ook tcpdump niet veel op... wat ik doe is: ik maak een ssh sessie naar mijn hostingprovider van mijn domein.. vanaf hier probeer ik met lynx naar mn chello-ip te komen, maar als ik op mn router in tcpdump oplet, komt er geen http aanvraag binnen... laat staan dat het op mn webserver terecht komt...

weet iemand heel toevallig of chello soms inkomend http verkeer blockt ivm code red?

Nope, dat doet chello niet. Tenminste hier in Helmond niet iig.

Op zondag 02 september 2001 17:13 schreef MAZZA het volgende:
Mijn poging dan...

code:

iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth0 -j DNAT -to-destination 192.168.0.4:80

In principe moet dit niet veel uitmaken, hoewel het wel netter is om sowieso te destination poort ook te specificeren. Als het goet is, wordt de DNAT sowieso naar dezelfde poort gedaan als waarop hij binnen kwam.
Het feit, dat hij al niet via tcpdump binnenkomt geeft eigenlijk wel aan, dat de fout niet in de PREROUTING zal zitten.
Beetje een vreemd probleem eerlijk gezegd.

Komen request op andere poorten wel gewoon binnen?
Probeer eens te telnetten naar wat andere poorten op je computer en kijk eens via tcpdump of die wel aankomen!

[Verwijderd]

Nee doet chello inderdaad niet (amsterdam)

apache config file alleen 192.168.0.x allow gezet?

denk het niet heh?

[Verwijderd]

Op zondag 02 september 2001 18:15 schreef ZiXon het volgende:
Nee doet chello inderdaad niet (amsterdam)

apache config file alleen 192.168.0.x allow gezet?

denk het niet heh?

Lijkt me niet he. de request komt dan sowieso nog wel aan op de server en is dus ook zichtbaar via tcpdump.
Het brengt me echter wel op een idee.
Apache draait toch niet via (x)inetd of met tcpwrapper support he
Dan moet je namelijk wel even /etc/hosts.allow en /etc/hosts.deny aanpassen waarschijnlijk voor apache.
Zie ook "man hosts_access" of "man hosts.allow".

[Passenger]

ik vat m niet meer hoor... zelfs als ik GEEN firewall script draai, wordt poort 80 nog geblocked...

voorbeeldje:
als ik vanaf mn account bij mijn hostingprovider telnet naar mijn ip, poortje 12345, krijg ik:

code:

Trying ***.**.***.***...
telnet: connect to address ***.**.***.***: Connection refused

Als ik naar poortje 80 probeer te telnetten krijg ik:

code:

Trying ***.**.***.***...

en op dit punt blijftie hangen??? Ik kan naar iedere poort telnetten, overal krijg ik netjes connection refused (omdat er geen services achter draaien, die wil ik netjes op mn servertje draaien), behalve dus op poortje 80!

Aargh....

(btw. als ik via grc.com een portscan over mezelf heen haal, staat alles op blocked, behalve 80, die staat op stealth )

nog meer mensen met ideeën?

[Verwijderd]

Kun je via je ssh sessie wel je router pingen? Zo ja kun je dan daarna ook je webserver pingen?

[Passenger]

Op zondag 02 september 2001 22:49 schreef KrunK het volgende:
Kun je via je ssh sessie wel je router pingen? Zo ja kun je dan daarna ook je webserver pingen?

ping is niet toegestaan op die server... maar, als ik probeer naar andere poorten te telnetten (bijv. 12345) zie ik dat wel bij tcpdump voorbij komen... maar poort 80 niet

[Verwijderd]

Kun je dan ff tijdelijk ping toestaan?

[Passenger]

Op maandag 03 september 2001 12:35 schreef KrunK het volgende:
Kun je dan ff tijdelijk ping toestaan?

Nee, ik bdoel de server waarvanaf ik probeer te connecten, daar MAG ik niet pingen... Ik zal t ff nog een keer duidelijk uitleggen, want ik doe t een beetje omslachtig...

Ik maak dus een ssh-sessie naar de server van mijn hostingprovider, hier staat namelijk lynx op, en via lynx kan ik dan dus kijken of mijn eigen webserver die in mn lan staat, van buitenaf te bereiken is. (ik doe dus net alsof ik fysiek achter een andere computer zit, in dit geval de computer van mn hosting provider, en vanaf die computer probeer ik mijn webserver in mn lan te bereiken).

[Passenger]

Op maandag 03 september 2001 12:51 schreef Tu-Tone het volgende:

[..]

Nee, ik bdoel de server waarvanaf ik probeer te connecten, daar MAG ik niet pingen... Ik zal t ff nog een keer duidelijk uitleggen, want ik doe t een beetje omslachtig...

Ik maak dus een ssh-sessie naar de server van mijn hostingprovider, hier staat namelijk lynx op, en via lynx kan ik dan dus kijken of mijn eigen webserver die in mn lan staat, van buitenaf te bereiken is. (ik doe dus net alsof ik fysiek achter een andere computer zit, die NIET in mijn LAN staat, in dit geval de computer van mn hosting provider, en vanaf die computer probeer ik mijn webserver in mn lan te bereiken).

[nicxz]

Ik denk dat nelske het wel eens bij het rechte eind zou kunnen hebben. Check de hosts.allow en hosts.deny even of die goed staan (op de webserver), en je toestaan om te connecten.

[Passenger]

Op maandag 03 september 2001 12:58 schreef nicxz het volgende:
Ik denk dat nelske het wel eens bij het rechte eind zou kunnen hebben. Check de hosts.allow en hosts.deny even of die goed staan (op de webserver), en je toestaan om te connecten.

maar de pakketjes bereiken mn router nog niet eens! althans, als ik een tcpdump aan zet op mn router, komt er niets binnen op tcp80... maar wordt dat nou OP mn router geblocked, of ERVOOR al? ik ben t spoor kwijt

[Verwijderd]

Echt wazig dit hoor.

Kijk eens welke chains er allemaal actief zijn op dit moment.

code:

iptables -L -n -t filter
iptables -L -n -t nat
iptables -L -n -t mangle

Flush alles, maar dan ook alles (de masquerade rule kan eventueel blijven staan).
Zorg dat alle policies op ACCEPT staan.
Zet zolang even in /etc/hosts.allow

code:

ALL: ip_nummer_van_machine_vanaf_waar_je_wil_connecten

Ga vervolgens tcpdump draaien (op de goede interface uiteraard (dus de externe interface)).

Probeer nu eens een verbinding te maken op poort 80 met je externe IP. Hij zal nu toch echt aan moeten komen; als dit niet het geval is, dan wordt de poort dus daadwerkelijk geblokkeerd, hoewel ik me dat niet voor kan stellen eigenlijk.

[Passenger]

Op maandag 03 september 2001 17:09 schreef nelske het volgende:
Echt wazig dit hoor.

Kijk eens welke chains er allemaal actief zijn op dit moment.

code:

iptables -L -n -t filter
iptables -L -n -t nat
iptables -L -n -t mangle

Flush alles, maar dan ook alles (de masquerade rule kan eventueel blijven staan).
Zorg dat alle policies op ACCEPT staan.
Zet zolang even in /etc/hosts.allow

code:

ALL: ip_nummer_van_machine_vanaf_waar_je_wil_connecten

Ga vervolgens tcpdump draaien (op de goede interface uiteraard (dus de externe interface)).

Probeer nu eens een verbinding te maken op poort 80 met je externe IP. Hij zal nu toch echt aan moeten komen; als dit niet het geval is, dan wordt de poort dus daadwerkelijk geblokkeerd, hoewel ik me dat niet voor kan stellen eigenlijk.

toch blijft het erop lijken dat het geblokkeerd wordt... ik zal eens wat testen uit gaan voeren met een stand-alone windows bak, misschien dat ik dan iets meer duidelijkheid krijg (dus of het nou aan mijn linux config ligt, of aan chello..)

to be continued...