UNИX, весна 2009, 10 лекция (от 06 мая)

Материал из eSyr's wiki.

Версия от 14:50, 9 мая 2009; ESyr01 (Обсуждение | вклад)

(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)

В след. раз будет экзамен:

Мысль 1. Мы даже почти не начали. Возм., перенести на след. семестр.
Мысль 2. А сейчас-то что делать?
Мысль 3. Непонятно, как должен выглядить экзамен и кому его проводить?

По поводу первой мысли. Может лечь фишка, может не лечь. Как она может лечь: в альте могут заставить писать курс для разработчиков семестровый. Лектору кажется, что если лектор будет этим действ. заниматься, то ни на что другое у лектора времени не будет с одной стороны, и это было бы интересно с другой. Но это вилами на воде писано.

Флейм-противостояние адблока и носкрипта. Флейм связан с тем, что в носкрипте есть код, который отменяет некоторые функции адблока, связанные с блокированием спонсоров носкрипта.

Что делать сегодня: можно нарпимер закрыть малые темы.

Александр произнёс слово shorewall, которое мучило лектора, недавно он таки посмотрел и узнал, что это такое. Это ПО для Linux, конкретно для iptables, которое позв. вместо вписывания правил заниматься более разумными вещами. Сделано это вот как: какие действия ожид. от адм. shorewallЖ

Нарисовать карту сети
Отинтерп. в терминах shorewall — выделить группы хостов в смысле доступа к ним. Часто они совп. с подсетями. Всё это записывается на языке конф. файлов.
Когда зоны распланированы, он может описать, как выгл. правила из одной зоны в другую: напримеР, доступ из одной зоны в дргуб блокир. напрочь, из другой в третью разрешён, нао натится
Опис. всякие мелочи, например, что есть сервер, где делается проброс портов. и так далее

При этом достигается довольно разумная отвязка от реальных адресов и компьютеров в сетях. Более того, даже достигается отвязка от подсетей: вы оперируете не понятием "подсеть за этим инт., подсеть за этим инт.". У вас машины могут лежать в разных зонах, зоны могут быть за разными интерфесами. И вот даже здесь наступает некая отвязка от нижнего уровня: вы манип. зонами, как вреальности они устроены, а не правилами.

В общую структуру shoerwall добавленна поддержка специфики: adsl-соединение, временные ip, если нет ни одного нормального ip, они получ. по dhcp. Такого сорта вещи добавлены. Вы просто указ., что у вас такой тип сети, а в какое правило iptables это будет превращено, неважно.

Факт., это такой опис. сети и компилятор в правила iptables.

В чём, собственно, главное дост. этоог продукта: главное дост. примерно в том, в ч м оно когда лектор говорил про pf. Это ПО для инженера, который не то чтобы не стал разьираться с iptablers, но у него может быть задача большая, и тогда сложно не ошибиться. Второй случай — сист. адм., и это инструментарий для него, в его задачами.

Кроме всего, вместо большого, если посмотреть внимательно, с помощью каких инстр. вы решаете свои задачи, то можно заметит, что исп. не только iptables, приходится дёргать кусочки в разных местах, чтобы это складывалось в МЭ. Вот SW и эть этот большой МЭ. Как и в pf, здесь всё склад. в одном месте. БОлее того, идея тут такая же, как и в etcnet'е альтовом: есть дерево файлов, колторые говорящие.

Всё этолпозв. перейти на более приличный уровень по сравнению с ipables, но, как летору показалось, и, если инстр. осваиваете, то с ним можете ходить куда хотите. Есть у shorewall ндеостаток: он довольно старый, с прошлого тысячелетия, и в те поры то ли различия в дистр. малы, толи слишком велики, то ли всё делали руками, и shorewall есть некая сетевая подсистема, которая может конфл. с сетевыми подсистемами арзл. дистрибутивов. ПОэтому на сайте есть документация, где написано, что надо поотключать. И это надо учитывать.

Второй недостаток: в желании всё сложить всё в одно место они прошли чуть дальше, чем надо, и pptp, например, поднимается автоматический.

Последний стабильный релиз SW вышел в 2000-м году. Тем не менее, это не значит, что проект не развивается. Что это означает на практике: если вы его собир. применять в производстве, то должны выбрать: либо исп. то, что вышло в 2000 году, либо использовать dev-версию.

Вообще, проект хорошо документирован. Более того, документированы не только интрефейсы, но и различные юзкейсы (случай с одним интерфейсом, два, три, четыре). В этом смысле, вещь весьма интересная.

Лектор не сказал бы, что это какой-то прорыв в этом безобразии, хотя, ему кажется, это чуть ли не первые ребята, которые реализовали то, что лектор описывал: вы опис. свод правил, и из этого компилир. правила фаерволла. В любом случае, это более понятно, чем созерцание правил FW.

лЕКТОР СКАЗАЛ, ЧТО ЭТО НЕ ПРОРЫВ, ПОСК. Есть аналогичные продукты: SuseFirewall 2. В отличие от SW, где всё делается редактир. конфигов, тут неск. иначе: есть набор конфигов, из которых компилируются правила FW, отличие в следующем: у SuSe один из самых продвинутых конф. движков, который позв. делать пор. вещи: например, изм. конфига в одном окошке конфиг. все машины и прочее. YaST называется. Соотв., главное, подо что зачёсан SuseFirewall 2, это через работу поверх YaST (заметно это потому, что часть с YaST документирована полностью, а конфиги — нет). И таких продуктов чёртова прорва. И эта прорва... лектор опишет свои ощущения: когда он пршёл в Альт, iptables привёл его уныние, уж больно он неудобен, посему ему пришла в голову идея написать макроязык. Естественно, к действ., это не имело отношения никакого. Большая часть проектов, которые лектор видел, сводилась к тому. что там либо сужалась задача, либо усложнялась модель. Из этого списка лектор может отметить только одну вещь: FireHOL. Лектору она показалась интересным тем, что там исп. структурированный конфиг, один большой. Там введены высокоуровневые понятия, такие как маршрут, зона. Это в рез-те довольно хорошо читается, поск. когда необх. понять, что происх. с тем или иным пакетом, то понято, куда смотреть. Разумеется, эта объектная модель опис. далеко не все возм. области применения. Но 80% случаев, когда нужно поднять фаерволл на билзлеж. маршрутизаторе, то её хватает.

К сожалению, у нас нет вермени, чтобы продолжить разговор, но леткора SW впечатлил тем, что они перевели предмет разговора от отдельных парвил к описанию сети.

Краткое резюме: у лектора есть подозрение, что iptables есть слишком низкоуровн. инструмент, чтобы им делать серьёзные решения. pf тоже дост. низкоуровнев, но там удобные вещи работают по умолчанию. Здесь же ещё более высокий уровень, посе. здесь порисх. абстрагирование от действий.

Графические конфигураторы. На этом рынке предложение очень большое, но малокачественное. Из них лектор бы обратил внимание на три вещи:

Firewall Builder. Эта штука предст. собой, чем она, собственно, интересна: это некая трёхуровневая программный продукт, который позв. настр. и запустить в эксплуатацию на выбор: iptables, ipfilter, pf, ipfw, pix , cisco route. Есть инструмент для картирования сети, есть уровень для преобр. в логику, и дальше эта логика применяется к сети. Когда лектор с этим разбирался, то понял. что поск. там много разных бэкендов, то там нельзя польз. разл. тонкими вещами.
Firestarter. Аналог виндовых фаерволлов.
Встроенные в дистрибутив средства. Обычно там есть средства различной примитивности.

Видимо, на этом тему надстроек над iptables можно принкрыть.

Можно немного поговорить про DMZ.

Про эту штуку имеет смысл поговорить с двух сторон. По её поводу сущ. много разных легенд, не всегда имеющих отн. к действиетльности. Причина, видимо потому, что у кого-то есть интсрументы и алг. членения сети, где есть разд. на внешних-опасных, внутренних-среднеопасных, DMZ. Вторая причина — DMZ это такая технология, стратегия орг. сети, которая часто приносит много полезного в работе и ей удобно польз.

В сущности это простая вещь. Рассм. ситуацию, когда есть интернет, внутр. еть и фаерволл. Какие вещи треб. от этой машины: обслуж. клиентов внутр. сети. Если внутри сети стоит сервер, то к нему тоже нужно применять аналогич. действия (тоже nat, ограничения и разрешения), однако, если внимательно присмотреться, то медлу сервером и клиентск. машиной есть разница: если это сервер, в отличие от клиент. машин, если и будет нат, то либо 1к1 или проброс портов. Второе: скорее всего, их нужно администрировать (ssh). Третье: если у них есть управл. интерфесы, то есть политика. сообр. которой на эти интерф. можно ходить на них. Обычно web-морды умеют https, но если не умеют, то обычно есть набор компьютеров, с которых можно ходить.

В общем, сервера они особенные. Более того, есть ещё одна забавная штука: например, есть веб-почта, это собственно почтовый сервер и белочка/круглокуб.

Вопрос: если по https польз. вводит пароль, то к почтовому серверу надо идти по imap или по imap/ssl? Проще конечно про imap, но это может кто-то подслушивать и так далее. Лучше просто выделить сервера в отдельную подсеть. В рез-те мы приходим к тому, что обр. некий парк. компьютеров, сеть компьютеров, которые обл двумя свойствами: отн. неё поведение с внеш. сетью примерно одинаковое, но внутри оно дост. свободное. Именно это и наз. DMZ.

Ничего чудесного и строго опр. тут нет. Это не протокол и не конкр. настр. конкр. машин.

Чего бы лектор попробовал бы рассказать: