Изпечатай

[Astor]

Здравейте, имам качен proftp сървър на един Slackware.
Въпросът ми е следния: При следните iptables правила:

:INPUT DROP [462:35730]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [47:6571]
-A INPUT -p tcp -m tcp --dport 20:21 -j ACCEPT

имам изключително бавен достъп до FTP сървъра и то само през cmd на Windows. Ако ползвам Windows Explorer като ftp клиент, след Logon прозореца не ми показва директориите в ftp-to: грешката е Connection Time Out.
Четох малко из google и разбрах, че трябва да редактирам iptalbes правилата така:

:INPUT DROP [462:35730]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [47:6571]
-A INPUT -p tcp -m tcp --dport 20:21 -j ACCEPT
-A INPUT -p ALL -m state --state RELATED,ESTABLISHED -j ACCEPT

и да зареда следния модул: ip_conntrack_ftp
След което всичко се орпавя. Но искам да ви питам следното:
Тези related и established връзки (за всички протоколи и на всичи портове) не са ли проблем за сигуността?
А модулът conntrack_ftp до колкото разбрах, е за да може една ftp сесия да променя порта си без да се налага наново стартиране на връзката. Ако искам да мога с Windows Explorer да отварям ftp-to трябва да е зареден, т.e. за да се "раузват" директориите на ftp-то се използва друг порт?

[Acho]

А в една локална мрежа ли са клиентите и сървъра ? Или през интернет се достъпват ? Просто питам, защото аз ползвам от много години също Slackware със proftpd, и си го достъпвам и от локалната мрежа и през интернета без проблеми (и с ftp клиенти, и с браузерите). Като никога не съм слагал специално iptables правила за ftp-то.

Другото което е добре да тестваш, опитай с ftp клиент, не с браузер. Явно говориш за Windows клиент. Има много ftp клиенти за Win. Пробвай с тях, как ще е.

Успехи.

[Astor]

Достъпът до ftp сървърът се осъществява и от локалната мрежа и от интернет. И в двата случая е едно и също положението. А тези правила са за сигурността на компютъра, до блокира всичко освен ftp, но забелязвам, че имам ГОЛЯМА разлика във времето за достъп до сървъра ако е зададено RELATED,ESTABLISHED -j ACCEPT (или също -P INPUT ACCEPT, но тогава все едно нямам firewall)
За достъп чрез WEB браузър нямам също никакъв проблем, но чрез него не мога да upload-вам, за това ползвам Windows explorer-a. Иначе и без добавяне на ip_conntrack_ftp модул нещата работят при всички програми освен при Windows explorer.

[romeo_ninov]

Достъпът до ftp сървърът се осъществява и от локалната мрежа и от интернет. И в двата случая е едно и също положението. А тези правила са за сигурността на компютъра, до блокира всичко освен ftp, но забелязвам, че имам ГОЛЯМА разлика във времето за достъп до сървъра ако е зададено RELATED,ESTABLISHED -j ACCEPT (или също -P INPUT ACCEPT, но тогава все едно нямам firewall)
За достъп чрез WEB браузър нямам също никакъв проблем, но чрез него не мога да upload-вам, за това ползвам Windows explorer-a. Иначе и без добавяне на ip_conntrack_ftp модул нещата работят при всички програми освен при Windows explorer.

Конкретно Windows explorer е възможно най-лошия избор за клиент. Той работи лошо даже и със перфектно настроени сървъри. Замисли се за filezilla

[Acho]

За да ползваш Windows Explorer, трябва да пуснеш samba, за същите директории на ftp-то. И от локалната мрежа ще си влизат и работят всички Win клиенти от мрежата. Интуитивно и безпроблемно, все едно че браузват Win машина с шернати директории. Ще прехвърлят файлове в двете посоки (от и към Slackware-то), разбира се ако искаш, може да им сложиш и различни рестрикции. За мен това е по-доброто решение (за достъп на файлове през локалната мрежа имам предвид) отколкото ftp протокола.

[Astor]

Направих си следния експеримент:
При следните правила в iptables:

-P INPUT DROP
-A INPUT -p tcp --dport 20:21 -j ACCEPT

БЕЗ правило --state RELATED,ESTABLISHED -j ACCEPT FileZilla ftp клиента каза следното:

Status:   Connecting to X.Y.Z.W:21...
Status:   Connection established, waiting for welcome message...
Error:   Connection timed out
Error:   Could not connect to server
Status:   Waiting to retry...
Status:   Connecting to X.Y.Z.W:21...
Status:   Connection established, waiting for welcome message...
Response:   220 ProFTPD 1.3.2 Server (FTP Server) [X.Y.Z.W]
Command:   USER userA
Response:   331 Password required for userA
Command:   PASS *******
Response:   230 User userA logged in
Status:   Connected
Status:   Retrieving directory listing...
Command:   PWD
Response:   257 "/home/userA" is the current directory
Status:   Directory listing successful

Т.е. много бавно се свързвам със сървъра и наистина е така, въпреки 2-те правила в iptables.
Но се чудя дали няма ПРОБЛЕМИ СЪС СИГУРНОСТТА ако добавя RELATED,ESTABLISHED да се приемат от firewall-a?

При спрян модул ip_conntrack_ftp (и добавено RELATED,ESTABLISHED -j ACCEPT ) filezilla казва следното:

Status:   Connected
Status:   Retrieving directory listing...
Error:   Connection timed out
Error:   Failed to retrieve directory listing

Т.е. не е проблема само в Windows Explorer-a и Filezilla не иска да browse-ва от ftp-то.

[gat3way]

Здравейте, имам качен proftp сървър на един Slackware.
Въпросът ми е следния: При следните iptables правила:

:INPUT DROP [462:35730]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [47:6571]
-A INPUT -p tcp -m tcp --dport 20:21 -j ACCEPT

имам изключително бавен достъп до FTP сървъра и то само през cmd на Windows. Ако ползвам Windows Explorer като ftp клиент, след Logon прозореца не ми показва директориите в ftp-to: грешката е Connection Time Out.

По такъв начин конфигуриран firewall-a, към ftp сървъра могат да се правят само трансфери в active mode, демек клиента при връзване праща отворен порт и сървъра се връзва на този порт. Ако Windows Explorer-a е конфигуриран да работи в passive mode, резултатът е логичен. А защо се бави в active mode с command-line ftp клиента, не мога да кажа - вероятно причината е някаква друга (шейпинг някакъв примерно, досаден антивирусен софтуер на уиндоуса или кой знае какво).

По този начин конфигуриран firewall-a, имаш и друго неудобство: клиенти зад NAT няма да могат да осъществяват трансфери, защото при тях ползването на passive mode е задължително.

Четох малко из google и разбрах, че трябва да редактирам iptalbes правилата така:

:INPUT DROP [462:35730]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [47:6571]
-A INPUT -p tcp -m tcp --dport 20:21 -j ACCEPT
-A INPUT -p ALL -m state --state RELATED,ESTABLISHED -j ACCEPT

и да зареда следния модул: ip_conntrack_ftp
След което всичко се орпавя.

Причината е че по този начин, firewall-a инспектира всеки FTP пакет и ако види PORT... команда, ще разреши новата връзка (пакетите, които я иницират се водят RELATED).  Така passive mode може да се случи.

Но искам да ви питам следното:
Тези related и established връзки (за всички протоколи и на всичи портове) не са ли проблем за сигуността?

Ами това е въпрос не толкова на firewall-a, колкото на FTP сървъра. Лошо написаните FTP сървъри, ще приемат всякакви PORT команди от клиентите и като резултат, ще позволят на лошите клиенти да ти bypass-ват firewall-a. Proftpd ако не се лъжа имаше опция, забраняваща такива волности и тя си е включена по дефолт.

А модулът conntrack_ftp до колкото разбрах, е за да може една ftp сесия да променя порта си без да се налага наново стартиране на връзката. Ако искам да мога с Windows Explorer да отварям ftp-to трябва да е зареден, т.e. за да се "раузват" директориите на ftp-то се използва друг порт?

FTP протокола ползва две връзки: контролна и такава за данни. По контролната минават командите и статус кодовете на резултатите. По връзката за данни минава всичко останало - файлове, включително и съдържания на директории. Когато се връзваш до сървъра, отваряш контролна конекция. Отварянето на връзката за данни е подробност, която обикновено се спестява на потребителите и се върши от клиента или сървъра. Както се досещаш, двете връзки използват различни двойки source/destination портове. Разликата между passive и active mode e най-вече в това кой иницира връзката за данни - клиента или сървъра.

[Astor]

балгодаря ти много за разясненията gat3way. Има една опция в proftpd.conf която е:
PassivePorts. Там се задават диапазона от портове които ще се ползват при passive mode. (например: 49152-65534) Това има ли по някакъв начин отношение към

..Лошо написаните FTP сървъри, ще приемат всякакви PORT команди от клиентите и като резултат, ще позволят на лошите клиенти да ти bypass-ват firewall-a. Proftpd ако не се лъжа имаше опция, забраняваща такива волности

и как се наричат тези "волности" за да потърся в Google повечко информация за тях?

В правилата на firewall-a тези портове (49152-65534) са забранени, би ли могло да се изгради passive-mode връзка при това положение? (Или това се водят RELATED пакети които ще се проруснат)

[gat3way]

Ами волностите се състоят в следното: при active режим, PORT командата всъщност предава 6 осем-битови стойности - 4 за IP адреса към който сървъра да се обърне и 2 за порта (портовете са 16 битoви стойности - от 0 до 65535).

Проблемът възниква, ако клиента реши да иницира active връзка и прати нечии друг IP адрес и порт вместо своя си. Примерно реши да прати адреса на сървъра или пък на машина от неговата мрежа, до която по принцип няма достъп. Така много елегантно може да накара сървъра да сканира портовете си/портовете на някоя машина, bypass-вайки firewall-a. Чрез комбинация от upload-ване/download-ване с *нормални* и *ненормални* PORT команди, лошият може да кара сървъра да иницира връзки до разни хостове зад firewall, до които лошият няма достъп, както и да праща по тези връзки разни лоши работи по избор на лошия.

Това се нарича "FTP bounce attack" и е доста старо като идея, затова повечето сървъри не го позволяват. Решението е просто - просто проверяват дали това, което е пратил клиента в PORT командата, съответства на IP адреса му и ако не съответства, го отрязват.

В правилата на firewall-a тези портове (49152-65534) са забранени, би ли могло да се изгради passive-mode връзка при това положение? (Или това се водят RELATED пакети които ще се проруснат)

Именно благодарение на ip_conntrack_ftp модула, пакетите, инициращи връзки на тези портове се маркират като RELATED. Благодарение на iptables правилото, пропускаш RELATED пакетите и тези връзки се установяват успешно. Поради тази причина, няма смисъл изрично да ги разрешаваш. Единствената причина да ги разрешиш е ако не искаш да ползваш ip_conntrack_ftp - това има смисъл когато сървърът търкаля големи трафици, понеже въпросния модул доста намалява пропусквателната му способност (по принцип connection tracking-a не е проста работа и не е от най-препоръчителните неща когато ти се налага да рутираш големите трафици).