[FTP Server] IIS werkt niet door firewall

[Verwijderd]

Lo,

Ik heb hier een win2k3 servertje draaien met IIS6. De webserver werkt perfect, maar de FTP server doet het alleen op port 21. Mits ik die poort open stel in de windows firewall. Ik wil 'm dus op een andere poort draaien uit veiligheidsoverwegingen. Dit werkt wel vanaf het netwerk, maar mensen van buitenaf kunnen 'm niet bereiken.

Ik heb in de firewall een nieuwe rule toegevoegd die port 1337 forward naar localhost:1337 (TCP). De mensen krijgen dan een socket 10060 error (connection timed out) hoewel ze wel kunnen verbinden, maar ze krijgen geen inhoud te zien. Ook het aan en uitzetten van PASV helpt hierbij niet. Wanneer ik de firewall uitschakel werkt het wel. Het ligt dus aan de firewall. Maar die schakel ik liever niet uit . Wie weet wat dit kan zijn?

De error btw:

Can't connect to remote server. Socket error = #10060.

425 Can't open data connection.
ERROR:>
Trashed response received.

Dit is NA het inloggen dus.

[ Voor 12% gewijzigd door Verwijderd op 01-11-2003 14:49 ]

[Xandrios]

Heb je de juiste Pasv poorten ook ingesteld in je firewall? En in een eventuele portmapping?

[Verwijderd]

Ik kan in IIS nergens iets vinden over PASV....de internet verbinding (MXstream) hangt direct aan de server, dus porten hoeven niet gemapt te worden verder.

[Verwijderd]

Je moet PASV-poorten openzetten om een PASV-verbinding te maken Zie bijvoorbeeld dit topic: FTP + Router. Wel even in je achterhoofd houden dat je geen router hebt. Maar de essentie van de poorten is hetzelfde

[Verwijderd]

Ik hoef geen pasv verbinding . Als ik alleen de poort instellingen verander naar port 21 en dan de standaard 'ftp server' rule in de windows firewall aanvink dan werkt het. Dus andere poorten hoef ik dan blijkbaar niet te openen? Als ik wel PASV ga gebruiken, welke poort moet dan nog meer open? 20?

[Verwijderd]

Verwijderd schreef op 02 november 2003 @ 01:28:
Als ik wel PASV ga gebruiken, welke poort moet dan nog meer open? 20?

Daar had ik juist die link voor gegeven Staat het allemaal in

[ijdod]

Bij de basis beginnen:

Hoe zit je IIS doos aan het internet gekoppeld? Via een router/firewall die NAT doet?

FTP is een lastig protocol, doordat er in het protocol zelf poorten worden onderhandeld. De client stuurt de server het PORT commando, met daarin zijn IP en de poort waarop hij het verkeer verwacht. Zit de client achter NAT, dan gaan er 2 dingen fout: de client stuurt zijn interne IP adres, en een poort waarvan de NAT router niet weet dat deze naar de client moet worden doorgestuurd. Om dit op te lossen is het PASV commando ontstaan. Die client geeft aan PASV te willen onderhandelen, en de server geeft aan op welk IP adres en poort hij het verkeer verwacht. Omdat de client dit nu initieert, kan een NAT router er mee overweg.
PASV is bedoelt voor de situatie waar de client achter NAT zit, en de server direct benaderbaar is (== geen NAT). Zet je de server achter NAT, dan heeft PASV exact hetzelfde probleem voor de server als PORT voor de client.

Tot zover simpel. De gangbare oplossing voor het bovenstaande probleem is statefull inspection. De NAT router herkent dat een pakket FTP is, en interpreteert de daarin gevonden PORT/PASV informatie. Deze info wordt gebruikt om benodigde poorten te openen en door te sturen naar de juiste interne client, en waar nodig wordt de inhoudt van de pakketten gewijzigd zodat de PORT/PASV de juiste poorten/IP adressen bevatten. Een intern adres wordt dan vervangen door het betreffende internet adres. Als de NAT router dit goed doet, werken zowel PASV als PORT voor clients en servers achter deze NAT router.

Het wordt leuk zodra je af wilt wijken van de standaard FTP poort (21). Dit poortnummer wordt gebruikt door het statefull inspection process om vast te stellen dat het FTP is, en (dus) hoe hij de data daarin moet interpreteren. Een afwijkend poortnummer zal dus niet als FTP herkent worden, en de statefull inspection voor FTP vindt niet plaats. De oplossing is de NAT router te vertellen dat poort 1337 ook FTP is. Of dit kan, hangt van de NAT router af.

De reden waarom men vaak simpelweg vraagt 'Heb je PASV geprobeerd?' (of vice versa)' is niet zozeer de oplossing van het probleem, maar eerder een hoop dat een van beide partijen wel een fatsoenlijke NAT router heeft

NB ik heb om het eenvoudig te houden de term NAT router gebruikt. De statefull inspection is echter typisch een firewall functie. De meeste NAT routers waar we het hier over hebben echter zo'n firewall aan boord.

[Verwijderd]

Ok, bedankt voor je verhelderende verhaal. Toch heb ik daarmee de oplossing nog niet helemaal.

Ik heb geen router tussen de server en de internetverbinding staan. De server zelf deelt de internetverbinding over het netwerk. Ik heb dus een ADSL verbinding van KPN (via Planet) met niet-gehackte ethernet modem. Ik gebruik dus IIS als FTP server en de standaard windows 2003 firewall. In die firewall kan je alleen maar instellen welke poort doorgestuurd moet worden naar welk ip adres+poort en of dat UDP of TCP is. Dat is dus 'localhost:1337' (TCP) in dit geval.

Ik heb naar aanleiding van je verhaal trouwens nog dit artikel in de knowledge base gevonden:
http://support.microsoft....;283679&FR=1&PA=1&SD=HSCH

Maar als ik het dus goed begrijp hoeft alleen port 21, of in mijn geval 1337, open te staan als ik PASV zou gebruiken. De data port voor de server stuurt alleen informatie naar buiten toe, alle informatie komt gewoon binnen op 1337. Kortom: zou het dan niet gewoon moeten werken als de client PASV instelt? Of moet dat op de FTP server ook nog ingesteld worden? Doe die dat niet automatisch? Ik kan er in ieder geval nix over vinden in IIS.

[ijdod]

Verwijderd schreef op 02 november 2003 @ 13:37:
Maar als ik het dus goed begrijp hoeft alleen port 21, of in mijn geval 1337, open te staan als ik PASV zou gebruiken.

Net andersom. Bij PASV moet de server een poort accepteren (en de firewall dus ook), en initieert de client een sessie naar die poort. bij PORT moet de client dat, en start de server de sessie. Als ik je configuratie goed voor ogen heb, zou normaal FTP dus moeten werken.

Als de clients echter zelf ook achter een 'domme' NAT router/firewall zitten, kan het moeilijk worden.

Ik heb naar aanleiding van je verhaal trouwens nog dit artikel in de knowledge base gevonden:
http://support.microsoft....;283679&FR=1&PA=1&SD=HSCH

Pijnlijk, het PASV voorbeeld wat daar staat klopt niet helemaal. Ze missen het detail dat na het antwoord van de server, de client de sessie opent naar het opgegeven adres/poort. Als de firewall voor de server daar dus geen rekening mee houdt, gaat PASV niet werken.

De data port voor de server stuurt alleen informatie naar buiten toe, alle informatie komt gewoon binnen op 1337. Kortom: zou het dan niet gewoon moeten werken als de client PASV instelt? Of moet dat op de FTP server ook nog ingesteld worden? Doe die dat niet automatisch? Ik kan er in ieder geval nix over vinden in IIS.

IIS kan met beiden overweg. Eea wordt vanaf de client geregeld.

Als de firewall van Win2k3 een simpel port filter is (waarschijnlijk; dus niet statefull), dan zal PASV niet zo maar werken. Normaal FTP zou dit wel moeten doen.

Ik vermoed dat het probleem met het gebruik van poort 1337 niet zozeer bij zou zit, maar bij de mensen die er naar toe proberen te connecten.

[Verwijderd]

hmmm...het komt er dus op neer dat het zo zou moeten werken. Maar dat is dus echt niet zo . Ook niet via web2ftp.com (timed gewoon uit (apart Nederlands )).

En op poort 21 komen andere mensen er dus wel in. Heb het met meerdere mensen getest en kan me niet voorstellen dat ze het allemaal fout doen...

Is het erg onverstandig om 'm op poort 21 te laten staan met al die FXPers?

[ijdod]

Neem aan dat je FXP bedoelt als risico van hacking, niet je eigen doelgroep?

Je interne clients (geen firewall, geen NAT) werken wel. Wat je als test zou kunnen doen, is de NT2k3 firewall uitschakelen, en kijken of je externe clients dan wel op 1337 kunnen connecten.

[ Voor 79% gewijzigd door ijdod op 03-11-2003 00:06 ]

[Verwijderd]

ijdod schreef op 03 november 2003 @ 00:03:
Neem aan dat je FXP bedoelt als risico van hacking, niet je eigen doelgroep?

Je interne clients (geen firewall, geen NAT) werken wel. Wat je als test zou kunnen doen, is de NT2k3 firewall uitschakelen, en kijken of je externe clients dan wel op 1337 kunnen connecten.

Ik bedoelde idd het eerste . Die scannen alleen op port 21 lijkt me. Anonymous account staat wel uit, maar hacken is ook erg populair tegenwoordig, zeker IIS servers .

Als ik de firewall uitzet werkt het dus wel op port 1337 zoals eerder genoemd. Dat is het vreemde.

[Verwijderd]

*bump*