Работа в Стамбуле

Блог

  • Как отозвать платеж при помощи МТ192 SWIFT message

    Как отозвать платеж при помощи МТ192 SWIFT message

    Вообще то не имеет никакого значения, что там банк отправителя напишет в качестве причины отзыва денежных средств.
    На основании инструкции Национального Банка Украины, любой банк обязан выполнять распоряжения клиента, если они не противоречат действующему законодательству и инструкции НБУ.
    SWIFT MT192 срабатывает не всегда

    Возвращать средства после МТ192 никто не будет, пока сам клиент не даст на то распоряжение, а распоряжения такого как вы понимаете может и не поступить. Блокировать средства на счете клиента на основании МТ192 ни один банк тоже не может.

    Обычно клиент сам распоряжается полученной суммой и банк дает ответ МТ196 банку плательщика, о том что отзыв по МТ192 противоречит условиям экспортного контракта…
  • Принципы защиты сетевого оборудования регионального уровня

    Принципы защиты сетевого оборудования регионального уровня

     Оборудование регионального уровня непосредственно связано с оборудованием сетей клиентов сети IP/MPLS ПАО «Ростелеком» и, следовательно, подвергается максимальному риску атак из сетей клиентов ПАО «Ростелеком».

    Принципы защиты оборудования регионального уровня

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

          В основном защита от несанкционированного доступа производится аналогично защите для маршрутизаторов ядра.

          Поскольку пиринг с сетями клиентов и с сетями других операторов происходит с использованием протокола BGP, то необходима, прежде всего, фильтрация префиксов, приходящих от BGP маршрутизаторов сторонних сетей с целью недопущения попадания некорректной маршрутной информации, анонсируемой маршрутизаторами сторонних сетей в результате ошибки или умышленно. Фильтрация префиксов IPv4 осуществляется на базе списка, приведённого в [RFC6890]. Данный список содержит адреса следующих зарезервированных IETF и не подлежащих выделению сетей:

    • 0.0.0.0/8;
    • 0.0.0.0/1 – 0.0.0.0/32;
    • 10.0.0.0/8;
    • 172.16.0.0/12;
    • 192.168.0.0/16;
    • 127.0.0.0/8;
    • 192.0.0.0/24;
    • 192.0.2.0/24;
    • 169.254.0.0/16;
    • 100.64.0.0/10;
    • 192.88.99.0/24;
    • 198.18.0.0/15;
    • 198.51.100.0/24;
    • 203.0.113.0/24;
    • 224.0.0.0/4;
    • 240.0.0.0/4;

          Фильтрация префиксов IPv6 осуществляется на базе списка, указанного в [RFC6890] следующие префиксы:

    • ::/128;
    • ::1/128;
    • FE80::/10;
    • FC00::/7;
    • 2001::/23;
    • 2002::/16;
    • 64:ff9b::/96;
    • ::ffff:0:0/96;
    • 100::/64;

          С целью уменьшения общего числа префиксов фильтруются все префиксы с маской, длина которой превышает 24 бита для IPv4 и 48 бит для IPv6.
          Такая же фильтрация применяется и при передаче префиксов за пределы автономной системы Ростелеком.

          Пример политики для фильтрации неиспользуемых в сети Internet префиксов на маршрутизаторах Juniper:

    protocols {

        bgp {

            group INET_Customers {

                type external;

                neighbor 1.1.1.2 {

                    description «### Test Client ###»;

                    import sanity-check;

                    export sanity-check;

                    peer-as 65432;

                }

            }

            group INET_v6_Customers {

                type external;

                family inet6 {

                    unicast;

                }

                neighbor 1::2 {

                    description «### Test IPv6 Client ###»;

                    import v6-sanity-check;

                    export v6-sanity-check;

                    peer-as 65432;

                }

            }

        }

    }

    policy-options {

        policy-statement sanity-check {

            term reject-bogons {

                from policy bogons;

                then reject;

            }

            term accept-blackhole {

                from community type_blackhole_route;

                then next policy;

            }

            term reject-long-prefixes {

                from {

                    route-filter 0.0.0.0/0 prefix-length-range /25-/32 reject;

                }

            }

        }

        policy-statement bogons {

            term match-rfc6890-networks {

                from {

                    route-filter 10.0.0.0/8 orlonger accept;

                    route-filter 172.16.0.0/12 orlonger accept;

                    route-filter 192.168.0.0/16 orlonger accept;

                    route-filter 0.0.0.0/1 through 0.0.0.0/32 accept;

                    route-filter 0.0.0.0/8 orlonger accept;

                    route-filter 127.0.0.0/8 orlonger accept;

                    route-filter 192.0.0.0/24 orlonger accept;

                    route-filter 192.0.2.0/24 orlonger accept;

                    route-filter 169.254.0.0/16 orlonger accept;

                    route-filter 192.88.99.0/24 orlonger accept;

                    route-filter 224.0.0.0/4 orlonger accept;

                    route-filter 240.0.0.0/4 orlonger accept;

                    route-filter 198.18.0.0/15 orlonger accept;

                    route-filter 198.51.100.0/24 orlonger accept;

                    route-filter 203.0.113.0/24 orlonger accept;

                    route-filter 100.64.0.0/10 orlonger accept;           

                }

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement v6-sanity-check {

            term reject-bogons {

                from policy v6-bogons;

                then reject;

            }

            term reject-long-prefixes {

                from {

                    route-filter ::/0 prefix-length-range /48-/128 reject;

                }

            }

        }

        policy-statement v6-bogons {

            term match-rfc6890-networks {

                from {

                    route-filter ::/128 exact accept;

                    route-filter ::1/128 exact accept;

                    route-filter ::/1 through ::/128 accept;

                    route-filter FE80::/10 orlonger accept;

                    route-filter FC00::/7 orlonger accept;

                    route-filter 2001::/23 orlonger accept;

                    route-filter 2002::/16 orlonger accept;

                    route-filter 64:ff9b::/96 orlonger accept;

                    route-filter ::ffff:0:0/96 orlonger accept;

                    route-filter 100::/64 orlonger accept;

                }

            }

            term reject-others {

                then reject;

            }

        }

    }

          Для снижения вероятности программных сбоев, которые могут произойти в случае большого количества транзитных автономных систем в пути для какого-то префикса, принимаются только анонсы, количество автономных систем в AS_PATH которых не превышает 50. Такое значение не позволяет принимать слишком длинные AS_PATH и в то же время достаточно для корректно сформированных анонсов.

          Пример контроля количества AS в принимаемых анонсах на маршрутизаторах Juniper Networks:

    protocols {

        bgp {

            group INET_Customers {

                type external;

                neighbor 1.1.1.2 {

                    description «### Test Client ###»;

                    import restrict-long-as;

                    peer-as 65432;

                }

            }

            group INET_v6_Customers {

                type external;

                family inet6 {

                    unicast;

                }

                neighbor 1::2 {

                    description «### Test IPv6 Client ###»;

                    import restrict-long-as;

                    peer-as 65432;

                }

            }

        }

    }

    policy-options {

        policy-statement restrict-long-as {

            term reject-long-as_path {

                from as-path too_long_as_path;

                then reject;

            }

        }

        as-path too_long_as_path «.{50,}»;

    }

          Пример контроля количества AS в принимаемых анонсах на маршрутизаторах Cisco Systems:

    router bgp 12389

     bgp maxas-limit 50

    !


          Также необходимо запретить приём от клиентов префиксов Ростелеком и маршрута по умолчанию. Значения BGP Community, не предназначенные для использования клиентами (раздел «3.2.1 Маркировка маршрутов»), должны быть удалены.

          Пример запрета приёма префиксов Ростелеком и маршрута по умолчанию:

    protocols {

        bgp {

            group INET_Customers {

                type external;

                neighbor 1.1.1.2 {

                    description «### Test Client ###»;

                    local-address 1.1.1.1;

                    import INET_CUSTOMER_in;

                    peer-as 65432;

                }

            }

            group INET_v6_Customers {

                type external;

                family inet6 {

                    unicast;

                }

                neighbor 1::2 {

                    description «### Test IPv6 Client ###»;

                    local-address 1::1;

                    import INET__v6_CUSTOMER_in;

                    peer-as 65432;

                }

            }

        }

    }

    policy-options {

        policy-statement INET_CUSTOMER_in {

            term reject-RT-aggregate {

                from policy RT-aggregate;

                then reject;

            }

            term reject-RT-longer-prefixes {

                from policy RT-longer-prefixes;

                then reject;

            }

            term reject-default-route {

                from {

                    route-filter 0.0.0.0/0 exact;

                }

                then reject;

            }

            term remove-12389-communities {

                then {

                    community delete 12389:1-3X;

                    community delete 12389:1UZZ;

                }

            }

        }

        policy-statement RT-aggregate {

            term match-RT-aggregate-networks {

                from {

                    route-filter 87.226.128.0/17 exact accept;

                    route-filter 79.133.64.0/19 exact accept;

                    route-filter 92.50.192.0/18 exact accept;

                    route-filter 94.25.0.0/17 exact accept;

                }

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement RT-longer-prefixes {

            term match-RT-longer-prefixes {

                from {

                    route-filter 87.226.128.0/17 longer accept;

                    route-filter 79.133.64.0/19 longer accept;

                    route-filter 92.50.192.0/18 longer accept;

                    route-filter 94.25.0.0/17 longer accept;

                }

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement INET_v6_CUSTOMER_in {

            term reject-RT-v6-aggregate {

                from policy RT-v6-aggregate;

                then reject;

            }

            term reject-RT-v6-longer-prefixes {

                from policy RT-v6-longer-prefixes;

                then reject;

            }

            term reject-default-route {

                from {

                    route-filter ::/0 exact;

                }

                then reject;

            }

            term remove-12389-communities {

                then {

                    community delete 12389:1-3X;

                    community delete 12389:1UZZ;

                }

            }

        }

        policy-statement RT-v6-aggregate {

            term match-RT-v6-aggregate-networks {

                from {

                    route-filter 2A01:620::/32 exact accept;

                }

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement RT-v6-longer-prefixes {

            term match-RT-v6-longer-prefixes {

                from {

                    route-filter 2A01:620::/32 longer accept;

                }

            }

            term reject-others {

                then reject;

            }

        }

        community 12389 members 12389:*;

        community 12389:1-3X members «^12389:.{1,3}$»;

        community 12389:1UZZ members «^12389:1…$»;

    }

          В целях уменьшения влияния анонсов отдельных клиентов на ресурсы маршрутизаторов Сети ограничивается количество префиксов, получаемых от клиентов, значением 1000 для префиксов IPv4 и 100 для IPv6 (это значение может быть изменено для отдельного клиента или пересмотрено для всей Сети при изменении общей ситуации в сети Internet). При превышении 80% от этого значения генерируется сообщение в журнале событий (syslog), а при превышении 100% сессия BGP разрывается и может быть установлена вновь через 30 минут.

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

    protocols {

        bgp {

            group INET_Customers {

                type external;

                family inet {

                    unicast {

                        prefix-limit {

                            maximum 1000;

                            teardown 80 idle-timeout 30;

                        }

                    }

                }

            }

            group INET_v6_Customers {

                type external;

                family inet6 {

                    unicast {

                        prefix-limit {

                            maximum 100;

                            teardown 80 idle-timeout 30;

                        }

                    }

                }

            }

        }

    }

          В существующей сети ПАО «Ростелеком» для защиты от некорректных маршрутов применяется фильтрация на основе информации Routing Arbiter Database, являющейся одной из наиболее полных на сегодняшний день баз информации о зарегистрированных в региональных центрах регистрации (Regional Internet Registry, RIR) объектах (автономные системы, префиксы, принципы взаимодействия с соседями). Такая фильтрация является очень мощным средством обеспечения безопасности и стабильности.    Кроме того, процесс получения информации и настройки маршрутизаторов автоматизируется с помощью специализированных программных средств. Если номер автономной системы клиента двухбайтный, для формирования имени фильтра на сети IP/MPLS ПАО «Ростелеком» используется форма CUSTOMER:<ASN>, где <ASN> – номер автономной системы клиента или название AS-SET, AS-NUM или AUT-NUM, зарегистрированные в RIR.

          Пример фильтра при приёме маршрутов от клиента:

    protocols {

        bgp {

            group INET_Customers {

                neighbor 1.1.1.2 {

                    description «### Test Client ###»;

                    import CUSTOMER:65432;

                    peer-as 65432;

                }

            }

        }

    }

    policy-options {

        policy-statement CUSTOMER:65432 {

            term rtbh {

                from {

                    community type_blackhole_route;

                    route-filter 2.1.0.0/16 orlonger;

                    route-filter 1.2.3.0/24 orlonger;

                }

                then {

                    community add NO_EXPORT;

                    next-hop discard;

                    accept;        

                }

            }

            term prefixes {

                from {

                    route-filter 2.1.0.0/16 upto /24;

                    route-filter 1.2.3.0/24 exact;

                }

                then next policy;

            }

            then reject;

        }

        community NO_EXPORT members no-export;

        community type_blackhole_route members 12389:55555;

    }

          Необходимо отметить, что фильтрация префиксов, получаемых от BGP-маршрутизаторов сторонних сетей, не гарантирует отсутствие входящих пакетов с адресами источников из запрещённых сетей. Как и в случае маршрутизаторов магистрального уровня, необходима настройка списков доступа на внутреннем интерфейсе маршрутизатора, связывающем подсистему управления маршрутизатором с подсистемой коммутации пакетов. Также необходимо запретить возможность записывания данных по протоколу SNMP для всех устройств уровня доступа, кроме маршрутизаторов с функциональностью IP SLA, оставив лишь возможность чтения некоторых параметров необходимых для систем мониторинга и управления, а также для систем биллинга. Для маршрутизаторов с функциональностью IP SLA остается возможность записи по протоколу SNMP в CISCO-RTTMON MIB.
          Таким образом, политика безопасности маршрутизаторов доступа в основном совпадает с политикой безопасности маршрутизаторов ядра. Для организации второго рубежа защиты, ориентированного на защиту не отдельного устройства, а сети от несанкционированного доступа и возможности проведения атак типа отказ в обслуживании необходима настройка фильтрации пакетов на клиентских интерфейсах. Универсальный фильтр, запрещающий прохождение пакетов, в адресах назначения которых указаны адреса интерфейсов внутренних устройств сети IP/MPLS ПАО «Ростелеком», кроме тех, которые обеспечивают функционирование публичных сервисов. Для клиентов, использующих только услуги передачи голосового трафика через устройства голосовых сегментов сети IP/MPLS ПАО «Ростелеком», настраиваются списки доступа, разрешающие доступ только к пограничным контроллерам сессий (SBC) на интерфейсах, посредством которых эти клиенты подключаются к сети.

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

    interfaces {

        ge-2/0/0 {

            unit 2 {

                family inet {

                    filter {

                        input Prohibited_Destinations;

                    }

                }

            }

        }

    }

    firewall {

        filter Prohibited_Destinations {

            term RTK_IPMPLS_internal {

                from {

                    address {

                        87.226.133.0/24;

                        87.226.134.0/24;

                        87.226.135.0/24;

                        87.226.136.0/24;

                        87.226.137.0/24;

                        87.226.138.0/24;

                        87.226.139.0/24;

                    }

                }

                then { 

                    discard;

                }

            }

            term RTK_IPMPLS_MGMT {

                from {

                    address {

                        87.226.129.0/24;

                        87.226.131.128/27;

                        10.0.0.0/8;

                    }

                }

                then {

                    discard;

                }

            }

            term default-action {

                then accept;

            }

        }

    }

          С целью защиты коммутирующих устройств узла:

    • протокол VTP (VLAN Trunking Protocol) на коммутаторах переводится в режим transparent;
    • приём и передача пакетов Spanning Tree Protocol (STP) запрещается на портах, к которым подключены клиенты;
    • защита от перегрузки интерфейса между маршрутизатором и коммутатором излишним трафиком осуществляется путём ограничения скорости входящего трафика на порту подключения клиента;
    • для предотвращения перегрузки таблицы MAC адресов коммутатора на интерфейсах подключения клиентов настраивается механизм Port Security, позволяющий коммутатору заучить не более определённого количества MAC адресов на этом порту;
    • производится ограничение трафика broadcast/multicast/unknown unicast на интерфейсах подключения клиентов (storm control);
    • не применяются протоколы автоматического обнаружения на уровне 2 (CDP, LLDP, LLDP-MED).

          Соответствующие настройки коммутаторов описаны в разделе «8 Принципы настройки агрегирующих коммутаторов».

  • Софт для угона IP трафика через BGP

    Софт для угона IP трафика через BGP

     

    Специалисты по IT-безопасности Антон Капела и Алекс Пилосов разработали методику, с помощью которой можно тайно перехватывать интернет-трафик и даже модифицировать его на пути к адресату.

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

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

    Возможность перехвата BGP-сессии присутствует на любом роутере
    Специалисты Капела и Пилосов показали на конференции DefCon, каким образом можно перехватить трафик, направляющийся в сеть конференции, и переправить его в контролируемую ими систему в Нью-Йорке, а затем доставить обратно.
    Необходимо отметить, что ранее перехватывать интернет-трафик, используя уязвимость BGP, были способны только разведывательные агентства.

    В настоящее время технология угона ip трафика через bgp стала доступна всем благодаря использованию пакета Loki, который работает на платформе Windows x64.

  • Модель сетевого взаимодействия OSI — Open Systems Interconnection

    Модель сетевого взаимодействия OSI — Open Systems Interconnection

    Модель ISO/ OSI предполагает, что все сетевые приложения можно подразделить на семь уровней, для каждого из которых созданы свои стандарты  и общие модели. В результате задача сетевого взаимодействия делиться на меньшие и более легкие задачи, обеспечивается совместимость между продуктами разных производителей и упрощается разработка приложений за счёт создания отдельных уровней и использования уже существующих реализаций.

    Open Systems Interconnection - Модель OSI

    Теоретически, каждый уровень должен взаимодействовать с аналогичным уровнем удаленного компьютера. На практике каждый из них, за исключением физического, взаимодействует с выше – и нижележащими уровнями – представляет услуги вышележащему и пользуется услугами нижележащего. В реальной ситуации на одном компьютере независимо друг от друга иногда выполняется несколько реализаций одного уровня. Например, компьютер может иметь несколько сетевых адаптеров стандарта Ethernet или адаптеры стандартов Ethernet и Token-Ring и.т.д.

    Физический уровень
    Физический уровень описывает физические свойства (например, электромеханические характеристики) среды и сигналов, переносящих информацию. Это физические характеристики кабелей и разъемов, уровни напряжений и электрического сопротивления и.т.д., в том числе, например, спецификация кабеля «неэкранированная витая пара» (unshielded twisted pair, UTP)
      
    Канальный уровень
    Канальный уровень обеспечивает перенос данных по физической среде. Он поделен на два подуровня: управления логическим каналом (logical link control, LLC) и управления доступом к среде (media access control, MAC). Такое деление позволяет одному уровнюLLC использовать различные реализации уровня MAC. Уровень MAC работает с применяемым в Ethernet и Token—Ring физическими адресами, которые «вшиты» в сетевые адаптеры их производителями. Следует различать физические и логические (например, IP) адреса. С последним работает сетевой уровень.
    Сетевой уровень
    В отличии от канального уровня, имеющего дело с физическими адресами, сетевой уровень работает с логическими адресами. Он обеспечивает подключение и маршрутизацию между двумя узлами сети. Сетевой уровень предоставляет транспортному уровню услуги с установлением соединения (connection—oriented), например Х.25, или без установления такового (connectionless) например IP (internetprotocol). Одна из основных функций сетевого уровня – маршрутизация.
    К протоколам сетевого уровня относиться IP и ICMP (Internet Control Massage Protocol).
    Транспортный уровень
    Транспортный уровень предоставляет услуги, аналогично услугам сетевого уровня. Надежность гарантируют лишь некоторые (не все) реализации сетевых уровней, поэтому ее относят к числу функций, выполняемых транспортным уровнем. Транспортный уровень должен существовать хотя бы потому, что иногда все три нижних уровня (физический, канальный и сетевой) предоставляет оператор услуг связи. В этом случае, используя соответствующий протокол транспортного уровня, потребитель услуг может обеспечить требуемую надежность услуг. TCP (Transmission Control Protocol) – широко распространенный протокол транспортного уровня.
    Сеансовый уровень
    Сеансовый уровень обеспечивает установление и разрыв сеансов, и управление ими. Сеанс – это логическое соединение между двумя конечными пунктами. Наилучший пример этой модели – телефонный звонок. При наборе номера Вы устанавливаете логическое соединение, в результате на другом конце провода звонит телефон. Когда один из собеседников говорит «аллё», начинается передача данных. После того как один из абонентов вешает трубку, телефонная компания выполняет некоторые действия для разрыва соединения. Сеансовый уровень следит также за очередностью передачи данных. Эту функцию называют «управление диалогом» (dialog management). Вот примеры протоколов сеансового, представительного и прикладного уровней –SMTP (Simple Mail Transfer Protocol), FTP (File Transfer Protocol) и Telnet.
    Представительный уровень
    Представительный уровень позволяет двум стекам протоколов «договариваться» о синтаксисе (представлении) передаваемых друг другу данных. Поскольку гарантий одинакового представления информации нет, то этот уровень при необходимости переводит данные из одного вида в другой.
      
    Прикладной уровень
    Прикладной уровень – высший в модели ISO/ OSI. На этом уровне выполняться конкретные приложения, которые пользуются услугами представительного уровня (и косвенно – всех остальных). Это может быть обмен электронной почтой, пересылка файлов и любое другое сетевое приложение.
    Таблица 1. модель ISO/ OSI и некоторые протоколы соответствующих уровней.
    ПРИКЛАДНОЙ УРОВЕНЬ
    SMTP (Simple Mail Transfer Protocol), FTP (File Transfer Protocol)
    ПРЕДСТАВИТЕЛЬНЫЙ УРОВЕНЬ
    СЕАНСОВЫ УРОВЕНЬ
    ТРАНСПОРТНЫЙ УРОВЕНЬ
    TCP AND UDP
    СЕТЕВОЙ УРОВЕНЬ
    IP, ICMP, ARP
    КАНАЛЬНЫЙ УРОВЕНЬ
    IEEE 802.3
    Ethernet
    ФИЗИЧЕСКИЙ УРОВЕНЬ
      
  • Скачать CiscoWorks • Скачать Cisco Prime LAN Management Solution 4.1 для Windows

    Скачать CiscoWorks • Скачать Cisco Prime LAN Management Solution 4.1 для Windows

    Пакет CiscoWorks LAN Management Solution (LMS) содержит набор средств управления, необходимых для упрощения развертывания, администрирования, мониторинга и диагностики различных кампусных инфраструктур от Cisco.

    CiscoWorks LAN Management Solution

    Используя общие централизованные системы и сведения о сети, CiscoWorks LAN Management Solution предоставляет уникальный набор функций, позволяющих снизить время развертывания сети и расходы на администрирование.

    Основные свойства Cisco LMS:

    • Надежный набор средств уровня 2 для обнаружения устройств и подключений, детализированной визуализации топологии, настройки услуг уровня 2 и отслеживание оконечных станций, облегчающее настройку, управление и понимание физической и логической сетевой инфраструктуры.
    • Представление сетевых устройств на основе графического пользовательского интерфейса с отображением в реальном времени динамических данных о состоянии позволяет упростить диагностику и устранение неисправностей устройств.
    • Обнаружение неисправностей в реальном времени, функции анализа и отчета, использующие подробные сведения об устройствах и правила поиска неисправностей, основанных на лучших методах компании Cisco.
    • Упрощенные задачи администрирования, требующие меньших затрат времени, и централизованное управление сетью с помощью управления заменой устройств, сетевой конфигурацией и образами программного обеспечения, доступность сети и анализ неисправностей.
    Cisco prime

    CiscoWorks LMS состоит из следующих программных компонентов:

    • CiscoWorks Common Services — базовая платформа, осуществляющая общее управление интеграцией со сторонними системами сетевого управления, контроль административного доступа и сервисами для всего семейства решений CiscoWorks.
    • CiscoWorks LMS Portal — собственно, CMS сайта.
    • CiscoWorks Assistant — появился с версии 3.0, представляет собой набор визардов для первичной настройки компонентов.
    • Resource Manager Essentials (RME) — для управления критичными сетевыми ресурсами через Интернет с использованием web-интерфейса. Предоставляет набор инструментов для поиска и устранения неисправностей в сети, сбора детализированных отчетов, централизованного обновления программного обеспечения и конфигураций устройств, управления и конфигурации VPN, CallManager и др.
    • Internet Performance Monitor (IPM) — для анализа, оптимизации производительности и отладки неисправностей сетевых соединений на основе Cisco IP SLA.
    • CiscoView — графическое средство управления устройствами.
    • MiniRMON — инструмент для работы с RMON и RMON2.
    • Campus Manager (CM) — для обнаружения и управления L2/L3 устройствми, конфигурирования и управления VLAN и ATM LANE, а также определения подключения пользователей и IP телефонов.
    • Device Fault Manager (DFM) — обеспечивает обнаружение и определение причин сбоев сетевого оборудования в режиме реального времени.
    • Virtual Network Management (VNM) — появился с версии 3.2, занимается визуализацией топологии виртуальных сетей и их диагностикой, VRF.
    • Health and Utilization Monitor (HUM) — появился с версии 3.0.1, идёт как Add-On, требует отдельной лицензии. занимается сбором, отображением и мониторингом параметров производительности, уведомлением о превышении пороговых значений. Поддерживает только cisco-устройства, может мониторить до 1000 устройств.

    Все эти компоненты имеют свою нумерацию в рамках конкретной версии LMS, скачать Cisco Prime LAN Management Solution 4.1 для Windows