Cisco module что за программа

uzverss

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

То есть «Делаем NAT..» но без «VPN на Cisco», «Zone Based Firewall» но без VPN, NAT+VPN+ZBF но без Traffic Policing. Куча источников, куча материалов, куча конфигов — полный хаос. Причём, не спасает даже Cisco Validated Design. Чтобы решить этот вопрос хотя бы для себя, я и решил оформить всё это дело в блоге. Итак, каким требованиям должен отвечать мой конфиг:

1. сеть разделена на несколько фрагметов
2. фрагменты разделены между собой ZBF
3. присутствует гостевая сеть для беспроводных точек доступа, контроль над которыми нам не принципиален (у секретаря генерального гости берут логин/пароль и пока ждут приема могут лазить по интернету)
4. у гостевой сети скорость порезана traffic policing
5. настроен Site-toSite VPN на другое предприятие (группу предприятий). Снаружи ZBF режет любые попытки подключения по VPN от любых других узлов, кроме доверенных.

11 WHAT CISCO Module Intro

Теперь стоит определиться с оборудованием, которое чаще всего закупается для реализации всех этих целей. Тут варианта два: ISR G2 и ASA. Так как Remote Access VPN нужен в минимальных рамках без NAC и сложной проверки Remote Client, а Site-to-Site VPN в будущем будет переделан в DMVPN, то я для себя вижу только один вариант — ISR G2.

Тут вариаций много, но мне ближе модели, которые имеют возможность установки 48-портового свитча и обрабатки телефонии. Из простых это 2921/2951, из средних — 3925(E)/3945(E), из серьёзных — 4451-X. Единственное, чем они отличаются — это производительность. Для меня малый офис ассоциируется с моделью 2951, поэтому я буду описывать конфигурацию непосредственно для неё.

1. Настраиваем подключение к модулю свитча

В моём примере 24-портовый свитч установлен в платоместо 1

NAME: «CISCO2951/K9», DESCR: «CISCO2951/K9 chassis, Hw Serial#: FCZ11223344, Hw Revision: 1.1»

PID: CISCO2951/K9 , VID: V05 , SN: FCZ11223344

NAME: «SM-ES2-24: EtherSwitch SM L2 + 23 10/100 + 1 10/100/1000 on Slot 1», DESCR: «SM-ES2-24: EtherSwitch SM L2 + 23 10/100 + 1 10/100/1000»

PID: SM-ES2-24 , VID: V02 , SN: FOC22334455

NAME: «C2921/C2951 AC Power Supply», DESCR: «C2921/C2951 AC Power Supply»

PID: PWR-2921-51-AC , VID: V03 , SN: QCS33445566

Этот модуль подключается двумя портами: G0/26 — к основному шасси на порт G1/0 (используется для управления), G0/25 — к MGF на порт G1/1 (используется для передачи трафика). Не будем сильно заморачиваться и настроим следующим образом.

ip address 172.16.1.2 255.255.255.0

CCNA 1 v7 Modules 4 – 7: Ethernet Concepts Exam Answers

description Internal switch interface connected to Service Module

switchport mode trunk

## Cisco SM-ES2-24

switchport mode trunk

К интегрированному свитчу можно подключиться по консоли и адрес 172.16.1.2 как раз используется для этого:

Trying 172.16.1.2, 2067 . Open

User Access Verification

Причем чтобы выйти обратно в консоль роутера надо использовать культовую комбинацию Ctrl+Shift+6 и затем X. У кого при этом переключается клава — сделайте два раза 😉 К настройке свитча вернёмся чуть позже — сейчас важно отстроить логику.

2. Нарезаем фрагменты сети.

Первое, что нам необходимо сделать, это разделить трафик по функциональной нагрузке.

ip address 111.111.111.111 255.255.255.0

ip address 192.168.1.1 255.255.255.0

ip address 192.168.2.1 255.255.255.0

ip address 192.168.3.1 255.255.255.0

ip address 192.168.4.1 255.255.255.0

ip address 192.168.5.1 255.255.255.0

ip address 192.168.6.1 255.255.255.0

ip address 192.168.7.1 255.255.255.0

ip address 192.168.8.1 255.255.255.0

ip address 192.168.9.1 255.255.255.0

Администраторы сети находятся в сети iLO_LAN, чтобы иметь прямой доступ к средствам управления. Если система хранения работает на FC, то сеть iSCSI_LAN не нужна. Тоже касается и DMZ_LAN. Гостевая сетка Guest_LAN используется для того, чтобы в неё запихнуть «неконтролируемую» точку доступа.

3. Настройка NAT

Здесь более менее всё стандартно.

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

ip access-list extended servers-traffic

permit ip 192.168.3.0 0.0.0.255 any

ip nat inside source list servers-traffic interface GigabitEthernet0/2 overload

Это правило временное. После появления VPN надо будет делать исключения в NAT. По аналогии делается правило для гостевой сети. Больше никому доступ в интернет не должен понадобиться.

4. Zone-Based Firewall

Кардинальное отличие ZBF от CBAC в том, что первый по умолчанию блокирует, а второй — разрешает. То есть, разместив интерфейс в какой-либо зоне и не настроив никакого доступа — мы блокируем любой трафик. В случае CBAC, пока ACL не повешен на интерфейс — трафик свободно ходит.

zone security servers-zone

zone-member security out-zone

zone-member security servers-zone

После того, как все интерфейсы помещены в свои зоны, можно прописывать zone-pair. Но для того, чтобы её прописать, надо сначала описать все компоненты, которые в ней используются.

class-map type inspect match-any cm-servers-to-out-protocol

match protocol icmp

match protocol tcp

match protocol udp

class-map type inspect match-all cm-servers-to-out

match access-group name servers-traffic

match class-map cm-servers-to-out-protocol

policy-map type inspect pm-servers-to-out

class type inspect cm-servers-to-out

zone-pair security zp-servers-to-out source servers-zone destination out-zone

service-policy type inspect pm-servers-to-out

Теперь надо настроить правило в обратную сторону. В первую очередь это нужно для того, чтобы почтовый сервер мог не только отправлять сообщения, но и получать их. А если снаружи порт закрыт, то письма приходить не будут. Для этого надо сделать, во-первых, zone-pair, а, во-вторых, публикацию порта 25/TCP почтового сервера наружу посредством NAT.

ip access-list extended acl-out-to-mail-server

permit tcp any host 192.168.3.254 eq smtp

class-map type inspect match-all cm-out-to-mail-server

match access-group name acl-out-to-mail-server

policy-map type inspect pm-out-to-servers

class type inspect cm-out-to-mail-server

zone-pair security zp-out-to-servers source out-zone destination servers-zone

service-policy type inspect pm-out-to-servers

ip access-list extended acl-nonat-to-mail-server

permit tcp any host 192.168.3.254 eq smtp

route-map rm-nonat-to-mail-server permit 10

match ip address acl-nonat-to-mail-server

ip nat inside source static tcp 192.168.3.254 25 111.111.111.111 25 route-map rm-nonat-to-mail-server extendable

Важно отметить, что разрешения и выборка трафика осуществляются на основании внутреннего адреса. Что касаемо route-map, то я тоже был немного сконфужен необходимостью её использования в таком варианте выборки трафика. Но других вариантов мне просто не оставили:

Cisco2951(config)#ip nat inside source static tcp 192.168.3.254 25 111.111.111.111 25 ?

extendable Extend this translation when used

forced Delete this entry and its children, even if in use

no-alias Do not create an alias for the global address

no-payload No translation of embedded address/port in the payload

redundancy NAT redundancy operation

route-map Specify route-map

vrf Specify vrf

5. Site-to-Site VPN

Малый офис как правило имеет подключение к основному офису. Приведу пример настройки самого простого соединения.

Сначала отстроим логический уровень — чтобы это «должно» было соединяться. Ясен пень, что пока доступ не расковыряем как надо, ничего соединяться не будет. Но в данном случае надо двигаться последовательно.

crypto isakmp policy 10

crypto isakmp key psk-for-vpn address 222.222.222.222

crypto ipsec transform-set AES256-SHA esp-aes 256 esp-sha-hmac

ip access-list extended vpn-to-hq

permit ip 192.168.3.0 0.0.0.255 host 192.168.33.254

permit ip host 192.168.3.254 192.168.55.0 0.0.0.255

crypto map OUTSIDE 4 ipsec-isakmp

set peer 222.222.222.222

set transform-set AES256-SHA

match address vpn-to-hq

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

ip access-list extended servers-traffic

permit ip 192.168.3.0 0.0.0.255 any

ip nat inside source list servers-traffic interface GigabitEthernet0/2 overload

ip access-list extended nonat-vpn-servers-traffic

deny ip any 10.0.0.0 0.255.255.255
deny ip any 172.16.0.0 0.15.255.255
deny ip any 192.168.0.0 0.0.255.255

permit ip 192.168.3.0 0.0.0.255 any

ip nat inside source list nonat-vpn-servers-traffic interface GigabitEthernet0/2 overload

Теперь очередь ZBF. Так как трафик приходит снаружи, то надо изменить/добавить ряд правил для зоны OUT.

ip access-list extended acl-vpn-hq-to-servers
permit ip host 192.168.33.254 192.168.3.0 0.0.0.255
permit ip 192.168.55.0 0.0.0.255 host 192.168.3.254
!
class-map type inspect match-any cm- vpn-hq-protocol

match protocol icmp

match protocol tcp

match protocol udp

class-map type inspect match-all cm-vpn-hq-to-servers
match access-group name acl-vpn-hq-to-servers match class-map cm-vpn-hq-protocol
!

policy-map type inspect pm-out-to-servers

class type inspect cm-vpn-hq-to-servers
inspect

class type inspect cm-out-to-mail-server

Итак, исходящий трафик был сконфигурирован в самом начале, входящий трафик сконфигурировали только что. С NAT разобрались. Перед финальным аккордом осталось только одно — сделать так, чтобы роутер мог В ПРИНЦИПЕ принимать VPN-пакеты.

permit udp host 222.222.222.222 any eq isakmp non500-isakmp

class-map type inspect match-any cm-hq-to-self-protocol

match protocol icmp

match protocol tcp

match protocol udp

class-map type inspect match-all cm-hq-to-self

match access-group name acl-hq-to-self

match class-map cm-hq-to-self-protocol

policy-map type inspect pm-out-to-self

class type inspect cm-hq-to-self

zone-pair security zp-hq-to-self source out-zone destination self

service-policy type inspect pm-out-to-self

Только после такого рода подготовки можно заходить на внешний интерфейс и вешать на него криптомапу.

crypto map OUTSIDE

6. Ограничение скорости для гостевой сети.

Так как пользователей в гостевой сети особо никто не контролирует, то мы им обрубаем трафик везде, кроме интернета. Но, что если гости заходят посмотреть Youtube? В лучшем случае, это увеличит нагрузку на канал. В худшем, они могут «съесть» весь канал. Чтобы этого не допустить, лучше «зарезать» канал до приемлемого значения.

class type inspect cm-guests-to-out

police rate 5242880 burst 655360

В данном примере канал «урезан» до 5Мбит/с. Этого вполне достаточно для комфортной работы в Интернет. Можно пропорционально изменить значения в зависимости от поставленной задачи. Как лучше резать трафик и как именно он режется на оборудовании можно ознакомиться в полезных ссылках.

7. Небольшие системные настройки

Для нормальной работы железяки необходимо, чтобы она нормально получала время по NTP. Прописывать сервера по IP не особо интересно, поэтому лучше сделать это по имени.

ntp server 1.ru.pool.ntp.org

ntp server 0.ru.pool.ntp.org

ntp server 3.ru.pool.ntp.org

ntp server 2.ru.pool.ntp.org

Здесь есть два нюанса. Во-первых, роутер должен нормально разрешать имена. Через внутренний DNS или внешний не принципиально. Главное чтобы это было. Для этого надо с интерфейса self дать доступ на интерфейс out по протоколу domain.

permit udp any host 8.8.8.8 eq domain

Я предпочитаю делать через внешний так как. во-вторых, надо с интерфейса self дать доступ на интерфейс out по протоколу ntp. Чтобы сделать всё однотипно проще сделать сразу одну policy-map на оба доступа.

В заключении, надо чётко ограничить доступ на роутер по ssh. При поставке железо уже преднастроено, поэтому я предпочитаю допиливать уже настроенный доступ.

access-class 23 in

privilege level 15

transport input ssh

access-class 23 in

privilege level 15

transport input ssh

В заключении хотел бы сказать, что все эти действия производятся СТРОГО до подключения оборудования в рабочую сеть и к провайдеру. В случае пренебрежения техникой безопасности возможны различные конфузы и неприятности.

Источник: uzverss.livejournal.com

Cisco ISE: Введение, требования, установка. Часть 1

У каждой компании, даже самой малой есть потребность в проведении аутентификации, авторизации и учета пользователей (семейство протоколов ААА). На начальном этапе ААА вполне себе хорошо реализуется с использованием таких протоколов, как RADIUS, TACACS+ и DIAMETER. Однако с ростом количества пользователей и компании, растет и количество задач: максимальная видимость хостов и BYOD устройств, многофакторная аутентификация, создание многоуровневой политики доступа и многое другое.

Для таких задач отлично подходит класс решений NAC (Network Access Control) — контроль сетевого доступа. В цикле статей, посвященному Cisco ISE (Identity Services Engine) — NAC решению для предоставления контроля доступа пользователям к внутренней сети с учетом контекста, мы подробно рассмотрим архитектуру, инициализацию, настройку и лицензирование решения.

Ссылки на все статьи в цикле приведены ниже:

1. Cisco ISE: Введение, требования, установка. Часть 1
2. Cisco ISE: Создание пользователей, добавление LDAP серверов, интеграция с AD. Часть 2
3. Cisco ISE: Настройка гостевого доступа на FortiAP. Часть 3
4. Cisco ISE: Профилирование. Часть 4

Кратко напомню, что Cisco ISE позволяет:

• Быстро и просто создавать гостевой доступ в выделенной WLAN;
• Обнаруживать BYOD устройства (например, домашние ПК сотрудников, которые они принесли на работу);
• Централизовать и применять политики безопасности к доменным и не доменным пользователям с помощью меток групп безопасности SGT (технология TrustSec);
• Проверять компьютеры на наличие установленного определенного ПО и соблюдение стандартов (posturing);
• Классифицировать и профилировать оконечные и сетевые устройства;
• Предоставлять видимость оконечных устройств;
• Отдавать журналы событий logon/logoff пользователей, их учетки (identity) на NGFW для формирования user-based политики;
• Нативно интегрироваться с Cisco StealthWatch и вносить в карантин подозрительные хосты, участвующие в инцидентах безопасности (подробнее);
• И другие стандартные для ААА сервера фичи.

Про Cisco ISE уже писали коллеги по отрасли, поэтому в дальнейшем советую ознакомиться: практика внедрения Cisco ISE, как подготовиться к внедрению Cisco ISE.

2. Архитектура

В архитектуре Identity Services Engine есть 4 сущности (ноды): нода управления (Policy Administration Node), нода распределения политик (Policy Service Node), мониторинговая нода (Monitoring Node) и PxGrid нода (PxGrid Node). Сisco ISE может быть в автономной (standalone) или распределенной (distributed) инсталляции. В Standalone варианте все сущности находятся на одной виртуальной машине или физическом сервере (Secure Network Servers — SNS), когда в Distributed — ноды распределены по разным устройствам.

Policy Administration Node (PAN) — обязательная нода, которая позволяет выполнять все административные операции на Cisco ISE. Она обрабатывает все системные конфигурации, связанные с ААА. В распределенной конфигурации (ноды можно устанавливать как отдельные виртуальные машины) у вас может быть максимум две PAN для отказоустойчивости — Active/Standby режим.

Policy Service Node (PSN) — обязательная нода, которая обеспечивает доступ к сети, состояние, гостевой доступ, предоставление услуг клиентам и профилирование. PSN оценивает политику и применяет ее. Как правило, PSN устанавливается несколько, особенно в распределенной конфигурации, для более избыточной и распределенной работы. Конечно же, эти ноды стараются устанавливать в разных сегментах, чтобы не терять возможности обеспечения аутентифицированного и авторизованного доступа ни на секунду.

Monitoring Node (MnT) — обязательная нода, которая хранит журналы событий, логи других нод и политик в сети. MnT нода предоставляет расширенные инструменты для мониторинга и устранения неполадок, собирает и сопоставляет различные данные, в также предоставляет содержательные отчеты. Cisco ISE позволяет иметь максимум две MnT ноды, тем самым формируя отказоустойчивость — Active/Standby режим. Тем не менее, логи собирают обе ноды, как активная, так и пассивная.

PxGrid Node (PXG) — нода, применяющая протокол PxGrid и обеспечивающая общение между другими устройствами, которые поддерживают PxGrid.

PxGrid — протокол, который обеспечивает интеграцию продуктов ИТ- и ИБ-инфраструктуры разных вендоров: систем мониторинга, систем обнаружения и предотвращения вторжений, платформ управления политиками безопасности и множества других решений. Cisco PxGrid позволяет обмениваться контекстом в однонаправленном или двунаправленном режиме со многими платформами без необходимости использования API, тем самым позволяя использовать технологию TrustSec (SGT метки), изменять и применять ANC (Adaptive Network Control) политику, а также осуществлять профилирование — определение модели устройства, ОС, местоположение и другое.

В конфигурации высокой доступности ноды PxGrid реплицируют информацию между нодами через PAN. В случае, если PAN отключается, нода PxGrid перестает аутентифицировать, авторизовывать и проводить учет пользователей.

Ниже схематично изображена работа разных сущностей Cisco ISE в корпоративной сети.

3. Требования

Cisco ISE может быть внедрен, как и большинство современных решений виртуально или физически как отдельный сервер.

Физические устройства с установленным ПО Cisco ISE называются SNS (Secure Network Server). Они бывают трех моделей: SNS-3615, SNS-3655 и SNS-3695 для малого, среднего и большого бизнеса. В таблице 1 приведена информация из даташита SNS.

Таблица 1. Сравнительная таблица SNS для разных масштабов

Источник: habr.com

Cisco ASA 8.4.2 с нуля. Часть 7. Modular Policy Framework

Modular Policy Framework (MPF) позволяет более выборочно управлять трафиком.

MPF может применяться на практике в следующих целях:

• Traffic inspection — процедура, необходимая для работы наиважнейшего принципа ASA, а именно Statefull Packet Filtering. Например для разрешения трафика FTP нам достаточно разрешить 21 порт, все остальные дочерние подключения ASA разрешит уже автоматически. И если для FTP мы можем тупо разрешить 20 и 21 порты, то проблема пропуска через NAT того же SIP вообще разрешима пожалуй только с помощью Traffic inspection.
• Prioritize, Police, Shape — Очень похожие функции на аналогичные в IOS Router
• IPS module — для работы с IPS также необходимо использование MPF.
• Set Connection Limits Policy — Изменение стандартных характеристик для соединений TCP позволяет защитить внутренние сервера от некоторых форм атак.

Создание правил MPF аналогично созданию политик на IOS.
Создание MPF выполняется в три этапа:

1. Create Class-map. Class-map позволяет выделить нужный нам трафик для последующей обработки.
2. Assign the class-map into policy-map. Policy-map определяет какие конкретные действия будут производиться над выделенным трафиком, т.е. class-map
3. Service Policy- Apply Policy on interface or Globally. Этим мы собственно активируем нашу Policy. На каком интерфейсе, или глобально.

Traffic Inspection

Default Modular Policy Configuration
Configuration > Firewall > Service Policy Rules
Traffic inspection работает уже по умолчанию благодаря тому, что в конфигурации по умолчанию уже включена Default Modular Policy.

class-map inspection_default match default-inspection-traffic ! policy-map type inspect dns preset_dns_map parameters message-length maximum client auto message-length maximum 512 policy-map global_policy class inspection_default inspect dns preset_dns_map inspect ftp inspect h323 h225 inspect h323 ras inspect rsh inspect rtsp inspect esmtp inspect sqlnet inspect skinny inspect sunrpc inspect xdmcp inspect sip inspect netbios inspect tftp inspect ip-options inspect icmp ! service-policy global_policy global

Здесь default-inspection-traffic директива, через которую включается инспектирование целого набора приложений и протоколов:

При работе инспектирования ASA фактически «подглядывает» за трафиком инспектируемых протоколов и приложений. Т.е. разбирает сессия на уровне приложений (application layer), и динамически разрешает необходимые порты. К этому относятся например SIP или H.323, которые работают с RTP и открывают сессии UDP вообще на случайных портах.

При включённой инспекци во время передачи можно видеть следующие соединения:

asa1# show conn 10 in use, 193 most used TCP dmz 192.168.253.10:21 inside 192.168.2.12:25947, idle 0:00:00, bytes 826, flags UIO TCP dmz 192.168.253.10:20 inside 192.168.2.12:25952, idle 0:00:00, bytes 1105408, flags UOB

Если отключить инспекцию FTP, то FTP уже сможет работать только в пассивном режиме, т.е. на 21 порту.

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

Application Inspection DEFAULTS

Как мы уже говорили, по умолчанию в inspection_default уже выставлено некоторое дефолтное поведение Application Inspection.
Т.е. для для каждого протокола, выставленного в class inspection_default выставлено Default Inspection.

Default Inspection проще всего посмотреть в ASDM ASA Help.
Default Inspection можно поменять, но там масса разных специфических параметров, поэтому проще всего работать из ASDM, который позволяет выставить Security Level.

Default Inspection проводится с названными протоколами и с дефолтными портами этих протоколов. Эту инфу можно посмотреть в ASDM, Default Inpections.
Если какой-то протокол работает на другом порту, это необходимо указать, например:

fixup protocol smtp 27

В результате будет добавлен дополнительный класс и добавлен к существующей global_policy:

class-map class_esmtp match port tcp eq 27 ! policy-map global_policy class class_esmtp inspect esmtp

Пример своей Application Inspection

access-list tftptraffic_acl extended permit udp any any eq tftp ! class-map TFTP_class match access-list tftptraffic_acl ! policy-map TFTP_policy class TFTP_class inspect tftp ! service-policy TFTP_policy global

Проверка Service Policy

show service-policy

Отображение как будет обрабатываться конкретный случай

show service-policy flow ip host 192.168.2.12 host 8.8.8.8

DNS Inspection

DNS использует UDP и должен обрабатываться через application inspection; в противном случае UDP обрабатывается лишь на основе activity timeouts.
ASA отслеживает UDP connections, и если обнаруживается UDP DNS Querry, то после получения DNS response данная сессия немедленно закрывается.

По умолчанию DNS Inspection включено, и выставлены следующие параметры, ограничивающие размер пакета DNS:

message-length maximum client auto message-length maximum 512

Это означает, что по умолчанию следующее поведение (взято из ASA Help):

• The maximum DNS message length is 512 bytes.
• DNS over TCP inspection is disabled.
• The maximum client DNS message length is automatically set to match the Resource Record.
• DNS Guard is enabled, so the ASA tears down the DNS session associated with a DNS query as soon as the DNS reply is forwarded by the ASA. The ASA also monitors the message exchange to ensure that the ID of the DNS reply matches the ID of the DNS query.
• Translation of the DNS record based on the NAT configuration is enabled.
• Protocol enforcement is enabled, which enables DNS message format check, including domain name length of no more than 255 characters, label length of 63 characters, compression, and looped pointer check.

В некоторых источниках рекомендуется выставить:

message-length maximum 4096

fixup protocol dns maximum-length 4096

ESMTP Inspection

ESMTP Inspection обеспечивает защиту от SMTP-based attacks через запрещение некоторых команд.
По умолчанию в конфигурации просто выставлено inspect esmtp. А в ASDM выставлено Use the default ESMTP inspection map.
Это означает следующее поведение (взято из ASA Help):

• The server banner is masked. The ESMTP inspection engine changes the characters in the server SMTP banner to asterisks except for the “2”, “0”, “0” characters. Carriage return (CR) and linefeed (LF) characters are ignored.
• Encrypted connections are not allowed. The STARTTLS indication is removed from the session connection attempt, forcing the client and server to negotiate a plain text session, which can be inspected.
• Special characters in sender and receiver address are not noticed, no action is taken.
• Connections with command line length greater than 512 are dropped and logged.
• Connections with more than 100 recipients are dropped and logged.
• Messages with body length greater than 998 bytes are logged.
• Connections with header line length greater than 998 are dropped and logged.
• Messages with MIME filenames greater than 255 characters are dropped and logged.
• EHLO reply parameters matching “others” are masked.

Prioritize, Police, Shape

Пример ограничения трафика для внутреннего пользователя:

object network pc1 host 192.168.2.249 ! access-list outside_mpc extended permit ip any object pc1 access-list outside_mpc extended permit ip object pc1 any ! class-map outside-class match access-list outside_mpc ! policy-map outside-policy class outside-class police input 500000 1500 police output 500000 1500 ! service-policy outside-policy interface outside

Проверка:
Проверка матчей на политике

show service-policy interface outside

Проверка матчей на ACL:

Set Connection Limits Policy

В данном разделе мы рассмотрим следующие методы защиты:
— Maximum number of simultaneous connections — Может защитить сервер от DoS
— Maximum number of connections allowed per client. Ограничить количество сессий торрентов для юзеров..
— Maximum numbers of TCP “half-open” (embryonic) connections allowed. Защита от “SYN” attacks.

access-list HTTP_traffic permit tcp any host 50.50.50.1 eq 80 access-list outbound_traffic permit ip 192.168.0.0 255.255.255.0 any ! class-map Web_SRV_Class match access-list HTTP_traffic ! class-map Outbound_Class match access-list outbound_traffic ! policy-map Web_SRV_policy class Web_SRV_Class set connection conn-max 3000 set connection per-client-max 100 set connection embryonic-conn-max 1500 ! policy-map outbound_policy class Outbound_Class set connection per-client-max 70 ! service-policy Web_SRV_policy interface outside service-policy outbound_policy interface inside

Источник: ciscomaster.ru