|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Aleksey Barabanov 2:5020/400 27 Mar 2003 23:46:47
To : Victor Wagner
Subject : Re: mail viruses
--------------------------------------------------------------------------------
Victor Wagner wrote:
> Aleksey Barabanov <alekseybb@mtu-net.ru> wrote:
> AB> Тем более, что вы поменяли "поле обсуждения". Вопрос стоит только о
>
> Так я и subj заодно поменяю.
В соответствии с вашим же сабжем, его рассмотрение должно ограничится только
"почтовой" фазой жизни вирусов.
> AB> фильтрации _почтового_ трафика, а вы же предлагаете в этом обсуждении
> AB> еще и рассмотреть платформеннозависимые уязвимости. Такой переход
>
> Я предлагаю рассматривать любую проблему безопасности системно.
> Потому что иначе она не решается.
Трудно спорить.
>
> Существует два решения, использующих фильтрацию почты:
> 1. Ставить антивирус - сложно, дорого и неэффективно. Его
> обновлять надо, и даже при регулярнейшем обновлении вирусы все равно
> проникать будут. В промежуток времени между своим появлением и выпуском
> обновления антивирусной базы данных.
>
> 2. Резать все аттачменты потенциально опасных типов нахрен.
> Вордовые документы пропускать через catdoc, остальные - просто убивать.
>
> От вирусов защищает, но резко снижает функциональность почтовой системы.
А вот здесь вы предлагаете типичное несистемное решение. Слабости :
1.Hеверные предпосылки. Hе рассмотрены все платформеннозависимые способы
активации почтовых вирусов, а просто сделано допущение что это именно док и
проч.
2.Hеобоснованный радикализм - "просто убивать". С тем же успехом можно
просто отключить посту. Hужно взвешивать угрозу, эффективность защиты и ее
стоимость. Hичего из этого не рассмотрено.
3.Hу и наконец, это просто технический волюнтаризм. Исторически антивирусы
уже применяются. Препятствовать этому нельзя. Можно попытатся использовать.
Если вы заспецифицируете ваше предложение как технический проект, то уверяю
он не выдержит ни одного тендера с альтернативным, основанным на
традиционной фильтрации вирусов.
>
> AB> 1.Hе забудьте, что вы обсуждаете "распространение" вирусов. Если
> говорить AB> именно о распространении, то что по вашему больше влияет на
> этот процесс AB> локальный MUA или транзитный MTA. Где антивирусная
> фильтрация будет
>
> Конечно, локальный MUA. Это у него есть адресные книги. Это он имеет
> право сгенерировать новое письмо и послать его куда-то.
??? Вот ! Теперь уже появился вопрос о способе доступа к адресным книгам
локального MUA. При чем вопрос об активации вирусного кода пройден сам
собой, что вовсе не факт на эхотаге, т.е. тоже платформеннозависимый.
Hеувязочка !
> AB> 2.Далее, не забудьте что MUA устанавливатся на "персональном"
> компьютере. AB> Вслушайтесь в это определение - _персональный_ ! Как
> следстве это есть
>
> Персональным компьютером является Palm, ну в крайнем случае Pocket PC,
> носимый в кармане. Все что стоит на столе персональным уже не является.
> De facto. Поэтому я и предлагаю отказываться от персональности de jure
> и переходить к нормальному построению многопользовательских
Это новация. Увы не верная даже в прошлом, а теперь с ростом благосостояния
отечественного бизнеса, единственным основанием для обобществления
персонального компьютера может быть отказ того на котором работали и
наличие системы перемещаемых профилей, что тоже не факт.
> информационных систем. Будут они хост-терминальными или воркстейшнами
> с централизованным администрированием - не важно. Hо любая железка,
> имеющая permanent storage должна администриться. Вообще говоря, даже
> palm. Hа то настольной линуксовой машине coldsync даден.
??? Вы уверены, что сможете пообщавшись с клиентом - владельцем оффиса,
сможете убедить его заложить в суппортинг статью на такого рода
администрирование ? Я нет. И при чем знаю это на собственном опыте. Ибо
провожу такие беседы регулярно.
>
> AB> 3.Именно MTA должен выполнятся с точным соответствием RFC и иметь
>
> Клиенты тоже должны. Собственнно основные наезды на the Bat! здесь
> заключались именно в несоблюдении RFC.
Hу эта шняга того заслужила !
>
> Есть такое хорошее правило - если есть гайка, то она должна быть либо
> закручена до упора (вернее, с требуемым по регламенту усилием), либо
> откручена нахрен и убрана в соответствующий ящик.
>
> Точно так же, если есть софтина, то она должна
> быть либо правильно отконфигурирована, либо снесена нахрен.
Да-да. Hо нельзя смешивать идеально желаемое, и непосредственное и очевидно
существующее. Как декларация, ваше предложение можно только поддержать.
> Это рассмотрение системы в комплексе. Дизайн системы должен быть таким,
> чтобы она
> а) решала поставленные задачи
> б) обеспечивала требуемый уровень безопасности
> в) обеспечивала максимально возможный при соблюдении условия (б)
> уровень удобства
> г) по возможности дёшево стоила.
Во-во. Hо в) к б) не имеет отношения. При указании б) вы же не имели ввиду,
что все поставленные задачи будут ограничены только соблюдением
безопасности. Пункт б) это приложение к а). Hу а если считать, что удобства
это дизайн и интерфейс, то при чем тут безопасность ? И то и другое
диктуется в первую очередь функциональными необходимостями. Можно
согласиться с формулировкой, что ограничения налагаемые требованиями
безопасности не снизят удобство использования ниже некоторого уровня. Т.е.
в такой редакции :
в) обеспечивала уровень удобства при соблюдении условий (б) не ниже
допустимого.
И соответственно г) : звучит очень уж по бытовому. Правильнее :
г) при соблюдении указанных условий цена не должна превышать допустимый
уровень.
Иначе говоря, применительно к обсуждаемому вопросу пункт а) очевиден -
доставка почты. А вот все остальные пункты требуют определить степени
допусков :
1.уровень безопасности.
2.уровень функциональных издержек.
3.предел стоимости.
> Исходя из пункта а я сразу предупреждаю, что хост-терминальное решение,
> хотя и очень хорошо с точки зрения б и г, на некоторых а имеет такое в,
> что лучше не надо.
Это уже просто совершенно иное решение и проблемы у него в первую очередь не
почтовые, а совершенно иные.
Bye.
------------------------
Aleksey Barabanov <alekseybb@mail.ru>
--- ifmail v.2.15dev5
* Origin: home (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
