Одминский блог

Настройка IP в CentOS

Настраивал себе систему в VmWare Player, после чего перенесли её на ESX Server, ну и по пути возникла необходимость, из дома, сменить на системе IP адрес и повесить дополнительный алиас на интерфейс. Поскольку настраивал центосину до этого исключительно из окошек Х, пришлось немного поморщить голову, но после прочтения официального мануала, все оказалось проще некуда.

Смена IP производится следующим образом:
Открываем файлец /etc/sysconfig/network-scripts/ifcfg-eth0 и смотрим что мы в нем имеем:

DEVICE=eth0
BOOTPROTO=dhcp
HWADDR=00:0C:29:BC:B7:60
ONBOOT=yes

Собственно как понятно из файла- IP адрес он цепляет от DHCP сервера, хотя мне казалось что я его задавал лапками, поэтому отрубаем DHCP и меняем настройки на:

DEVICE=eth0
BOOTPROTO=static
HWADDR=00:0C:29:BC:B7:60
ONBOOT=yes
DHCP_HOSTNAME=crm_security.lan
IPADDR= новый_IP_адрес
NETMASK=255.255.255.0
GATEWAY= новый_шлюз
TYPE=Ethernet

После перезагрузки машины или рестарта сетевых служб, с помощью команды service network restart , система переподхватит новый IP адрес.

Теперь по поводу алиасов- там же где мы правили файло с сетевыми настройками, создаем файлик ifcfg-<if-name>:<alias-value> Единственно что надо учесть тот момент что алиас не может цеплять свой адрес по DHCP, поэтому следует задавать статический адрес, для чего создаем файл /etc/sysconfig/network-scripts/ifcfg-eth0:0 и в него прописываем следующие строки:

DEVICE=eth0:0
ONBOOT=yes
BOOTPROTO=static
IPADDR=алиас_IP
NETMASK=255.255.255.255

Если нужно добавить пул алиасов, скажем от 192.168.10.1 до 192.168.10.200, то сделать это можно либо создав 200 конфигурационных файлов для алиаса, либо описав весь пул адресов, для чего создадим файл /etc/sysconfig/network-scripts/ifcfg-eth0-range0 и внесем в него следующие строки:

IPADDR_START= 192.168.10.1 # первый IP в пуле
IPADDR_END= 192.168.10.200 # последний IP в пуле
NETMASK=255.255.255.255
CLONENUM_START=1 # число <alias-value> с которого будет начинаться пул
NO_ALIASROUTING=yes

Рубрика: Linux | Ваш отзыв »

Ускоряем разрешение доменных имен через resolve.conf

Системный файл /etc/resolv.conf является файлом конфигурации процедур сервера доменных имен. В этом файле хранится информация об используемых DNS серверах, и этот файл перечитывается при вызове процедуры разрешения имен. В файл можно поместить информацию о трех DNS серверах, причем алгорит действия будет таким, что запрос всегда уходит на стоящий первым в списке сервер. В случае если он не отвечает в течении некоторого времени (по умолчанию 5 секунд), то запрос отправляется на вторичный сервер DNS, если он не отвечает, то запрос переходит к третичному серверу DNS. То есть по умолчанию система всегда использует первый из списка сервер, и обращается ко второму и третьему только в случае, если первичный сервер не отвечает.

Но в версии BIND 8.2 были добавлено некоторое количество новых опций, с помощью которых мы можем несколько ускорить работу разрешения доменных имен для нашего сервера:

Опиция timeout позволяет задавать время таймаута для присутствия в очереди запросов. По умолчанию этот параметр равен 5 секундам (максимально 30), так что если мы хотим ускорить отработку запроса, то выставляем этот параметр например на 2 секунды:
options timeout:2

Опция rotate позволяет использовать из списка доменных серверов все адреса, а не только первый, который может быть перегружен многочисленными запросами. Причем вторичный и третичный сервера используются только в случае отказа в обслуживании первого сервера. Поэтому с помощью этой опции мы можем разгрузить первичный сервер и отправить часть запросов на остальные сервера, указанные в resolve.conf
options rotate

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

Опираясь на все вышесказанное, resolve.conf  будет иметь следующий вид:

nameserver 1.1.1.1
nameserver 2.2.2.2
nameserver 3.3.3.3
option rotate
option timeout:2

Рубрика: Интернет | Ваш отзыв »

Перепрошиваем свич HP ProCurve

На старой работе возникла проблема с HPшными свичами ProCurve 2XXX серий, которые  закупал лет 6 назад. С месяц назад у ребят началась какая то свистопляска с портами и дуплексами, в связи с чем решили мы их перепрошить. Операция не сложная, но долгая по времени и довольно стремная, ибо система строилась на века, поэтому возникает опасение, что все транки и VLAN могут послетать если что то пойдет не так.

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

Начиная с версии прошивки I.08.74 устройство не поддерживает FEC trunks (Cisco Systems’ Fast EtherChannel for aggregated links) и CDP (Cisco Discovery Protocol). Вместо них введены, базирующиеся на IEEE стандарте, протокол LACP aggregated links (предназначенный как раз для организации транков) и протокол LLDP для оповещения по сети и сбора информации о соседних устройствах.

Для апргейда до актуальной версии прошики I.10.xx необходимо иметь как минимум версию I.08.07, если она ниже, то сначала обновляемся до неё, после чего вторым обновлением поднимаем прошивку до I.10.xx. Версия промежуточной прошивки может отличаться у разных моделей.

Конфиги созданные с помощью прошики I.10.65 или новее, не поддерживаются предыдущими версиями прошивок, так что в случае варианта даунгрейда устройства, все придется настраивать заново.

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

Перепрошить дейвайс можно двумя способами: через XMODEM соединение, и загрузкой с TFTP сервера. Работу с TFTP я рассмотрю позднее, ибо она требует настроить TFTP сервер, а пока попробуем перепрошить с помощью соединения  XMODEM. Сам XMODEM является простейшим протоколом передачи данных и отлично зарекомендовал себя еще на BBSках в далеких 70х годах. Не буду вдаваться в его подробности, ибо кому интересно тот почитает сам, а перейду сразу к нашей процедуре. Итак для перепрошивки нам необходим сам файл прошивки, скаченный с офф.сайта; стандартный RS-232 кабель  “мама-мама” и компьютер с com-портом, или, в связи с тем, что сейчас найти такой компьютер практически нереально, переходник usb-serial. Подключаемся к свичу с помощью встроенного терминала Windows (пуск -> стандартные -> связь -> HyperTerminal) со стандартными параметрами: 9600 без управления потоком, дважды щелкаем Enter и мы в строке управления CLI. Для начала нам надо перевести терминал на более высокую скорость, ибо загрузка имиджа на 9600 будет идти почти полтора часа. Для этого говорим:
# configure
# console baud-rate 115200
После чего перегружаем свич и подключаемся уже с использованием указанной скорости
Даем команду  # menu и в загрузившимся меню выбираем Download OS и выставив XMODEM говорим execute (также можно сделать это прямо из CLI задав команду # copy xmodem).  После этого нажимаем ентер и задаем отправку файла через терминал:  выбираем Передача -> Отправить файл, во вкладке Протокол выставляем XMODEM и выбираем необходимый файл прошивки.Минут 10-15 файл закачивается после чего перегружаем свич. Процесс первой загрузки будет идти несколько дольше чем обычно, так что не стоит начинать кусать локти раньше времени.

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

Рубрика: Оборудование | Ваш отзыв »

Checkpoint Secure Client VPN для 64битных Windows 7

После анонсирования новой системы Windows 7, вскрылась новая проблема, на которую никто не обращал внимания до этого, не смотря на то, что она уже была озвучена применительно еще к системам Vista: на 64-битных системах Windows Vista/7 невозможно использование IPSEC VPN клиента от Checkpoint – Secure Client, с помощью которого удаленный хост может подключаться к шлюзам Connectra, VPN-1, UTM-1 и Power-1 используя протоколы стандарта IPSEC. Это продукт отлично себя зарекомендовал на большинстве систем Microsoft и Mac, но к сожалению, после установки на 64-битную систему, пакет Secure Client не запускается в принципе, так что использование его невозможно.

И вот здесь начинается некоторая непонятка, ибо Checkpoint обещает выпуск обновленного полнофункционального VPN клиента Secure Client, поддерживающего 64битные системы, только в конце второго квартала, и на данный момент предлагает два вида решения: использование облегченного VPN клиента Endpoint Connect (он также интегрирован в продукт Endpoint Security Client R73), входящего в комплект Connectra, но при этом поддерживающего соединение со шлюзами, начиная от NGX R65 HFA40. В данный момент единственная версия клиента  Endpoint Connect, поддерживающая 64битные системы, является  Endpoint Connect R73, который дает возможность подключения к системам выше R65 HFA40 и Connectra R66.

Для использования этой версии клиента также необходимо произвести апгрейд поддержки Endpoint Connect на шлюзах, путем установки установки патча поддержки R73. Последняя актуальная версия клиента Endpoint Connect, а также патч для шлюза VPN-1 и портала Connectra доступны для скачивания на офф.сайте Checkpoint.

Лицензируется использование этого продукта в виде Check Point Endpoint Security – Secure Access license, путем приобретения лицензии на удаленное рабочее место, то есть если два пользователя работают с одной машины, то нужна всего одна лицензия, если же один пользователь предполагает работать с двух разных машин, то две лицензии.

Другим вариантом использования VPN клиента на 64битныхз платформах, является использование продукта SSL Network Extender (SNX) для построения шифрованного туннеля 3го уровня SSL VPN. Версия SNX R71 HFA1 for Windows поддерживает 64битные платформы Windows 7/Vista/XP. Этот клиент скачивается с портала Check Point Security Gateways по запросу пользователя, пытающегося установить шифрованное соединение через протокол HTTPS. Продукт поддерживает шлюзы, начиная с версии NGX R60 и выше. Для использования версии R71, на шлюзах также должен быть установлен патч поддержки этой версии, который можно скачать на офф.сайте Checkpoint.

Лицензируется использование данного продукта путем приобретения лицензии SNX (на определенное количество пользователей: 25, 100, 250 и т.д) или также Check Point Endpoint Security – Secure Access license, которая приобретается по количеству удаленных рабочих мест.

Так что все разговоры о том, что Endpoint Connect поддеривается только VPN порталом Connectra либо развод на лишние, причем не малые, бабуськи, либо просто незнание материала.

Рубрика: Check Point | Ваш отзыв »

Баг прошивки 8.0.42 для Sofaware 500W

Прекрасную новость я получил буквально пару минут назад от компании Sofaware, куда я обратился со своей “болью”: после того как устройство Sofaware 500W само, без разрешения, грейдилось на последнюю версию прошивки 8.0.42- сразу же начинались траблы с работоспособностью- по дефолтной политике дропались входящие UDP пакеты на 53 порт, даже в случае наличия правила разрешающего это действие; пропадал доступ к веб морде из вне сетки по https; и самое пакостное- после перевода wi-fi и Lan VLAN’ов в режим bridge, для того чтобы пользователи этих двух сетей могли работать друг с другом и внутренними ресурсами (хотя по причине этого косяка, выяснилось что все это реализуется и при обычном режиме firewall просто описанием взаимодействия подсетей)- начинались проблемы с доступам к внутренним ресурсам, транслируемым в интернет, по их внешним IP адресам, причем настолько сильные, что все соединения smtp/pop3/http/https/ssh дропались по таймауту.

Вообщем ответ тех.поддержки был, что shit happend- сие есть баг (баг заключается в том, что дропаются те пакеты у которых исходящий порт такой же как и входящий- 53; если же порт стандартно выше 1024 порта, то они проходят нормально), посему надо откатить устройство на более раннюю версию прошивки, но как оказывается сам я это сделать не могу, а это указывается ручками на стороне сервис центра производителя SMP, где оператор ручками указывает какому MAC адресу на какую прошивку перегрузиться. Но самое веселое, что это уже сделали, попросив меня ручками передернуть устройство. И мало кого волнует, что я в 50 километрах от устройства и самое близкое когда собирался туда заехать – это конец недели.

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

*** 23.12.09 *** Баг после отката не исчез, по прежнему дропаются входящие и исходящего 53 порта, но зато разрешилась проблема с доступом по https к консоли. Оказалось, что сервер https, для внешних подключений, переехал со своего стандартного порта на 981, т.к. обращение https://server:981 позволяет достучаться к серверу из вне.

Рубрика: Check Point, Оборудование | Ваш отзыв »

SMB уязвимость в Windows 7

Радостная новость в стане мелкомягких, не успела появиться Windows 7, как обнаружилась DoS уязвимость, причем не абы где, а в самом сердце операционки: она базируется на реализации протокола Microsoft Server Message Block (SMB). Этой уязвимости подвержены серверные платформы Server 2008 и Windows 7, причем для последних это является первой зарегистрированной уязвимостью 0-дня (zero-day).

SMB – это протокол совместного межсетевого использования файлов (ненавижу переводить английскую терминологию) который входит в Microsoft Windows. Уязвимость вызывает ошибку SMB при обработке специально сконфигурированного SMB-пакета. Удаленный злоумышленник может использовать данную уязвимость через специально созданный особым образом сетевой пакет. Удачное использование уязвимости приведет к отказу в обслуживании атакуемой машины и её зависанию, вплоть до ручной перезагрузки системы. Данную уязвимость невозможно использовать для перехвата контроля или установки злонамерного программного обеспечения на атакуемую систему.

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

Рубрика: IT безопасность, Windows | Ваш отзыв »

Ищу аппаратный шейпер

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

Первое, что пришло в голову это воспользоваться стандартной функцией управляемого свича Bandwidth Control , то есть ограничение скорости по порту- наиболее дешево и сердито, но как оказалось, например для имеющихся у клиентов HP ProCurve 2ХХХ серии данный функционал оказался недоступен, после чего погрузился в интернет с ключевым словом шейпер и bandwidth control . Варианты типо checkpoint не рассматривались, поскольку в первом приближении нужен был недорогой и простой аппаратный шейпер, хотя они и присутствуют начиная с safe@office в составе QoS, но устройства начального уровня мне не подходят, поскольку safe@office держит до 50-70 пользователей, а остальные начинаются от трешки зелени.
В результате нарыл некоторое количество моделек:

Для начала россыпью идут устройства от Planet: управляемый свич FGSW-2624SF и 8ми портовые гигабитники GSD-802PS / GSD-802S

почти в этом же ключе, хотя мне нравятся меньше, маршрутизаторы D-Link DGS-3610-26 / DI-1137C-1TP

какой то не понятный, но близкий сердцу названием маршрутизатор TP-Link TL-R480T

вроде как поддерживают большинство маршрутизаторов и рутеров от Linksys WRT310N / EZXS55W / EZXS88W / EZXS16W / WET610N / WRT160N / WRT610N / WRT110 но надо вчитываться в каждое дополнительно

как более дорогой аналог: Cisco Catalyst 3500  (команда Rate Limiting)

ну и наколенные варианты Zyxel P-334WT EE которые я не очень лю, поскольку уже имел опыт неприятной работы с их оборудованием

Вариант с Planet мне понравился больше всего, поскольку пользовался ими длительное время и никаких нареканий на их оборудование не имею, кроме разве что слишком низкой цены но пораскинув немного мозгами, пришел к тому что не плохо было бы иметь на внешнем шейпере и ips с доступом к нефильтрованному трафику, поэтому вероятнее всего в ближайшее время буду настраивать шейпер под freebsd с прикрученным туда же snort’ом

Рубрика: Сети | Ваш отзыв »