Компьютерная безопасность

 

 

 

 

 

 

Курсовой проект

 

по дисциплине

«Компьютерная безопасность»

 

 

 

 

 

 

 

 

 

 

 

 

                                                                                                   Выполнили: 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Орел 2013 г.

 

 

 

 

 

MPLS VPN

Будущее технологии коммутации меток (Multi Protocol Label Switching, MPLS) и виртуальных частных сетей на ее основе (MPLS Virtual Private Network, MPLS VPN) все еще туманно. Многочисленные положительные отзывы, высказываемые на различных конференциях, форумах и в средствах массовой информации, достигают порой таких превосходных степеней, как «наиболее значимая сетевая технология», на деле успехи MPLS пока весьма скромны. Причина не только в отсутствии достаточного числа внедрений. Сомнению и жесточайшей критике подвергаются даже теоретические положения, на которых базируется эта технология.

Два авторитетных специалиста  из компании AT&T (и одновременно члена IETF) — Стив Белловин и Рэнди Буш подвергли MPLS VPN резкой критике. Белловин, будучи гуру по безопасности, считает, что сети MPLS VPN обеспечивают для корпоративных пользователей меньший уровень защищенности по сравнению с уже зарекомендовавшими себя технологиями ATM/FR VPN и IPSec VPN. Буш, как специалист по сетевым операциям, указывает на плохую масштабируемость MPLS VPN — в основном из-за того, что таблицы маршрутизации для узлов клиентов конфигурируются и хранятся на пограничных маршрутизаторах провайдера. Эти и ряд других аргументов завершаются убийственным выводом: «MPLS — это социальная болезнь...» Достаточно серьезные обвинения, если учесть статус авторов, тем более что компания AT&T применяет MPLS в своей сети, предлагая на базе этой технологии услугу IP-Enabled Frame Relay.

Среди серьезных аргументов в защиту MPLS VPN выдвигается тезис  о том, что отсутствие встроенного  шифрования в MPLS не является ее недостатком, так как потребитель этой услуги или сам провайдер в случае повышенных требований к безопасности может применить шифрование IPSec как дополнение к MPLS VPN. В остальных случаях MPLS VPN предоставляет тот же уровень защиты, что и ATM/FR VPN, так как и те, и другие базируются на виртуальных каналах (в MPLS они называются иначе — пути коммутации меток, но это не меняет их сути). Многие специалисты опровергают утверждение о недостаточной масштабируемости MPLS VPN. Они указывают на то, что MPLS VPN автоматически обеспечивает связь узлов виртуальной сети по принципу «каждый с каждым» (как в обычной сети IP), так что попарные связи между узлами не требуется конфигурировать вручную, как это необходимо в противопоставляемых технологиях ATM/FR VPN. (Под термином «узел» здесь и далее понимается территориально обособленная часть корпоративной сети, например сеть удаленного филиала.)

Кэролин Даффи Марсан высказывает и такое мнение по поводу противоречивых оценок MPLS: отношение к MPLS — вопрос не столько технический, сколь мировоззренческий, он связан с общим отношением конкретного специалиста к стратегии развития Internet и технологий IP. Те, кто считает, что Internet должен сохранить простоту «тупой» сети и доставку данных «по мере возможности» (best effort), никогда не признают MPLS. Чтобы обосновать свою предвзятую позицию, они могут приводить множество аргументов «против», но суть кроется в их принципиальном неприятии идеи усложнения транспортной инфраструктуры Internet. Те же, кто придерживается мнения, что Internet может превратиться в Сеть нового поколения (Next Generation Network) только с приобретением новых свойств (в частности, стать более интеллектуальной и централизованно управляемой сетью, обеспечивающей контроль над путями следования трафика и высокий уровень качества обслуживания), безоговорочно приветствуют MPLS как одно из средств трансформации глобальной сети.

Как видим, вопрос о перспективах MPLS VPN совсем не прост, он затрагивает  различные аспекты сетевой индустрии: технические, организационные и  даже философские. MPLS VPN — это только одна из разновидностей виртуальных  частных сетей. Чтобы оценить  справедливость аргументов противоборствующих сторон, полезно сначала понять, что такое «виртуальная частная  сеть» в самом общем виде, какие  основные типы VPN существуют сегодня  в сетевом мире и какие критерии следует использовать при их сравнении.

Прежде чем описывать  атаки, необходимо дать определение VPN и кратко перечислить ее основные компоненты. Это позволит понять, куда могут быть направлены усилия злоумышленников. Итак, не претендуя на истину в последней  инстанции, технологию VPN можно определить как комплекс мероприятий по передаче данных из одной точки сети в другую безопасным образом. Это, на первый взгляд достаточно расплывчатое, определение  охватывает все возможные технологии построения VPN (включая и MPLS). Анализ этого определения позволяет  сделать ряд замечаний:

Безопасная передача данных реализуется на базе специальных  протоколов VPN и, как правило, с использованием шифрования (технологию MPLS, о которой  уже писал в КомпьютерПресс, № 10’2001, оставляю в стороне).

Поскольку обычно передача данных происходит по незащищенной сети (например, Internet), то необходимо реализовать обмен ключами шифрования между абонентами VPN, а в общем случае реализовать инфраструктуру управления ключами.

Средства построения VPN могут быть реализованы на базе программного или программно-аппаратного  обеспечения.

Наличие нескольких абонентов VPN требует их аутентификации.

VPN не только используется  людьми, но и реализуется ими.

Руководствуясь  этим, можно перейти к описанию возможных классов атак на элементы VPN.

Атаки на VPN  MPLS

 

Атаки на криптографические  алгоритмы

Первое, что приходит на ум, — это атаки на используемый криптографический алгоритм. В настоящий момент все алгоритмы можно условно разделить на две категории: известные и секретные. К известным алгоритмам относятся DES, TripleDES, RSA, AES и наш отечественный ГОСТ 28147-89. Эти алгоритмы знакомы специалистам довольно давно, так же как и их слабые и сильные стороны.

Варианты атак на криптоалгоритмы достаточно разнообразны. Самой простой является атака только на зашифрованной текст, когда криптоаналитик располагает лишь зашифрованным текстом и путем анализа статистического распределения символов, а также посредством других методов пытается распознать исходный текст. Любой алгоритм должен защищать от такой атаки. Более сложным случаем является атака с известным незашифрованным текстом. Здесь аналитику известен фрагмент исходного текста либо он делает обоснованное предположение о нем. Например, это может быть стандартное начало или завершение документа: «Конфиденциально», «Уважаемый», «С уважением» и т.д. Существуют и более сложные типы атак, например дифференциальный криптоанализ, однако их рассмотрение выходит за рамки статьи. Можно только отметить, что большинство распространенных на сегодняшний день алгоритмов устойчивы к этим атакам.

Если все же вам  предлагают VPN с секретным, патентованным  или уникальным алгоритмом, не имеющим  аналогов и обеспечивающим недосягаемый уровень безопасности, то у вас  есть повод задуматься. Как было доказано еще в конце XX века, стойкость  криптографического алгоритма должна определяться не его секретностью, а ключом. Поэтому все попытки  скрыть алгоритм от общественности дают повод усомниться в его надежности.

Атаки на криптографические  ключи

Вышеописанные атаки  на используемые в настоящее время  алгоритмы практически бессильны, что вынуждает злоумышленников  проверять все возможные ключи  шифрования (атака полным перебором). Поэтому принципиально важным является выбор алгоритма с достаточной  длиной ключа. В табл. 1 приведен сравнительный анализ времени и средств, затрачиваемых различными классами злоумышленников при полном переборе криптографических ключей, используемых в симметричных алгоритмах (DES, AES, ГОСТ 28147-89 и т.д.). Из этой таблицы следует, что отечественный алгоритм ГОСТ 28147-89 с длиной ключа 256 бит не может быть взломан в обозримом будущем, а зарубежные средства, подпадающие под экспортные ограничения США, ломаются относительно легко.

Асимметричные алгоритмы  используют ключи большей длины, так как атака полным перебором  на симметричные алгоритмы требует  больших временных затрат, нежели аналогичная атака на криптографию с открытым ключом. В табл. 2приведено соответствие длин ключей в симметричных и асимметричных алгоритмах для обеспечения сопоставимого уровня безопасности зашифрованных данных.

Разумеется, длина  ключа зависит от того, как долго  должна сохраняться в тайне защищаемая информация. Если речь идет о персональных данных или ноу-хау и бизнес-проектах, срок жизни которых может составлять десятилетия, то и длина ключа (при современном уровне развития вычислительной техники) для их защиты должна быть большой (не менее 128 бит). Если же речь идет о защите оперативной информации, например о котировках акций или военных сведениях тактического плана, то с учетом того, что такая информация теряет свою актуальность уже через несколько часов и даже минут, длина ключа может быть и не столь большой. Представьте, что криптоаналитики противника только через 10 минут дешифровали сообщение о запуске баллистической ракеты, которая достигает заданной точки через 8 минут. Актуальность такой информации практически равна нулю.

Для алгоритмов, основанных на открытых ключах, например RSA, существует ряд математических проблем, которые  не всегда учитываются при построении криптосистемы. К ним можно отнести  выбор начальных значений, на основе которых создаются ключи. Есть определенные числа, позволяющие очень быстро вычислить секретный ключ. В то же время правильный выбор начальных  значений позволяет гарантировать  невозможность «лобовой» атаки  в течение нескольких сотен лет  при современном развитии вычислительной техники. Аналогичные проблемы существуют и в симметричной криптографии.

Атаки на датчики  случайных чисел

Под криптосистемой понимается не только используемый алгоритм зашифровывания/расшифровывания, но также  механизм генерации и распределения  ключей и ряд других важных элементов, влияющих на надежность криптосистемы. Надежность криптосистемы складывается из надежности отдельных элементов, ее составляющих. Поэтому в некоторых  случаях нет необходимости атаковать  алгоритм — достаточно попытаться атаковать один из компонентов криптосистемы, например механизм генерации ключей. Если датчик случайных чисел, реализованный в криптосистеме для генерации ключей, недостаточно надежен, то говорить об эффективности такой системы не приходится, даже при наличии хорошего криптографического алгоритма.

Датчики случайных  чисел (ДСЧ), а точнее датчики псевдослучайных  чисел, являются одним из ключевых элементов  при построении любой криптографической  системы, в том числе и VPN, и  позволяют создавать действительно  стойкие ключи. Псевдослучайными они  называются потому, что по-настоящему случайные числа в природе  существуют, а на компьютере получить их практически невозможно. Самый  простой способ: не глядя несколько  раз нажать на кнопки клавиатуры или  подвигать мышью. Если злоумышленник  может предсказать значения, генерируемые ДСЧ, то он способен и вычислить криптографические  ключи, что ставит под удар всю  инфраструктуру VPN. Поэтому рекомендуется  выбирать действительно эффективные  датчики псевдослучайных чисел, которые обычно реализуются аппаратным образом, и не использовать функции  random, rnd и т.д., встроенные во многие языки программирования. В России качество ДСЧ (как и вообще любых криптографических систем) подтверждается Федеральным агентством правительственной связи и информации при Президенте РФ (ФАПСИ). Один из таких датчиков реализован на электронном замке «Соболь», который имеет сертификат ФАПСИ, и может быть использован (и используется) при построении криптографических систем.

Атаки на протоколы VPN

Внастоящий момент для построения VPN используется ряд протоколов, включая IPSec, PPTP, L2TP и т.д. Эти протоколы не шифруют данные, а лишь определяют, как используются алгоритмы шифрования и ряд других условий, необходимых для построения VPN (включая контроль целостности, аутентификацию абонентов и т.д.). За последние пару лет многие исследователи принимались за анализ данных протоколов с точки зрения безопасности, но серьезных «дыр» обнаружено практически не было. А те, что все-таки были найдены, были связаны с неправильной эксплуатацией или уже были устранены разработчиками. Однако теоретическая возможность обнаружения уязвимостей в протоколах IPSec, PPTP и т.д. сохраняется.

Атаки на протоколы  аутентификации

Установление соединения между абонентами требует их взаимной аутентификации, то есть проверки подлинности. В качестве протоколов аутентификации могут использоваться RADIUS, TACACS (в  том числе и TACACS+) и сертификаты. Не будем подробно останавливаться  на атаках на эти протоколы и осветим  только получивший в последнее время  распространение метод использования  сертификатов. Особенно это актуально с учетом того факта, что сертификаты являются ключевым элементом федерального закона об электронной цифровой подписи. Главная проблема связана с доверием к удостоверяющим центрам (Certificate Authority), которые призваны выдавать на каждый открытый ключ абонента сети свой сертификат. Если этот центр не дает абсолютной гарантии, то вся инфраструктура VPN и гроша ломаного не стоит. Узлы сети VPN не смогут доверять сертификатам, выданным удостоверяющим центром. Существуют и другие возможные атаки на систему сертификатов, но объем данной статьи не позволяют рассмотреть их все.

Атаки на реализацию

Атаки именно этого  типа наиболее часто используются злоумышленниками. Связано это с тем, что для  этого не требуется обширных познаний в области математики. Достаточно быть квалифицированным программистом  или просто знать человеческие слабости. Примеров неправильной реализации, приводящей к атаке на нее, можно назвать  множество, в частности:

Секретный ключ шифрования хранится на жестком диске, доступ к  которому никак не контролируется.

Криптографический ключ, хранящийся в оперативной памяти, не затирается после использования.

Обеспечивается  безопасность сеансовых ключей и  уделяется недостаточное внимание защите главных ключей.

Открыт доступ к  «черным спискам» скомпрометированных  ключей.

Отсутствует контроль целостности программного комплекса VPN, что позволяет злоумышленнику изменить ПО, отвечающее за шифрование или проверку целостности получаемых по сети пакетов.

Если же говорить о конкретных уязвимостях, то их можно  назвать не меньше десятка. В частности, уязвимости реализации PPTP, приводящие к отказу в обслуживании в ОС Windows NT, межсетевом экране WatchGuard Firebox II, маршрутизаторах Cisco и BinTec. Не обошлось и без уязвимостей IPSec. Например, в OpenBSD присутствовала также приводившая к отказу в обслуживании уязвимость, связанная с некорректной обработкой пакетов AH/ESP (специальные режимы IPSec), а в Windows 2000 в декабре прошлого года была обнаружена уязвимость в реализации протокола обмена ключами IKE для IPSec.

Можно добавить, что  существуют варианты атак не только на программную составляющую VPN, но и  на аппаратные элементы, например на таблетки Touch Memory, смарт-карты и другие аппаратные носители криптографических ключей.

Атаки на оборудование VPN

Достаточно часто VPN реализуется на базе уже существующего  сетевого оборудования, как правило, маршрутизаторов (например, Cisco 1720) или программно-аппаратных межсетевых экранов (например, CheckPoint VPN-1 на базе платформы Nokia IP Security Solutions). Также существуют и специализированные устройства построения VPN (например, «Континент-К»). А раз это обычное устройство, поддерживающее стек TCP/IP, то на него могут быть реализованы атаки «отказ в обслуживании», которые могут нарушить функционирование самого устройства и обусловить временный сбой во взаимодействии защищаемых с их помощью сетей и узлов.

Атаки на операционные системы

Нередко VPN реализуется  чисто программными средствами (например, в Windows 2000), и программное обеспечение VPN является надстройкой над операционной системой, что зачастую используется злоумышленниками. Поэтому, независимо от надежности и защищенности ПО VPN, уязвимости операционной системы могут свести на нет все защитные механизмы VPN. Это особенно важно для продукции компании Microsoft, которая не отличается продуманностью с точки зрения защиты: не было недели, чтобы не обнаружилась очередная дыра в операционных системах Windows NT, Windows 2000, а с недавнего времени — Windows XP.

Атаки на пользователей

Не стоит забывать, что конечный пользователь также  является элементом VPN и также подвержен  атакам, наравне со всеми прочими  элементами. Пользователь может передать дискету с секретными ключами, а  может потерять такую дискету  или другой носитель секретных ключей и не сообщать об утере до того момента, пока эта дискета не понадобится  вновь.

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

 

Ещё не много  о основных  угрозах.

Прежде чем говорить о  технологии MPLS VPN, как о методе и  средстве обеспечения сетевой безопасности, обозначим, какие угрозы чаще всего  возникают в современных сетях  передачи данных. Можно выделить четыре основные группы таких угроз: первая группа — это вирусные атаки, с которыми, согласно статистике, так или иначе связаны до 70% всех сетевых инцидентов; вторая — это рассылка спама, которая больше относится к такой области информационной безопасности, как защита от информации; третья — это атаки типа “отказ в обслуживании” и наиболее опасная их разновидность — распределенная атака “отказ в обслуживании”; и, наконец, четвертая — это атаки с использованием уязвимостей ПО открытых информационных сервисов, ошибок программирования и настройки.

Как уже отмечалось выше, традиционные средства и методы борьбы с этими угрозами основаны на принципе установки разнообразных “информационных  барьеров” — межсетевых экранов  и сетевых фильтров, систем обнаружения  вторжения, активного аудита, сканеров безопасности (сюда же можно отнести  различные обманные системы, mail sweeper, mime sweeper). Средства и методы построения виртуальных частных сетей (VPN) отличаются от традиционного подхода к защите сетей на основе “информационных барьеров”. Они позволяют строить выделенные, или частные, сети на базе разделяемой сетевой инфраструктуры и таким образом реализовать упреждающую, превентивную стратегию защиты сети.

Сети MPLS L3 VPN строятся на основе разделения таблиц маршрутизации. Сетевые  префиксы, принадлежащие определенной сети VPN, выносятся в отдельную  таблицу маршрутизации, и продвижение  трафика в рамках данной VPN происходит по маркированному пути LSP (Label Switched Path), построенному специально для префиксов в этой таблице. Продвижение трафика в рамках одной сети MPLS L3 VPN осуществляется следующим образом: на точке входа в MPLS-домен к пакету добавляются две метки — внутренняя и внешняя; внешняя метка используется для продвижения трафика по MPLS-домену от точки входа к точке выхода, а внутренняя — для направления трафика в точке выхода на устройство пользователя CE — Customer Edge (см. рисунок). Внутренняя метка необходима, поскольку через устройства PE1 и PE2 (Provider Edge) могут проходить несколько VPN-сетей.

Технологии MPLS L3 VPN допускают  весьма гибкие схемы организации  виртуальных соединений пользователей, когда один пользователь может участвовать  в нескольких виртуальных сетях  сразу. В этом случае продвижение  трафика также управляется на основе внешних и внутренних меток.

С точки зрения сетевой  безопасности технологии MPLS L2/L3 VPN предлагают новый уровень защиты сетевого трафика. Несмотря на то что пакеты передаются по разделяемой опорной сети, из-за разнесения сетевых префиксов в разные маршрутные таблицы трафик одной VPN-сети получается изолированным в рамках каждого маршрутизатора — еще до применения к нему (трафику) правил продвижения пакетов и тем более до реализации правил традиционной, “барьерной”, политики сетевой безопасности. В результате атаки типа “отказ в обслуживании”, а также атаки с использованием уязвимостей прикладного ПО в принципе не могут быть осуществлены извне выделенной сети MPLS VPN. Трафик такой атаки просто не дойдет до цели потому, что маршруты MPLS VPN находятся в выделенной маршрутной таблице, которая не задействуется в процессе принятия решения по маршрутизации внешнего трафика.

Безопасность MPLS VPN

Вопросы, требующие  ответа:

Как сделать  раздельной адресацию?

Как сделать  маршрутизацию раздельной?

Как скрыть сетевую магистраль?

Как устранить  уязвимость к атакам типа DoS и вторжениям в сеть?

Парадокс  обеспечения абсолютной изолированности при сохранении полной связности.

 

При создании VPN на базе IP-сети сложно проблема состоит в достижении изолированности 

Решение:

Для изоляции - автоматическая фильтрация маршрутных объявлений

Для связности - применение туннелей для передачи клиентского трафика по внутренней сети провайдера.

Устойчивость  MPLS VPN к атакам

Имеется возможность  задать объект атаки в сети провайдера - IP-адрес глобальной связи (WAN link)

Главная цель – обеспечить защищенность каждой VPN от атак из других VPN.

Из VPN, подключенной к тому же самому PE

Через магистральную  сеть

 

Два возможных  пути атаки в MPLS VPN

1. Атака на PE
2. Атака на сигнальный механизм MPLS (на внутренние LSR)

Атаки на PE

DoS-атака на PE. Затопление обновлениями таблиц маршрутизации

Несанкционированный доступ к  PE

Могут быть проведены такие же атаки как и на маршрутизаторы ISP. Используются те же методы предотвращения.

Предотвращение  атак на PE

Несанкционированный доступ к PE

В access-list заносятся записи, запрещающие доступ к PE по telnet из CE.

Затопление  маршрутными обновлениями

Использование аутентификации в протоколах маршрутизации 

Настроить access-list так, чтобы сообщения других протоколов маршрутизации не  пропускались

Ограничения общего количества маршрутов в VRF

Ограничения общего количество маршрутов, которые  могут быть приняты BGP во время одной сессии

 

Атака на систему  сигнализации MPLS VPN

Пакеты передаются по магистральной сети на основании  меток 

Метки назначаются  протоколами продвижения меток  LDP/RSVP

Возможно ли подменить метку (аналогично IP-спуфингу)?

 

Спуфинг меток в MPLS

Связь между  CE и PE является IP интерфейсом, не использующим метки

PE router ни при каких обстоятельствах не принимает по этому интерфейсу пакетов с меткой

При получении  пакета с меткой по интерфейсу с  CE маршрутизатор PE отбрасывает его

Протокол  LDP может использовать аутентификацию на основе MD-5

Рассмотрим  более подробно методы защиты VPN MPLS:

 

Алгоритм MD5

 

Алгоритм MD5 является разработкой Рона Ривеста (RFC 1321). Алгоритм получает на входе сообщение произвольной длины и создает в качестве выхода дайджест сообщения длиной 128 бит. По настоящее время этот алгоритм остается одним из самых распространеных алгоритмов хеширования. Однако в настоящее время длина его выхода 128 бит является недостаточно большой, чтобы противопостоять атакам прямого перебора. Кроме того, однаружены ряд уязвимостей MD5 против линейного и дифференциального криптоанализа.

На вход алгоритма поступает  входной поток данных, хеш которого необходимо найти. Длина сообщения может быть любой (в том числе нулевой). Запишем длину сообщения в L. Это число целое и неотрицательное. Кратность каким-либо числам необязательна. После поступления данных идёт процесс подготовки потока к вычислениям.

Ниже приведены 5 шагов алгоритма:

Шаг 1. Выравнивание потока

Сначала дописывают единичный  бит в конец потока (байт 0x80), затем  необходимое число нулевых бит. Входные данные выравниваются так, чтобы их новый размер  L' был сравним с 448 по модулю 512 (L'=512*N+448). Выравнивание происходит, даже если длина уже сравнима с 448.

Шаг 2. Добавление длины сообщения

В оставшиеся 64 бита дописывают 64-битное представление длины данных (количество бит в сообщении) до выравнивания. Сначала записывают младшие 4 байта. Если длина превосходит 2⁶⁴-1, то дописывают только младшие биты. После этого длина потока станет кратной 512. Вычисления будут основываться на представлении этого потока данных в виде массива слов по 512 бит.

Шаг 3. Инициализация  буфера

Для вычислений инициализируются 4 переменных размером по 32 бита и задаются начальные значения шестнадцатеричными числами (шестнадцатеричное представление, сначала младший байт):

А = 01 23 45 67;

В = 89 AB CD EF;

С = FE DC BA 98;

D = 76 54 32 10.

В этих переменных будут  храниться результаты промежуточных  вычислений. Начальное состояние ABCD называется инициализирующим вектором.

Шаг 4. Вычисление в цикле

Заносим в блок данных элемент n из массива. Сохраняются значения A, B, C и D, оставшиеся после операций над предыдущими блоками (или  их начальные значения, если блок первый).

AA = A

BB = B

CC = C

DD = D

Суммируем с результатом  предыдущего цикла:

A = AA + A

B = BB + B

C = CC + C

D = DD + D

После окончания цикла  необходимо проверить, есть ли ещё блоки  для вычислений. Если да, то изменяем номер элемента массива (n++) и переходим  в начало цикла.

Шаг 5. Результат  вычислений

Результат вычислений находится  в буфере ABCD, это и есть хеш. Если выводить побайтово, начиная с младшего байта A и закончив старшим байтом D, то мы получим MD5-хеш.

 

ACL: списки контроля  доступа

ACL (Access Control List) — это набор текстовых выражений, которые что-то разрешают, либо что-то запрещают. Обычно ACL разрешает или запрещает IP-пакеты, но помимо всего прочего он может заглядывать внутрь IP-пакета, просматривать тип пакета, TCP и UDP порты. Также ACL существует для различных сетевых протоколов (IP, IPX, AppleTalk и так далее). В основном применение списков доступа рассматривают с точки зрения пакетной фильтрации, то есть пакетная фильтрация необходима в тех ситуациях, когда у вас стоит оборудование на границе Интернет и вашей частной сети и нужно отфильтровать ненужный трафик.

Функционал ACL состоит в  классификации трафика, нужно его  проверить сначала, а потом что-то с ним сделать в зависимости  от того, куда ACL применяется. ACL применяется  везде, например:

На интерфейсе: пакетная фильтрация

На линии Telnet: ограничения  доступа к маршрутизатору

VPN: какой трафик нужно  шифровать

QoS: какой трафик обрабатывать приоритетнее

NAT: какие адреса транслировать

 Для применения ACL для  всех этих компонентов нужно  понять как они работают. И мы в первую очередь будем касаться пакетной фильтрации. Применительно к пакетной фильтрации, ACL размещаются на интерфейсах, сами они создаются независимо, а уже потом они прикручиваются к интерфейсу. Как только вы его прикрутили к интерфейсу маршрутизатор начинает просматривать трафик. Маршрутизатор рассматривает трафик как входящий и исходящий. Тот трафик, который входит в маршрутизатор называется входящим, тот который из него выходит — исходящий. Соответственно ACL размещаются на входящем или на исходящем направлении.

 Из вашей частной  сети приходит пакет на интерфейс  маршрутизатора fa0/1, маршрутизатор  проверяет есть ли ACL на интерфейсе или нет, если он есть, то дальше обработка ведется по правилам списка доступа строго в том порядке, в котором записаны выражения, если список доступа разрешает проходить пакету, то в данном случае маршрутизатор отправляет пакет провайдеру через интерфейс fa0/0, если список доступа не разрешает проходить пакету, пакет уничтожается. Если списка доступа нет — пакет пролетает без всяких ограничений. Перед тем как отправить пакет провайдеру, маршрутизатор ещё проверяет интерфейс fa0/0 на наличие исходящего ACL. Дело в том, что ACL может быть прикреплен на интерфейсе как входящий или исходящий. К примеру у нас есть ACL с правилом запретить всем узлам в Интернете посылать в нашу сеть пакеты.

 Так на какой интерфейс  прикрепить данную ACL? Если мы прикрепим ACL на интерфейс fa0/1 как исходящий, это будет не совсем верно, хотя и ACL работать будет. На маршрутизатор приходит эхо-запрос для какого-то узла в частной сети, он проверяет на интерфейсе fa0/0 есть ли ACL, его нет, дальше проверяет интерфейс fa0/1, на данном интерфейсе есть ACL, он настроен как исходящий, всё верно пакет не проникает в сеть, а уничтожается маршрутизатором. Но если мы прикрепим ACL за интерфейсом fa0/0 как входящий, то пакет будет уничтожатся сразу как пришел на маршрутизатор. Последнее решение является правильным, так как маршрутизатор меньше нагружает свои вычислительные ресурсы. Расширенные ACL нужно размещать как можно ближе к источнику, стандартные же как можно ближе к получателю. Это нужно для того, чтобы не гонять пакеты по всей сети зря.

 Сам же ACL представляет  собой набор текстовых выражений,  в которых написано permit (разрешить) либо deny (запретить), и обработка ведется строго в том порядке в котором заданы выражения. Соответственно когда пакет попадает на интерфейс он проверяется на первое условие, если первое условие совпадает с пакетом, дальнейшая его обработка прекращается. Пакет либо перейдет дальше, либо уничтожится.