[slackware] Iets houdt de verbinding naar buiten tegen*

[Zym0tiC]

Ik zal de situatie uitleggen:ik heb een slackware 10.2 server draaien. Hierop bevind zich oa smb,www,ftp,ssh. Nu werkt intern alles perfect. Zowel via ip als via domain name. Maar nu is van buitenaf geen van deze service te benaderen. Wanneer het precies is mis gegaan zou ik niet weten aangezien van binnenuit lijkt alsof alles goed gaat. ik kan dan namelijk ook gewoon het dyndns gebruiken.

De poorten zijn natuurlijk gemapped naar het juiste adres.Wat vreemd is is trouwens dat bepaalde mappings naar een andere pc wel goed werken.

Om eens te testen heb ik in de server een damn small linux cd gestopt en hiervan geboot. Hierna de bijbehorende webserver gestart en vervolgens bleek dat nu ook van buitenaf alles te benaderen is.
Ook eens geprobeerd om de webserver op een andere pc te zetten en de mapping aan te passen. Alles werkt gewoon zoals bedoeld.

Nu zou je zeggen het probleem ligt dus aan apache, maar dat is niet zo want ssh,ftp, etc is ook van buitenaf niet te benaderen.

Het lijkt dus wel of iets in het systeem zaken tegenhoud.

iptables -L geeft aan dat er geen rules zijn

output van cat /proc/sys/net/ipv4/ip_forward is 0 routing staat dus uit.

openvpn draait ook niet atm.

Maar wat kan het nog wel zijn.. ik zie het niet zo zitten om de server opnieuw te installeren namelijk.

[Verwijderd]

routering ?

[arikkert]

eeh naar BINNEN tegen

Lijkt toch op een firewall/tcpwrappers probleem op je slackware distro
Zet je netwerkkaart eens in "promiscuous mode" met tcpdump, snoop ozo. Ik ken Slackware en iptables niet goed.
Het moet haast wel dat de promisc mode de pakketten eerder ontvangt dan de firewall dus als je firewall blockt dan zie je de kamikaze-pakketten nog wel komen.

In sommige distros kan je kernel gebuild zijn met default_block_all als firewall. Dan moet je juist firewall rules hebben om services open te zetten.

Wat doet ping (ICMP) van buiten naar binnen of nmap ? smb,www,ftp,ssh gaat bijna altijd alleen over TCP

[ Voor 73% gewijzigd door arikkert op 29-10-2005 16:29 ]

[Zym0tiC]

Verwijderd schreef op zaterdag 29 oktober 2005 @ 15:03:
routering ?

dit staat uit zoals te zien is in de TS.

[Zym0tiC]

arikkert schreef op zaterdag 29 oktober 2005 @ 16:13:
eeh naar BINNEN tegen

Lijkt toch op een firewall/tcpwrappers probleem op je slackware distro
Zet je netwerkkaart eens in "promiscuous mode" met tcpdump, snoop ozo. Ik ken Slackware en iptables niet goed.
Het moet haast wel dat de promisc mode de pakketten eerder ontvangt dan de firewall dus als je firewall blockt dan zie je de kamikaze-pakketten nog wel komen.

In sommige distros kan je kernel gebuild zijn met default_block_all als firewall. Dan moet je juist firewall rules hebben om services open te zetten.

Wat doet ping (ICMP) van buiten naar binnen of nmap ? smb,www,ftp,ssh gaat bijna altijd alleen over TCP

nou je het zegt, naar binnen ja

output ping:

code:

Pingen naar shinebox.ath.cx [84.28.95.47] met 32 byte gegevens:

Time-out bij opdracht.
Time-out bij opdracht.
Time-out bij opdracht.
Time-out bij opdracht.

Ping-statistieken voor 84.28.95.47:
Pakketten: verzonden = 4, ontvangen = 0, verloren = 4    (100% verlies).

Niet bereikbaar dus.

Ik heb in de kernel source eens gekeken naar default_block_all maar ik kon daar niets van vinden. Vervolgens maar een simpele firewall opgezet die http verkeer door laat maar ook dit mocht niet baten.

tcpdump met de -p parameter gedraait maar omdat ik via ssh connect krijg ik een hoop troep erdoor heen en kan dus niet echt volgen of er iets anders nuttigs bij zit. Ik heb hier geen extra tobo en monitor bij de hand.

[arikkert]

gebruik de opties van tcpdump dan, man tcpdump enzo
bijv :

code:

 tcpdump -l -i {jouw netwerkkaartinterface} port 80

en probeer vanaf je een andere host in je eigen lan je slackware bak eens te bereiken.

[ Voor 40% gewijzigd door arikkert op 29-10-2005 21:41 ]

[Zym0tiC]

arikkert schreef op zaterdag 29 oktober 2005 @ 21:37:
gebruik de opties van tcpdump dan, man tcpdump enzo
bijv :

code:

 tcpdump -l -i {jouw netwerkkaartinterface} port 80

en probeer vanaf je een andere host in je eigen lan je slackware bak eens te bereiken.

Dan krijg ik dit:

code:

listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
05:42:10.101045 IP 192.168.0.1.1072 > server.shinebox.http: S 2700032869:2700032869(0) win 16384 <mss 1460,nop,nop,sackOK>
05:42:10.101200 IP server.shinebox.http > 192.168.0.1.1072: S 1936108287:1936108287(0) ack 2700032870 win 5840 <mss 1460,nop,nop,sackOK>
05:42:10.102548 IP 192.168.0.1.1072 > server.shinebox.http: . ack 1 win 17520
05:42:10.103081 IP 192.168.0.1.1072 > server.shinebox.http: P 1:446(445) ack 1 win 17520
05:42:10.103154 IP server.shinebox.http > 192.168.0.1.1072: . ack 446 win 6432
05:42:10.104610 IP server.shinebox.http > 192.168.0.1.1072: . 1:1461(1460) ack 446 win 6432
05:42:10.104643 IP server.shinebox.http > 192.168.0.1.1072: P 1461:1969(508) ack 446 win 6432
05:42:10.107493 IP 192.168.0.1.1072 > server.shinebox.http: . ack 1969 win 17520
05:42:10.136928 IP 192.168.0.1.1072 > server.shinebox.http: P 446:868(422) ack 1969 win 17520
05:42:10.137593 IP server.shinebox.http > 192.168.0.1.1072: . 1969:3429(1460) ack 868 win 7504
05:42:10.137621 IP server.shinebox.http > 192.168.0.1.1072: P 3429:3447(18) ack 868 win 7504
05:42:10.140464 IP 192.168.0.1.1072 > server.shinebox.http: . ack 3447 win 17520
05:42:10.144612 IP 192.168.0.1.1072 > server.shinebox.http: P 868:1288(420) ack 3447 win 17520
05:42:10.145235 IP server.shinebox.http > 192.168.0.1.1072: . 3447:4907(1460) ack 1288 win 8576
05:42:10.145264 IP server.shinebox.http > 192.168.0.1.1072: P 4907:5644(737) ack 1288 win 8576
05:42:10.148032 IP 192.168.0.1.1072 > server.shinebox.http: . ack 5644 win 17520
05:42:10.180258 IP 192.168.0.1.1073 > server.shinebox.http: S 2566651790:2566651790(0) win 16384 <mss 1460,nop,nop,sackOK>
05:42:10.180329 IP server.shinebox.http > 192.168.0.1.1073: S 1926340939:1926340939(0) ack 2566651791 win 5840 <mss 1460,nop,nop,sackOK>
05:42:10.182523 IP 192.168.0.1.1072 > server.shinebox.http: P 1288:2536(1248) ack 5644 win 17520
05:42:10.182559 IP 192.168.0.1.1073 > server.shinebox.http: . ack 1 win 17520
05:42:10.183039 IP 192.168.0.1.1073 > server.shinebox.http: P 1:418(417) ack 1 win 17520
05:42:10.183094 IP server.shinebox.http > 192.168.0.1.1073: . ack 418 win 6432
05:42:10.183972 IP server.shinebox.http > 192.168.0.1.1072: . 5644:7104(1460) ack 2536 win 11232
05:42:10.184013 IP server.shinebox.http > 192.168.0.1.1072: . 7104:8564(1460) ack 2536 win 11232
05:42:10.184044 IP server.shinebox.http > 192.168.0.1.1072: . 8564:10024(1460) ack 2536 win 11232
05:42:10.185703 IP server.shinebox.http > 192.168.0.1.1073: . 1:1461(1460) ack 418 win 6432
05:42:10.185738 IP server.shinebox.http > 192.168.0.1.1073: P 1461:2624(1163) ack 418 win 6432
05:42:10.188278 IP 192.168.0.1.1072 > server.shinebox.http: . ack 8564 win 17520
05:42:10.188344 IP server.shinebox.http > 192.168.0.1.1072: . 10024:11484(1460) ack 2536 win 11232
05:42:10.188370 IP server.shinebox.http > 192.168.0.1.1072: P 11484:12063(579) ack 2536 win 11232
05:42:10.191151 IP 192.168.0.1.1073 > server.shinebox.http: . ack 2624 win 17520
05:42:10.191524 IP 192.168.0.1.1072 > server.shinebox.http: . ack 11484 win 17520
05:42:10.343864 IP 192.168.0.1.1072 > server.shinebox.http: . ack 12063 win 16941

33 packets captured
66 packets received by filter
0 packets dropped by kernel

Nu heb ik net eens wat over tcpdump zitten lezen maar ik kom er niet echt wijs uit waar ik nu naar het probleem moet zoeken. Er zijn in ieder geval geen packets gedropped.

En als ik een portscan op poort 80 van buitenaf doe dan krijg ik dit:

code:

listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
05:40:21.712148 IP 204.2.109.47.2146 > server.shinebox.http: S 3911845111:3911845111(0) win 57344 <mss 1460,nop,wscale 0,nop,nop,timestamp 46635162 0>
05:40:24.686298 IP 204.2.109.47.2146 > server.shinebox.http: S 3911845111:3911845111(0) win 57344 <mss 1460,nop,wscale 0,nop,nop,timestamp 46635462 0>
05:40:27.885952 IP 204.2.109.47.2146 > server.shinebox.http: S 3911845111:3911845111(0) win 57344 <mss 1460,nop,wscale 0,nop,nop,timestamp 46635782 0>
05:40:31.087398 IP 204.2.109.47.2146 > server.shinebox.http: S 3911845111:3911845111(0) win 57344 <mss 1460>
05:40:34.286460 IP 204.2.109.47.2146 > server.shinebox.http: S 3911845111:3911845111(0) win 57344 <mss 1460>
05:40:37.486817 IP 204.2.109.47.2146 > server.shinebox.http: S 3911845111:3911845111(0) win 57344 <mss 1460>
05:40:43.686810 IP 204.2.109.47.2146 > server.shinebox.http: S 3911845111:3911845111(0) win 57344 <mss 1460>

7 packets captured
14 packets received by filter
0 packets dropped by kernel

[arikkert]

204.2.109.47 probeert een http-connectie te maken op je slackware server.
Het probleem ligt dus niet aan routering of nat, maar echt op je slackware server.

[Seth4Chaos]

Zym0tiC schreef op zaterdag 29 oktober 2005 @ 00:45:
iptables -L geeft aan dat er geen rules zijn

wat geeft die precies aan (output dump?) want het lijkt er wel een beetje op alsof je 'default policy' op drop of deny staat.

[Zym0tiC]

Seth4Chaos schreef op zondag 30 oktober 2005 @ 14:12:
[...]

wat geeft die precies aan (output dump?) want het lijkt er wel een beetje op alsof je 'default policy' op drop of deny staat.

op dit moment is dat:

code:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
ACCEPT     all  --  loopback/8           loopback/8
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:http
ACCEPT     icmp --  anywhere             anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Normaal gesproken:

code:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Ik begin sterk het vermoeden te krijgen dat het probleem tijdens een van de laatste updates (swaret) is gekomen.

* Zym0tiC maar eens kijken wat toen geupdate is.

[Newjersey]

hmm misschien kan er iets staan in /etc/hosts.deny , wat alles tegenhoud?

[Zym0tiC]

Newjersey schreef op zondag 30 oktober 2005 @ 19:59:
hmm misschien kan er iets staan in /etc/hosts.deny , wat alles tegenhoud?

hier staat niets in. Ik ben trouwens maar met een herinstall begonnen. Heb wel /etc gebackupped eens kijken of ik toch nog ergens wat vreemds tegen zou komen.

Iedereen bedankt voor de moeite

[Coen Rosdorff]

De eerste dump laat zien dat je webserver werkt.
Een machine op het lan wisselt namelijk verkeer uit met poort 80 (http) van je server.

De 2 dump laat zien dat inkomende verbindingen naar je server wel werken. Er gaan echter geen packets (antwoorden van de webserver) naar buiten toe.

Ik gok op een routerings probleem. Geen default route? Wat zegt 'route'?
Kan je het ip-adres in de 2e dump pingen? Kan je een traceroute naar die host uitvoeren?

[arikkert]

little_soundman schreef op maandag 31 oktober 2005 @ 02:07:
Ik gok op een routerings probleem. Geen default route? Wat zegt 'route'?
Kan je het ip-adres in de 2e dump pingen? Kan je een traceroute naar die host uitvoeren?

Met je tcpdump analyse ben ik het eens maar
Als de default route niet goed staat (stond), vind ik het vreemd dat de topicstarter wel connecties naar het Internet achter de router kon openen. Ook dan is een default route nodig.