Чуточку ликбеза. Навеяно предшествующими копипастами разной чепухи на данную тему. Уж простите, носинг персонал.

IP-адрес (v4) состоит из 32-бит. Любой уважающий себя админ, да и вообще айтишник (про сетевых инженеров молчу) должен уметь, будучи разбуженным среди ночи или находясь в состоянии сильного алкогольного опьянения, правильно отвечать на вопрос «из скольки бит состоит IP-адрес». Желательно вообще-то и про IPv6 тоже: 128 бит.

Обстоятельство первое. Всего теоретически IPv4-адресов может быть:
2³² = 2¹⁰*2¹⁰*2¹⁰*2² = 1024*1024*1024*4 ≈ 1000*1000*1000*4 = 4 млрд.
Ниже мы увидим, что довольно много из них «съедается» под всякую фигню.

Записывают IPv4-адрес, думаю, все знают, как. Четыре октета (то же, что байта, но если вы хотите блеснуть, то говорите «октет» — сразу сойдете за своего) в десятичном представлении без начальных нулей, разделенные точками: «192.168.11.10».

В заголовке IP-пакета есть поля source IP и destination IP: адреса источника (кто посылает) и назначения (кому). Как на почтовом конверте. Внутри пакетов у IP-адресов нет никаких масок. Разделителей между октетами тоже нет. Просто 32-бита на адрес назначения и еще 32 на адрес источника.

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

Представляю пока две статьи, ориентированных на «продолжающих» системных администраторов, для опытных я вряд ли открою что-то новое.
В этих статьях мы рассмотрим построение интернет шлюза на linux, позволяющего связать несколько офисов компании, и обеспечить ограниченный доступ в сеть, приоритезацию трафика (QoS) и простую балансировку нагрузки с резервированием канала между двумя провайдерами.
Конкретно в этой части:

• Простейшая настройка Shorewall
• Ужасно сложная настройка dnsmasq
• Не менее сложная настройка OpenVPN
• И для многих продолжающих админов нетипичная, динамическая маршрутизация, на примере OSPF

А во второй части будут рассмотрены:

• Более подробная настройка Shorewall
• Страшный и не понятный QoS
• Балансировка нагрузки и резервирование

В третьей части:

• QoS во всю ширь в Shorewall
• Более подробная настройка Shorewall
• Раскидывание трафика по каналам в соответствии с протоколами
• Костыли, без них, никуда

В четвертой части:

• Автоматические события
• Макросы

Представляю вторую статью из серии, ориентированных на «продолжающих» системных администраторов, для опытных я вряд ли открою что-то новое.
В этих статьях мы рассмотрим построение интернет шлюза на linux, позволяющего связать несколько офисов компании, и обеспечить ограниченный доступ в сеть, приоритезацию трафика (QoS) и простую балансировку нагрузки с резервированием канала между двумя провайдерами.
Конкретно в этой части:

• Более подробная настройка Shorewall
• Страшный и не понятный QoS
• Балансировка нагрузки и резервирование

А в предыдущей части были рассмотрены:

• Простейшая настройка Shorewall
• Ужасно сложная настройка dnsmasq
• Не менее сложная настройка OpenVPN
• И для многих продолжающих админов нетипичная, динамическая маршрутизация, на примере OSPF

В третьей части:

• QoS во всю ширь в Shorewall
• Более подробная настройка Shorewall
• Раскидывание трафика по каналам в соответствии с протоколами
• Костыли, без них, никуда

В четвертой части:

• Автоматические события
• Макросы

Я очень долгое время ходил вокруг NOC и облизывался на него, как та лиса на виноград. Ставил, тыкался и бросал. А потом снова возвращался, ибо прельщал подлец своими возможностями. И понимание того, что именно его не хватает в жизни для «щастья» в конце концов заставило зажать нервы в узду и взяться за NOC всерьез.

Если кто-то еще не знает что такое noc project, то это центр управления сетевой инфраструктурой. Программа позволяет организовать контроль за сбоями, слежение за производительностью, активацию сервисов, ведение базы знаний, управление адресным пространством, управление виртуальными сущностями (VLAN, DLCI), архивирование и ведение базы конфигураций, обеспечение работы DNS, генерацию отчетов. Вот тут можно про него почитать, офигеть от его крутости и вернуться сюда. А конкретно здесь я чуть-чуть расскажу про особенности установки, немного коснусь темы добавления оборудования, слегка углублюсь в вопросы его настройки, пробегусь по некоторым функциям этого программного комплекса и закончу на чем-нибудь позитивном или не очень. Как получится :)

На Гиктаймс уже не раз и не два размещались статьи про сборку своего домашнего NAS/медиа-сервера/ТВ-приставки и тому подобных произведений чешущихся и относительно прямых рук. Для тех, кто любит подобное рукоблудие, или планирует сам заняться таковым, ниже представлена еще одна вариация на эту тему.

В течении многих лет мы, ввиду специфики работы, постоянно сталкиваемся с необходимостью съема FDB-таблиц (Forwarding DataBase) управляемых коммутаторов с данными о коммутации MAC-адресов абонентов и устройств. За это время мимо нас прошли несколько сотен различных моделей устройств многих производителей, а количество версий их прошивок сложно сосчитать. Накопив опыт – можно им и поделиться.

В данном случае затронем лишь тему съема требуемых данных по SNMP-протоколу.

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

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

Считаю, что динамическая маршрутизация именно в данной задаче работала бы не так быстро и вероятно надежно, как того требует проект. Ничего не имею против динамической маршрутизации, но негативные отзывы о работе ее на оборудовании MikroTik и некоторая специфика сети (об этом ниже), повлияли на выбор в сторону статики и скриптов.

В недавнем прошлом в связи с переходом с ADSL на Ethernet представилась отличная возможность попробовать оборудование от Mikrotik. В связи с чем был куплен роутер RB750GL. Железка оказалась превосходной как внешне, так и с точки зрения функционала и надёжности.
В итоге у меня осталось оба канала и было решено настроить резервирование с автоматическим переключением. Стандартные средства переключения шлюзов не покрывают всё многообразие сбоев, поэтому нужно писать свои скрипты.

Хочу поделиться своим скриптом бэкапа конфигурации и отсылки логов на почту с Mikrotik RouterBoard RB750GL (в моём случае 5.14, firmware 2.38). Думаю подойдёт к большинству устройств на этой славной ОС. Преимущество подхода в том, что сам файл конфигурации приходит в качестве приложенного к письму с логами файла. А логи находятся прямо в письме — не в приложении.

Наверно тот у кого доступ в интернет осуществляется по ADSL заглядывал в настройки модема и натыкался на параметры vpi/vci. Впервые с ними столкнувшись возникает резонный вопрос «что это и для чего?» В этой статье я решила рассказать немного подробнее о том как осуществляется доступ по технологии ADSL, про PPPoE и конечно же про параметры vpi/vci.

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

Многие из вас наверняка заметили, что я пишу книгу о Zend Framework. Недавно я закончил черновики двух глав: «Архитектура приложений на Zend Framework» и «Понимая Zend Framework». В первой главе объясняется архитектурный шаблон Model-View-Controller (MVC) и причины, по которым он стал стандартом де-факто для веб-приложений. Во второй исследуется связь MVC с компонентами Zend Framework, их структурой и взаимодействием.

Завершив обе главы я осознал, что большую часть времени описывал модель и ее фактическое отсутствие в Zend Framework. На самом деле ни один веб-фреймворк не предлагает нам полноценную модель (по причинам, которые я объясню чуть позже). И ни в одном из них не дается внятного объяснения этому обстоятельству. Вместо этого они последовательно связывают понятие модели с родственным, но не идентичным понятием доступа к данным, что изрядно всех запутывает.

Эта сторона фреймворков никогда не привлекала особого внимания. И все же именно она лежит в основе целого класса проблем в тех приложениях, которые пытаются использовать MVC по образу и подобию фреймворков для веб-приложений. Более того, попытки донести идею модели до других разработчиков нередко напоминают битье головой о стену. Я не хочу сказать, что все разработчики тупые или не понимают саму идею, просто никто из них (вне зависимости от того, работают они с PHP или нет) не связывает модели с той областью, которая наделяет их смыслом — принципами объектно-ориентированного программирования.

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

Итак, начнем. Для начала свяжем центр с первым филиалом с использованием IPSEC.

В этой статье я бы хотел привести примеры настройки NAT на ОС FreeBSD и провести некоторое сравнение способов, которые, по моему мнению, наиболее часто используются.

Для начала:
NAT (от англ. Network Address Translation — «преобразование сетевых адресов») — это механизм в сетях TCP/IP, позволяющий преобразовывать IP-адреса транзитных пакетов. Также имеет названия IP Masquerading, Network Masquerading и Native Address Translation.

Рассмотренные варианты:
— Демон Natd
— IPFilter (ipnat)
— PF nat
— ng_nat
— ipfw nat (kernel nat)

Знание некоторых принципов легко возмещает незнание некоторых фактов.
Гельвеций

Оптические трансиверы

В настоящее время применение оптических технологий при построении телекоммуникационных сетей стало практически повсеместным. Каждый, кто имел дело с оптическим коммутационным или передающим оборудованием, сталкивался с работой оптических приемо-передающих устройств – трансиверов (англ. transceiver = transmitter + receiver).

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

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

Если коротко, схема такая. Атакующий внедряется в сеть сигнализации SS7, в каналах которой отправляет служебное сообщение Send Routing Info For SM (SRI4SM), указывая в качестве параметра телефонный номер атакуемого абонента А. В ответ домашняя сеть абонента А посылает атакующему некоторую техническую информацию: IMSI (международный идентификатор абонента) и адрес коммутатора MSC, который в настоящий момент обслуживает абонента.



Далее атакующий с помощью сообщения Insert Subscriber Data (ISD) внедряет в базу данных VLR обновленный профиль абонента, изменяя в нем адрес биллинговой системы на адрес своей, псевдобиллинговой системы.

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

Вторая часть

С чего всё начиналось

Я работаю в небольшой фирме, которая разрабатывает и производит системы записи телефонных разговоров. Но в ряде случаев клиентам нужен аналоговый GSM шлюз как источник телефонной линии. Ранее его закупали и перепродавали. Но то что закупали было низкого качества и часто попадался брак — было принято решение самим разработать. Разработали мы вдвоём: схемотехник и я — программист, недавние выпускники без опыта разработок в аналоговой телефонии и без опыта внедрения в производства. Получилось, мягко говоря, не очень, хоть и была решена проблема брака и скорее «вопреки».

Но проблема в том, что для нас даже 1% брака недопустим: на каждый случай у тех поддержки и разработчиков уходило очень много времени на клиента. Да и для всех нас это недопустимо чисто из соображений профессиональной гордости. Мы хотели такой шлюз снять с производства, даже несмотря на то, что у нас была доля от каждого изделия. Это очень стыдно, когда дилеры про остальные изделия говорят: «у вас вообще брак бывает?», а про наши «мы боимся их продавать — у нас же потом ничего не купят».

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



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

Уфа – один из крупнейших экономических, промышленных и научных центров нашей страны, обладающий обширным историческим, культурным и спортивным наследием. В июле 2015 г. в Уфе проходили международные саммиты ШОС и БРИКС.


Конгресс-холл заседаний международных делегаций ШОС и БРИКС в Уфе

На мероприятии необходимо было обеспечить бесперебойную мобильную связь технологий 4G, 3G, 2G. Используя накопленный опыт и применяя различные технические решения, нам предстояло развернуть покрытие мобильной связи на всех новых объектах саммитов. Я отвечал за организационную и техническую части этого интенсивного проекта.

«Протон» с Экспресс-МД1 и Экспресс АМ44 на борту

Наша спутниковая сеть пережила несчитанное количество мелких сбоев и аномалий в работе спутников. Экспресс-2 (отказ двигателей коррекции), Экспресс-АМ11 (разгерметизация), KazSat-1 (отказ системы управления), Экспресс-АМ2 (отказ системы поворота солнечных батарей), NSS-703 (полная выработка «рабочего тела» двигателей точной коррекции)… И да, Экспресс-МД1.

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

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

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