По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Данная тема наиболее важная из всех пред идущих, в ней пойдет речь об управлении пакетами. Установка, удаление, обновление пакетов. Поиск пакетов и их зависимостей. Получение полной информации о пакетах. Dpkg утилита управления пакетами в Debian системах и во всех операционных системах которые от нее пошли это mint, Ubuntu и другие. Утилита достаточно большая и работать с ней не очень удобно, поэтому обычно предпочитают использовать более распространённый пакетный менеджер apt. Сама утилита имеет большое количество ключей, в добавок значение ключей зависит от регистра ключа. Заглавная буква в ключе или прописная, имеют разный функционал. Основные ключи: -I перечень пакетов в системе; -L перечень файлов в пакетах; -s информация о статусе пакета; -S поиск пакета, содержащего данный файл; -i установка пакета; -I информация о пакете в файле *.deb; -r простое удаление пакета; -P удаление пакета вместе с конфигурационными файлами. Dpkg-reconfigure переконфигурация пакета. Можно сказать, что это мастер настройки пакета. Полезная утилита. Теперь посмотрим, как это работает вводим dpkg --help: Dpkg сложная низкоуровневая утилита, имеет кучу настроек, на скриншоте приведен вывод справки по ней. Если мы просмотрим внимательно то, в конце справки мы увидим рекомендацию использовать менеджер управления пакетами apt или aptitude. Утилита dpkg используется для каких-то очень тонких настроек пакетов. Можно посмотреть список установленных пакетов в системе dpkg -l . В системе их установлено их достаточно много, поэтому для поиска нужного использовать grep. dpkg -s mc посмотрим статус пакета midnight commander. И видим, что пакет mc, он установлен, размер его, архитектуру (разрядность), зависимости. Используя, ключ S, мы можем посмотреть в какой пакет входит данная программа. Программа mc входит во множество пакетов. А вот, например, /bin/ls входит в базовые утилиты ядра, о чем вы можете убедится, набрав команду с ключом S, т.е в базовый состав любого дистрибутива Ubuntu. Можем посмотреть более подробно работу с пакетом, для этого можно скачать какой-нибудь пакет, например, webmin небольшая графическая утилита для управления unix сервером. Скачиваем и кладем, например, в /opt. Переходим в директорию, где находится наш пакет cd /opt, далее мы можем посмотреть информацию по данному пакету dpkg I /opt/ webmin_1.955_all.deb. Мы можем увидеть версию пакета и краткое описание, в котором говорится, что при установке будет установлен вебсервер и мы получим через него управление к базовым сервисам. Установим пакет dpkg i /opt/ webmin_1.955_all.deb. dpkg не умеет ставить зависимости именно этим он плох. Есть ключи, которые позволяют ставить зависимости, но по умолчанию он не умеет. При установке система выдала ошибки, на то что необходимые зависимости не установлены, но набирая информацию о пакете можно увидеть, что пакет webmin уже установлен. Но он не будет работать т. к. зависимости необходимые для работы не установились, но сам dpkg его установил. Можно его удалить командой dpkg r webmin, т. к. мы конфигураций не писали и ничего с данным пакетом не делали, если бы мы уже поработали необходимо было бы удалять через ключ p. После этой команды если посмотреть статус пакета, то мы увидим deinstall т.е удален. Еще можно посмотреть команду dpkg-reconfigure. Используется для переконфигурирования пакетов. Например, можно реконфигурировать временную зону dpkg-reconfigure tzdata. Таким образом открывается удобный мастер и мы можем прям налету изменить параметры пакета. Еще надо сказать, что у dpkg , есть свой конфигурационный файл. Располагается он /etc/dpkg/dpkg.cfg APT APT Advance Packaging Tool Программа для работы с пакетами в Debian системах. Продвинутый пакетный менеджер, причем иногда используется в дистрибутивах, основанных на Mandriva. В основном используется несколько утилит: apt-get - утилита для скачивания и установки пакетов; apt-cache утилита для поиска пакетов; aptitude - утилита полного управления пакетами с опцией псевдографики; Для работы с пакетным менеджером нам так же понадобится понятие репозитория. /etc/apt/source.list - список репозиториев. Вот так у нас выглядит файл справки по apt-get --help. У программы, как видно есть свои ключи. Теперь попробуем сделать apt-get update данная команда обновляет список всех репозиториев, команда проверяет, какие новые места появились откуда можно скачать обновления, т.е. просто обновляется информация об источниках обновлений. Если мы хотим поискать обновление пакетов и их установить, то мы используем команду apt-get upgrade. Данная команда проверяет все установленное ПО на наличие обновлений и, если находит предлагает установить обновление. Данную процедуру рекомендуется делать, сразу после установки свежей Операционной системы. В дальнейшем перед данной операции обязательно сделайте Резервную копию данных! Для установки любого дополнительного программного обеспечения мы можем воспользоваться apt-get install gmail-notify. Для удаления мы можем использовать ключ remove. При инсталляции программного обеспечения зачастую ставится куча зависимостей, которые необходимы для корректной работы основного программного пакета, а при удалении с ключом remove данные зависимости остаются. Для того чтобы очистить систему от неиспользуемых зависимостей рекомендуется использовать ключ apt-get autoremove. Теперь мы можем посмотреть apt-cache, как работает. Для начала справку. apt-get help Это инструмент для поиска информации в двоичных файлах, у него тоже есть куча настроек и ключей. Попробуем воспользоваться поиском. apt-cache search gmail ищем все пакеты, где может встречаться "gmail". Мы можем посмотреть информацию по какому-либо пакету например: apt-cache show gnome-gmail. Утилита показывает размер, название, кто произвел, архитектура и краткое описание пакета. С помощью команды и ключа apt-cache depends gnome-gmail мы можем посмотреть от каких зависимостей зависит пакет. Т.е. без каких пакетов программное обеспечение работать не будет. Мы можем посмотреть обратные зависимости apt-cache rdepends gnome-gmail т.е. кто зависит от данного программного обеспечения. Далее посмотрим утилиту aptitude. Данная утилита по умолчанию не идет и ее необходимо установить apt-get install aptitude. Посмотрим справку по данной утилите aptitude help. Так же мы можем увидеть, что это такая же программа по управлению пакетами как apt-get и apt-cache. Те же самые команды и ключи, за исключением того, что здесь есть графика и мы можем написать aptitude и попасть в графическую оболочку. Можно зайти, например, в не установленные пакеты и установить, что необходимо. Для этого необходимо встать на интересующий пакет и нажать знак плюса и нажимаем g, для произведения действия. Для выхода из графического режима используем q. Теперь рассмотрим репозитории, то место, где хранится вся информация о пакетах, которые мы можем использовать скачивать обновления и сами пакеты. Это как в windows есть центральный узел обновления windows update, так и в Linux есть узлы , как родные , так и сторонние для обновлений. Смотрим cat /etc/apt/sources.list Вот в таком виде хранятся репозитории в Ubuntu, которые подключены. Хранилища пакетов. У нас есть 2 вида указателей. Deb файлы исходники и deb-src файлы исходники. Далее у каждой строчки указателе есть ссылка в интернете и далее описание дистрибутива. Далее есть несколько видов репозиториев. Main - это основной репозиторий. Не требует установки дополнительных пакетов и является официально поддерживаемым от производителей Ubuntu. Есть пакеты, которые помечены restricted это пакеты, которые содержат частично свободное программное обеспечение, т.е. не полностью свободное программное обеспечение. Есть еще universe это дистрибутивы Ubuntu управляемые сообществом официально не поддерживаются, но есть куча энтузиастов. Есть пакеты multiverse - это пакеты, которые не соответствуют политики свободно распространяемого программного обеспечения. Ничего не мешает нам дописать свои репозитории. Это можно сделать через специальную команду из консоли или просто отредактировав файл. Это необходимо делать, когда у нас есть, какое-либо программное обеспечение, которое не обновляется в составе операционной системы. Если мы добавили репозиторий самостоятельно, то обязательно необходимо сделать apt-get update. Для того, чтобы операционная система перечитала список репозиториев.
img
Почитать лекцию №15 про управление потоком пакетов в сетях можно тут. Совокупность проблем и решений, рассмотренных в предыдущих лекциях, дает некоторое представление о сложности сетевых транспортных систем. Как системные администраторы могут взаимодействовать с очевидной сложностью таких систем? Первый способ - рассмотреть основные проблемы, которые решают транспортные системы, и понять спектр решений, доступных для каждой из этих проблем. Второй - создание моделей, которые помогут понять транспортные протоколы с помощью: Помощь администраторам сетей в классификации транспортных протоколов по их назначению, информации, содержащейся в каждом протоколе, и интерфейсам между протоколами; Помочь администраторам сетей узнать, какие вопросы задавать, чтобы понять конкретный протокол или понять, как конкретный протокол взаимодействует с сетью, в которой он работает, и приложениями, для которых он несет информацию; Помощь администраторам сетей в понимании того, как отдельные протоколы сочетаются друг с другом для создания транспортной системы. Далее будет рассмотрен способ, с помощью которого администраторы могут более полно понимать протоколы: модели. Модели по сути являются абстрактными представлениями проблем и решений. Они обеспечивают более наглядное и ориентированное на модули представление, показывающее, как вещи сочетаются друг с другом. В этой лекции мы рассмотрим этот вопрос: Как можно смоделировать транспортные системы таким образом, чтобы администраторы могли быстро и полностью понять проблемы, которые эти системы должны решать, а также то, как можно объединить несколько протоколов для их решения? В этой серии лекции будут рассмотрены три конкретные модели: Модель Министерства обороны США (United States Department of Defense - DoD) Модель взаимодействия открытых систем (Open Systems Interconnect - OSI) Модель рекурсивной интернет-архитектуры (Recursive Internet Architecture - RINA) Модель Министерства обороны США (DoD) В 1960-х годах Агентство перспективных исследовательских проектов Министерства обороны США (DARPA) спонсировало разработку сети с коммутацией пакетов для замены телефонной сети в качестве основного средства компьютерной связи. Вопреки мифу, первоначальная идея состояла не в том, чтобы пережить ядерный взрыв, а скорее в том, чтобы создать способ для различных компьютеров, используемых в то время в нескольких университетах, исследовательских институтах и правительственных учреждениях, чтобы общаться друг с другом. В то время каждая компьютерная система использовала свою собственную физическую проводку, протоколы и другие системы; не было никакого способа соединить эти устройства, чтобы даже передавать файлы данных, не говоря уже о создании чего-то вроде "Всемирной паутины" или кросс-исполняемого программного обеспечения. Эти оригинальные модели часто разрабатывались для обеспечения связи между терминалами и хостами, поэтому вы могли установить удаленный терминал в офис или общественное место, которое затем можно было использовать для доступа к общим ресурсам системы или хоста. Большая часть оригинальных текстов, написанных вокруг этих моделей, отражает эту реальность. Одной из первых разработок в этой области была модель DoD, показанная на рисунке 1. DoD разделяла работу по передаче информации по сети на четыре отдельные функции, каждая из которых могла выполняться одним из многих протоколов. Идея наличия нескольких протоколов на каждом уровне считалась несколько спорной до конца 1980-х и даже в начале 1990-х гг. На самом деле одним из ключевых различий между DoD и первоначальным воплощением модели OSI является концепция наличия нескольких протоколов на каждом уровне. В модели DoD: Физический уровень отвечает за получение "0" и "1" модулированных или сериализованных на физическом канале. Каждый тип связи имеет свой формат для передачи сигналов 0 или 1; физический уровень отвечает за преобразование 0 и 1 в физические сигналы. Интернет-уровень отвечает за передачу данных между системами, которые не связаны между собой ни одной физической связью. Таким образом, уровень интернета предоставляет сетевые адреса, а не локальные адреса каналов, а также предоставляет некоторые средства для обнаружения набора устройств и каналов, которые должны быть пересечены, чтобы достичь этих пунктов назначения. Транспортный уровень отвечает за построение и поддержание сеансов между коммутирующими устройствами и обеспечивает общий прозрачный механизм передачи данных для потоков или блоков данных. Управление потоком и надежная транспортировка также могут быть реализованы на этом уровне, как и в случае с TCP. Прикладной уровень - это интерфейс между Пользователем и сетевыми ресурсами или конкретными приложениями, которые используют и предоставляют данные другим устройствам, подключенным к сети. В частности, прикладной уровень кажется неуместным в модели сетевого транспорта. Почему приложение, использующее данные, должно считаться частью транспортной системы? Потому что ранние системы считали пользователя-человека конечным пользователем данных, а приложение - главным образом способом изменить данные, которые будут представлены фактическому пользователю. Большая часть обработки от машины к машине, тяжелая обработка данных перед их представлением пользователю и простое хранение информации в цифровом формате даже не рассматривались как жизнеспособные варианты использования. Поскольку информация передавалась от одного человека другому, приложение считалось частью транспортной системы. Два других момента могли бы помочь включению прикладного уровня сделать его более осмысленным. Во-первых, в конструкции этих оригинальных систем было два компонента: терминал и хост. Терминал тогда был дисплейным устройством, приложение располагалось на хосте. Во-вторых, сетевое программное обеспечение не рассматривалось как отдельная "вещь" в системе, маршрутизаторы еще не были изобретены, как и любое другое отдельное устройство для обработки и пересылки пакетов. Скорее, хост был просто подключен к терминалу или другому хосту; сетевое программное обеспечение было просто еще одним приложением, запущенным на этих устройствах. Со временем, когда модель OSI стала чаше использоваться, модель DoD была изменена, чтобы включить больше уровней. Например, на рисунке 2, на диаграмме, взятой из статьи 1983 года о модели DoD ("Cerf and Cain, "The DoD Internet Architecture Model"), есть семь слоев (семь почему-то являются магическим числом). Были добавлены три слоя: Уровень утилит - это набор протоколов, "живущих" между более общим транспортным уровнем и приложениями. В частности, простой протокол передачи почты (SMTP), протокол передачи файлов (FTP) и другие протоколы рассматривались как часть этого уровня. Сетевой уровень из четырехслойной версии был разделен на сетевой уровень и уровень интернета. Сетевой уровень представляет различные форматы пакетов, используемые на каждом типе канала, такие как радиосети и Ethernet (все еще очень Новые в начале 1980-х годов). Уровень межсетевого взаимодействия объединяет представление приложений и протоколов утилит, работающих в сети, в единую службу интернет-дейтаграмм. Канальный уровень был вставлен для того, чтобы различать кодирование информации на различные типы каналов и подключение устройства к физическому каналу связи. Не все аппаратные интерфейсы обеспечивали уровень связи. Со временем эти расширенные модели DoD потеряли популярность; модель с четырьмя слоями является той, на которую чаще всего ссылаются сегодня. На это есть несколько причин: Уровни утилит и приложений в большинстве случаев дублируют друг друга. Например, FTP мультиплексирует контент поверх протокола управления передачей (TCP), а не как отдельный протокол или слой в стеке. TCP и протокол пользовательских дейтаграмм (UDP) со временем превратились в два протокола на транспортном уровне, а все остальное (как правило) работает поверх одного из этих двух протоколов. С изобретением устройств, предназначенных в первую очередь для пересылки пакетов (маршрутизаторы и коммутаторы), разделение между сетевым и межсетевым уровнями было преодолено определенными событиями. Первоначальная дифференциация проводилась в основном между низкоскоростными дальнемагистральными (широкозонными) и короткозонными локальными сетями; маршрутизаторы обычно брали на себя бремя установки каналов в широкополосные сети вне хоста, поэтому дифференциация стала менее важной. Некоторые типы интерфейсов просто не имеют возможности отделить кодирование сигнала от интерфейса хоста, как было предусмотрено в разделении между канальным и физическим уровнями. Следовательно, эти два уровня обычно объединены в одну "вещь" в модели DoD. Модель DoD исторически важна, потому что Это одна из первых попыток систематизировать функциональность сети в модели. Это модель, на которой был разработан набор протоколов TCP / IP (на котором работает глобальный Интернет); Артефакты этой модели важны для понимания многих аспектов проектирования протокола TCP / IP. В нее была встроена концепция множественных протоколов на любом конкретном уровне модели. Это подготовило почву для общей концепции сужения фокуса любого конкретного протокола, позволяя одновременно работать многим различным протоколам в одной и той же сети.
img
Международная организации ISO представляет свою уникальную разработку под названием OSI, которой необходимо создать базу для разработки сетевых стандартов. Сетевая модель TCP/IP контролирует процесс межсетевого взаимодействия между компьютерными системами. Несмотря на это, модель OSI включает в себя 7 уровней сетевого взаимодействия, а модель TCP/IP - 4. Межсетевой экран Netfilter определяет протоколы Некоторые из них могут быть заданы только косвенно. Протоколы сетевого уровня и межсетевое экранирование Для формирования сквозной транспортной системы необходимо предоставить сетевой уровень (Network Layer). Он определяет маршрут передачи данных, преобразует логические адреса и имена в физические; в модели OSI (Таблица 2.1) данный уровень получает дейтаграммы, определяет маршрут и логическую адресацию, и направляет пакеты в канальный уровень, при этом сетевой уровень прибавляет свой заголовок. Протокол IP (Internet Protocol) Основным протоколом является IP, который имеет две версии: IPv4 и IPv6. Основные характеристики протокола IPv4: Размер адреса узла - 4 байта В заголовке есть поле TTL Нет гарантии при доставке, что будет правильная последовательность Пакетная передача данных. Если превысится максимальный размер для пакета, тогда обеспечивается его фрагментация. Версия состоящее из четырех бит поле, которое содержит в себе номер версии IP протокола (4 или 6). Длина заголовка - состоящее их 4х бит поле, которое определяет размер заголовка пакета. Тип обслуживания поле, которое состоит из 1 байта; на сегодняшний день не используется. Его заменяют на два других: DSCP, которое делит трафик на классы обслуживания, размер его составляет 6 бит. ECN - поле, состоящее из 2 бит, используется в случае, если есть перегрузка при передаче трафика. Смещение фрагмента используется в случае фрагментации пакета, поле которого равно 13 бит. Должно быть кратно 8. "Время жизни" поле, длиной в 1 байт, значение устанавливает создающий IP-пакет узел сети, поле, состоящее из 1 байта Транспорт поле, размером в один байт. Доп. данные заголовка поле, которое имеет произвольную длину в зависимости от содержимого и используется для спец. задач. Данные выравнивания. Данное поле используется для выравнивания заголовка пакета до 4 байт. IP уникальный адрес. Адреса протокола четвёртой версии имеют длину 4 байта, а шестой 16 байт. IP адреса делятся на классы (A, B, C). Рисунок 2.2. Сети, которые получаются в результате взаимодействия данных классов, различаются допустимым количеством возможных адресов сети. Для классов A, B и C адреса распределяются между идентификатором (номером) сети и идентификатором узла сети Протокол ICMP Протокол сетевого уровня ICMP передает транспортную и диагностическую информацию. Даже если атакующий компьютер посылает множество ICMP сообщений, из-за которых система примет его за 1 из машин. Тип поле, которое содержит в себе идентификатор типа ICMP-сообщения. Оно длиною в 1 байт. Код поле, размером в 1 байт. Включает в себя числовой идентификатор, Internet Header + 64 bits of Original Data Datagram включает в себе IP заголовок и 8 байт данных, которые могут быть частью TCP/UDP заголовка или нести информацию об ошибке. Типы ICMP-сообщений, есть во всех версиях ОС Альт, и они подразделяются на две большие категории. Протоколы транспортного уровня и межсетевое экранирование При ПТУ правильная последовательность прихода данных. Основными протоколами этого уровня являются TCP и UDP. Протокол UDP Основные характеристики протокола UDP приведены ниже. Простую структура, в отличие от TCP Сведения придут неповрежденными, потому что проверяется контрольная сумма Нет гарантии надёжной передачи данных и правильного порядка доставки UDP-пакетов Последнее утверждение нельзя рассматривать как отрицательное свойство UDP. Поддержка протокола не контролирует доставку пакетов, значит передача данных быстрее, в отличие от TCP. UDP-пакеты являются пользовательскими дейтаграммами и имеют точный размер заголовка 8 байт. Адрес порта источника - поле, размером 16 бит, с № порта. Адрес порта пункта назначения - поле, размером 16 бит, в котором есть адрес порта назначения. Длина - размером 16 бит. Оно предназначено для хранения всей длины дейтаграммы пользователя и заголовка данных. Контрольная сумма. Данная ячейка обнаруживается всею пользовательскую дейтаграмму. В UDP контрольная сумма состоит из псевдозаголовока, заголовка и данных, поступивших от прикладного уровня. Псевдозаголовок это часть заголовка IP-пакета, в котором дейтаграмма пользователя закодирована в поля, в которых находятся 0. Передающее устройство может вычисляет итоговую сумму за восемь шагов: Появляется псевдозаголовок в дейтаграмме. В поле КС по итогу ставится 0. Нужно посчитать число байтов. Если четное тогда в поле заполнения мы пишем 1 байт (все нули). Конечный результат - вычисление контрольной суммы и его удаление. Складываются все 16-битовых секций и дополняются 1. Дополнение результата. Данное число и есть контрольная сумма Убирается псевдозаголовка и всех дополнений. Передача UDP-сегмента к IP программному обеспечению для инкапсуляции. Приемник вычисляет контрольную сумму в течение 6 шагов: Прописывается псевдозаголовок к пользовательской дейтаграмме UDP. Если надо, то дополняется заполнение. Все биты делятся на 16-битовые секции. Складывается все 16-битовых секций и дополняются 1. Дополнение результата. Когда результат = нулю, убирается псевдозаголовок и дополнения, и получает UDP-дейтаграмму только семь б. Однако, если программа выдает иной рез., пользовательская дейтаграмма удаляется. Чтобы передать данные - инкапсулируется пакет. В хосте пункта назначения биты декодируются и отправляются к звену данных. Последний использует заголовок для проверки данных, заголовок и окончание убираются, если все правильно, а дейтаграмма передается IP. ПО делает свою проверку. Когда будет все правильно, заголовок убирается, и пользовательская дейтаграмма передается с адресами передатчика и приемника. UDP считает контрольную сумму для проверки . Если и в этот раз все верно, тогда опять заголовок убирается, и прикладные данные передаются процессу. Протокол TCP Транспортный адрес заголовка IP-сегмента равен 6 (Таблица 2.2). Протокол TCP совсем другой, в отличие от протокола UDP. UDP добавляет свой собственный адрес к данным, которые являются дейтаграммой, и прибавляет ее IP для передачи. TCP образует виртуальное соединение между хостами, что разрешает передавать и получать данные как поток байтов. Также добавляется заголовок перед передачей пакету СУ. Порт источника и порт приемника поля размером по 16 бит. В нем есть номер порта службы источника. Номер в последовательности поле размером в 32 бита, содержит в себе номер кадра TCP-пакета в последовательности. Номер подтверждения поле длиной в 32 бита, индикатор успешно принятых предыдущих данных. Смещение данных поле длиной в 4 бита (длина заголовка + смещение расположения данных пакета. Биты управления поле длиной 6 бит, содержащее в себе различные флаги управления. Размер окна поле размером 16 бит, содержит в себе размер данных в байтах, их принимает тот, кто отправил данный пакет. Макс.значение размера окна - 40967байт. Контр. сумма поле размером 16 бит, содержит в себе значение всего TCP-сегмента Указатель поле размером 16 бит, которое используется, когда устанавливается флаг URG. Индикатор количества пакетов особой важности. Опции - поле произв. длины, размер которого зависит от данных находящихся в нём. Чтобы повысить пропускную функцию канала, необходим способ "скользящего окна". Необходимы только поля заголовка TCP-сегмента: "Window". Вместе с данным полем можно отправлять максимальное количество байт данных. Классификация межсетевых экранов Межсетевые экраны не позволяют проникнуть несанкционированным путем, даже если будет использоваться незащищенныеместа, которые есть в протоколах ТСР/IP. Нынешние МЭ управляют потоком сетевого трафика между сетями с различными требованиями к безопасности. Есть несколько типов МЭ. Чтобы их сравнить, нужно с точностью указать все уровни модели OSI, которые он может просчитать. МЭ работают на всех уровнях модели OSI. Пакетные фильтры Изначально сделанный тип МЭ и есть пакетный фильтр. ПФ - часть маршрутизаторов, которые могут быть допущены к разным сист.адресам. ПФ читают информацию заголовков пакетов 3-го и 4-го уровней. ПФ применяется в таких разделай сетевой инфраструктуры, как: пограничные маршрутизаторы; ос; персональные МЭ. Пограничные роутеры Главным приоритетом ПФ является скорость. Также пф ограничивать доступ при DoS-атаки. Поэтому данные пф встроены в большинство роутеров. Преимущества пф: Пф доступен для всех, так как остается в целостности ТСР-соединение. Недостатки пакетных фильтров: Пфпропускают данные с высших уровней МЭ имеет доступ не ко всей информации Большинство пф не аутентифицируют пользователя. Для исходящего и входящего трафика происходит фильтрация. МЭ анализирующие состояние сессии Такие МЭ являются пакетными фильтрами, которые считывают сохраняемый пакет 4-го уровня OSI. Плюсы МЭ четвертого уровня: Информацию могут узнать только установленные соединения Пф доступен для всех, остается в целостности ТСР-соединение Прокси-сервер прикладного уровня Если применять МЭ ПУ, тогда нам не потребуется устройство, чтобы выполнить маршрутизацию. Прокси-сервер, анализирующий точный протокол ПУ, называется агентом прокси. Такой МЭ имеют много преимуществ. Плюсы прокси-сервера ПУ: Прокси требует распознавание пользователя МЭ ПУ проанализирует весь сетевой пакет. Прокси ПУ создают детальные логи. Минусы прокси-сервера ПУ: МЭ использует больше времени при работе с пакетами рикладные прокси работают не со всеми сетевыми приложениями и протоколами Выделенные прокси-серверы Эти прокси-серверы считывают трафик определенного прикладного протокола и не анализируют его полностью. Прокси-серверы нужны для сканирования web и e-mail содержимого: отсеивание Java-приложений; отсеивание управлений ActiveX; отсеивание JavaScript; уничтожение вирусов; блокирование команд, определенных для приложений и пользователя, вместе с блокирование нескольких типов содержимого для точных пользователей.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59