Архив рубрики: Networks

Не открывается web-интерфейс HP 1910. Свитч не пингуется.

Если у вас достаточно крупная сеть и вы используете коммутаторы HP 1910, то вы тоже могли столкнуться с такой проблемой: в определенные моменты времени вы просто не можете открыть админку коммутатора и даже пинговать его не можете. Но при этом, с других компьютеров/серверов он вполне может открываться и пинговаться. И более того, если вы будете долго и упорно его пинговать — вам он тоже начнет отвечать! Причины этой, на первый взгляд непонятной проблемы, очень просты: у свичей HP 1910 очень маленькая ARP-таблица — 256 записей. Со временем, при работе в сети >256 хостов, она может заполниться на 100% и может случиться так, что ваш адрес туда не попадет.

Как это лечить:

  1. Для начала, необходимо все же попасть на свитч с какого-нибудь адреса (например, с DHCP-сервера — чаще всего запись о нем есть в ARP-таблице).
  2. Заходим в ARP-management и удаляем все динамические записи.
  3. Добавляем там же необходимые нам статические записи (например, IP-адрес и MAC того компьютера/сервера, с которого чаще всего осуществляется доступ к свичам). Полезно будет также добавить IP и MAC шлюза по умолчанию — это защитит от внезапного появления в сети еще одного шлюза (но в этом случае лучше еще и статическую запись MAC с привязкой к порту сделать).

После этого свитч всегда будет отвечать на ваши пинги и веб-интерфейс будет открываться без проблем.

Обновление прошивки HP 1910 через COM-порт

Иногда на коммутаторах HP 1910 бьются файлы прошивок. Чаще всего это, по всей видимости, происходит из-за износа флэш-памяти и в таких случаях программно ему уже не помочь. Но бывают случаи, когда он «просто почему-то побился» и коммутатор можно оживить путем форматирования флэш-памяти и заливки новой прошивки.

Для форматирования флэшки необходимо подключиться консольным кабелем, настроить соединение (38400, 8, 1, N) и нажать при загрузке Ctrl+B. Таким образом мы попадем в BootWare-меню. В нем необходимо нажать Ctrl+F и согласиться с форматирование флэшки. Желательно перед этим убедиться в наличии у вас свежей прошивки в виде файла *.bin :)

Далее перезагружаем коммутатор и снова входим в BootWare. На этот раз он сделает это сам — прошивки-то нет. В Bootware выбираем пункт 2 «Enter Serial SubMenu». Т.к. файл прошивки весит более 10 Мб — лучше переключить Serial-интерфейс на скорость 115200. Для этого жмём и снова 5 (пункт 115200). И тут настает время задуматься над тем, каким именно образом мы будем слать на него файл. Далеко не всё ПО умеет слать файлы в COM-сессию. Putty, например, такого не делает. Для этого придется найти старенький, но так необходимый HyperTerminal (последний раз он входил в комплект Windows XP). В нем создаем новое подключение, выбираем параметры 115200, 8, None, 1, None (см. скриншот).

Далее жмем «ОК» и подключаемся. Выходим на один уровень выше (пункт 0). И выбираем пункт 2 — Update Main Application File. Коммутатор переходит в режим приема файла, а мы нажимаем «Transfer»->»Send File», выбираем в окошке прошивку коммутатора и протокол Xmodem:

Отдыхаем минут 40 и по окончанию передачи на запрос коммутатора выдаем имя файла. После этого выходим на основной уровень меню, File Control (4), Display All Files (1). Проверяем, чтобы напротив нашего файла прошивки стоял флаг М.

После этого выходим в главное меню и загружаемся (1). Если флэшка умерла не совсем — коммутатор загрузится и будет работать еще долго.

Загрузка cisco 4000 в ROMMON.

В процессе различных экспериментов с версиями прошивок cisco ISR 4000 может возникнуть ситуация, когда девайс перестает реагировать на ваши действия (в т.ч. в консоли). Т.е. он вполне себе отображает процесс загрузки, на него можно даже по ssh зайти… Правда, после входа по ssh не появляется стандартного приглашения командной строки. Что делать и как жить дальше?

Все довольно просто. Надо подключиться консольным кабелем к циске, выключить ее секунд на 30, открыть com-порт, например, в PuTTY, включить девайс. После появления первых строк текста в консоли — надо нажать Break и дождаться прерывания процесса загрузки с появлением приглашения ROMMON. Выглядит это примерно так:

Initializing Hardware ...

System integrity status: 00000610
Rom image verified correctly


System Bootstrap, Version 15.4(3r)S5, RELEASE SOFTWARE
Copyright (c) 1994-2015 by cisco Systems, Inc.

Current image running: Boot ROM0

Last reset cause: PowerOn
Cisco ISR4331/K9 platform with 4194304 Kbytes of main memory


no valid BOOT image found
Final autoboot attempt from default boot device...
Warning: filesystem is not clean
Warning: filesystem is not clean
File size is 0x1bcc9bfc


monitor: command "boot" aborted due to user interrupt


rommon 1 >

Если нажатие кнопки Break не помогает, можете воспользоваться соответствующей командой из меню PuTTY (Special command -> Break)

После появления приглашения можно выполнить команду dir bootflash: для просмотра файлов прошивок на флэшке и загрузить нужный образ (тот, с которым все было хорошо) командами:

BOOT=bootflash:isr4300-universalk9_npe.03.16.02.S.155-3.S2-ext.SPA.bin

sync

confreg 0x2102

reset

В этом случае, isr4300-universalk9_npe.03.16.02.S.155-3.S2-ext.SPA.bin — это файл образа в памяти устройства.

Если при попытке просмотра файлов командой dir bootflash: у вас появляется сообщение «Please reset before continuing», то простой reset вам не поможет. Необходимо выполнить следующее:

confreg 0x0

reset

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

Уязвимость во всех версиях Joomla, позволяющая выполнить удаленно любой код (CVE-2015-8562)

Несколько дней назад была обнаружена уязвимость (CVE-2015-8562), которая затрагивает все версии Joomla, начиная с версии 1.5 и позволяет злоумышленнику удаленно выполнить любой код на сервере. Уязвимость возникла из-за недостаточной фильтрации информации о браузере (в частности, юзерагенте) при записи данных сессии в БД. Для актуальных версий Joomla уже доступен апдейт до версии 3.4.6, в котором уязвимость устранена. Если же вы пользуетесь версией 1.5 или 2.5, вам необходимо вручную заменить файл libraries/joomla/session/session.php на исправленный файл, который вы можете скачать отсюда: https://docs.joomla.org/Security_hotfixes_for_Joomla_EOL_versions

Также, можно по логам веб-сервера отследить пытались ли вас взломать. Для взлома, в строку юзер-агента записывается примерно следующее:

}__test|O:21:\x22JDatabaseDriverMysqli\x22:3:{s:2:\x22fc\x22;O:17:\x22JSimplepieFactory\x22:0:{}s:21:\x22\x5C0\x5C0\x5C0disconnectHandlers\x22;a:1:{i:0;a:2:{i:0;O:9:\x22SimplePie\x22:5:{s:8:\x22sanitize\x22;O:20:\x22JDatabaseDriverMysql\x22:0:{}s:8:\x22feed_url\x22;s:60:\x22eval(base64_decode($_POST[111]));JFactory::getConfig();exit;\x22;s:19:\x22cache_name_function\x22;s:6:\x22assert\x22;s:5:\x22cache\x22;b:1;s:11:\x22cache_class\x22;O:20:\x22JDatabaseDriverMysql\x22:0:{}}i:1;s:4:\x22init\x22;}}s:13:\x22\x5C0\x5C0\x5C0connection\x22;b:1;}\xF0\x9D\x8C\x86"

Таким образом, примерная строка для поиска в логах будет выглядеть как  __test|O:

Этого вполне достаточно для того, чтобы отсеять все правильные юзер-агенты и запросы от попыток эксплойта.

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

Блокировка торрентов, скайпа на windows-машинах «дешёвым» методом

Торренты в корпоративной сети с одним выходом в интернет — зло. При отсутствии жестоких ограничений на количество коннектов и ограничений скорости, они могут сильно повлиять на работу интернета у остальных сотрудников. В интернете достаточно информации о блокировке торрентов на самом разном железе/софте и самыми разными способами: начиная от подробного анализа пакетов и заканчивая простой блокировкой динамических UDP и TCP портов (>1024). Ни один из способов не дает стопроцентной гарантии, кроме, возможно, использования маршрутизатора Cisco, или аналогов. Проверить их вживую пока не удалось. Все способы, так или иначе, реализуются только на шлюзе. А если посмотреть на проблему с другой стороны?…

После довольно долгого периода наблюдения за сетевым трафиком и приложениями в локальной сети, я понял, что сотрудники в 99% случаев слишком ленивы, чтобы использовать клиенты-торрентокачалки, отличные от utorrent. Именно этот факт позволяет легко отсечь 99% трафика торрентов. По крайней мере, он позволяет вовремя обнаружить и ограничить такой трафик. И реализуется он при помощи групповых политик. Создаем новую групповую политику и открываем в дереве следующий путь: Computer configuration -> Windows Settings-> Policy-based QoS

Policy-based QoS

Кликаем правой кнопкой по Policy-based QoS и выбираем пункт «Create new policy». Вводим имя новой политики и назначаем любое, отличное от нуля, значение DSCP (например, 1):

Policy-based QoS{tip}Лучше использовать «невалидные» с точки зрения DSCP значения, иначе можно попасть на софт, который маркирует свой «правильный» трафик теми же значениеями.{/tip}

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

На следующем экране выбираем «Only applications with this executable name:» и вводим utorrent.exe (или skype.exe, если вы хотите обнаруживать трафик скайпа):

Policy-based QoS

На следующем экране оставляем все по умолчанию:

Policy-based QoS

Далее выбираем протоколы TCP и UDP и завершаем создание правила:

Policy-based QoS

После этого, трафик от процесса utorrent.exe будет маркироваться DSCP флагом «1» и его легко будет обнаружить на любом шлюзе. Действия же, по факту обнаружения, будут зависеть от внутренних политик компании — блокировать или просто наказывать за нарушение полиси.