Server for home lab - HP Proliant DL360 G5 - Complete installation.

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

Требования и выбор

Итак, постановка задачи при выборе сервера:

  1. Максимальное соотношение цена/кечество.
  2. Возможность установки 2х процессоров. Процессоры строго Intel, так как задачи будут самые разные. Т.е. никаких SUN/Oracle или AMD.
  3. Минимальный размер оперативной памяти - 16GB (для нескольких VM). Желательно наличие возможности расширения до бОльшего размера. Чем быстрее тем лучше.
  4. Возможность установки в rack-овую стойку. Чем меньше Unit-ов - тем лучше. Глубина не более 75см чтобы поместиться шкаф глубиной 800мм.
  5. Крайне желательно наличие встроенных средств удаленного управления (питание, KVM). Минимальный вариант - внешний/встроенный IP-KVM или Intelligent Platform Management Interface (IPMI).
  6. Крайне желательно наличие RAID контроллера позволяющего собрать RAID 5/6 с возможностью работы как с SAS, так и SATA дисками (при чем одновременно), соответственно, с возможностью горячей замены. Чем дешевле винты - тем лучше (3.5′’ дешевле, чем 2.5′’). Чем больше максимально возможное количество винтов - тем лучше.
  7. Возможность расширения количества сетевых интерфейсов (для IOU/WVRP/VM/Wireshark и т.д.)
  8. Желательно наличие полного резервирования по питанию.

Выбор промышленных/кустарных серверов сейчас чрезвычайно большой. Перебрал/перепробовал/передумал много различных вариантов, начиная с использования относительно быстрого Notebook-а с Core i7 или Desktop-а в роли “сервера” (категорически в кавычках), продолжая кустарными серверами в корпусе 1U с теми же Core i7 или Xeon процессорами, заканчивая промышленными серверами HP/Dell/IBM/Fujitsu/другие. Выбор сделал, наверное, самый тривиальный/частый/статистически_прогнозируемый - строго HP, т.е. промышленный сервер Proliant серии Density Line (DL). По соотношению “цена/качество(функционал) + размеры” оптимальным посчитал именно DL 360 G5. Т.е. далеко не свежее поколение, но все же…

[Read More…]

Cisco rotary groups. Potential security threat.

Исходя из опыта могу смело сказать, что операторы большинства сетей всерьез задумываются о безопасности лишь после первого инцидента. Этому способствуют несколько факторов: сроки, прессинг менеджеров, недостаточный уровень знаний в области безопасности. Но есть и еще один, возможно, наиболее значимый фактор - предрасположенность софта, а именно Cisco IOS, к всякого рода неприятностям. Откуда такое мнение? Это собственный вывод исходя их практики работы с софтом/железом различных вендоров.

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

Итак, у инженера есть задача переопределить дефолтный Telnet TCP порт 23 на какой-то другой, к примеру, с целью закрыть дефолтный ACLем, так как его сканируют наиболее часто. Это возможно благодаря команде rotary. Пример конструкции:

conf t
 line vty 0 15
  rotary 66
  end

В результате залогиниться простейшим Windows Telnet клиентом будет можно И на порт 23 И на порт 3066. Чаще всего после этого закрывают дефолтный порт 23 ACLeм, но очень часто забывают о том, что IOS начинает слушать не только порт 3000 + rotary group number (66), но и другие порты (5000, 7000, 10000). Иногда бывает так, что пользователи даже зная об этом пытаются проверить возможность использования портов для взлома используя, к примеру, Telnet клиент из Windows. Логин не проходит, пользователь спокоен, порт открыт.

На самом же деле, эти порты можно легко использовать. К примеру, порт “7000 + rotary group number” слушает сервис “Telnet protocol, binary mode” (RFC856). Windows клиент по факту его не поддерживает. Тогда как в PuTTY это проблема была успешно решена (ссылка). Т.е. можно спокойно логиниться.

Далее, порт “5000 + rotary group number” согласно документации слушает сервис “Raw TCP protocol (noTelnet protocol)”. Попробовал Windows Telnet клиент, PuTTY RAW соединение - не логинится с ошибкой неправильный пароль. Казалось бы, можно успокоиться. Однако, можно успешно использовать действительно RAW TCP соединение, к примеру, с помощью Netcat, который можно найти портированый и под Windows:

D:>nc -v 10.10.10.1 5066
10.10.10.1: inverse host lookup failed: h_errno 11004: NO_DATA
(UNKNOWN) [10.10.10.1] 5066 (?) open

User Access Verification

Username: cisco
cisco
Password: cisco

SW1#conf t
conf t
Enter configuration commands, one per line.  End with CNTL/Z.
SW1(config)#end
end
SW1#q
q

D:>

При этом в логах видим неоспоримое подтверждение с указанием порта:

SW1#
*Mar  1 00:53:31.242: %SEC_LOGIN-5-LOGIN_SUCCESS: Login Success [user: cisco] [Source: 10.10.10.254] [localport: 5066] at 00:53:31 UTC Mon Mar 1 1993
SW1#

Самое интересное тут то, что ни маршрутизатор, ни коммутатор не показывают того, что они слушают вышеописанные порты.

Возможно позже опишу существующие, вернее, известные мне доступные команды на маршрутизаторах/коммутаторах Cisco предназначенные для просмотра портов которые слушает Cisco IOS. Могу сказать сразу, что способа который бы позволял видеть действительно все порты я не нашел (: Поэтому при создании ACLей пользуюсь утилитой Nmap.

Cisco Catalyst - Tagging native vlan.

Вроде бы мелочь, а времени на поиск причины связанной с тегирование Native VLANа в IEEE 802.1Q™ транках на Cisco Catalyst можно потратить немало. Проблема в том, что несмотря на то, что в выхлопе команды “show interface switchport” есть отображение нужного параметра “Administrative Native VLAN tagging”, он не отражает действительности и всегда показывает состояние “enabled”. Т.е. в случае, когда с одной стороны транка тегирование Native VLANа включено, а с другой нет, можно потратить время.

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

Выходов два - или искать в конфиге (sh run | include ..) или воспользоваться единственной show командой показывающей достоверное состояние:

Switch#sh run | i native  
vlan dot1q tag native 
Switch#

Switch#show vlan dot1q tag native 
dot1q native vlan tagging is enabled
Switch#

Проверено на Cisco Catalyst 3550/3560/3750.

При использовании протокола ISL такой проблемы не встретишь, так как все VLANы при этом тегируются и такой сущности/концепции как Native VLAN в ISL не существует.

Cisco PPTP/VPDN server - Error 691 - PPP: Received LOGIN Response FAIL.

При конфигурации PPTP сервера на Cisco 877W с IOS 12.4T (точная модель тут неважна, тем не менее) встретился с проблемой аутентификации. При правильном логине/пароле получаю ошибку:

Error 691: The remote connection was denied because the user name and password combination you provided is not recognized, or the selected authentication protocol in not permitted on the remote access server.

PPTP сервер настраивал не раз, конфигурация проще некуда, дебаги говорят, что логин ИЛИ пароль неправильные. Что конкретно - неизвестно:

router#show vpdn history failure
Table size: 20
Number of entries in table: 1

User: PPTP_User_Name, MID = 2
NAS: Information is not applicable
Gateway: router, IP address = 150.150.150.150, CLID = 2
Log time: Jul  5 08:41:29.930, Error repeat count: 1
Failure type: AAA authentication failure
Failure reason: Authentication failed

router#terminal monitor
router#debug ppp authentication
Jul  5 08:41:27.910: ppp1 PPP: Using vpn set call direction
Jul  5 08:41:27.910: ppp1 PPP: Treating connection as a callin
Jul  5 08:41:27.910: ppp1 PPP: Session handle[5900001B] Session id[17]
Jul  5 08:41:29.902: ppp1 PPP: Authorization required
Jul  5 08:41:29.914: ppp1 MS-CHAP-V2: O CHALLENGE id 1 len 27 from "router"
Jul  5 08:41:29.922: ppp1 MS-CHAP-V2: I RESPONSE id 1 len 59 from "PPTP_User_Name"
Jul  5 08:41:29.922: ppp1 PPP: Sent MSCHAP_V2 LOGIN Request
Jul  5 08:41:29.930: ppp1 PPP: Received LOGIN Response FAIL
Jul  5 08:41:29.930: ppp1 MS-CHAP-V2: O FAILURE id 1 len 13 msg is "E=691 R=0"
router#

Так как я был точно уверен, что логин/пароль приходят правильные, решил что это или bug или он просто не видит моих локальных пользователей. Не долго думая создал пользователя с паролем в открытом виде, т.е. не “username … secret …”:

conf t
 username USERNAME password 0 PASSWORD

Проблема решилась. Самое интересное, что я не встречал в доках информации о том, что нельзя использовать “secret” для таких пользователей. Уже зная что искать, нагуглил в этом треде следующее:

PPTP on an IOS router using LOCAL AUTHENTICATION will fail when using encrypted secrets rather than regular passwords.

Как-то так…

Wake-on-LAN (WOL) для включения питания хоста с Windows XP, находящегося за Cisco NAT.

Решил очень кратко законспектировать простейшее решение, позволяющее “разбудить”, к примеру, домашний ПК, находящийся за домашним Cisco маршрутизатором. посредством Wake-on-LAN (WOL).

  1. Следует убедиться, что функция Wake-on-LAN (WOL) НЕ отключена в BIOS. В противном случае ее следует включить.
  2. Также следует убедиться, что функция WOL поддерживается сетевым адаптером и включена. В настоящее время большинство современных сетевых адаптеров, в большей степени интегрированных, поддерживают WOL. Однако, если речь идет о PCMCIA или ExpressCard или тем более о безымянном USB LAN адаптере, то шансы резко уменьшаются. Включение функции WOL, к примеру, в Windows XP, выглядит следующим образом: “Device Manager” (devmgmt.msc) > “Network adapters” > “Properties” > “Advanced” > Включить Wake-on-LAN (могут называться по разному: Wake Up Capabilities, Wake on Settings, …)
  3. Следующих шаг - активация возможности удаленного подключения: “My Computer” > “Properties” > “Remote” > “Allow users to connect remotely to this computer” > “OK”.
  4. Теперь уже можно проверить работу WOL в локальной сети. Воспользовавшись любой утилитой позволяющей генерить “магический пакет”, к примеру, этой. Это наиболее мне понравившаяся не требующая установки консольная утилита. Кроме того, там же можно найти очень подробное описание работы WOL на русском языке - ссылка. Для генерации “магического пакета” следует предварительно узнать MAC адрес сетевого адаптера той машины которую требуется “разбудить”. В Windows посмотреть MAC адрес можно командой “ipconfig /all”:
    C:>ipconfig /all | findstr "Description Physical"
            Description . . . . . . . . . . . : Intel(R) PRO/Wireless 3945ABG Network Connection
            Physical Address. . . . . . . . . : 00-18-DE-CA-7B-44
            Description . . . . . . . . . . . : Intel(R) PRO/1000 PL Network Connection
            Physical Address. . . . . . . . . : 00-15-58-7B-5A-DB
    C:>
    

    Тут мы видим, что у нас два сетевых интерфейса, выбираем нужный, а это в моем случае проводной адаптер с MAC адресом “00-15-58-7B-5A-DB”. Для включения:

    woncli -m 00:15:58:7B:5A:DB 255.255.255.255

    В случае, если “магический пакет” предназначен для хоста находящегося в другой сети, то на маршрутизаторе на интерфейсе сети получателя следует включить ip directed-broadcast:

    conf t
     interface ...
      ip directed-broadcast
    
  5. Следующий этап - настраиваем возможность включения посредством WOL через Cisco NAT. Допустим, адрес внутреннего хоста - 172.16.1.100, NAT outside интерфейс в сторону Инета - Dialer0. В таком случае следует добавить строку:
     ip nat inside source static udp 172.16.1.255 65535 interface dialer 0 5555
    

    Интересных особенностей тут две:

    1. Нужно указать именно широковещательный адрес сети (.255) иначе не сработает.
    2. Это будет работать БЕЗ команды “ip nat inside” на внутреннем интерфейсе, что для меня очень странно.

    При такой конфигурации для включения хоста следует послать из Инета “магический пакет” в направлении внешнего адреса маршрутизатора (Dialer0), при этом следует указать UDP порт 5555:

    woncli -m 00:15:58:7B:5A:DB example.com:5555

В этой утилите также есть маленькая неприятная особенность: нельзя указать домен третьего уровня и более, к примеру test.example.com уже не сработает и придется указывать IP адрес.

Ну и чтобы выключить хост подключившись к нему по RDP, можно использовать команду shutdown (-s shutdown, -t timeout, -f force):

shutdown -s -t 0 -f

Admin area