Подарочек из контакта

Tuesday, 01 Mar 2011

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

Просмотрел для начала автозагрузки и иже с ними, и обнаружил что эта пакость сделала невидимым файл
C:\WINDOWS\system32\drivers\etc\hosts и понаписала в него всякого дикого мусора, среди которого промелькивали осмысленные строки:
##############################################
91.193.194.141 odnoklassniki.ua
91.193.194.141 vkontakte.ru
91.193.194.141 www.durov.ru
91.193.194.141 www.odnoklassniki.ru
91.193.194.141 wap.vkontakte.ru
91.193.194.141 vk.com
91.193.194.141 www.durov.vkontakte.ru
91.193.194.141 www.wap.vkontakte.ru
91.193.194.141 www.vkontakte.ru
91.193.194.141 www.pda.vkontakte.ru
91.193.194.141 durov.vkontakte.ru
91.193.194.141 odnoklassniki.ru
91.193.194.141 pda.vkontakte.ru
91.193.194.141 www.vk.com
91.193.194.141 www.odnoklassniki.ua
91.193.194.141 durov.ru
##############################################

а также создала еще один файл в этой же папке с названием hюsts в который навалила следующего флуда:

##############################################
windows
765765765765765765765765765765765767575
765765765765765765765765765765765767575
765765765765765765765765765765765767575
##############################################

Собственно редирект IP на фишинг страничку которая и предлагает прислать бабусек за анлок сайтов. IP’шник литовский и принадлежит ISP: Odessa Hosting Service
Учитывая про при последовавшем прогоне системы через все многообразие имеющихся антивирей- было найдено пара троянов, застывших в ужасе, в темповой папке, после чего я полез смотреть кто из них проделывает эту пакость и оказалось что троянчики тут не при чем- а эта лажа приходит из социальной сети “В Контакте”, где на стену приходит ссылко вида http://09g020923jf9jdq.ru/?edcvfr=101036702 при проходе на которую предлагается к скачиванию файлец
PODAROK.exe, который и проводит указанную манипуляцию с файлом hosts.

А троянчики были просто залетные, видимо оставшиеся от дикого и неуемного серфинга по сети.

VN:F [1.9.21_1169]
Rating: 10.0/10 (1 vote cast)
VN:F [1.9.21_1169]
Rating: +1 (from 1 vote)

Распределенная сеть Wi-Fi на рутерах Linksys WRT 160NL

Friday, 28 Jan 2011

Возникла задача построить беспроводную сетку Wi-Fi в нескольких крыльях офиса, но так что бы всюду рулила одна сеть с единым SSID. Скажу откровенно один раз я уже накололся с этим, когда попытался совокупить CheckPoint Edge и D-Link’овский рутер, как раз из-за того что каждый производитель использует для сопряжения AP в режиме bridge, repeater и WDS свои собственные фичи, так что если есть необходимость построения подобной схемы, то оборудование надо приобретать одного бренда.

Для этих целей мы закупили Wi-Fi рутеры Linksys WRT 160NL- совершенно новые модельки, которые гонятся уже под лейблом Cisco. Но к сожалению родная прошивка рутера не позволяет поднять подобный функционал, по этой самой причине пришлось обратиться к кастомной прошивке DD-WRT, которая базируясь на открытом коде Linux’ового ядра, значительно расширяет функционал обычных рутеров. Я уже имел некоторое количество экзерсисов с этой прошивкой, когда пытался подключить другу torrent клиента и монтирование NTFS’ных дисков на рутере, и если дойдут руки, то о результатах отпишусь позднее. А пока создаем распределенную беспроводную сеть на двух (можно и более) рутерах Linksys WRT 160NL.

Для начала качаем кастомную прошиву с сайта DD-WRT и перепрошиваем основной рутер. Условно назовем его MAIN-AP. Выбираем прошивку для своего рутера, на данный момент актуальная версия v24 SP2 (SVN revision 14896), скачиваем, после чего подключаемся к рутеру через LAN кабелюку и проходим: Administration ->
Дожидаемся завершения прогресса перепрошивки и заходим в консоль администратора. Вводим имя пользователя и новый пароль, после чего настраиваем рутер для работы в обычном режиме- задаем настройки внешней сетки, внутренней, DHCP сервера и Wi-Fi сети. Также необходимо отключить встроенный брандмауэр ибо он может помешать взаимодействию сетевых устройств.

После этого переходим к настройке вторичного рутера. Назовем его Bridge-AP. Для начала задаем ему внутреннюю сетку из того же пула, что и была задана для Main-AP, и отключаем внешний интерейс и DHCP сервер, ибо адреса у нас будет раздавать первичный AP: идем Setup -> Basic Setup и расставляем галочки следующим образом
Connection Type: Disabled
STP:  Disabled
DHCP Server: Disable

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

Далее переключаемся из режима шлюза в режим рутера: Setup -> Advanced Routing и в выпадающем меню ставим Router. Отрубаем также брандмауэр ибо он может мешать работе AP: во вкладке Security -> Firewall отключаем все галки кроме Filter Multicast, после чего отключаем SPI firewall переключая в статус Disable.

После этого переходим к настройке Wi-Fi:
Идем в основные настройки Wi-Fi: Wireless -> Basic Settings и выставляем следующие параметры
Wireless Mode : Client Bridge
Wireless Network Mode : аналогично настройкам MAIN-AP
Wireless Network Name(SSID) : аналогично настройкам MAIN-AP
Wireless Channel : аналогично настройкам MAIN-AP
Wireless SSID Broadcast : аналогично настройкам MAIN-AP
Network Configuration : Bridged

Переходим к разделу настройки безопасности Wi-FI: Wireless-> Wireless Security
Выставляем тип безопасности (WEP, WPA или WPA2-Personal) аналогично настройкам MAIN-AP, точно также задаем и алгоритм шифрования: TKIP, AES, или  TKIP + AES, после чего вводим фразу что мы использовали при настройке MAIN-AP.

Сохраняемся и говорим Administration -> APPLY Settings после чего выключаем рутер, относим его в другое помещение и подключаем его прямым кабелем из его LAN порта в LAN порт рутера MAIN-AP, после чего включаем. Вуаля- у нас в обоих помещениях теперь пашет один и тот же SSID, так что тыкая из одной части зала в другую мы даже можем не заметить, когда мы перейдем на другую AP.

*** Единственный косячный момент который я заметил при работе с DD-WRT именно на Linksys заключается в том, что работать надо в IE ибо в Firefix web-интерфейс почему то подглючивает с завидным постоянством.
Тип шифрования рекомендую выставлять mixed на обоих рутерах, ибо в этом случае скорость передачи данных выше.
Также у меня возникли проблемы с раздачей репитером wi-fi в случае если запрещено широковещательное объявление SSID, поэтому пришлось транслировать имячко сети в эфир.

Обновление от 11.02.2011:  очень странная тема, ибо это решение у меня прожило в районе суток, после чего вторичный рутер перестал раздавать wi-fi в принципе, так что перепробовав 4 возможных прошивки, и перенастроив все решение раз 50, остановился на том, что у меня оба устройства работают в режиме AP. Криво в теории, но на практике работает пока нормально- продолжаю искать причину не понятного глюка. :(

VN:F [1.9.21_1169]
Rating: 8.2/10 (5 votes cast)
VN:F [1.9.21_1169]
Rating: +2 (from 2 votes)

Всего один день- отличный хостинг по фантастическим ценам

Sunday, 28 Nov 2010

Шикарное предложение от одного из лучших и при этом экономичных хостеров- компании Hostgator. Их команда маркетологов проводила акцию так называемой черной пятницы, которую я по причинам своей работы просто пропустил- некогда было повозиться с почтой, и в данный момент их настолько вдохновила эта акция, что они решили её повторить в этот понедельник 29 Ноября 2010 года.

Акция будет проходить весь день с 9 утра 29 ноября до 9 утра 30 ноября по московскому  времени, и в рамках проводимой акции компания будет предлагать свои услуги, по промо ценам за первый месяц использования, со скидкой более 50%. Для получения скидки необходимо быть новым клиентом, то есть зарегистрироваться сейчас, и ввести при заказе код промокупона: CYBERMONDAY2010.

Использование данного купона, позволит зарегистрироваться на площадках хостинг провайдера, по следующим ценам:
Shared Hosting – всего $2.48/месяц
Reseller Hosting – всего $12.48/месяц
VPS Hosting – всего $9.98/месяц (первый месяц)
Выделенный сервер – всего $87/month (первый месяц)

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

И откровенно говоря, я сам подумываю о том, чтобы зарегать себе виртуалку за 2.5 грина в месяц, ибо за такие деньги это наиболее фантастическое предложение.
Для регистрации пройти на сайт Hostgator, и не забыть ввести код промо-купона CYBERMONDAY2010.

VN:F [1.9.21_1169]
Rating: 10.0/10 (1 vote cast)
VN:F [1.9.21_1169]
Rating: +1 (from 1 vote)

Объединяем интерфейсы в CentOS

Friday, 16 Jul 2010

Разбираясь, накануне, с настройкой IP адреса в CentOS обнаружил интересную фичу по объединению нескольких интерфейсов в один виртуальный, тем самым повышая скорость передачи данных и создавая функционал отказоустойчивости, с помощью модуля ядра bonding.

Для этого необходимо создать bonding интерфейс, путем создания файла /etc/sysconfig/network-scripts/ifcfg-bond<N> , где N номер объединяемого интерфейса. Содержимое файла аналогично содержимому файла описания настроек обычно интерфейса, с той разницей что директива DEVICE= должна содержать поле bond<N>, где N номер интерфейса.

Пример файла выглядит следующим образом:
DEVICE=bond0
BOOTPROTO=none
ONBOOT=yes
NETWORK=10.0.1.0
NETMASK=255.255.255.0
IPADDR=10.0.1.27
USERCTL=no

После того как файлы будут созданы, можно объединять интерфейсы путем добавления директив MASTER= и SLAVE=  , так что за исключением этих полей оба файла должны выглядеть идентично. Например для интерфейсов eth0 и eth1файлы конфигурации будут выглядеть следующим образом:
DEVICE=eth<N>
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no

Для того чтобы  слияние интерфейсов работало, необходимо чтобы модуль bonding был загружен в ядро, для чего необходимо проверить, чтобы в файле /etc/modules.conf присутствовала строка:
alias bond<N> bonding
где N номер интерфейса, и для каждого сконфигурированного интерфейса должна присутствовать своя запись.

VN:F [1.9.21_1169]
Rating: 8.5/10 (2 votes cast)
VN:F [1.9.21_1169]
Rating: +1 (from 1 vote)

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

Thursday, 15 Jul 2010

Настраивал себе систему в 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

VN:F [1.9.21_1169]
Rating: 8.2/10 (21 votes cast)
VN:F [1.9.21_1169]
Rating: +11 (from 11 votes)

Делегируем управление субдоменом

Monday, 07 Jun 2010

Возникла необходимость делегировать управление доменной зоной третьего уровня (то есть например newdomain.odminblog.ru) серверам доменных имен хостера. Первое что пришло в голову, это создать зону в named.conf где указать что данный сервер является вторичным и первичным обозначить доменный сервер хостинг провайдера.

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

############################################
zone “newdomain.odminblog.ru” {
type slave;
file “slave/newdomain.odminblog.ru”;
masters {
DNS-провайдера;
};
############################################

Но данный вариант по мне не корректен, так что пришлось пойти в изысканиях дальше.  Поковырявшись в доках, мануалах и описаниях на сайте RU-CENTER пришел к тому, что управление зоной можно делегировать в файле описания зоны, подобно тому как это делает провайдер при делегировании PTR записи. Для этого необходимо описать DNS сервера отвечающие за данный субдомен, в разделе определения серверов доменных имен, причем их имена должны принадлежать к субдомену.

newdomain    IN    NS    ns1.newdomain.odminblog.ru
newdomain    IN    NS    ns2.newdomain.odminblog.ru

После чего, через канонический тип имени CNAME определяем доменные сервера провайдера

ns1.newdomain  CNAME  ns1.DNC-провайдера.
ns2.newdomain  CNAME  ns2.DNC-провайдера.

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

VN:F [1.9.21_1169]
Rating: 7.5/10 (2 votes cast)
VN:F [1.9.21_1169]
Rating: +1 (from 1 vote)

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

Wednesday, 12 May 2010

Системный файл /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

VN:F [1.9.21_1169]
Rating: 9.6/10 (5 votes cast)
VN:F [1.9.21_1169]
Rating: +2 (from 2 votes)