Комментарии 32
> сумел пережить многочисленных конкурентов, в том числе fsp, scp, rsync, uucp, WAIS, gopher и ftpmail
Пережил — значит, живет после того, как другой умер.
А scp и rsync вполне себе живие.
Пережил — значит, живет после того, как другой умер.
А scp и rsync вполне себе живие.
Угу, если бы ещё этот scp не впадал в маразм (состояние stalled)… Приходится большие файлы wget-ом по https гонять.
Куда отправлять поздравления?)
Передайте, что наверное не смогу прийти на день рожденья…
Но всего наилучшего!
Но всего наилучшего!
а работа через NAT как требовала костылей раньше, так и до сих пор требует.
Conntrack — не такой уж и страшный костыль. Особенно если учесть, сколько других протоколов без него жить не могут за натом.
И это еще не все проблемы…
ИМХО, FTP своё отжил — усовершенствования стандартов(спецификаций) гиблое дело в данном случае. Требуется переписать их в корне.
Хотя я считаю, что в этом протоколе необходимости ни какой нет и ему пора на покой. Как и было упомянуто имеются более продуктивные аналоги. Мир прекрасно будет жить с P2P, HTTP(S), SSH (SFTP, SCP), возможно упомянуть NFS и даже SMB. Наиболее подходящая замена, разумеется, ssh. Единственное что реально стоит оставить в живых это TFTP — он реально нужен в узких кругах.
ИМХО, FTP своё отжил — усовершенствования стандартов(спецификаций) гиблое дело в данном случае. Требуется переписать их в корне.
Хотя я считаю, что в этом протоколе необходимости ни какой нет и ему пора на покой. Как и было упомянуто имеются более продуктивные аналоги. Мир прекрасно будет жить с P2P, HTTP(S), SSH (SFTP, SCP), возможно упомянуть NFS и даже SMB. Наиболее подходящая замена, разумеется, ssh. Единственное что реально стоит оставить в живых это TFTP — он реально нужен в узких кругах.
Это потому что сам NAT — костыль (о его взаимоотношениях с FTP есть здесь: www.eserv.ru/NAT ). Но вообще для FTP NAT не проблема, если не забывать включать PASV-режим в FTP-клиенте.
> если не забывать…
Еще одна головная боль с FTP протоколом. Гемор либо со стороны клиента, либо со стороны сервера… Долбанные 2 режима…
Еще одна головная боль с FTP протоколом. Гемор либо со стороны клиента, либо со стороны сервера… Долбанные 2 режима…
Обычно гемор со стороны клиента, т.к. на серверы не ставят NAT/firewall (которые и мешают работе FTP).
На серверах NAT весьма не редкое явление. Я уже не говорю о вашей квалификации, если вы считает что сервера работают без firewall'ов… И вот радость разрешать огромные диапазоны портов для приёма соединений от клиентов по ftp.
Зачем на сервере firewall — я понимаю: админу кажется, что так сервер лучше защищен (хотя серверный софт легко защищает себя сам). Но вот зачем на FTP-сервере NAT?
Краткое и примитивное назначение firewall на сервере (более объёмное я обсуждать в рамках комментариев не буду) — светить в мир только строго те порты что необходимо.
NAT образуется не обязательно специально — зачастую это сила обстоятельств. Например, у компании куплен единственный внешний IP адрес и что бы не вешать все нужные сервисы на этот бедный шлюз, организуется NAT — тем самым позволяя под каждую серверную службу (DNS, HTTP, FTP etc) выделить отдельную машину(виртуальную машину), находящуюся внутри корпоративной сети и имеющую выход в интернет именно через тот самый шлюз. Как видите NAT тут просто необходимость…
Другая ситуация это организация NLB по средствам шлюза.
NAT образуется не обязательно специально — зачастую это сила обстоятельств. Например, у компании куплен единственный внешний IP адрес и что бы не вешать все нужные сервисы на этот бедный шлюз, организуется NAT — тем самым позволяя под каждую серверную службу (DNS, HTTP, FTP etc) выделить отдельную машину(виртуальную машину), находящуюся внутри корпоративной сети и имеющую выход в интернет именно через тот самый шлюз. Как видите NAT тут просто необходимость…
Другая ситуация это организация NLB по средствам шлюза.
> светить в мир только строго те порты что необходимо
Те, что не используются, и так «не светятся» (а те, что светятся — используются и нормально контролируются самими серверным софтом и без помощи firewall), см. www.eserv.ru/FireWall
А описанный вами DMZ можно сделать без NAT'а — tcpmap'ами (HTTP) и udpmap'ами (DNS) — больше контроля. Хотя вот как раз FTP плохо живётся на DMZ, его лучше на сам «бедный шлюз» и ставить, ресурсов он берет не много.
Те, что не используются, и так «не светятся» (а те, что светятся — используются и нормально контролируются самими серверным софтом и без помощи firewall), см. www.eserv.ru/FireWall
А описанный вами DMZ можно сделать без NAT'а — tcpmap'ами (HTTP) и udpmap'ами (DNS) — больше контроля. Хотя вот как раз FTP плохо живётся на DMZ, его лучше на сам «бедный шлюз» и ставить, ресурсов он берет не много.
OMG… Ну у вас и каша в голове… Ко всему прочему мир у вас заканчивается на сайте eserv.ru…
Почитайте что такое NAT и его применение, а так же разновидности и возможности фаерволов. А ваши xxxmap, так и вообще меня убили…
p.s. думаю наш разговор исчерпан в силу того, что разговариваем мы немного на разных языках. Вы на своём — пользовательском уровне толкуете, я на своём.
Почитайте что такое NAT и его применение, а так же разновидности и возможности фаерволов. А ваши xxxmap, так и вообще меня убили…
p.s. думаю наш разговор исчерпан в силу того, что разговариваем мы немного на разных языках. Вы на своём — пользовательском уровне толкуете, я на своём.
Да, на разных. Вы на своём админском, а я на своём — как разработчик этих самых серверов (FTP в т.ч.) с 15-летним стажем ;)
Сочувствую вашим клиентам…
У нас рыночная экономика, мои клиенты сами меня выбрали :) Если бы я их обижал — ушли бы.
Ладно, а по существу дела — про NAT, firewall (и по связи их с FTP) — в чем автор статей на eserv.ru неправ? И что убийственного в моих словах про «xxxmap»? Подскажите — спасёте моих будущих клиентов :)
Ладно, а по существу дела — про NAT, firewall (и по связи их с FTP) — в чем автор статей на eserv.ru неправ? И что убийственного в моих словах про «xxxmap»? Подскажите — спасёте моих будущих клиентов :)
Моё желание развивать дискуссию о сетевых технологиях по прежнему отрицательно и тем не менее я напишу пару предложений.
Ваши (ну или не ваши) xxxmap'ы это и есть NAT в реализации Eserv (и между прочим автор это говорит прямым текстом). И DMZ и NAT это не одно и тоже!
Что до статей на eserv, то весомой частью они по делу (не целиком, конечно, но вполне достаточно что бы считать их пригодными для изучения и восприятия). Хотя, моё лично мнение, таково, что подобные статьи я люблю значительно меньше чем более менее официальные спецификации.
Ваши (ну или не ваши) xxxmap'ы это и есть NAT в реализации Eserv (и между прочим автор это говорит прямым текстом). И DMZ и NAT это не одно и тоже!
Что до статей на eserv, то весомой частью они по делу (не целиком, конечно, но вполне достаточно что бы считать их пригодными для изучения и восприятия). Хотя, моё лично мнение, таково, что подобные статьи я люблю значительно меньше чем более менее официальные спецификации.
Я не говорил, что DMZ и NAT — это одно и то же. Просто описанную вами конфигурацию («под каждую серверную службу выделить отдельную машину, находящуюся внутри корпоративной сети») обычно называют DMZ. А как обеспечить доступ к этим внутренним машинам извне — это отдельный вопрос. Можно с помощью NAT, а можно с помощью прокси (маппингом портов в прокси, либо вообще специализированным прокси — для внутреннего HTTP-сервера, например, это позволяет организовать фронтальный кэш). Прокси проще настраивать, чем NAT, и удобнее потом контролировать. В обе стороны :)
ОМГ! И вы еще говорите о том, что сервисы сами себя защищают (хотя в данном случае фаервол бы не помог)… Что-то пару минут не зайти было на eserv.ru — решил посмотреть/разобраться что да как…
И что вы думаете? у них NS открыт для свободного пересыла зоны, да еще и BIND не долго думая свою версию написал...! Хотите полюбоваться на их настойки DNS? Всего-то и надо что запросить axfr запись, через любой клиент (nslookup, dig, host)… (специально для виндузятников: nslookup -q=AXFR eserv.ru @ns1.eserv.ru)
И что вы думаете? у них NS открыт для свободного пересыла зоны, да еще и BIND не долго думая свою версию написал...! Хотите полюбоваться на их настойки DNS? Всего-то и надо что запросить axfr запись, через любой клиент (nslookup, dig, host)… (специально для виндузятников: nslookup -q=AXFR eserv.ru @ns1.eserv.ru)
А там в DNS есть что-то секретное? :) И, если в bind открыт xfr, то это вовсе не значит, что его нельзя закрыть тем же bind'ом, безо всяких firewall'ов.
bind может всё и даже больше, я об этом написал… читайте внимательно
> (хотя в данном случае фаервол бы не помог)
Непосредственно информацию получить можно и поочередными запросами, но тут же всё на блюдечке… Она может быть проэксплуатирована. Да и сам факт трансфера открывает некоторые возможности.
Что же касается так докучающего вопроса о firewall, то тут яркий пример где он помог бы в силу правил его настройки. В данном домене торчит наружу мускуль — а зачем? Скорее всего просто забыли прописать что слушать надо только localhost. Firewall не позволил бы торчать кому не попадя во внешний мир. А мускуль вещь дырявая да и брутится не плохо, так что…
> (хотя в данном случае фаервол бы не помог)
Непосредственно информацию получить можно и поочередными запросами, но тут же всё на блюдечке… Она может быть проэксплуатирована. Да и сам факт трансфера открывает некоторые возможности.
Что же касается так докучающего вопроса о firewall, то тут яркий пример где он помог бы в силу правил его настройки. В данном домене торчит наружу мускуль — а зачем? Скорее всего просто забыли прописать что слушать надо только localhost. Firewall не позволил бы торчать кому не попадя во внешний мир. А мускуль вещь дырявая да и брутится не плохо, так что…
Ну, мускуль ведь тоже можно сделать невидимым для внешних подключений настройкой интерфейсов без помощи firewall'ов.
И потом, сам по себе firewall может стать дополнительным источником серьезных проблем просто из-за особенностей реализации (под виндой по крайней мере). Тут как с антивирусами — главное не «перебдеть».
И потом, сам по себе firewall может стать дополнительным источником серьезных проблем просто из-за особенностей реализации (под виндой по крайней мере). Тут как с антивирусами — главное не «перебдеть».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Стандарту FTP исполнилось 40 лет