(defun ipfw blog)

Team Viewer Server

2009-12-19T23:27:00.000+02:00

Довольно давно использую по работе и не только замечательную программку TeamViewer. И вот недавно, по чистой случайности обнаружил интересный номерок, даже незнаю причислять это к Eastern Egg'sам или это такая учебно-демонстрационная фишка, но суть ее в том, что компания-разработчик, держит в сети специальный сервер, на котором запущен TeamViewer в круглосуточном режиме!

Чтобы подключиться к этому серверу нужно ввести в поле ID тима 12345. Ну хорошо, ай-ди мы знаем, но нужен еще и код. Думаете на сервере прописан постоянный пароль? Дудки! Он динамический, но его говорит сам Тим.

Вводим то что нам говорят и попадам в ~~преисподнюю~~ Windows 2003 Server.

Возможности у нас обрезаны по самое не балуйся, все щелчки правой кнопкой мышки по таскбару, рабочему столу, в окнах открытия/закрытия файлов отключены, все ярлычки read-only, как и вся папка рабочий стол. Ни создать, ни удалить ничего нельзя. Ну оно и понятно, зачем давать всем полный доступ к своему серверу, его быстро превратили бы в машину для ддоса или спам-бота, да мало ли применений можно найти для Intel(R) Pentium(R) III Xeon processor с 1GB RAM и выходом в инет...

Но мы не теряемся, вписываем в поле File name: c:\ нажимаем Энтер и видим.. да, содержимое системного диска. Но видим мы только *.txt файлы. Не теряемся вбиваем в то же поле *.* и теперь все секреты нам видны. Сразу бросаеться в глаза папочка sysprep. заходим в нее и видим параметры развертывания ОС. Среди них есть и такие интересные сведения как ключ для установки Windows и пароль администратора (еще бы найти куда его ввести)...

Вызываем тоже окно, идем в C:\Documents and settings\Demo\Start Menu\Programs\StartUp и открываем файлик startup.cmd:

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

Вообщем такое вот пасхальное яйцо.

Быстро поднимаем DialIn Server

2009-11-04T15:50:00.000+02:00

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

Это был пролог. Теперь же ближе к сути. Имееться старый dialin сервер (PIII, FreeBSD 4.6) с модемным пулом в 12 Зикселей, обслуживает около трех-четырех одновременных подключений. Задача: Перенести это все дело на отдельный, относительно новый сервер (2*Dual Xeon 2,2; 2048 RAM; 160GB Raid-0;1Gbps link). Строго говоря, такая конфигурация для таких целей не то что слишком хорошая, она просто нереальная. Задействовано будет около 1% мощностей, но поскольку другой машины просто небыло, а старый сервер уже вот вот прикажет долго жить, было решено сделать на чем есть, а незадействованные ресурсы потом придумаем как использовать, хоть поднять несколько виртуальных машин для грубых экспериментов. Основная задача DialIn в нашей организации - предоставление интернета на скорости около 56Kbps, а так же пропуск некоторых пользователей к корпоративному почтовому серверу.
Специально для всей этой кухни закупили две платки Moschip MCS 9865. В графе поддерживаемых драйверов значиться Linux Kernel 2.6.14 & above. Хмм... Нативная поддержка в Линукс это уже что-то. В качестве дистрибутива был выбран Debian 5.0 Lenny. Ну что ж все в сборе, можно приступать.

Поехали

Инсталяция Debian'а самая стандартная, благо сейчас с установкой Линукса может справиться любой школьник. Я использовал текстовый режим, из компонентов остаавил только базовую систему, больше ничего не требуеться. После установки несем сервер его будущий дом, тобишь серверную, подключаем там все модемы к RS232-портам, само собой питание и сеть. Все дальнейшие действия совершаем удаленно, с рабочего места.
Собственно что нам нужно сделать:

Собрать и подгрузить драйвер для MCS9865.
Настроить mgetty для приема вызовов.
Настроить PPP для установления связи.
Создать правила файрволла.
Забыть о сервере.

1. Драйвер. Копируем с диска к плате архив MCS9865_Linux.tar.gz.

dialin:~# сp /media/cdrom/drivers/Linux/MCS9865_Linux.tar.gz ~/

dialin:~# tar zxvf MCS9865_Linux.tar.gz
dialin:~# cd MCS9865_Linux
dialin:~# make

И сразу же получаем:

make -C /lib/modules/2.6.26-2-686/build/ SUBDIRS=/root/MCS9865_Linux modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.26-2-686'
CC [M] /root/MCS9865_Linux/mcs9865.o
/root/MCS9865_Linux/mcs9865.c: In function ‘serial9865_probe’:
/root/MCS9865_Linux/mcs9865.c:2068: error: ‘SA_SHIRQ’ undeclared (first use in this function)
/root/MCS9865_Linux/mcs9865.c:2068: error: (Each undeclared identifier is reported only once
/root/MCS9865_Linux/mcs9865.c:2068: error: for each function it appears in.)
make[2]: *** [/root/MCS9865_Linux/mcs9865.o] Ошибка 1
make[1]: *** [_module_/root/MCS9865_Linux] Ошибка 2
make[1]: Leaving directory `/usr/src/linux-headers-2.6.26-2-686'
make: *** [default] Ошибка 2

Ну что же, мы не ищем легких путей. Открываем файл mcs9865.c на 2068-ой строке и видим:

//Register a ISR
if ((retval = request_irq(dev->irq, serial9865_interrupt,SA_SHIRQ,"mcs9865-serial",&serial9865_ports[retval])))
goto disable;

Да, я знаю о чем вы подумали, использовать goto плохо, это влечет за собой уменьшение толщины озонового слоя... Сейчас речь не об этом. Как говорил нам make ‘SA_SHIRQ’ undeclared,
а благодаря гуглу мы узнаем что SA_SHIRQ уже два года как deprecated и что заменить его нужно на волшебный IRQF_SHARED. После всех этих шаманств, командуем:

make && make install

И драйвер должен нормально собраться, проинсталлироваться и подгрузиться как модуль. Проверяем модули и выдачу lspci:

dialin:~/MCS9865_Linux# lsmod | grep mcs9865
mcs9865 16736 2
mcs9865_isa 2500 0
dialin:~/MCS9865_Linux# lspci -v | grep -i "NetMos"
03:01.0 Serial controller: NetMos Technology Device 9865 (prog-if 02 [16550])
03:01.1 Serial controller: NetMos Technology Device 9865 (prog-if 02 [16550])
03:01.2 Communication controller: NetMos Technology Device 9865
03:02.0 Serial controller: NetMos Technology Device 9865 (prog-if 02 [16550])
03:02.1 Serial controller: NetMos Technology Device 9865 (prog-if 02 [16550])
03:02.2 Communication controller: NetMos Technology Device 9865

Как видим все отлично поставилось и определилось. В /dev/ появились 4 устройства ttyD0-D3, и 4 ttyS0-S3. Что-то тут не то. Как видно по выводу lspci, имеються две платы-контроллеры с двумя портами на борту и к ним подсоединены по две двухпортовые железки. Тоесть всего портов должно быть 12, а у нас 8. После непродолжительного гугления выяснилось что по умолчанию Линукс отображает только 4 устройства /dev/ttyS и чтобы увеличить это число нужно при загрузке передать ядру параметр 8250.nr_uarts=x, где х - необходимое количество устройств. Приводим /boot/grub/menu.lst к следующему виду:

default         0
timeout         5
color cyan/blue white/blue

title        Debian GNU/Linux, kernel 2.6.26-2-686
root         (hd0,0)
kernel       /vmlinuz-2.6.26-2-686 root=/dev/sda3 ro 8250.nr_uarts=16
initrd       /initrd.img-2.6.26-2-686

title        Debian GNU/Linux, kernel 2.6.26-2-686 (single-user mode)
root         (hd0,0)
kernel       /vmlinuz-2.6.26-2-686 root=/dev/sda3 ro single
initrd       /initrd.img-2.6.26-2-686

Перезагружаемся, логинимся и видим:

dialin:/boot/grub# ls -l /dev/tty[SD]*
crw-rw---- 1 root dialout 201, 0 Ноя 3 13:37 /dev/ttyD0
crw-rw---- 1 root dialout 201, 1 Ноя 3 08:00 /dev/ttyD1
crw-rw---- 1 root dialout 201, 2 Ноя 3 08:00 /dev/ttyD2
crw-rw---- 1 root dialout 201, 3 Ноя 3 08:00 /dev/ttyD3
crw-rw---- 1 root dialout   4, 64 Ноя 3 08:00 /dev/ttyS0
crw-rw---- 1 root dialout   4, 65 Ноя 3 08:00 /dev/ttyS1
crw-rw---- 1 root dialout   4, 74 Ноя 3 08:00 /dev/ttyS10
crw-rw---- 1 root dialout   4, 75 Ноя 3 08:00 /dev/ttyS11
crw-rw---- 1 root dialout   4, 76 Ноя 3 08:00 /dev/ttyS12
crw-rw---- 1 root dialout   4, 77 Ноя 3 08:00 /dev/ttyS13
crw-rw---- 1 root dialout   4, 78 Ноя 3 08:00 /dev/ttyS14
crw-rw---- 1 root dialout   4, 79 Ноя 3 08:00 /dev/ttyS15
crw-rw---- 1 root dialout   4, 66 Ноя 3 08:00 /dev/ttyS2
crw-rw---- 1 root dialout   4, 67 Ноя 3 08:00 /dev/ttyS3
crw-rw---- 1 root dialout   4, 68 Ноя 3 08:00 /dev/ttyS4
crw-rw---- 1 root dialout   4, 69 Ноя 3 08:00 /dev/ttyS5
crw-rw---- 1 root dialout   4, 70 Ноя 3 08:00 /dev/ttyS6
crw-rw---- 1 root dialout   4, 71 Ноя 3 08:00 /dev/ttyS7
crw-rw---- 1 root dialout   4, 72 Ноя 3 08:00 /dev/ttyS8
crw-rw---- 1 root dialout   4, 73 Ноя 3 08:00 /dev/ttyS9
dialin:/boot/grub#

То что нужно. Теперь ставим необходимое ПО:

dialin:/boot/grub# aptitude install uucp mgetty ppp

Говорим init'у что будем использовать модемы:

dialin:~# vim /etc/inittab
D0:23:respawn:/sbin/mgetty -D -n 3 ttyD0
D1:23:respawn:/sbin/mgetty -D -n 3 ttyD1
D2:23:respawn:/sbin/mgetty -D -n 3 ttyD2

И так далее для всех остальных модемов. Пару слов о том что все это значит. 23 - указывает на каких уровнях запуска (runlevels) будет действовать запись, respawn заставляет init перезапускать mgetty после отсоединения пользователей, число после -n, говорит через сколько звонков модем должен поднять трубку. Чтобы изменения вступили в силу, перезапускаем init:

dialin:~# kill -1 1

Теперь переходим к настройке mgetty. Собственно все опции храняться в трех файлах, директории /etc/mgetty.В /etc/mgetty/login.config вписываем строчку

/AutoPPP/ - a_ppp /usr/sbin/pppd file /etc/ppp/options.server

Этим мы указываем что mgetty будет стартовать pppd при поднятии трубки модемом, а параметры будет брать из файла /etc/ppp/options.server.

Далее на очереди файл mgetty.config. Он описывает параметры для каждого из модемов, строки инициализации, скорость, лог файлы для каждого. Мы просто скопировали этот файл со старого сервера. Примерный вид:

########################################
# 884544
### ZyXEL U-3xxxx ##

rings 1
port ttyD0
init-chat "" \d\d\d+++\d\d\dATQ0E1V1H0 OK ATL0M0S0=0 OK AT&K3 OK
statistics-chat "" AT OK ATI2 OK
statistics-file /tmp/modem1.log
modem-type cls2
data-only y

Понятно, что для каждого типа модема строка инициализации должна быть своя. Теперь настраиваем ppp. Создаем файлик /etc/ppp/options.server, в нем содержаться общие параметры для всех модемов. Мы запишем в него только одну строку:

dialin:~# echo "lock" > /etc/ppp/options.server

Теперь создадим конфигурационные файлы для каждого порта. Имя нужно составлять таким образом: options.port, где вместо port подставляем имя порта для каждого модема.

В этих файлах храняться настройки соединения. Мы туда впишем такие строки:

modem
crtscts
-detach
require-pap
refuse-chap
proxyarp
login
ms-dns 4.2.2.2
ms-dns 4.2.2.1
ms-dns 193.193.193.100
172.16.81.12:10.10.5.202

DNS-серверы внешние, последняя строка задает на ip-адресацию внутри тонеллей pppX, которые будут автоматически подниматься, при соединению пользователей. А весь траффик pppd сам будет заворачивать на этот интерфейс.
Используеться PAP-авторизация пользователей, благодаря строкам refuse-chap и require-pap.
Пользователей прописываем в файле /etc/ppp/pap-secrets, в формате логин пароль IP-адрес.
Ну вот и все, нам осталось только настроить NAT, на вышестоящих шлюзах ну и файрволл на этом. Однако этот процесс уже сугубо индивидуальный и зависит от топологии сети и требований системных администраторов. Поэтому оставляю это вам.

Эпилог

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

Неординарная работа с Active Directory

2009-11-02T14:29:00.009+02:00

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

Начнем с основ

Active Directory представляет собой LDAP-совместимую реализацию Службы Каталогов, основное предназначение которой – предоставить централизированное средство управления всеми елементами определенной организации подключенными к сети, а так же хранить подробную информацию о них. Каждый елемент Службы Каталогов принято называть обьектом, а информация о нем храниться в виде набора атрибутов.
Ограничение на количество обьектов накладываеться только движком БД(Microsoft Jet Blue) который для своей работы использует АД. Теоретически эти ограничения составляют: 16Тб на размер базы данных и около 1млрд обьектов Службы Каталога. Пока что этот лимит небыл превышен и вряд ли будет в обозримом будущем…
Для удобной работы с такими большимы количествами обьектов АД организовывает их в логические группы, создавая таким образом иерархическую структуру. Обьекты способные содержать в себе другие обьекты называют контейнерами.

(Оснастика администратора ActiveDirectory)

Обьект можно однозначно идентифицировать по его имени. АД поддерживает такие форматы именования обьектов как: UNC, URL и LDAP. Каждый обьект имеет составное имя (Distinguished name, DN) и именно его мы будем использовать для манипулирования данными Службы Каталогов. Атрибуты составного имени:

DC – класс обьекта домена
OU – имя организационной единицы (подразделения)
CN – общее имя

Пример составного имени: CN=Ivanov I.A,OU=Маркетинг,DC=microsoft,DC=com
Каждому обьекту службы каталогов также присваиваеться уникальный идентификатор (GUID/UUID) – уникальная строка длиной в 128 бит, которая используеться большей частью для внутренних нужд Active Directory. Пример:

{1acc40ef-d1e1-4b0e-94d6-ef1894b3545a}

Физически вся информация об объектах AD храниться в файле

%systemroot%\NTDS\NTDS.DIT

Вся работа с ним осуществляеться системным агентом каталога(DSA), именно он выстраивает иерархию обьектов и предоставляет возможность работы этими данными приложениям извне используя протокол LDAP(Lightweight Directory Access Protocol). Для этого необходимо сформировать LDAP URL. Делаеться это достаточно просто, он имеет вид: LDAP://server/ + DN, где server – IP адрес или DNS имя сервера на котором располагаеться служба каталогов, а DN - уже знакомое нам составное имя. Пример ldap url:

LDAP://dc.microsoft.com/CN=IvanovI.A,OU=Маркетинг,DC=microsoft,DC=com

Приступаем

Имея все эти сведения можем уже попробовать написать простенькое приложение основная задача которого – соединиться со службой каталогов и забрать какие-то данные, пускай это будут сведения обо всех основных контроллерах домена предприятия.
Для реализации вышепоставленной задачи нам понадобиться:

Visual C# (мы начнем с него, можно и Express версии)
Реальный или виртуальный контроллер домена
Учетная запись с правами не ниже администратора домена

Создавать мы будем пока что консольное приложение, но потом легко будет подключить и GUI.
Создаем новый проект:

Сразу идем в References и подключаем System.DirectoryServices

Теперь подключаем пространство имен:

using System.DirectoryServices;

Теперь пара слов для чего мы все это проделали. Основным средством взаимодействия нашего приложения с Active Directory являеться обьект System.DirectoryServices. Располагаеться он во внешней библиотеке System.DirectoryServices.dll и чтобы его использовать нужно подключиться эту самую бибиотеку. После всех этих действий мы можем забыть о том что это внешний компонент и работать с ним как с родным.
Из пространства имен System.DirectoryServices нас прежде всего интересуют два класса: DirectoryEntry и DirectorySearcher. MSDN нам говорит что первый из них инкапсулирует в себе узел или обьект иерархии Active Directory, а второй служит для выполнения запросов к Active Directory Domain Services. Используя эти два класса можно делать с обьектами Службы каталога все что угодно.

using System;
using System.Collections.Generic;
using System.Linq;
using System.DirectoryServices;
using System.Text;

namespace adcmd
{
   class Program
   {
      static void Main(string[] args)
      {
         DirectoryEntry entry = new DirectoryEntry("LDAP://Toaster", "admin", "123");
         foreach (DirectoryEntry child in entry.Children)
            Console.WriteLine(String.Format("{0}: ({1})", child.Name, child.Path));
      }
   }
}

Вот такой простенький код покажет нам ВСЕ обьекты AD первого уровня вложенности, с их путями в формате LDAP URL. Ключевое свойство здесь entry.Children, это коллекция и содержит она все дочерние елементы обьекта entry. Таким образом, мы можем добраться до обьектов любого уровня вложенности, ведь у child тоже есть поле Children. К родительскому же обьекту можно обратиться используя свойство Parent.
Далее неплохо было бы научиться работать с атрибутами обьектов. Делаеться это через свойство экземпляра класса DirectoryEntry Properties. Давайте посмотрим все атрибуты корневого елемента каталога:

using System;
using System.Collections.Generic;
using System.Linq;
using System.DirectoryServices;
using System.Text;

namespace adcmd
{
   class Program
   {
      static void Main(string[] args)
      {
         DirectoryEntry entry = new DirectoryEntry("LDAP://Toaster", "admin", "123");
         foreach (string prop in entry.Properties.PropertyNames)
            Console.WriteLine(String.Format("{0}: {1}", prop, entry.Properties[prop].Value.ToString()));
      }
   }
}

Вот что получилось у меня:

Итак, мы уже немного поднаторели в выборке данных, приступаем к реализации основной задачи. Как вы помните, нужно выбрать всех пользователей (вывести фамилию и инициалы) которые принадлежат определенной группе безопастности.
Алгоритм работы предельно прост:

Соединяемся со службой каталога;
вибираем всех пользователей;
проходимся по всех и смотрим атрибут MemberOf. Говоря на языке С# он представляет собой коллекцию обьектов типа String с именами всех груп безопастности, в которых состоит пользователь. Тоесть то что доктор прописал!
перебираем эту коллекцию и если находим соответствие – выводим на экран значение другого атрибута, а именно displayUsername, в нем содержиться фамилия и инициалы пользователя, указанные при введении его в AD.

Создаем новый проект, или же модицируем ранее созданный. Нам понадобяться те же библиотеки.
Код

using System;
using System.Collections.Generic;
using System.Linq;
using System.DirectoryServices;
using System.Text;

namespace adcmd
{
   class Program
   {
      static void Main(string[] args)
      {
         String FML;  // здесь будем хранить инициалы
         String OU;    // а здесь отдел
          /* Соединяемся с Active Directory */
          DirectoryEntry entry = new DirectoryEntry("LDAP://internal.Toaster", "admin", "123");

          /* Создаем обьект для поиска *
          DirectorySearcher mySearcher = new DirectorySearcher(entry);
          /* Настраиваем фильтр поиска (только пользователи) */
          mySearcher.Filter = "(&(objectClass=user)(objectCategory=person))";
          /* Сортировка по убыванию */
          mySearcher.Sort = new SortOption("displayName", SortDirection.Ascending);
          /* Проходимся по всех найденных обьектах */
          foreach (SearchResult resEnt in mySearcher.FindAll())
          {
             /* Получаем DirectoryEntry для каждого обьекта AD */
             DirectoryEntry de = resEnt.GetDirectoryEntry();
             /* Если пользователь состоит в какой-то группе безопастности и имеет имя... */
             if (de.Properties["MemberOf"].Value != null && de.Properties["displayName"].Value != null)
             {
                /* ...начинаем просмотр всех групп */
                for (int i = 0; i < style="color: rgb(163, 21, 21);">"MemberOf"].Count; i++)
                 /* Этот пользователь член нужной группы? */
                 if (de.Properties["MemberOf"][i].ToString().Contains("Бухгалтерия"))
                 {
                    /* Да, извлекаем Фамилию и инициалы */
                    FML = de.Properties["displayName"][0].ToString();
                    /* А теперь извлекаем OU(отдел) пользователя*/
                    OU = de.Parent.Path.ToString();
                    /* Чистим данные от ненужного мусора */
                    OU = OU.Replace("LDAP://internal.Toaster/OU=", "");
                    OU = OU.Replace(",DC=Toaster", "");
                    /* Выводим искомую информацию в форматированном виде. */
                    Console.WriteLine(String.Format("{0}\t{1}", FML, OU));
                 }
              }
           }
        Console.WriteLine("All done.");
        Console.ReadKey();
     }
  }
}

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

Hello, world!

2009-10-17T20:17:00.001+03:00

Это первая запись в блоге, обычно люди в первом посте приветствуют своих будущих читателей и т. д. Для меня это просто место где я буду учиться излагать свои мысли, писать на интересные темы, преимущественно на Ай-ти тематику, тобишь программирование (~~C, C++, C#, Delphi, PHP, Python, shell, scheme~~) на чем угодно, администрирование ~~Windows/Unix/Linux~~ всего что только можно, ну и вообще о гиковом лайфстайле. Надеюсь блог поможет мне как-то структурировать мои знания и навыки, а также развить свой стиль написания статей.