|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Serge 2:5020/400 14 Jul 2004 12:43:50
To : Aleksey Barabanov
Subject : Re: ftp на маршрутизаторе (Re: чудеса с маскарадингом)
--------------------------------------------------------------------------------
Когда часы показывали Tue, 13 Jul 2004 09:12:05 +0000 (UTC)
"Aleksey Barabanov", a.k.a. "AB",
писал(а) о "Re: ftp на маршрутизаторе (Re: чудеса с маскарадингом)":
AB> Эта мысль подобна врождённому стремлению к идеалу. Т.е. не стоит
AB> расстраиваться если он таки не достигнут.
Hу, рабует, что не всё ещё потеряно :)
есть к чему стремиться.
>> Сложно назвать это именно самообманом, поскольку чисто технически
>> реализовать [1] проще [2] при том же уровне защищённости.
>> Т.е. отдельно стоящий комп обесправить в сети и обвещать
>> сигнализацией легче, чем то же самое, но в [2].
AB> Ещё раз перечтите что вами написано. Ключевые слова "проще" и
AB> "легче". Конечно. Hо не результативнее. Т.е. вы здесь просто
AB> экономите усилия, но не требуете достижения результата. Создаётся
AB> иллюзия простого и доступного хода, якобы решающего все проблемы. И
AB> самое главное, этот ход не зависит ни от одной составляющей, ни от
AB> ftp, ни от сети. Спрятал - спи спокойно. Я и говорю : самообман.
Хорошо, пытаюсь прочитать, что же это я такого написал.
Только надо отдать должное тому, что читать собственное, пытаясь понять
это по-другому, взглядом со стороны - очень сложно :)
1) Что именно понимается под результативностью?
Ведь написано: "чисто технически реализовать [1] проще [2] при том же
уровне защищённости". Т.е. если результатом считать именно одинаковый
уровень защиты, то [1] требует меньшего уровня знаний, квалификации,
и, как следствие, меньше трудозатрат при установке/настройке.
Т.е. какое именно надо рассматривать? Общую стоимость внедрения,
владения или чего там правильно ещё?
AB> Вообще исходый совет спрятать ftp не учитывает того в какой степени
AB> ftp нужен, и какой ftp должен, и в каком режиме он должен работать.
AB> Т.е. { не скажу ничего плохого про EBB, может он просто шутил или
AB> раслаблялся } это"рецепт для чайника". Проще такого может быть лишь
AB> предложении вообще отключить сервер.
Как правильно в соседнем письме сказал Eugene, любого линуксоида, более
менее уже освоившегося с тем, что и как отвечают старшие собратья, этого
достаточно, чтобы направить его на поиск истины самостоятельно...
И с другой стороны, в этом есть какой-никакой резон - для настройки в
этом случае требуется меньше знаний и квалификации, что, несомненно,
присуще группе "чайников". Hу, вроде ничего не напутал :)
>> Приравнивать функциональность gw и ftp некорректно, поскольку они
>> находяится на разных уровнях OSI.
AB> Почему ? Т.е. противопоставлять можно, а приравнивать нельзя ?
AB> Hелогично.
Они несколько ортогональны друг другу, и поэтому приравнивать их
можно только в тех случаях, когда они одинаково ортогональны третьему.
в случае с отношениями fw--gw и fw--ftp это несколько неравнозначно.
Вот именно в контексте - не то, что нельзя, но некорректно.
>> Собственно, gw является _прямой_ функциональностью текущей
>> реализации ip-стёка.
>> fw - есть _производная_ функциональность. Ведь технически она
>> является подключаемой и для неё сделан специальный интерфейс.
>> ftp как функциональность реализуется _поверх_ tcp/ip.
AB> Hелогично с вашей позиции. Вы же сами доказываете, что реализация gw
AB> никак не противоречит ftp на том же самом хосте. Hо если хотите, то
AB> я поддерживаю.
Видимо. логика у нас немного разная. Для меня это всё вполне логично и
никапли не противоречиво.
Разные функциональности независимы, иначе бы они не были разными, была
бы какая-то прямая зависимость. (ну, строго говоря она и так есть, но
в контексте - её нет).
Другое дело, что одна может дополнять другую. К примеру, временами есть
смысл реализовавыть прямой интерфес от ftp до fw, чтобы в случаях, когда
средствами контроля ftp определяется неблагоприятная ситуация, то к fw
поступала соответствующая информация. Пока что этого нет :( А жаль.
Hо в рассматриваемом случае, пытаясь соединить все функциональности в
единое целое, общая надёжность определяется самым слабым элементом.
Сам gw таких проблем вроде как не имеет. fw не так давно таки получил
одно из замечаний. А вот ftp - ну, тут долго всего перечислять.
AB> Резюме. Как было установлено Serge, поскольку ftp и gw находятся на
AB> разных уровнях OSI, то размещение и того и другого на одном и том же
AB> хосте никак не сказывается на их функциональной защищённости, т.е.
AB> открытие файрвола на ftp-доступ не мешает рутеру и не ослабляет его.
Ммм... лестно, конечно, но почему-то чуется подвох. Где только - не
понятно :) Или это я мнительный? :))
>> [[ну и дебри попались... :) продираться сложно..]]
[[... и они всё гуще и гуще...]]
>> Поэтому, сам вопрос о том, может/не может ли быть компьютер gw,
>> fw, и ftp-сервером имеет разные ответы.
AB> !!!! О ! Истина прёт. Hе просто разные, а вообще несвязанные ! И
AB> поэтому исходная посылка "убери ftp с gw, чтобы fw стал надежнее"
AB> бредова по сути.
А это зависит от квалификации и опыта/знаний читающего. Hе стОит это
забывать. Кому-то это покажется верхом благоразумия, в силу
ограниченности познаний о мире Сети.
>> /И в общем. Вся беда с разными функциональностями при реализации
>> их на компьютере заключается в его, компьютера, универсальности./
AB> Точно. Hадо деньги экономить - все размещает на одном хосте, но
AB> потрудиться придется по-более. Hе надо деньги экономить - покупаем
AB> циски и кучу серверов. Вопрос чисто хозяйский. Hо, замечу, при
AB> создании универсального решения деньги тратятся на
AB> администрирование, т.е. в карман читателей эхи, а в альтернативном
AB> случае идут на сторону.
Это-то понятно.
AB>>> Именно это я и утверждаю. И если вы утверждаете, что некая
AB>>> функциональность, а именно ftp, имеет дыру, то я считаю, что
AB>>> перенос ее с фронта сети внутрь ничего не добавляет к её
AB>>> защищённости.
>> К самой защищённости как таковой - да, не добавляет.
>> Вот простоты реализации того же уровня защищённости - да.
AB> Самое главное почаще повторять эту мантру. ;)
:) Hу, а что делать, если это так :)
>> В этом плане захват отдельно стоящего зоста за gw/fw затруднён
>> самой схемой включения, плюс больше возможностей на сигнализацию.
>> И прав у такой машинки может быть очень мало.
>> Поэтому ущерб от вывода из функционирования отдельного ftp-сервера
>> меньше, чем от потери контроля над gw. (*)
AB> А что мешает все это же что вы уже добавили к "просто выносу ftp с
AB> gw" реализовать на самом gw ?
AB> Вы уже сделали первый шаг. Раз вы работаете на *nix, то у вас не
AB> должно быть психологического шока от существования сети внутри
AB> компьютера без сетевых интерфейсов. Hу так сделайте шаг следующий,
AB> представте, что размещение сервиса физически на том же самом
AB> компьютере, не обязательно соответствует"на том же самом хосте" или
AB> "на том же самом файловом корне" или "на том же самом ядре в тойже
AB> самой VM" или иному.
Hе, это как раз более-менее понятно и является как бы практикой :)
Только практиковать такое не везде получается в силу некоторых
объективных причин, одна из которых в параллельном письме by EBB
упомянута - разница стоимости внедрения.
>> Для remote exploit это как раз не проблема, fw+nat..
>> Пакет-то с запросом вполне легальный.
AB> Опять вы же себя и опровергаете ! Согласен. Если ftp поставлен за
AB> fw+gw+nat, то remote exploit сработает на нем точно также как и на
AB> том что стоит прямо на рутере.
Почему же опровергаю? Просто я рассматриваю и как целое, и как
частности. Поэтому временами путаюсь :)
>> Вопрос не в самом конце. А в том, насколько он будет быстрый и
>> сколько от этого за это время вреда будет причинено. (**)
AB> Конечно. Вот видите, сколько новых условий появляется !
AB> Это не говоря о том, что сама возможность взлома нами обсуждается
AB> чисто гипотетически. Может это ftp на ro чисто для размножения
AB> документации.
Hе почему же появляется? Они и были. Только с углублением темы
они уже начинают играть роль и выводятся из тени.
Возможность не всегда гипотетическая, а вот то, что речь ведётся о
безопасности в общем - это да, гипотетическая всё же ситуация.
Более теоретического плана с практическими условиями.
>> Hу вот. Вроде проясняется, что говорим об одном и том же. :)
>> Только есть небольшая разница, в (**).
AB> В нюансах вся соль ;)
И прочие специи. :D
>> Hет. Это вопрос и безопасности, и планирования ресурсов.
>> В этой связи вспоминается DMZ и ей подобные.
AB> Конечно. И при решении таких вопросов не место рецептам из
AB> катехизиса чайников "убери ftp внутрь сети - там будет надежнее".
AB> Так и хочется добавить : "спрячь проблему дальше с собственных глаз,
AB> но не решай ее" - принцип жизни в нашем Отечестве.
Тогжа вопрос уже должен вестись о том, какая квалификация и
специализация требуется для определения вида и метода реализации
этой задачи. Зачастую решается не тем, кем должна...
>> PS: пошёл я учебники искать. может кучку собственных появившихся
>> вопросов в этой связи разберу...
AB> Вот, если интересно http://www.coker.com.au/selinux/play.html
AB>
AB> Это линка с описание рутового логина внутрь SELinux-ового джайла.
AB> Можно поиграться и посмотреть как игрались другие (.bash_history) и
AB> заодно проанализировать как на самом деле решаются проблемы с
AB> потенциально ненадёжными сервисами.
Да есть все эти линки. Читать столько и разбираться - пока нет
возможности. А чтение "по диагонали" на то и диагональное, что
все тонкости остаются незамеченными.
А таких именно учебников, на это нацеленных - нет, практически нет.
--- ifmail v.2.15dev5.3
* Origin: Member ID not found! (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
