Активное-пассивное решение ftp
У меня есть клиент ftp (приложение.NET, к которому у меня нет источника), который работает только в активном режиме, который должен передавать данные на ftp-сервер устройства, который говорит только пассивно.
Я ничего не могу сделать, чтобы изменить программное обеспечение с обеих сторон; но все, что между ними, является честной игрой. (маршрутизация, программное обеспечение Windows или Linux, хитрости брандмауэра,...)
Есть ли какое-то программное обеспечение FTP-прокси? Или какое-то решение, которое я мог бы попробовать?
1 ответ
Есть (или, может быть, был?) Очень хороший демон под названием SuSE Proxy Suite. Он перехватывал FTP-трафик и позволял перенаправлять ftp-клиент на какой-то определенный backend-сервер, и, если мне не изменяет память, он также допускал активные<->пассивные преобразования. Я использовал программу в довольно тяжелых условиях в течение многих лет без проблем.
К сожалению, моя старая закладка ( http://proxy-suite.suse.de/), кажется, перенаправляет себя на страницу Novell. Несколько репозиториев пакетов (FreeBSD, Debian после быстрого поиска в Google), похоже, все еще содержат программное обеспечение, так что у вас может быть некоторая надежда.
У FreshPorts есть хорошее описание программного обеспечения:
http://www.freshports.org/net/proxy-suite/
РЕДАКТИРОВАТЬ: еще одна вещь. Я понятия не имею, была ли эта небольшая проблема исправлена позже (это было не в 2004 году, когда я последний раз использовал эту штуку), но по умолчанию proxy-suite работает как root, так как он должен связываться с низкими портами. И он работал как Really Root, поскольку он не использовал возможности Linux.
Сегодня должно быть возможно установить возможности файла с помощью команды setcap следующим образом:
sudo setcap 'cap_net_bind_service=+ep' /path/to/file
Но если это не сработает (хотя возможности и существуют, команда setcap не очень часто встречается, когда я пропатчил proxy-suite), вот еще один обходной путь.
Примерно в 2004 году я написал небольшой патч, в котором отбрасывались все возможности, кроме CAP_NET_BIND_SERVICE, сразу после запуска, поэтому даже некоторые потенциальные дыры в безопасности были бы менее опасными. Обычно вам может не понадобиться этот патч, но если у вас есть это заболевание, называемое паранойей безопасности, и передача вашего файла происходит между темными углами Интернета вместо удобной офисной локальной сети, патч может быть хорошей идеей.
Чтобы узнать, работает ли ftp-прокси с полными привилегиями root, проверьте, возвращает ли getpcaps что-то вроде этого:
yourserver root# getpcaps `pidof ftp-proxy`
Capabilities for `16982': =eip cap_setpcap-eip
Исправленная версия должна возвращаться так:
yourserver root# getpcaps `pidof ftp-proxy`
Capabilities for `9522': = cap_net_bind_service+ep
И наконец, вот патч, который я написал миллионы лун назад, я надеюсь, что он все еще может быть применен.
--- common/com-misc.c.orig 2006-11-20 13:54:59.000000000 +0200
+++ common/com-misc.c 2006-11-20 14:40:47.000000000 +0200
@@ -36,0 +37 @@
+#include <sys/capability.h>
@@ -748,0 +750,18 @@
+ /*
+ * If running as root, drop all the privileges except CAP_NET_BIND
+ */
+ if (geteuid() == 0) {
+ cap_t caps = cap_init();
+ static cap_value_t capv[] = {CAP_NET_BIND_SERVICE};
+ const int numcaps = sizeof(capv) / sizeof(capv[0]);
+ if (caps == NULL)
+ syslog_error("cap_init() failed; errno = %d", errno);
+ if (cap_set_flag(caps, CAP_PERMITTED, numcaps, capv, CAP_SET) < 0)
+ syslog_error("Could not set permitted capabilities;
errno = %d", errno);
+ if (cap_set_flag(caps, CAP_EFFECTIVE, numcaps, capv, CAP_SET) < 0)
+ syslog_error("Could not set effective capabilities;
errno = %d", errno);
+ if (cap_set_proc(caps) < 0)
+ syslog_error("Could not apply capability set; errno =
%d", errno);
+ cap_free(caps);
+ }
+