Попытка поставить или обновить не увенчалась успехом, так что стал копаться и обнаружил что оказывается Chrome не дружит с веткой RHEL5, и поддерживается только в версии RHEL6. Переставлять операционку мне уже не хотелось, так что пошукав по инету, нашел пофиксенный исходник Chromium переписанный Ryoji Kamei, который можно скачать с его сайта. Ставится ручками из yum, после добавления репозитория, но там собственно все расписано довольно подробно.

Но поскольку у меня операционка была сделана для определенных задач, то места оказалось не достаточно, так как требуется около 400Мб, и в итоге я, плюнув на все с прибором, полез смотреть работу данной прилады таки в винду. Тут конечно пришлось пошайтанить с проксями и впнами, чтобы гугель не совсем понял откуда пришел данный запрос, но вообщем установил я эту приладу  с данной страницы WebStore – надо отметить, что это бета-версия и весит она 20 метров. К тому же цепляется данная тулза к вашему аккаунту в системе google.

После установки на ваш компьютер, а точнее в вашу бродилку, данная прилада генерит уникальный 12ти значный код, на основе которого и происходит инициализация сессии. Код действителен порядка нескольких минут, в течении которых вы можете инициировать подключение, введя данный код в машине с которой необходимо подключиться. После чего вы получаете совместный доступ к компьютеру, по аналогии с TeamViewer, а целевой рабочий стол получает предупреждение что к нему подключился пользователь с мылом, которое вы указывали при логине в Google. Сама сессия строиться через рандомныйID@id.talk.google.com, и на самом деле довольно ощутимо подтормаживает, именно ввиду того что вы соединяетесь не peer-to-peer, а через средства Google. И вот тут встает большой вопрос, насколько данный вид связи безопасен и закрыт для третьих глаз, поскольку сообщение идет через ssl канал и канал Google-talk, но через гуглевые серваки: 74.125.43.126:443 и 173.194.35.227:19295.

Естественно, что помимо RDP вы получаете еще и видео-чат связь, но помнится еще Гомер изрек “Бойтесь данайцев, дары приносящих”, ибо SSL вещь хорошая, но памятуя о разговорах вокруг зарождения компании Google и участия в этом министерства обороны США, есть небольшое подозрение в том, что никто не мешает ставить на стороне данайцев в смысле компании Google так называемый ssl-декодер, который занимается дешифровкой сессии, преобразуя её в удобочитаемый, для “операторов”, формат. А учитывая что люди предоставляющие данный сервис, через бродилку Google Chrome пробивают практически любые защиты- у меня были пробиты: фаервол конечной машины, виртуальный NAT и фаервол хостовой машины, а также внешний рутер, то подобная тулза становится отличным способом влезть к вам в компьютер, и что самое главное – абсолютно добровольно с вашей стороны.

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

Приехал в офис и стал ломать голову каким образом все коннектится, ибо естественно ни в какой интернет пакеты не уходят, а ломятся на внутреннюю адресацию. В итоге оказалось, после длительных лазаний под столами и трейсов пакетов, что все замучено через так называемый wi-fi мост, с которым я морочился на уровне совмещения рутеров Linksys. Тоже самое поднимается на беспроводных точках доступа от D-link, но тут все было завернуто через оборудование Ubiquiti Networks- американского производителя беспроводного оборудования для 4G и WiMax.

До этого момента я с ними не сталкивался, и оказалось что все те мосты что я делал на указанном оборудовании- просто детский лепет по сравнению с кирогазами Ubiquiti, поскольку они используют их технологию AirMax Technology, позволяющую кидать канал в 100Мб на расстояния до 50 километров. Естественно что эти нереальные расстояния требуют специальных антенн и еще более специальных вышек, для того чтобы сигнал не гасился препятствиями, но расстояние в 2-3 километра, можно покрыть за счет стандартных передатчиков, установленных в зоне прямой видимости.

Другое дело, что для того чтобы все это реально заработало и было к тому же законно, то необходимо приобретать сертифицированное оборудование и получать разрешение гостехнадзора на организацию беспроводного моста.  Хотя вроде бы это можно обойти, если поднимать оптический мост, на лазерных передатчиках, но я что то новых решений найти не смог, кроме древнего Unlike OmniBeam 2000/4000, датированного началом 2YK. К тому же в России как я понимаю достать его, в отличии от оборудования Ubiquiti, практически невозможно. Так что вернемся к Ubiquiti Networks.

На их сайте представлено большое количество оборудования, но для наших целей построений Wi-Fi моста на стандарте 802.11 a/b/g подходит серия NanoStation или же NanoStation Loco, представляющие собой устройства с ethernet интерфейсом 10/100 BASE-TX, коим они подключаются к проводной локальной сети и способны устанавливать беспроводной мост на расстояния до 20 километров со скоростью 25Мб/с, что для терминального подключения, или прокинутого канала интерент в удаленный фоис- более чем достаточно. Также имеется более совершенное устройство Ubiquiti Rocket позволяющее поднимать скорость передачи данных до 100Мб/с.

По деньгам подобное решение получается примерно следующим:
Ubiquiti Rocket M5 стоит в районе 9к рублей, за два передатчика
Ubiquiti NanoStation обойдется где то в районе 6-7к рублей за два передатчика
Направленная антенна Rocket Dish 5G обойдется по 9к за антенну, то есть 18к рублей за прием-передачу
Ну и желательно чтобы в комплект входила грозозащита, предохраняющая активное оборудование от атмосферных разрядов, например Ethernet РГ4 PoE – районе 800 рублей за штуку

Если у нас расстояние небольшое, то мы вполне можем ограничиться парочкой NanoStation или NanoBridge с антигрозовой защитой (без приобретения дополнительных антенн), и подобное решение обойдется всего в 10-12к рублей по российским ценам за оборудование. Если же заказывать у производителя оборудования Ubiquiti Networks, то полагаю что возможно уложиться и вообще в 5-6к рублей.

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

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

Крайне желательно, чтобы пользователи не имели вообще никакого доступа к сети, кроме терминального соединения со своей машиной, на которую бы они входили зная свою учетную запись, и IP адрес компьютера, с тем чтобы левому человеку было бы сложно отсканить сетку. В этой связи необходимо создавать базу пользователей и соответствия логинов (и как следствие сертификатов) и IP адресов машин, и поскольку мы заранее знаем какой IP получит сотрудник, то и на фаерволе на виртуальном интерфейсе разрешать прохождение не все ко всем, а определенный IP удаленного клиента, на определенный IP компьютера внутри сети. И только по RDP. Никаких 135, 137 и т.д портов. Ну или же, если у вас в сети есть терминальный сервер, то всех пользователей – на терминальный сервер.

Как я это не ни люблю, но необходимо вести полное логирование безопасности- входов в домен и выходов, а также действий внутри домена.

Естественно, что для удаленного использования, оптимально было бы задействовать двухфакторную аутентификацию, основанную не только на шифровании на основе сертификата, но и на вводе пароля. Ибо если пользователь профуфыкает сертификат, то между логином и доступом в защищенное пространство сети, остается прокладочка в виде пароля. Для этого, для генерации сертификата пользователя, следует использовать команду:
# ./build-key-pass vpn-client
естественно не забывая проделывать все необходимые для генерации процедуры. Но тут мы можем упереться в пользователей не желающих вводить два пароля подряд- их конечно понять можно, но тут уже зависит от вашей настойчивости. Мне, если честно, мои нервы, в этом плане, всегда были дороже.

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

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

# cd /usr/ports/security/openvpn
# make && make install
# make clean
в логе инсталяшки видим напоминалку о том, что надо бы врубить работу пакета в /etc/rc.conf, синтаксис которого описан в файле /usr/local/etc/rc.d/openvpn. В этой связи добавляем в /etc/rc.conf следующие строки:
openvpn_enable=”YES”
openvpn_if=”tun”              # driver(s) to load, set to “tun”, “tap” or “tun tap”
openvpn_configfile=”/usr/local/etc/openvpn/openvpn.conf”
openvpn_dir=”/usr/local/etc/openvpn”
Поскольку указанных директорий и файлов у нас нет, то создаем их:
# mkdir /usr/local/etc/openvpn
# touch /usr/local/etc/openvpn/openvpn.conf
а также всю внутреннюю структуру папки /usr/local/etc/openvpn
# mkdir /usr/local/etc/openvpn/ccd
# mkdir /usr/local/etc/openvpn/keys

Надо отметить, что в работе openvpn использует openssl и его структуру, так что если мы планируем еще тщательнее защищаться, то нам надо весь фарш из папки /etc/ssl переносить в нашу папку /usr/local/etc/openvpn/ , включая как папки certs, crl, serial, private, так и  базы данных сертификатов serial и index.txt. Поскольку я бился на удаленной системе посредством ssh, а переться в офис мне совсем не хотелось, то я оставил все на месте, минимизировав перенастройку openssl.

После этого переходим к созданию сертификатов RSA, для чего следуем в папку /usr/local/share/doc/openvpn/easy-rsa/2.0 где редактируем файл /usr/local/share/doc/openvpn/easy-rsa/2.0/vars где прописываем свои настройки, чтобы этого не делать при создании сертификатов:
export KEY_COUNTRY=”RU”
export KEY_PROVINCE=”RF”
export KEY_CITY=”Moscow”
export KEY_ORG=”Peredelka”
export KEY_EMAIL=”admin@odminblog.ru”
export KEY_CN=vpn-server
export KEY_NAME=odmin_root
export KEY_OU=Adminz

После этого надо дать права на исполнение для некоторых файлов:
# chmod +x whichopensslcnf vars clean-all build-ca pkitool build-key-server build-key build-dh
после чего можно инициировать создание файлов ключей (если вы используете bash, то первую команду можно опустить):
# sh
# . vars
# ./clean-all
# ./build-ca
где собственно в диалоге уже будут прописаны наши данные, так что стоит ограничиваться только нажатием энтера.
Теперь создаем сертификат X.509 для нашего сервера, который мы указали в KEY_CN=vpn-server, при этом нам будет предложено задать пароль для обмена ключами, а также надо отметить, что переменную An optional company name [] следует задавать той же что и была указана для создания корневого сертификата Organization Name (eg, company). После этого подписываем наш сертификат своими силами.
# ./build-key-server vpn-server
Создаем сертификат X.509 для клиентской части, при этом имя клиента KEY_CN мы указываем отличным от имени сервера, например vpn-client.
# ./build-key vpn-client
Теперь генерим ключи Диффи-Холмана, которые будут использоваться при хендшейках и обмене ключами:
# ./build-dh
генерация займет некоторое время, но она идет на автомате. На последок создаем файл для TLS аутентификации:
# openvpn –genkey –secret keys/ta.key
после чего в папке keys смотрим полученные ключики, которые соотносятся следующим образом.

Ключи сервера:
ca.crt , vpn-server.crt , vpn-server.key, dh1024.pem, ta.key
Ключи клиентской части:
ca.crt , vpn-client.crt , vpn-client.key, ta.key
Серверные ключики копируем из папки создания в папку openvpn, созданную нами первоначально  /usr/local/etc/openvpn/keys, после чего переходим к редактированию файла конфигурации /usr/local/etc/openvpn/openvpn.conf
### openvpn.conf  ###
dev tun0
port 5656
proto udp
ca /usr/local/etc/openvpn/keys/ca.crt
cert /usr/local/etc/openvpn/keys/vpn-server.crt
key /usr/local/etc/openvpn/keys/vpn-server.key
dh /usr/local/etc/openvpn/keys/dh1024.pem
tls-auth /usr/local/etc/openvpn/keys/ta.key 0
client-config-dir ccd
# задаем подсеть сервера VPN
server 172.16.0.0 255.255.255.0
# Прописываем маршрутизацию на внутреннюю сетку (у меня 192.168.0.0)
push “route 192.168.0.0 255.255.255.0″
# Маршрутизация для клиента
route 172.16.0.0 255.255.255.252
tls-server
tls-timeout 120
comp-lzo
auth MD5
cipher BF-CBC
keepalive 10 120
max-clients 100
user nobody
group nobody
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verb 3
#########
Создаем файл c именем клиентского хоста, заданным при генерации сертификата:
# echo “ifconfig-push 172.16.0.2 172.16.0.1″ > /usr/local/etc/openvpn/ccd/vpn-client
при этом у нас получается подсеть для клиента с маской 255.255.255.252 которую мы указывали в файле настроек, так что в нашем случае это будет туннель с клиентской частью 172.16.0.2, серверной частью 172.16.0.1, широковещательным адресом 172.16.0.3 и адресом сетки 172.168.0.0, так что последующих клиентов эта запись будет иметь вид (в файлах для их имён и сертификатов):
ifconfig-push 172.16.0.6 172.16.0.5
ifconfig-push 172.16.0.10 172.16.0.9
ifconfig-push 172.16.0.14 172.16.0.13
если кто не понял то адресация IP идет +4

также создаем файлы журналирования:
# mkdir /var/log/openvpn
# touch /var/log/openvpn/openvpn-status.log
# touch /var/log/openvpn/openvpn.log
Открываем на нашем фаерволе входящий трафик на порт udp/5656 для того чтобы внешние клиенты могли подрубаться к нашему VPN серверу, а также разрешить прохождение трафика через интефрейс OpenVPN и внутресетвой трафик.

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

Вроде как теперь все должно работать, так что для того чтобы все запустилось- перезапускаем сервер, и настраиваем клиента на локальной машине.
На локальной машине, ставим пакет OpenVPN, который можно взять с офф.сайта. После этого сливаем клиентские файлы: ca.crt , vpn-client.crt , vpn-client.key, ta.key в папочку C:\Program Files\OpenVPN\config (или той куда ставили клиента) и создаем в ней файл клиентских настроек openvpn.ovpn, в который прописываем следующие параметры:
#### openvpn.ovpn ###
dev tun0
proto udp
# внешний IP VPN-сервера
remote X.X.X.X
# порт подключения
port 5656
client
resolv-retry infinite
ca ca.crt
cert vpn-client.crt
key vpn-client.key
tls-client
tls-auth ta.key 1
auth MD5
cipher BF-CBC
ns-cert-type server
comp-lzo
persist-key
persist-tun
verb 3
#########

После этого запускаем клиента и он автоматом ломится на наш сервак и устанавливает сессию.

Собственно на этом можно было бы закочить, если бы в сети не жили беспокойные парни, которым обязом надо поставить себе Windows 7, да еще и x64. Для запуска OpenVPN под Windows 7 следует ставить версию openvpn-2.1_rc19 (или какую нить другую от _rc15). Выкачиваем её и щелкаем правой кнопкой на инсталлер: Свойства -> Совместимость -> Запустить пакет в режиме Windows Vista , а также выставить галку “Выполнять эту программу от имени администратора“. После этого можно запускать инсталлер, который встанет без проблем, после чего на значке OpenVPN GUI надо будет также выставить, что запускать его следует от админа.

Для особо беспокойных, живущих в режиме параноик-мод, файлы ключиков, можно записать например на шифрованный диск или внешний носитель, и запускать клиент только после того как диск будет подмонтирован, тогда в openvpn.ovpn , пути настроек будут выглядеть следующим образом (сертификаты расположены в папке keys):
ca  “X:\\keys\\ca.crt”
cert “X:\\keys\\vpn-client.crt”
key “X:\\keys\\vpn-client.key”
tls-auth “X:\\keys\\ta.key” 1

При установке клиента под Линух, файл конфигурации клиента openvpn.conf должен лежать в папке /usr/local/etc/openvpn , местоположение ключиков задаем естественно из него.

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

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

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

Сегодня решив продвигаться на мауле, так как планирую попробовать продавать методику поиска тицасто-пыаристых дропов, выложил несколько халявных доменов с PR 2, дык народ даже спасибо не сказал, так что кто людям помогает, то тратит время зря.

В любом случае в активе имеются домены с историей, с тиц 10, в каталоге DMOZ, домены с PR1-2, которые предоставляю как в виде списка, так и передачей доменов в аккаунт.

С помощью стандартного сервера доменных имен BIND, настроить такой сервер, на базе любой *nix системы, можно за считанные минуты, но при этом необходимо выполнить некоторое количество телодвижений, которые я и перечислю ниже.

В файл /etc/rc.conf добавляем строку запускающую наш сервер доменных имен:
named_enable=”YES”
Открываем наш файл, отвечающий за локальных резолв /etc/resolv.conf и меняем его содержимое (вероятнее всего там стоит провайдерские DNS), на следующие строки, содержащие ваши домены:
domain  your-domain.ru
search host.your-domain.ru your-domain.ru
nameserver 127.0.0.1
для того чтобы сделать поиск доменных имен по кешу локального сервера.
Проверяем в файле /etc/nsswitch.conf наличие записи
hosts:      files dns
говорящей о том, что при резолве имен сначала будет использоваться информация содержащаяся в файле /etc/hosts, а затем запрашивать у доменных серверов, в соответствии с описанием в файле /etc/resolv.conf
После этого в файл /etc/host.conf добавляем строку
order hosts,bind
которая разрешает ту же последовательность, что и в файле /etc/nsswitch.conf
После этого переходим к настройке основного файла конфигурации любого доменного сервера, а не только кеширующего: /etc/namedb/named.conf. Для начала добавляем и раскомментируем следующие опции, идущие списком после директивы options {
Каждая строка, а также перечисление например IP адресов, должно закрываться символом точки с запятой “;”
Определяем на каких интерфейсах слушать входящие пакеты:
listen-on       { 127.0.0.1; 192.168.0.1; 172.16.0.1; };
Данную строку следует прописывать, если возникают какие то проблемы с фаерволом:
query-source address * port 53;
Также если охота поиграться с безопасностью, то можно озвучить сети, из которых разрешены запросы (сети определяем перед директивой options), а также отрубить фингерпринт и включить обработчик рекурсивных запросов:
acl “our_lanz” { 192.168.0.0/24; };
options {
directory “/etc/namedb”;
allow-recursion { “our_lanz”; };
allow-query {“our_lanz”; };
version “unknown”;
fake-iquery no;
};
Добавляем директивы запросов к DNS провайдера, для того чтобы дергать запросы из них и тем самым облегчить работу сетки:
forwarders {
NS_IP1; NS_IP2;
};
forward first;
На этом в принципе можно и остановиться, ибо все должно уже начать шуршать, после перезапуска сервера доменных имен, но для того чтобы произвести классические действия- идет в описание доменных зон и добавляем локальные зоны:
zone “.” {
type hint;
file “named.root”;
};
zone “0.0.127.in-addr.arpa” {
type master;
file “master/127.0.0″;
};
Надо отметить, что все эти файлы указываются от корневой директории named.conf, так что создаем упомянутый файл /etc/named/master/127.0.0
@               IN      SOA     host.your-domain.ru. hostmaster.your-domain.ru. (
1       ; Serial
8H      ; Refresh
2H      ; Retry
1W      ; Expire
1D)     ; Minimum TTL
NS      host.your-domain.ru.
1                       PTR     localhost.
и проверяем что файл /etc/named/named.root содержит информацию о корневых доменных серверах, в нем на самом деле много инфы, вроде подобного:
.                        3600000  IN  NS    A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.      3600000      A     198.41.0.4
A.ROOT-SERVERS.NET.      3600000      AAAA  2001:503:BA3E::2:30
;
Теперь радостно перезапускаем наш сервер доменных имен, и можем спокойно тестить или заниматься другими делами.
Тестится естественно через терзания nslookup’a:
# nslookup
Default server: 127.0.0.1
Address: 127.0.0.1#53
> odminblog.ru
Server:         127.0.0.1
Address:        127.0.0.1#53
Non-authoritative answer:
Name:   odminblog.ru
Address: 174.120.3.60

Как видно из Non-authoritative answer сервер берет эти данные из кеша, о чем нас и предупреждает этой надписью.

Yota 4G:
в районе 2к рублей за модем (PC Express или USB-stick);
~5к рублей за wi-fi точку доступа на основе технологии 3G;
тарифные планы 1400 рублей в месяц, без ограничений на скорости до до 10 Мбит/сек downstream, до 3 Mбит/сек upstream;
Также можно подключиться за 700 рублей в месяц на скорости 512кб/c down и 128кб/c up;
Про лимиты трафа не сказано, а особо искать не было желания, так что принял за то что они отсутствуют

SkyLink 3G интернет:
порядка 2к за модем (PC Express или USB-stick);
точки доступа от 8к рублей, либо рутер D-Link за 3к + к нему модем от 3к рублей;
Тарифы от 900 рублей за безлимитный город и 2500 рублей за областной на скорости 3Мбит/сек.;
При превышении трафика порога в 2Гига, скорость падает до 128кб/c

Билайн 3G интернет:
1200 рублей за модем;
точек доступа я не обнаружил;
тарифный безлимит 450 рублей до 7,2Мб/c;
По истечении порога в 2 Гбайта, скорость доступа в Интернет снижается до 64 Кбит/c.

МТС 3G интернет:
1400 рублей за модем (2к если модем еще и с wi-fi рутером);
отдельный рутер 4к – с Ethernet портом;
безлимиты 750 рублей (лимит: 500 Мб в сутки, 8Гб в месяц) и 1350 рублей (лимит: 1Гб в сутки, 12 Гиг в месяц). Скорость в районе 3,6Мб/c;
При превышении суточного порога скорость падает до 64кб/c, то 3 утра следующего дня, при превышении месячного трафика до 16кб/с до конца месяца

Мегафон 3G интернет:
Модемы тоже в районе 1500 рублей;
безлимитка начинается от 500 рублей с лимитом в 2,5Гб, 800 рублей в 4Гб и далее, на скорости в районе 3Мб/с;
При превышении лимита трафика скорость падает до 64кб/с, но лимит можно увеличть на 1,5Гб (за 150 рублей) или на 3Гб (за 300 рублей)

Исходя из всего вышесказанного, для клиента я решил выбирать между йотой или МТС’ом, так как у последнего все выглядело наиболее интересно- как в плане цен, так и в плане правил ограничения на трафик мобильного интернета, поскольку 12 гиг в месяц давали порядка 400 метров в день, чего должно было бы хватить за глаза для серфинга и чтения почты, под угрозой анальной кары для сотрудников за скачивание файлов. Йота опять же выглядела убедительно, но есть опасение, что могут возникнуть проблемы с качеством связи вне пределов Садового кольца, тем более, что на улице где сидел клиент, судя по карте покрытия сети 4G, было несколько пятен, где доступ предполагался только на открытом воздухе.

Тогда как для себя, я, с подачи друга, нашел отличный вариант безлимитного мобильного интернета от Билайна за 300 рублей в месяц. Оказалась интересная особенность безлимитного 3G интернета, в том, что все лимиты на использованный трафик есть только у авансовых тарифных планов (всюду лимит в 1Гб, после чего скорость падает до 64 Кбит/c, а у МТС, как уже писал выше до 16Кб/c), тогда как у тарифного плана с постоплатой, таких лимитов нет, и подключение к интернету происходит на скорости 256 Кбит/с без ограничений по лимиту использования. Поскольку мне 256 Кбит/с было за глаза, то я и прикупил себе постоплатный план с 0 рублей абонентки и включил на ней безлимитный мобильный интернет за 300 рублей в месяц. Пытался найти под него PCMCI модем, но ехать на савелу- было не охота, так что купил за 1200 рублей какой то китайский момед Flyer U12, который на самом деле оказался каким то УГ, ибо скорость на нем почему то была ниже, чем на старенькой Nokia, когда я догадался вставить sim-карту в неё для теста, так что вероятнее всего дело в качестве приема, и, учитывая, что я победил iPhone и могу теперь выходить в интернет через bluetooth соединение, то и надобность в этом модеме совершенно отпала.

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

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

Для Мегафона:
*151#
Такчже если звонки разрешены, можно набрать в суппорт оператора: 0500.

Для МТС:
*123#
Также можно позвонить в службу поддержки МТС: 0887.

Для Билайн:
*110#
Опять же можно отзвонить в поддержку оператора, по номеру: 0611.

Так, по инфе на вчерашний вечер, некоторых клиентов секс-шопа Sexyz.ru уже начали троллить в социальной сети “ВКонтакте”, ибо у них обнаружились какие то нереальные списки заказанных сексуальных игрушек.

Новость изначально коснулась только Яндекса, но позднее выяснилось что все эти данные также доступны и на большинстве поисковиков- Mail, Rambler, Google. Собственно как и в случае утечки информации с сайта Мегафон- индексация поисковиками стала возможной в связи с некорректной работой файла индексации интернет-магазина robots.txt.

Искренне сомневаюсь, что данная ошибка появилась вчера, скорее всего кто то из пытливых умов просто вышел на эту дырку безопасности, которому подвержена часть интернет магазинов, причем скорее всего их объединяет, помимо неправильно заполненного robots.txt, криворукие веб-мастера, которые создавали движок интернет магазина таким образом, что статусы заказов клиентов находятся в открытом доступе, и единственной защитой от индексации поисковыми системами является файл robots.txt. Надо отметить, что за подобное распространение личной информации интернет-магазин вполне реально может налететь на не плохой штраф.

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

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

Мог бы понаписать много чего еще, но пошел проверять роботсы на своих сайтах. Ибо чем Яндекс не шутит.

З.Ы: Поковырявшись на сайте вышеозначенного сексшопа и других героев ленты яндекса, обнаружил что собственно это одна и та же платформа, и как оказалось- это сугубо российская поделка Shop-Script – за который люди еще платят бобло порядка 300 американских рублей. Полагаю что после такого замечательного и главное показательного пиара в интернете, у парней их поделка будет продаваться уже менее успешно. Так что развитие ситуации было видимо таким, что кто то случайно пробил Sexyz.ru, и дальше уже по фингерпринту движка ситуация пошла развиваться дальше. Тем более что для этого даже не надо было терзать поисковые системы запросами, а просто зайти на офф.сайт shop-script.ру в раздел партнеров, где и выложена часть сайтов, использующих данный движок. Сексшопов естественно в данном списке нет.

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

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

Так что учитывая тот факт, что на Мегафон тем не менее уже подают в суд с исками в 30-50к рублей, то здесь все гораздо серьезнее и все таки у мегафона имеется своя сильная юридическая база, чего лишены торговцы самотыками, так что их однозначно будут иметь как тузик грелку. А они в свою очередь перевыставлять претензии к создателям дырявого двигла. Так что полагаю и интернет магазины, использовавшие дырявое двигло Shop-Script и самих быдлокодеров, продающих не тестированную поделку, ждет не мало приятных минут общения с судейскими.

Ну и попутно подумываю о возможности платного оказания услуг в этом профиле, занимаясь именно почтовым рассылками по базам клиентов- то есть не пуская их никуда, и проводи массовые рассылки по клиентам изъявившим получать данные рассылки. И в этой связи стал думать о повышении КПД рассылки, так как первые пробы давали порядка 10% прочитанных сообщений из всего списка отосланных писем и порядка 2-3% открытия ссылок, указанных в письме. Остальные письма даже не были прочитаны, исходя из моих счетчиков, то есть они либо попали в спам и были удалены, либо пользователь не сказал “загрузить из интернета” картинки, обращение к которым и считалось за открытие письма. В этой связи я довел до клиента свои мысли по поводу повышения кпд рассылки писем, но клиент реагировал крайне вяло и в этой связи я наметил несколько пунктов, что следует делать для повышения успешности рассылки, и чего делать напротив не надо если вы хотите провести успешную почтовую рассылку:

1. Использовать для рассылки реальный почтовый сервер, так как на встроенном smtp-клиенте вы далеко не уедите.
2. Перед массовой рассылкой писем необходимо прогнать свой сервер по списку наиболее популярных RBL листов, чтобы понять что он в них отсутствует. Если же он в них наличествует, то дать запрос на исключение его из этих списков.
4. Убедиться что у вашего почтового сервера есть PTR запись. Делается это путем ввода следующей команды:
nslookup IP
Также в инете полно сервисов которые позволяют проверить наличие реверсивной зоны.
5. При верстке письма крайне желательно чтобы это делал профессионал, знакомый с версткой именно под почтовые рассылки в интернете, так как там имеется некоторое количество особенностей отображения символов и самой верстки
6. Также желательно, чтобы письмо версталось “все в одном”, то есть изображения были бы интегрированы в письмо- делается это через задание и  описание классов изображений, но с этим вопросом лучше обратиться в пункт 3.
7. Если вы верстали сами и у вас есть изображения которые необходимо разместить на внешнем сервере, постарайтесь сделать так чтобы это был сервер клиента.
8. Крайне желательно чтобы все файлы- и счетчики, и изображения и файлы для скачивания располагались на стороне клиента, ибо если они располагаются на стороннем сервере, то это для автоматических систем, да и для пользователей, попахивает банальным фишингом, и часть автоматических систем просто заблокирует ваше письмо.
9. Никаких внешних файлов, которые пользователь должен скачать к себе на компьютер. Это лишний повод не открывать ваше сообщение. Если вы хотите от пользователя какие то действия, то организуйте форму у себя на сайте- это будет стоить лишних 2-3к рублей, но значительно повысит выхлоп от вашей массовой рассылки в интернете.
10. Перед началом почтовой рассылки проверьте вашу базу на валидность- это займет какое то время, но снизит нагрузку на ваш сервер и уменьшит базу от 5 до 10%, ибо пользователи частенько вводят не существующие адреса, или же увольняются, акки суспендятся и прочее.
11. По возможности проводите массовую рассылку персонализировано, то есть рассылайте письма с указанием поля TO, а не скрытыми пользователями, или идущими списком, так как это повышает доверие к письму, при проверке спам-фильтрами.

Искренне порадовали слова президента о сотнях миллионов потенциальных игроков, но его хмыканье на тему “для тех кто не знает” стопудово выдает чувака в теме, относящегося как раз к упомянутым “взрослым особям, часами просиживающим за мониторами”, только вот я боюсь, что вместо расслабона после работы Дмитрий Анатольевич шпилит во время и вместо рабочего дня.

Конечно было бы интересно пошпилить на арене или на просторах Калимдора против ДАМ’а, но думаю что он рассекает по просторам Азерота в сопровождении 40ppl рейда из ФСО’шников или сотрудников отдела “К”, которые просто досят атакующего. А моет и напротив, несчастного эльфийского медведа ганкают все кому не попадя и затеплилась мечат- погамать на своем серваке, да не абы как, а в миссии бога. Правда если бы народ узнал на каком серваке он играет- либо сервак бы полег от переполнения желающими поиграть с русским президентом, либо на всем реалме перебили ли бы всех медведей, включая NPC’шных.

Теперь осталось понять на каком движке поднимать мега игру, чтобы “грабить корованы”©- либо на линейке, либо перепиливать аллодов. Ибо списывать бабосы под это дело будут уже не по-деццки.

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

ПАТИ НА БАБУ-ЯГУ, НИД КОЖЕМЯКА, ДВА СТРЕЛЬЦА, БАБКА-ПОВЕДУНЬЯ, И 2 ДД ИВАНУШКА-ДУРАЧОК, ИЛИ ЕМЕЛЯ 55+ЛВЛ С СОБОЙ МОЛОДИЛЬНЫЕ ЯБЛОКИ ПО 2 СТЕКА МИНИМУМ, КОЩЕЙ-ПВП-СЭТ ИЛИ КРАБОСЕТ “ЩУЧИЙ ВЕЛЕНЫЙ” СБОР НА ОПУШКЕ ЧЕРЕЗ 15 МИН

дворф медведь опыт 2800 перелив лф аналог дприст рпал фдк
ну или как-то так

Альянс- лояльная князю дружина, византийское духовенство, купцы, монгольские наемники; Орда- волхвы, некрещеная русская знать и остальное население Руси… И аццкое пвп))

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

1. Если вы не планируете соскакивать из офиса через полгода, надо выделять место под постановку шкафа для патч-панели, на которую будет разводиться сетка, и коммутационного оборудования.
2. Если вы не можете выделить комнату под серверную, то хотя бы постарайтесь отгородить уголок где будет стоять оборудование и крайне желательно, чтобы шкафы запирались на ключик и были вне зоны действия безумных уборщиц, манагеров и прочего люда, который может выдернуть бесперебойник из сети, для того чтобы зарядить свой телефон
3. Админы не птицы, так что расшивать патч панель под потолком не самое приятное занятие. К тому же каждый раз лезть на стремянку чтобы посмотреть линкует ли кабель на неуправляемом свиче- на самом деле издевательство над инженером.
4. Оборудование имеет свойство греться, поэтому его желательно держать в комнате с работающим кондеем, а не бухгалтерами, которые летом открывают окна, так как боятся простудиться и в комнате стоит стабильные 35. Учтите что некоторые производители железа, например SUN, гарантируют работоспособность оборудования до 25 C в помещении.
5. Сетку надо разводить в одно место. Если такой возможности нет, то постарайтесь обеспечить наличие управляемых свичей, или хотя бы с гигабитными портами на борту, чтобы можно было соединить удаленные свичи по транку или же на скорости в гигабит.
6. При построении кабельной системы требуйте схему разводки, причем крайне желательно, чтобы расшивали сеть на патч-панель не как бог на душу положит, а по какому то алгоритму- например по комнатам.
7. Сетку надо кидать как минимум витой парой категории 5Е, желательно экранированной. Если вы настолько гениальны что пускаете слаботочку и силовые кабеля по одному коробу то экранирование маст-хэв. Если вы еще не поняли, то силовые кабели и слаботочку желательно вести разными каналами.
8. Гигабитную сетку оптимально разводить витой парой 6 категории. Не жлобитесь на кабельной системе- потом будите себя ругать дважды.
9. Никаких шаманств в расшитии восьмижильного кабеля на 2 джека, так как оптимальная скорость на 100Mb получается только за счет расшивания всех 4 пар. Работаю не все, но при расшитии по 2 пары- вопрос почему тормозит сетка- адресуйте себе.
10. Все провода должны заканчиваться патч-панелью, так как лапша из торчащих из стены кабелей- неуправляема.
11. Кабельную систему ведите в коробах, или фальш-потолках, полах. Никаких замуровываний кабелей в стену, так как в случае обрыва админ будет шаманить с лозой. Лучше пустите короб по полу, или же убирайте кабели в плинтуса.
12. Покупайте хорошие джеки и крамперы, так как дешевые и бракованные джеки могут портить оборудование.
13. Кабельная система должна идти одними маршрутами, а не разбегаться как тараканы по потолку.
14. Кабели в фальшпотолках убирайте в кабель-канал. Тоже самое касается и соединений офисов через нейтральную территорию. Даже убрав в него один кабель, вы практически 100% гарантируете то, что какой нить электрик офис-центра не рубанет вам сетку, перерезав неизвестный кабель.
15. Обжимайте кабели в соответствии со стандартами: европейскими или американскими. Никаких отсебятин, так как люди которые будут работать после вас, помянут вас хорошим словом, а не матерной бранью, обнаружив что вся сетка расшита по разному и выдержан только один стандарт- то что кабель прямой.
16. Не оставляйте длинных хвостов при прокладке кабеля- максимум 25-30 сантиметров. Если все таки оставили, то скрепляйте их кольцом стяжками или же теми же жилами витой пары.
17. Старайтесь избегать изломов кабеля.
18. Если вставляете розетку, то расшивайте её, а не сворачивайте кабель.
19. Подписывайте розетки и патч-панели. Каждый раз лезть в схему очень быстро надоедает.
20. Разводите всю СКС витой парой, так как в последствии будет проще эксплуатировать.
21. Прежде чем разводить кабельную систему- правильно посчитайте количество компьютеров и сетевых устройств в комнате, после чего добавьте еще 2-3 розетки.
22. Если внедряете какие то свичи или хитрые комбинации из кабелей- не ленитесь отображать это на схеме сети. Схема сети обязательна для наличия, так как на разведку боем новый админ потеряет  от пару дней до недель.

Вроде пока все что пришло в голову, если вспомню что то еще, то допишу позже.

Век информационных технологий во многом обязан развитию компьютерных сетей. Речь идет о компьютерных сетях разного масштаба, которые превратили информацию в ещё более дорогостоящий товар, чем ранее. Существует два типа компьютерных сетей, о которых вы можете слышать каждый день. Одна из них называется, конечно, «Интернет», а другая, которая может применяться в вашей компании, «Интранет». В этой статье мы сравним две сети и расскажем о различиях между ними.

Фундаментальное понятие Интранет и Интернет сводится к компьютерной сети. Компьютерные сети позволяют обмениваться ресурсами и информацией между группой компьютеров. Первая оперативная компьютерная сеть была создана для департамента обороны США и была известна как «Управление перспективными исследованиями сети» (ARPANET). С тех пор, сетевые технологии и архитектура сети превратилась в сложную и изощренную систему, результатом которой стал Интернет. Передовые компьютерные технологии, вместе с набором программного и аппаратного обеспечения сделали такую сеть возможной. Как вы увидите дальше, Интранет и Интернет являются наиболее сложными сетями.

Определение

Интранет или интрасеть подразумевает внутреннюю частную сеть компьютеров или объединение нескольких компьютерных сетей, использование и доступ к которым ограничивается рамками одной компании и её сотрудников. Передача данных по такой сети управляется протоколами Интернета, как HTTP и протоколами передачи данных компании. Подобные сети применяются для облегчения коммуникации внутри компании. В отраслях, специализированных на информационные технологии, наличие интрасети становится необходимым элементом успешного бизнеса, поскольку их деятельность включает огромное количество обмена данными.

Сам факт того, что вы получаете доступ к информации по средствам Интернет, говорит о том, что вы уже представляете возможности международной сети, которая предоставляет вам свои услуги. Возьмите небольшую компьютерную сеть, которая покрывает незначительную область вашего города, а затем интегрируйте её с другими таким же небольшими сетями в форме локальной сети. Теперь интегрируйте все локальные сети для формирования глобальной сети компьютеров. Следующим шагом интегрируйте глобальные сети в национальные сети, а затем объедините все национальные сети вместе и получите Интернет! Это единая сеть, соединяющая все компьютеры мира с помощью интернет-протоколов, которые делают обмен информацией и маршрутизацию возможными. Главное различие между интрасетями и сетью Интернет в том, что первую могут представлять сотни компьютеров, в то время как вторая объединяет более миллиарда компьютеров и покрывает весь мир.

Структура, масштаб и сложность

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

Управление сервером

Одно из самых фундаментальных различий между Интранетом и Интернетом заключается в управлении сервером. Интранет контролируется одним сервером, который адекватно справляется со всеми задачами. Принимая во внимание, что Интернет управляет связью со множеством компьютеров по всему миру, представьте количество обслуживающих серверов. Виною тому огромные объемы данных, которые хранятся и обмениваются в сети Интернет, что делает крайне важным децентрализованные сервера. Есть разница между управлением городом и нацией? Децентрализация имеет огромное значение.

Использование

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

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

Собственно памятуя о том, что в XP это делалось через патч драйвера termsrv.dll (если вероисповедание не позволяет использовать  какую нить GPL вроде UltraVNC или TightVNC), который был выдернут из XP SP2 beta, где ограничение на количество подключенных столов отсутствовало, то я решил погуглить на эту тему, и довольно быстро нарыл такую же приладу для Windows 7, которая собственно патчит вышеозначенную утилиту после чего многопользовательский вход через терминал становится доступен для администратора системы и группы пользователей удаленного рабочего стола. Собственно прилада для версии 32 бита и версии 64 бита. Причем судя по всему она использует те же библиотеки, так как на форумах народ пишет, что пользовали как раз старую библиотеку.

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

shutdown -r  (не перепутать с ключиком -s, иначе нам придется пилить в дальний офис)

После этого получаем полноценный сервер терминалов, но по крайней мере в XP количество максимальных соединений было ограничено 3 конкурирующими сессиями, так что разгоняться больше 3-5 пытаться не стоит. Единственно, что если мы хотим мочить удаленных пользователей из под админа терминальной машины, нам необходимо отключить контроль учётных записей UAC в Windows.

А вот тут начинается самое интересное, так как в функционале удаленных рабочих столов Windows Server 2008+ появился интересный функционал Terminal Server RemoteApp, позволяющий запускать удаленные приложения на клиентской машине, без использования терминальной консоли, что позволит нам снизить нагрузку на трафик, так как нам не придется отрисовывать все плюхи, а также обрезать дикому юзверю весь иной функционал. Собственно имея все это в Server 2008 можно было бы предположить что этот же функционал доступен и на Windows 7. Только в случае рабочей станции он отключен, и его необходимо подключить в реестре, для чего, на удаленной машине (уже сервере терминалов), идем в ветку реестра:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\TSAppAllowList
где меняем значение параметра fDisabledAllowList с 0 на 1, после чего в этой же ветке создаем папку с названием Application (вроде можно и произвольное название) в которой создаем подпаки приложений доступных для запуска с удаленного сервера терминалов, путем создания строковых параметров:
Name – имя приложения
Path – директория приложения (именно директория, а не полный путь до файла)

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

remoteapplicationmode:i:1
remoteapplicationprogram:s:имя бинарника приложения
disableremoteappcapscheck:i:1
alternate shell:s:rdpinit.exe

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

Тогда приходится влезать в это болото, которое называется маршрутизация средствами Windows платформ. Для начала посмотрим что  у нас прописано в таблице маршрутизации на сервере. Входим в терминальную консоль cmd и даем команду:
> route PRINT
которая нам высветит список имеющихся в системе интерфейсов, таблицу маршрутизации и постоянные маршруты. Кстати точно эту же картинку можно получить и командой:
> netstat -rn
Теперь собственно мы можем добавить статический маршрут, средствами командной строки. Предположим что нам надо срутить пакеты в сеть 172.16.0.0/24 через внутренний маршрутизатор 192.168.10.250, для чего задаем следующую команду:
> route add 172.16.0.0 mask 255.255.255.0 192.168.10.250 if 1
на самом деле можно со спокойной совестью опустить, маршрут подцепится и без этого, просто пакеты будут рутиться через внутренний интерфейс 127.0.0.1. Для того чтобы удалить данный маршрут достаточно сказать:
> route delete 172.16.0.0
При добавлении машртура мы можем получить загадошное сервисное сообщение “Запрошенная операция требует повышения”, для чего правой клавишей шелкаем в иконку командной строки и говорим “запуск от имени администратора”.
Но вся беда с том, что такие маршруты живут до следующей перезагрузки, поэтому нам необходимо сказать чтобы маршруты сохранялись на потсоянной основе, для чего задаем ключик -p:
> route -p add 172.16.0.0 mask 255.255.255.0 192.168.10.250

Собственно для меня это наиболее удобный вариант, так как не требует ковыряния с системе, да и подходит как для Windows Server, так и для простых рабочих станций под управлением виндусни; но особо беспокойные умы могут  воспользоваться на MS Server службой Network Policy and Access Services, для чего идем в Диспетчер сервера -> Роли -> Добавить роли -> Службы политики сети и доступа -> Маршрутизация (автоматом добавится Служба удаленного доступа) после чего уже в оснастке управления маршрутизации через правый клик на имени сервера включаем машрутизацию и, зайдя в раздел Статические маршруты прописываем необходимые нам маршруты. Там же можно настроить и политики прохождения пакетов (вкладка Основное, свойства интерфейсов), а также динамическую маршрутизацию, путем добавления RIP или IGMP протоколов.

Обычно я это делал средствами DBmailAdmin, но на этом серваке мне его ставить было ломы, ради управления 10ю пользователями и поэтому я там ничего кроме белки (ака squrellmail) не поднимал, так что пришлось ковыряться из консоли.

Делается это естественно с помощью утилиты dbmail-users, но без использования самого пользователя, а только на уровне алиасов сервера. Для добавления перенаправления (форварда) адреса, говорим:

# dbmail-users -x alias@local-domain -t forward-mail@external-domain

Для того чтобы удалить это перенаправление почты, задаем:

# dbmail-users -x alias@local-domain -T forward-mail@external-domain

*** Кстати в процессе ковыряния нашел интересный вариант как безусловно переправить всю почту с одного ящика на другой:

# dbmail-export -d -u orphaned-user -m orphaned-mailbox

В данном случае ключик -d еще и потрет всю почту в ящике

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

Так что не боясь предстать капитаном очевидность в этот раз я распишу как организовать программный маршрутизатор средствами FreeBSD. И хотя писалось все это еще под 4.2, но тем не менее и под 7.4 все эти же рецепты применимы, разве только с той разницей, что все пакеты отличаются версиями с большую сторону. Сказать откровенно, я предпочитаю программные маршрутизаторы за их дешевизну, простоту и быстроту в настройке, поскольку для программного маршрутизатора сгодится любая древняя машинка, главное чтобы в ней была возможность поставить дополнительные сетевухи. При этом программный маршрутизатор отличается от аппаратных аналогов тем, что произведя один раз настройку маршрутизатора вы следующий настроите уже за полчаса, а не будите копаться в мануалах нового для вас агрегата, купленного клиентом с оказией, не понимая почему це фича вдруг оказалась багой. К тому же вменяемый аппаратный маршрутизатор стоит не малых денег и вполне сопоставим по стоимости с хорошим компом, который помимо того что будет с сотни раз мощнее, также при этом сможет, естественно при желании, стать принт-сервером, фаерволом, проксей, поточным антивирем и еще чем угодно, и что самое основное- это решение маштабируемое, то есть добавление нового интерфейса сопряжено с гораздо меньшими затратами, нежели при попытке расширения аппаратного маршрутизатора, главное подобрать материнку с 2-3 слотами под сетевуху, ибо найти две интегрированные не проблема. И естественно формула скорость работы/цена для программного маршрутизатора будет на порядки ниже аппаратного, так как стоимость гигабитного маршрутизатора уже будет сопоставима с покупкой мощного сервера для офиса. Ну это просто вода относительно того за что я люблю программные рутеры, а теперь собственно перейдем к самой настройке маршрутизатора.

Для начала устанавливаем систему FreeBSD 7.4 и настраиваем её в соответствии с нашими требованиями, то есть можно настроить как защищенную систему если она торчит в инет, или служит для защиты серверной фермы от локалки; ну а ленивцы могут ограничиться просто установкой нужных пакетов, если она будет служить просто для маршрутизации пакетов между сетями внутренней сети предприятия.

Собственно для начала имеем две сетки: 192.168.0.0/24 (основная) и 192.168.10.0/24 (дополнительная) которые нам и надо совокупить посредством нашего настроенного сервера FreeBSD, в который мы же загодя воткнули две-три-четыре и более сетевых карт (максимум который у меня прекрасно существовал было 5 сопряженных сетей, не считая вирутальных интерфейсов). Предположим что для сетевых интерфейсов мы выбрали IP адреса: 192.168.0.1 и 192.168.10.1

Смотрим что за интернерфейсы установлены в системе:
# ifconfig
тут нам главное понять какой интерфейс какой, для чего не плохо было бы ознакомиться с чипами карт. Порядок интерфейсов обычно идет от проца к периферии, а у дополнительных интерфейсов в зависимости от нумерации слотов, возрастая от видюхи. Но проверить все это можно эмперическим путем просто воткнув рабочий кабель в систему, посе чего интерфейс перейдет из статуса status: no carrier в status: active. Предположим у нас в системе два интерфейса rl0 и rl1.
Поняв какие интерфейсы будем сопрягать, идем в /etc/rc.conf и добавляем необходимый интерфейс, так как там уже должен присуствовать один из интерфейсов, если в процессе настройки системы FreeBSD мы поднимали сетку.
##### /etc/rc.conf #####
ifconfig_rl0=”inet 192.168.0.1 netmask 255.255.255.0″
ifconfig_rl1=”inet 192.168.10.1 netmask 255.255.255.0″
#####################
Чтобы поднять теперь интерфейс, выполним
# /etc/netstart
Второй интерфейс rl1 ожил и теперь пингуется из подсети 192.168.10.1, но для того чтобы сервер настроить как маршрутизатор необходимо в ядре разрешить пересылку пакетов между пакетами, за что отвечает парметр net.inet.ip.forwarding. Его значение в системе в данный момент:
# sysctl net.inet.ip.forwarding
net.inet.ip.forwarding: 0
где значение 0 означает что маршрутизация запрещена, поэтому для включения функционала маршрутизации, нам необходимо присвоить этому значению 1, для чего выполняем:
# sysctl net.inet.ip.forwarding=1
net.inet.ip.forwarding: 0 -> 1
Теперь настройка маршрутизации завершена и маршрутизатор будет фурычить до перезагрузки системы, после чего значение net.inet.ip.forwarding переключится обратно в 0. Для того чтобы избежать этого добавляем в файл /etc/rc.conf следующую строку:
gateway_enable=”YES”
после чего уже безбоязненно можем перегрузить машину.
При такой схеме наш маршрутизатор будет рутить только сопряженные с ним сети, представленные интерфейсами, или же алиасами на интерфейсах, в том же случае когда у нас в сети уже существуют маршрутизаторы, прикрывающие еще какие то сети, то тогда поднимаем на нашей машине статическую таблицу маршрутизации. Делается это также в файле /etc/rc.conf
##### /etc/rc.conf #####
static_routes=”network1 network2 network3″
route_network1=”-net 10.10.15.0/24 192.168.0.25″
route_network2=”-net 172.168.10.0/24 192.168.0.25″
route_network3=”-net 192.168.168.0/24 192.168.10.111″
#####################
то есть мы задаем названия маршрутов, которые дальше выводим в виде сетки, и внешнего, для нашего маршрутизатора, интерфейса шлюза.
Также в случае использовании настроенного сервера FreeBSD в качестве внутреннего маршрутизатора, необходимо на внешнем шлюзе, заданном для рабочих станций и серверов сети дефолтным маршрутом, поднять маршрутизацию на внутреннюю сеть задав маршрут в 192.168.10.0, через 192.168.0.1. На самом деле тут обычно и возникает самый косячный момент, особенно в случае использования интернет шлюзом аппаратных фаерволов типо D-Link, у которых вроде функционал рутинга имеется, но чтобы настроить удаленный маршрут надо долго и упорно танцевать с бубном, так что гораздо проще для нашего уже настроенного маршрутизатора задать дефолтовым маршрутом интернет-шлюз, а все машины предприятия завернуть на него- это добавит лишний хоп, но уберет проблему настройки маршрутизации на сторонних серверах.

И вот собственно при попытке их вытащить с многострадального хостинга, выяснилось что сделать это не представляется возможным, так как при трансфере стандартным leechftp которым я пользовался стопяцот лет, русские названия превращаются в нечитабельную крокозябру, так что трансфер по ftp на русском превратился в серьезный головняк, так как выяснять какие файлы какие и потом их переименовывать (как мне посоветовали веселые разработчики) было реально сизифовым трудом. Опять же загоном сайта в архив эта проблема не решалась, так как файлы в архиве тоже были со сбитой кодировкой. Поэтому пришлось задуматься в чем проблема того что скачать ftp на русском не представляется возможным.

А оказалось что проблема в том, что кодировку utf-8 поддерживает весьма небольшое количество ftp-клиентов, так что следующим этапом стал поиск удобоваримого клиента, в резьтате чего сформировался следующий список:

SmartFTP
FileZilla (вроде как в варианте патченной версии)
плагин к FireFox- Fireftp
Lftp
FTPRush

Из них я попробовал несколько штук, и остановился на SmartFTP- правда к сожалению данный клиент является коммерческим, что подразумевает что за него надо бы платить денег. Так как с FileZilla у меня возникли таки траблы с переносом файлов, Fireftp эпизодически задумывалось о судьбах рунета, в вот SmartFTP работал отлично, так что в данный момент я использую исключительно его, в том числе и для работы с файлами по ftp на русском, поскольку решать проблему русскоязычных файлов никто не захотел. SmartFTP оказался отличным ftp-клиентом, который помимо возможности скачать ftp на русском позволяет выполнять все необходимые для ftp-клиента функции: качать, переносить директории и файлы без трансфера на удаленную машину, редактировать удаленные файлы, менять права и многое-многое другое. Единственный вскрывшийся глюк оказался в том, что при редактировании файла на локальной машине- следует убирать выделение с файла, так как он, при попытке сохранения изменений, будет удален.

Сказано- сделано. Сначала я попробовал пойти по пути наименьшего сопротивления и попытался выискать субподрядчика на данный сервис, но все услуги начинались от 4-5к рублей, при этом ты не мог быть уверен в том, что твоя база далее не пойдет по рукам, и памятуя о том, что хочешь завалить дело- поручи его другому, я полез искать программы для массовой рассылки по интернету.

Поискав софтину для этого дела, я перепробовал несколько программ для массовых рассылок писем, как российских, так и зарубежных компаний, но остановил свой выбор между Atompark ePochta и AMS Enterprise, о которых расскажу несколько позже, но обе программы заслуживают своего внимания, тем более что ePochta, практически в три раза дешевле AMS, хотя в качестве программы для организации почтовых рассылок в интернете AMS выглядел более мощным продуктом. На самом деле, программ для массовой рассылки писем не так и много, ибо большинство рассылок что я видел в инете крутятся около 10-20к адресов, так что я со своими 200к был похож на героя фильма “Как потратить миллион долларов”. Но так или иначе погоняв какое то время обе программы для массовой рассылки писем, я остановил свой выбор на AMS Enterprise. Следующим этапом я более-менее ознакомился с её интерфейсом и основными возможностями, о которых расскажу позже, а пока могу заметить что мне крайне понравилась возможность подтягивания различных форматов в качестве шаблонов письма, а также крайне удобный редактор писем и возможность организации нескольких рассылок одновременно, к тому же, как оказалось имеется отличный модуль сбора статистики по просмотрам писем и открытию ссылок, правда требующий отдельного хостинга.

Поскольку макет мне скинули в ворде, а переверстывать мне совсем не хотелось, ибо с этого дела я не имел ничего кроме геморроя накануне увольнения, то я конвертнул его в *.mht формат, предполагающий веб документ “все в одном”, и подтянул его в AMS. Но тут меня ждал сюрприз, ибо картинки не отображались, так как полюбас ссылались как и в стандартном html’е на диск Ц. Тогда я захостил картинки для почтовой рассылки на тестовом сервере, наскоро переверстал макет, сославшись на внешний ресурс и все отлично запустилось. Единственно возникла проблема с одной картинкой, которая не отображалась в MS Outlook от 2007 версии, как выяснилось из-за того что в Word’e она была вставлена не сразу в таблицу, а сначала помещена в форму, куда уже и вставлялась картинка. Убрав форму и вставив изображение сразу в таблицу, наконец таки получил требуемый результат. Но тем не менее в процессе переверстки столкнулся с тем, что по непонятным причинам, после правок, например дублировались блоки изображений, или добавлялся какой нить тупой фрагмент кода, который убирался только путем экспорта во внешнюю программу и верстки html кода там. Но так или иначе верстка была побеждена и пришло время переходить к самой рассылке как таковой.

В обоих программах присутствует встроенный smtp-сервер, но памятуя о своих экзерсисах относительно борьбы со спамом, я понял что мне для проведения качественной массовой рассылки почты, нужен как минимум callback и нормальный резолв хостнейма, а как максимум PRT-запись о моем серваке, так что я начал поиск того, что в простонародье именует anti-abuse или bulletproof хостинг, то есть хостинг кладущий болта на абузы- жалобы спамополучателей  на то, что данный сервер хостит сайт спамера. Но меня данный сервис интересовал в первую очередь в плане предоставления SMTP-relay через который я мог бы произвести рассылку, и как приятное дополнение, захостить 5-6 картинок и скрипт статистики, на который ссылалось письмо для учета прочтений и открытий ссылок. А таких контор оказалось не так много, и большинство из них естественно первым же вопросом спрашивали, что будите рассылать и просили предъявить письмо. Вообщем, облазив пол инета нашел я 6-7 компаний, чьи цены начинались от 60 грина (как собственно и антиабузные серваки) за единоразовую рассылку и доходили до 800 баков. Почти все они были просто какими то людьми из инета, представленными номерами асек на форумах, и только двое имели фронтэнд в виде хостинг конторы. Поскольку мне не хотелось попадать на 4-5к рублей, я собственно и отдал предпочтение одной из двух контор, после чего мне выделили smtp-сервер и я провел через него пробную рассылку. Наиболее неприятный момент оказался в том, что сервак хостера, видимо в целях того чтобы не светиться, довольно тормазнуто реагировал на отсылку писем, так что тестовые письма шли по 20-30 минут, и это вызывало некоторые опасения в том, что при отправке 200к почтовых сообщений, я просто интеллигентно уроню очередь почтаря. Перед тем как башлять деньги за абузоустойчивый хостинг, рекомендую взять его на тестирование и прогнать IP адрес по RBL листам, с тем чтобы посмотреть – не находится ли он, случайно в базах спамеров, так как даже в случае дедика вам предлагают уже юзанный кем то IP, так что не известно что с него делали до вас. Это займет может быть час – полтора от силы, но зато вы будите абсолютно уверены в том, что ваша рассылка не уйдет в молоко.

Также вскрылся не понятный глюк с 2003 Outlook’ом в который письмо, отправленное через данного хостера, приходило в виде кода, а не сверстанного письма, так что видимо сервак каким то образом менял заголовок письма, который и вышибал нормальное отображение емаила, при том что в остальных версиях Outlook все выводилось нормально. Нагнув слегка суппорт хостинга, я получил требуемый результат и стартанул рассылку, которая заняла у меня порядка 11-12 часов.

Кстати, еще на этапе тестирования, также вскрылся косяк со сбором статистики AMS Enterprise, так как на попытку подтянуть удаленный лог (который кстати не создавался скриптом статистики amsweb.php самостоятельно, так что пришлось его создавать ручками) программный модуль AMS отвечал “ошибка MakeCopy” и не показывал никакой стотистики. На оффсайте AMS Enterprise сказано что надо задать права 755 на папку и на скрипт, но это ничего не дало, тем более что на логфайл надо давать права 777 для нормальной записи в него. Так что пришлось после проведения рассылки парсить лог руками с целью выяснения количества просмотров и открытых файлов, но во-многом благодаря программе Notepad+ этот процесс не стал большой проблемой.

На всякий случай массовую рассылку писем, все же лучше производить поэтапно, разделив большую базу адресов на небольшие сегменты по 20-30к. Это несколько гиморойнее, но спокойнее, так как в случае если прога вылетит с ошибкой, что надо признаться, все же случается- не придется вычислять примерное количество адресов, что надо удалить из списка, для продолжения прогона.

Ну что сказать в итоге? Как оказалось- основной проблемой при организации массовой рассылки в интернете, является  не сама рассылка, а процесс подготовки к ней и особенно верстка макета, с учетом того что письмо должно выглядеть в различных почтовых клиентах приемлимо, так что текстовая рассылка является наиболее простым вариантом. К тому же, в душе затеплился алчный огонек, учитывая стоимость данного вида услуги и время которое она занимает в плане работы, ибо сама рассылка- осуществляется без тебя, при нормальной настройке таймаутов и потоков. То есть в виде заработка это довольно перспективное занятие, но откровенно говоря только в плане рассылки писем адресатам, которые готовы к получению данного сообщения и не будут жаловаться и костить тебя по чем свет стоит. Но тут сразу же возникает вопрос ценообразования, ибо если просить мало, то к тебе потянутся всякие перцы, которые будут пытаться втюхать тебе рассылку спама, закамуфлированного под новости фирмы, а если ломить 2-3 конца, чтобы спамеру было не выгодно к тебе обращаться- это отпугнет, в лучшем случае, часть клиентов.

Итак для начала мы ставим винды, предположим это будет win7 pro. Естественно гораздо проще бы было поставить какой нить user-friendly Linux, врубить родной фаервол, добить это дело кем нить вроде eset или clamavd и работать под юзерскими правами- это бы значительно упростило жизнь мне, но не конечному пользователю (всем любителям пофлудить на тему: я пользователь линукс и хочу поинтересоваться, что такое вирусы- рекомендую погуглить на сабж: пару сотен, причем червей, найдете довольно быстро), тем более что хорошо заточенный винюк не сильно опаснее прикрытого линуха, и уж стопудово лучше MacOS без анттвиря.

Итак, поставив Windows 7, следом ставим Firefox 4 и навсегда прощаемся с Яшей ака IE. После этого прикручиваем к FF дополнение noscript, которое будет висеть в трее бродилки и ругаться на все опасные и не очень интерактивы. Затем ставим фаервол Comodo Firewall Pro и следом за ним Eset Smart Security. Если вам жалко заплатить за хороший, не тормозной антивирь 600 рублей, то можете конечно поставить антивирус от того же Comodo, или какой либо другой на ваш вкус- я предпочитаю именно эту связку, перейдя на нее года четыре назад с Outpost Firewall+Eset,  в те прекрасные времена когда аутпост отправлял core2 в BSOD при использовании Firefox. И надо признаться, что за все это время ни разу не имел каких либо проблем что под XP, что под семеркой. Хотя тут опять же надо заметить, что мои наиболее неспокойные клиенты все же умудрялись ловить различных ботов, но об этом ниже. После установки этой связки, не перегружая машину, дружим оба программных продукта, добавляя их в исключение друг к другу, иначе при загрузке машины вы станете свидетелем двухактовой трагедии ‘чужой против хищника’, в которой всегда выигрывает Eset. Да, перед установкой всего этого богатства, отключите встроенный виндовый фаервол, ибо этому фейку не место на нормальной машине.

После этого ставим Comodo в режим обучения, отвечая ‘да’, только если вы инициировали подключение или понимаете о чем разговор. После недели терзаний фаервол можно спокойно переключать в safe mode. Затем устанавливаете хорошую тулзу Search-and-Destroy которая будет следить за всякими адварями и мальварами, а также отлавливать попытки изменения конфигурации машины.

Ну и теперь переходит к основной части марлезонского балета: качаем себе бесплатную виртуальную машину Sun VirtualBox или VMWare Player, которую благополучно и ставим на свою рабочую станцию. После чего устанавливаем в нее винду-мак или линух, создаем на диске копию виртуальной машины, и уже из под виртуалки спокойно лазим по тем самым сайтам, с которых и начиналась наша эпопея.

Если тема с виртуалками вам по той или иной причине не подходит, то создайте себе для работы пользователя с ограниченными правами, из под которого вы будите работать или хотя бы лазить в инет.  После чего настройте себе хранение всех документов, почты и всего прочего на дополнительном разделе или жестком диске, доставьте все нужные программы и сделайте резервную копию системного раздела, что бы в случае серьезной заразы откатиться к работоспособной версии операционки за 15-20 минут. Копию системного диска можно сделать с помощью Acronis True Image, и держать резервную копию естественно также на дополнительном разделе, чтобы после просто загрузиться с диска True Image и перезалить систему.

Ну и на десерт основные правила инет-серфинга: все вышеуказанные действия, кроме настройки виртуальной машины, совсем не панацея, ибо они лишь призваны помочь пользователю сохранить свою машину в безопасности, но безопасность сама по себе- это комплекс мер, включающий помимо настройки всех необходимых сервисов, также и включение головы пользователя, который не должен скачивать и устанавливать какие то программы и утилиты из неизвестных источников, использовать ломанные программы желательно также в виртуальном окружении, поскольку зачастую ломалки содержат всевозможные трояны, не устанавливать дополнительные кодеки, которые вам предлагают установить для просмотра того или иного ролика, ибо это с вероятностью 100% будет попытка подсунуть вам злонамеренный код, не кликать по всевозможным popup окнам и прежде чем нажимать на “ДА”- читать что вам предлагают или спрашивают. И естественно ходить по проверенным ресурсам, ибо большая часть порева является так называемыми саттелитами, на которых хитроумные вебмастера не размещают ничего кроме рекламы партнерского сайта, а в последнее время, в связи с расширением бизнеса редая, вешают те самые программные модули, которые при заходе на сайт потенциальной жертвы, сами устанавливаются на компьютер пользователя и начинают просить денег на лечение. Так что подытоживая все выше сказанное хочу заметить, что лучшая защита от вирусов и ботов- это не антивирус, а голова и здравый смысл пользователя.

В итоге ребутнули сервак ESXi, все поднялось, так что вечером я выехал на удаленную площадку. Прибыв на место, немного пошакалил по свичам, ибо решил было, что проблема крылась в них, но все было вроде нормально, так что я приступил снова к настройке Untangle. Надо отметить, что я, как истинный российский одмин, хотя и веселюсь на эту тему, некоторое время уже как читаю мануал только после того как все сломалось, так что в данном случае я полагал, что официального wiki how-to-install untangle вполне достаточно для того чтобы поставить платформу. Стартанул сервак на ESXi, и как только, судя по процентным соотношениям загрузки, платформа запустила сетевые интерфейсы у меня снова полегла сеть. Это меня подвигло в совершеннейшие не понятки, поскольку сеть лежала наглухо- то есть она отсутствовала как класс- пинги не проходили даже до свича, в который была воткнута машина, не говоря уже про какие то шлюзы и сервера, сидевшие на соседях по каскаду. Рубанув сервер, снова поднял ESXi и удалил с него Untangle, решив поднять его в тестовом варианте у себя на машине. В итоге на след. день, подняв его в оболочке VMware Workstation я так же радостно положил сетку своего офиса, но поскольку доступ к виртуальной среде у меня уже был не по сети, то отрубив интерфейсы на виртуально машине, я полез в инет с извечным вопросом “whatafuck?”.

Оказалось, что в платформе Untangle реализована технология Re-Router (до этого мне с ней как то не доводилось встречаться), благодаря которой данная платформа безопасности  интегрируется в существующую сетевую топологию без каких либо дополнительных перенастроек инфраструктуры, путем заворачивания на себя всего трафика на уровне L2 протоколов. Примерно тоже самое происходит при уязвимости men-in-middle, когда машина внутри сетки производит так называемую атаку ARP spoofing, отвечая на все ARP broadcasts “ЭТО ЙА!” и тем самым беря на себя функционал центрального шлюза и вообще всех машин в сетке, так что в ARP таблице свичей все пакеты замыкаются на интерфейсе Untangle,и даже после падения платформы трафик не будет проходить до динамического изменения ARP таблицы.  Данная технология интегрирована в ядро, и в первом приближении не отключабельна, так что на форуме Untangle тамошние спецы рекомендуют относиться к ней как к данности, и в этой связи, в обязательном порядке, использовать на сервере два интерфейса, даже в случае необходимости использования одного- как в моем варианте VPN-сервера. Но в этом случае рабочий интерфейс надо делать внешним, а внутренний переводить в режим bridge и бриджевать его на внешний интерфейс
Настройка в админской части Untangle: Config -> Networking -> Internal Interface
Config Type: bridge
Bridge to: External (static)

Кстати таким же образом можно организовывать проброс трафика к внешнему шлюзу, но это уже другой разговор. В случае виртуальной машины, как у меня, я просто добавил в работающую конфигурацию еще один интерфейс, подтянул его встроенным detect’ом и привязал к внешнему интерфейсу, после чего лежащая сетка ожила в течении 30 секунд. Еще в течении 15 минут поднял VPN-сервер и настроил подключение. Самое приятное, что openVPN сервер сам генерит клиентскую часть, так что просто логинимся через бродилку к VPN-серверу, заходим внутрь и из настроек openVPN сервера, раздела Clients, говорим для определенного пользователя Distribute Client, после чего либо скачиваем его по приложенным ссылкам, либо отправляем его на email который можно вписать в форму отправки. Клиент после установки получает полностью настроенный OpenVPN клиент, не требующий уже никаких вводов логина и дополнительных настроек.

Почитав немного про Untangle на их оффсайте, пришел в неописуемый восторг, поскольку производитель этого open-source продукта предлагает большое количество бесплатных, и платных модулей к своему решению, построенному на базе Debian GNU/Linux. Само по себе решение очень классное и представляет наборный шлюз, который поднимается в минимальной конфигурации и управляется через веб-консоль, при этом давая возможность сисадмину подключать и отключать те или иные модули, предлагаемые в виде дополнительного софта: spam blocker, phish blocker, spyware blocker, web filter, kaspersky antivirus, commtouch spam booster, wan failover, wan balancer, virus blocker, IPS, protocol control, firewall, captive portal, ad clocker, policy manager, directory connector, openVPN, attack blocker, bandwidth control, web cache и некоторое количество тулзов для управления.
Самое главное, что часть основных блейдов (по аналогии с checkpoint назову их так) предоставляется бесплатно- это фаерволл, openVPN, web filter lite, virus/spam/attack/phish/spyware blocker. Остальные можно поставить на 14дней и поковырявшись, прикупить себе уже в нормальное использование- меня например сразу заинтересовали bandwidth control и wan failover поскольку воротить такое руками муторно, а у производителя Untangle эти решения стоят по:
630 баксов на три года за bandwidth – позволяющий QoSить и лимитить юзверей по использованию канала;
126 баксов за три года wan failover, позволяющего построить полноценный isp redundancy, который у checkpoint например стоит полтора косаря за год;
модуль Каспера, позволяющий поднять полноценное сканирование на ходу от всевозможных угроз на всем многообразии протоколов, обойдется в 252 бакса на три года;
полноценный Web-filter выйдет в 630 грина на три года, при том что фильтрует по 53 категориям, на 20 языках, и держит в базе на данный момент около 450М веб-сайтов.
Управление порталом очень удобное и более того- он встает как на стандартную машину с минимальной конфигурацией: P4 Processor (или аналогичный AMD), 80 GB HDD, 2 NIC и 1 GB RAM; так и на VMware Workstation и ESXi- единственный момент что в случае ESXi надо заводить ручками диск и карточки, так как Untangle не понимает vmware дрова использующиеся платформой ESXi, поэтому пришлось драйв ставить BusLogic, а сетевухи e1000.  На Workstation же встал без проблем (кстати на том в 16 гигов), в течении буквально 10-15 минут элементарного инсталлятора.  Также на сайте компании, предлагается приобрести у них либо сервак, спецом заточенный под платформу Untangle, либо же специальную UTM’ку их же производства.

Но вот после установки на сервер, начались довольно интересные грабли, о которых я расскажу несколько позднее.

Но в процессе запуска- выяснилось что машинка не подхватывает IP адрес по DHCP, при работе в bridged mode, а при попытке задать статический IP я получал ругань на тему того, что данный IP уже используется, при том что данный адрес был однозначно свободен. Озадачившись данной проблемой проверил на всякий случай фаервол винды, но как оказалось он был отключен. Поковырявшись в меру возможностей в серваке и vmware, решил не озадачивать клиентского админа, а переставил Player на Workstation и попробовал поднять виртуалку в таком варианте. Но проблема осталась той же самой, при этом когда я переключил сетки в NAT вариант-  поднимался внутренний IP и все начинало нормально шуршать.

В итоге обратился к админу с описанием проблемы и предположением о том, что какая то тулза препятствует нормальному прохождению пакетов, выступая видимо фаерволом. Поковырявшись, админ сказал что обнаружил что на серваке зачем то был установлен, тысячу лет назад, kerio vpn client, который он благополучно снес. После данной манипуляции все зашуршало прекрасно, так что причина крылась именно в kerio vpn client который видимо как любой ipsec клиент имеет встроенный фаервол у которого имеются свои взгляды на прохождение пакетов. У клиента от checkpoint, например, таких проблем замечено не было.

Начну с того что я остановился сразу на платформе Asterisc, во первых потому что это наиболее популярный open-sourse, во-вторых потому что по данной платформе огромное количество полезной информации в интернете.

Погуглив, почитав и пообщавшись по форумам с людьми, выявил для себя следующие моменты:
под платформу лучше всего использовать отдельный сервер, поскольку на виртуалке могут возникнуть траблы как с трафом, так и с производительными мощностями, особенно в случае если трафик от провайдера приходит в одном кодеке, а в офисе мы используем другой;
для дедика вполне хватит сore2 или core i3, как минимум с 2Гб оперативы на борту, так что на первое время вполне сгодится какой нить десктоп, если руководство жмет деньги на приобретение полноценного сервера;
использовать лучше кодек g711, при этом под каждый активный разговор отводится порядка 64 кбит/с, так что умножаем на это число количество входящих линий и получаем необходимую под VoIP полосу пропускания;
использовать можно FreeBSD или CentOS, хотя тут мнения разделяются, как собственно и в любой холиваре- единственное что я пока осознал, что обновления для платформы Asterisc выходят на Cent OS с большим опозданием, по сравнению с фрей;
для сервака лучше использовать внешний, отдельный IP, поскольку при пробросе SIP портов (5060 udp/tcp и выделенный upd диапазон для траффа) через NAT могут возникнуть проблемы (в моем случае точно, поскольку на D-Link’e эти проблемы возникли даже при пробросе rdp);
можно использовать аналоговые телефоны, но для них придется докупать либо специальную карту в сервер, чья стоимость составляет около 2к грина, либо же VoIP шлюз, который также стоит в районе 200 грин;
цены на IP-телефоны начинают от 4к за более менее нормальные аппараты, так что имеет резон использовать бесплатные софтовые клиенты, так как в этом случае контора попадает только на гарнитуры, чья стоимость составляет от 700 рублей за штуку;
если планируется иметь факс, то его лучше вешать на аналоговую линию, поскольку для передачи факсимильных сообщений требуется идеализированный траффик, в противном случае факсы будут приходить крайне отстойного качества;
сама платформа Asterisc метит траффик, так что использовать для него приоритезацию траффика QoS не составляет проблемы;
некоторые провайдеры имеют свойство зафильтровывать SIP траффик, чтобы потенциальные клиенты не пользовались сторонними сервисами, так что придется либо брать данный вид трафа у этого провайдера, либо же каким то образом договариваться с ним;
в этом же ключе я пробивал возможность использования VoIP со шлюзом Checkpoint, который я уже успел несколько подзабыть за прошедшие полгода, в связи с чем выяснилось несколько моментов: в стандартной поставке Checkpoint FW будет корректно обрабатывать и пропускать VoIP траффик, и даже фильтровать его по политикам безопасности (при заведении объекта шлюза VoIP), а также симафорить с помощью IPS блейда, имеющего стандартными несколько сигнатур для проверки VoIP траффика. Но есть хочется чего то большего, то необходимо приобретать блейд  Voice over IP (VoIP) Software Blade, который этих сигнатур имеет большее количество и к тому же может не только проверять VoIP траффик, но и при необходимости вносить изменения в пакеты: транслировать адреса или вносить исправления в заголовки. Единственный момент здесь в том, что данный блейд встает только на версию R65, то есть весьма и весьма древнюю, так как на новых версиях SPLAT данный блейд не работает.

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

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

После того как все прошло успешно и вам вылали первый PIN- не выбрасывайте его, ибо он и будет служить паролем для вашего входа на сайт, где в качестве логина используется номер мобильного, без цифры 8. Заходим в личный кабинет, с использованием приведенных ранее параметров, и далее идем создавать шаблон для вывода бабосов: верхнее меню ПЛАТЕЖИ -> левый сайдбар СОЗДАНИЕ ШАБЛОНА -> Платежные системы -> Webmoney

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

Все- теперь идет в Google Adsense – в настройки платежей, и заполняем инфу для вывода: вкладка Мой Аккаунт -> поле Назначение платежа -> раздел Назначение платежа ->  кнопка Настройка Rapida -> где все заполняем теми же именами и фамилиями что и в Рапиде, после чего пишем адрес куда доставлять и (ВНИМАНИЕ!!!) в поле Номер шаблона в “Рапиде” прописываем именно тот уникальный номер, что был присвоен нашему шаблону (чтобы обновить в памяти, проходим в Рапиде по следующему пути: Рапида -> Личный кабинет -> Платежи -> Шаблоны и срисовываем поле Уникальный №. Как пишут люди- если в поле Номер шаблона в “Рапиде” , то бабки просто капнут на аккаунт в Рапиде и вы сможете сами распоряжаться своими бабками как пожелаете- благо там есть все, от вывода бабосов на карту, до коммунальных платежей, но меня история с вебманями устраивает более всего.

Чего и вам желаю!

На D-Link сайте нашел веселые картинки, показывающие как и что сделать, но поскольку мне их публиковать ломы. то распишу руками.
1. Логинимся на рутер
2. Создаем объект на который будем пробрасывать порты:
Objects -> Address Book -> InterfaceAddresses -> Add IP4 Address
Name: Имя-сервера
Address: IP-адресс сервера
3. Создаем правила проброса портов:
Rules -> IP Rules -> Add IP Rule Folder -> Входим в новую папку и Add IP Rule (две штуки)

3.1. Правило проброса:
Вкладка General:
Action: SAT
Service: rdp
Source (interface/network): any/all-nets
Destination (interface/network): core/wan_ip
Вкладка SAT:
Включаем кнопочка на Destination IP
New IP Address: Имя-сервера (из п.2)
New Port: 3389
Включаем чекбокс: All-to-One Mapping: rewrite all destination IPs to a single IP

3.2 Правило прохождения пакета:
Вкладка General:
Action: Allow
Service: rdp
Source (interface/network): any/all-nets
Destination (interface/network): core/wan_ip

По версии D-Link на этой торжественной ноте можно говорить: Configuration -> Save and Activate, но у меня после этого канал поднимался где то на полторы минуты, после чего соединение висло, а рутер говорил что он был перезапущен из-за ошибки: “Could not establish bi-directional communication after configuration upload”. Зная как работает D-Link, я пришел к тому, что второе правило, которое гарантирует прохождение пакета- не отрабатывает тот самый пресловутый  bi-directional , который D-Link обещает всем выбравшим в действии правила Allow, для того чтобы не создавать два правила туда и назад. Но це оказалась не фича, а бага, поэтому я добавил третье правило:

Вкладка General:
Action: Allow
Service: rdp
Source (interface/network): wan/Имя-сервера (из п.2)
Destination (interface/network): any/all-nets

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

Просмотрел для начала автозагрузки и иже с ними, и обнаружил что эта пакость сделала невидимым файл
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.

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

Для этих целей мы закупили 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. Криво в теории, но на практике работает пока нормально- продолжаю искать причину не понятного глюка.

Акция будет проходить весь день с 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.

Для этого необходимо создать 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 номер интерфейса, и для каждого сконфигурированного интерфейса должна присутствовать своя запись.

Смена 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

Согласуясь с вышесказанным запись в 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-записи для корневого домена, что было довольно неожиданно, ибо вся остальная зона отдавалась замечательно.

Но в версии 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

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

Начиная с версии прошивки 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 обещает выпуск обновленного полнофункционального 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 либо развод на лишние, причем не малые, бабуськи, либо просто незнание материала.

McAfee IntrShield у нас уже есть отлаженный и настроенный, а вот ISS Proventia IPS нужно поставить и для  этого инженеры IBM предоставили нам имидж. Но ввиду того что IPS аппаратный комплекс, то имидж представляет собой Boot сервер, с которого устройство, при загрузке должно по DHCP получить IP адрес и после этого по TFTP подтянуть с Boot сервера имидж для перепрошивки устройства. После загрузки, в консоли устройства набираем reinstall и на устройство заливается новая прошивка.

Вообщем встал вопрос, как загрузить виртуальную машину VMware по протоколу TFTP. Для этого запускаем виртуальную машину и тут же входим в консоль и жмем F2 для того чтобы войти в виртуальный биос машины. Там выбираем Boot и плюсиком поднимаем позицию Network boot from AMD Am79C970A наверх. После чего сохраняем и перегружаем машину: все можем спокойно грузить по TFTP.

Это говорит нам о том, что функционал LACP отрубает порты. Сам LACP (Link Aggregation Control Protocol) это протокол обеспечивающий работу транка, то есть объединение нескольких каналов в один для увеличения пропускной способности. Агрегированные каналы LACP используют для повышения пропускной способности канала и для и повышения отказоустойчивости.
Смотрим статистику конфигурации самого LACP

Chife-0# show lacp
LACP

ORT LACP TRUNK PORT LACP LACP
NUMB ENABLED GROUP STATUS PARTNER STATUS
……………..
35 Passive 35 Down No Success
36 Passive 36 Up No Success
37 Passive 37 Down No Success
38 Passive 38 Up No Success
39 Passive 39 Up No Success

LACP исходя из статистики пребывает в passive режиме, но при этом блокирует порты. Происходит это из-за того, что когда порт поднимает линк, passive LACP запрещает его использование до тех пор пока соединение не стабилизируется и не выяснится что это активное соединение. Если утверждение верно, то создается транк, если нет, то порт освобождается.

Для решения данной проблемы есть несколько ступенчатых вариантов разрешения проблемы:
1. Обновить версию прошивки свича до последней стабильной версии.
2. Проверить чтобы на обоих окончаниях сетевого кабеля выставлена одна и та же скорость и нет конфликтов: то есть с обоих сторон должна стоять или Auto-Auto или 100FDx -100FDx, но никак не Auto-100FDx
3. Если все вышесказанное не помогло, то можно отключить LACP если мы не используем его функционал для создании транка. При отключении данного функционала ничего не теряется ибо остается еще два варианта создания транков: HP port trunking (который использую я) и FEC.
Для этого опять же заходим в консоль и далее даем команды:
Chife-0# con t
Chife-0(config)# int all
Chife-0(eth-1-48,Trk1)# no lacp
Chife-0(eth-1-48,Trk1)# write mem

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

switch# config
switch(config)# clock set MM/DD/YYYY HH:MM:SS
switch(config)# wr mem

http://www.yougetsignal.com/tools/web-sites-on-web-server/

https://secure.domaintools.com

http://www.ip-adress.com/reverse_ip/

Но более интересный вопрос, как эти сервисы работают?
Понимаю, что это какой то скрипт, но ламбадой буду, то что он работает на базе стандартных dig и resolveip, с вкраплениями whois.  Но как их выстроить в правильный конвейер пока ума не приложу.

Немного воды:

Для задачи поддержки обратной зоны существует специальный домен IN-ADDR.ARPA. Сам файл описания зоны домена обратного просмотра состоит преимущественно из записей PTR типа “Pointer”.

[name][ttl] IN PTR [host]

то есть для сервера ns.server.ru c IP= A.B.C.D запись будет следующего вида

$ORIGIN C.B.A.in-addr.arpa.
D PTR ns.server.ru.

или же

123.46.181.62.in-addr.arpa. IN PTR ns.server.ru.

просмотреть информацию об имеющейся реверсивной записи можно командой:

# dig -x A.B.C.D

там же, кстати, можно увидеть и того, кто является ответственным за поддержку пула адресов. Также посмотреть ситуацию по по PTR в том числе можно на сайте http://www.squish.net/dnscheck
Опять же информация по ответственному за пул адресов можно получить командой:
# whois IP

Основной вывод:

В связи с чем еще раз хочу сказать с полной ответственностью- PTR запись размещает у себя провайдер, или тот кто является обладателем пула IP адресов. Хотя ленивый провайдер и может делегировать право ведения обратной зоны и серверу ответственному за поддержку основной (в смысле организации) или предоставить возможность удаленного управления своим сегментом.Делегирование осуществляется перенаправлением запросов на другие сервера, путем создания обратной зоны, состоящей из записи синонимов CNAME.

Например для сети провайдера 172.16.10.0/24, разбитой на подсети 172.16.10.0/25 ; 172.16.10.128/26 ; 172.16.10.192/26 это будет выглядеть так:

############################################
$ORIGIN 10.16.172.in-addr.arpa.
@ IN SOA ns.provider.ru. dnsmaster.provider.ru. (…)
;
; пулл 0-127 /25
;
0/25 IN NS ns.a.ru.
0/25 IN NS ns.a-slave.ru.
;
1 IN CNAME 1.0/25.10.16.172.in-addr.arpa.
2 IN CNAME 2.0/25.10.16.172.in-addr.arpa.
;
; пулл 129-191 /26
;
128/26 IN NS ns.b.ru.
128/26 IN NS ns.b-slave.ru.
;
129 IN CNAME 129.128/26.10.16.172.in-addr.arpa.
130 IN CNAME 130.128/26.10.16.172.in-addr.arpa.
;
; пулл 193-255 /26
;
192/26 IN NS ns.c.ru.
192/26 IN NS ns.c-slave.ru.
;
193 IN CNAME 193.192/26.10.16.172.in-addr.arpa.
194 IN CNAME 194.192/26.10.16.172.in-addr.arpa.
############################################

Сама же организация обязана вести на своем NS сервере запись вида

############################################
$ORIGIN 0/25.10.16.172.in-addr.arpa.
@ IN SOA ns.a.ru dnamaster.a.ru (…)
IN NS ns.a.ru.
IN NS ns.slave.ru.
;
1 IN PTR host1.a.ru.
2 IN PTR host2.a.ru.
3 IN PTR host3.a.ru.
############################################

Для двух других блоков адресов SOA записи будут соответственно:
$ORIGIN 128/26.10.16.172.in-addr.arpa.
@ IN SOA ns.b.ru dnamaster.b.ru (…)

$ORIGIN 192/26.10.16.172.in-addr.arpa.
@ IN SOA ns.c.ru dnamaster.c.ru (…)

*** По мотивам двухчасового разговора по аське с гуру piv_m

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

iPhone OS поддерживает несколько типов VPN шифрования:  L2TP, PPTP и Сisco IPSec VPN. Более подробную инфу можно глянуть на сайте Apple. Для подключения к Сisco IPSec VPN версия прошивки должна быть 2.0 и выше. Также поддерживается два вида сертификатов:

• PKCS1 (.cer, .crt, .der)
• PCSC12 (.p12, .pfx)

Для того чтобы настроить VPN соединение, идем Settings -> General -> Network -> VPN и выбираем Add VPN Configuration. Вбиваем все значения, которые выдает нам одмин, или которые мы знаем сами по себе, после чего говорим сохранить, и включем кнопочку Turn VPN on для того чтобы инициировать VPN соединение. После того, как VPN соединение будет создано, оно появится в главном меню Settings, и когда мы подключены к VPN, VPN иконка высвечивается в статус баре (см. картинко внизу).

Завести можно несколько VPN соединений, но подключение осуществляется к дефолтному, переназначить которок можно в пункте: Settings > General > Network > VPN простым перещелкиванием по соединениям.

Сами протоколы L2TP/IPSec  являются теми же VPN протоколами которые используют встроенные клиенты для MacOS и Windows. iPhone VPN клиент для L2TP/IPSec почти идентичен клиенту используемому на MacOS. Поскольку Cisco поддерживает эти протоколы шифрования, то мы имеем возможность подключаться к ASA серверу, используя IPSec. К VPN от Check Point мы можем подключаться, используя протокол L2TP, но речь сейчас не о нем. Как я сказал уже, VPN клиент для iPhone почти идентичен используемому на системах MAC OS, почти да не совсем- у него имеется ряд функциональных ограничений, так сказать несколько кастрированная версия. При настройке Cisco ASA нужно о них помнить.  Роемся на оффсайте в поисках документации по цискаридзе, откуда извлекаем на свет информацию об ограничениях и настройке ASA (данные выводы справедливы для iPhone OS 2.0):

• IKE phase 1—3DES шифрование с хэшированием SHA1 (md5 метод не поддерживается)
• IPSec phase 2—3DES или AES шифрование с MD5 или SHA методом хэширования
• PPP Authentication—MSCHAPv2 (официальная поддержка) но PAP, MS-CHAPv1 работает в тестовом режиме
• Pre-shared key (нет поддержки сертификатов).

Диалог в Cisco CLI:

ip local pool CLIENT-POOL 192.168.10.128-192.168.10.141 mask 255.255.255.240
crypto ipsec transform-set iPhone esp-3des esp-sha-hmac
crypto ipsec transform-set iPhone mode transport

crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 10 set transform-set iPhone
crypto map outside_map 65535 ipsec-isakmp dynamic SYSTEM_DEFAULT_CRYPTO_MAP
crypto map outside_map interface outside

group-policy iPhone internal
group-policy iPhone attributes
vpn-tunnel-protocol l2tp-ipsec
address-pools value CLIENT-POOL

tunnel-group iPhone type remote-access
tunnel-group iPhone general-attributes
default-group-policy iPhone
authentication-server-group denlab-RADIUS
tunnel-group iPhone ipsec-attributes
pre-shared-key test
tunnel-group iPhone ppp-attributes
authentication ms-chap-v2
crypto isakmp enable outside
crypto isakmp policy 5
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
crypto isakmp nat-traversal 20

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

show vpn-sessiondb detail remote filter protocol L2TPOverIPSec
или
show vpn-sessiondb detail remote filter protocol L2TPOverIPSecOverNAtT

Теперь попробуем проверить насколько это справедливо для прошивки iPhone 3.0..

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

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

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

Такое вот прекрасное устройство, причем вместе с подпиской на год и безлимитное число пользователей, оно выходит чуть больше штуки грина. Все очень просто настраивается через веб морду по http или https. Но есть одно маленькое НО- коробка идет со стандартной прошивкой 7.х которая после того как подцепляешь подписку, без вопроса грейдится на самую последнюю 8.0.42 после чего начинается свистопляска. Все входящие DNS пакеты на внутренний сервер, который натится из сетки, начинаются дропаться по дефолтному правилу, не смотря на указанную политику о том чтобы их пропускать. Помимо этого, напрочь отрубается внешний доступ к веб морде, а при попытке поднять wi-fi в бридж моде, для того чтобы иметь доступ из wi-fi сети к сетевым ресурсам, вешается внутрисетевой трафик, т.ч. простейшие операции вроде отправки почтового сообщения вешаются наглухо. В общем пришел к тому что нужно откатываться на старую версию прошивки, но как это сделать чтобы устройство не обновилось снова, не могу понять, в этой связи открыл тикет на офф.сайте. Пока суть да дело, с разборкой логов и настроек, мне упало еженедельное письмо от sofaware со статистикой по неделе работы устройства, где также была анонсирована эта самая многострадальная прошивка 8.0.42 откуда я с радостью узнал, что дроп пакетов на 53 порт UDP оказывается “не бага, а фича”, т.к. это трактуется как domain атака, также прикрывается атака на порт 51376 и 54498.

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

После чего легкий ступор и ощущение пата.  Российская служба поддержки Planet удивленно разводит руками, и ссылаясь на то, что у него как у электроника “где то должна быть кнопка”- форвардит запрос в Тайвань к производителю.
Лезем в инете на предмет системных паролей, ведь как известно у большинства производителей существуют таблицы системных паролей для внутреннего пользования, с помощью которых инженеры компаний могут получить доступ к устройствам. Паролей не нахожу, зато нахожу то, что базы ISS X-Force и Juniper трактуют как уязвимость прошивки Planet, а именно сброс системного пароля через терминальную консоль.

Подключаемся с помощью кабеля RS-232, прчем надо отметить, что Planet пошли своим путем- их настройки отличаются от стандартных, тем что они используют более высокую скорость передачи baud rate- 19200. Подключаемся к консоли и пытаемся залогиниться под пользователем admin. В обзорах сказано, что существуют два пароля с помощью которых пароль пользователя admin возвращается к стандартному пустому значению: ” [^_^] ” и ” ISPMODE ” (кавычки естественно не учитываются)

Второй пароль у меня не проходит, а вот ” [^_^] ” позволяет войти в консоль с правами администратора. В веб-консоль, к сожалению, по прежнему нет доступа, хотя уязвимость описывалось как возможность подключения как к консоли так и к веб-морде, поэтому не долго думая сбрасываем настройки Planet в фабричные настройки:

planet # factory default

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

Первое, что пришло в голову это воспользоваться стандартной функцией управляемого свича 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’ом

Несколько слов об SSH: это сетевой протокол прикладного уровня используемый в среде Unix/Linux, с помощью которого осуществляется удаленное управление операционной системой и на его базе организуются зашифрованные туннели. Также его можно использовать для передачи файлов также как и протокол FTP. Так что в данном случае мы осуществляем удаленное управление сервером на базе Iphone.

Установка поддержки SSH с помощью Cydia

Наверняка стает вопрос, почему надо использовать ssh, коли он разработан для Unix систем? Но поскольку iPhone OS является кастрированной версией Mac OS X, которая в свою очередь базируется на ядре UNIX системы, то можно сказать что iPhone OS это облегченная версия UNIX, по этой причине мы и можем использовать SSH.

Поскольку компания Apple не включает поддержку sshв телефоны iPhone мы вынуждены, предварительно сделать jailbreak системы. После того как мы произвели джейлбрейк, то можем спокойно переходить к установке ssh: заходим в Cydia и в поиске задаем “OpenSSH” пакет. Нажимаем иконку Install и устанавливаем на iPhone, после чего перегружаем телефон. Когда система загрузится, никаких новых иконок не появится, но тем не менее утилита SSH поднимается в автоматическом режиме и прослушивает удаленные запросы на предмет установления соединения.

*** У Вас наверняка включена автоблокировка телефона? Дело в том, что в процессе передачи файла по SSH телефон должен быть в активном состоянии, для этого необходимо отключить автоблокировку: идем Settings -> General -> Auto-Lock и выставляем Never.

Передача файлов с использованием SSH

В вашем iPhone уже имеется поддержка SSH и он прослушивает входящие покеты на предмет  SSH запроса. Перед тем как передавать файлы на ваш iPhone, необходимо задать IP адрес для iPhone.

Проверить IP адрес можно по следующему пути Settings -> Wi-Fi. Нажимаем на имя активного соединения WiFi и просматриваем подробности. Вы видите IP адрес телефона и его сетевые настройки, там же вы можете задать настройки сети для вашего  iPhone. В нашем примере IP адрес будет 10.0.1.5.

Поскольку IP адрес вам уже известен, переходим к следующему шагу- установке подключения к iPhone с компьютера.

Подключения компьютера к iPhone с помощью WinSCP

Для пользоватей  Windows я бы порекомендовал скачать программу WinSCP, которая является свободнораспространяемым SSH клиентом для Win XP/Vista. Установка WinSCP элементарна и ни чем не отличается от установки стандартной программы в среде Windows. Для пользователей Unix и Mac систем- в самих системах есть встроенная поддержка ssh и встроенный клиент.

Установив приложение, запускаете WinSCP и, чтобы подключиться к iPhone, нажимаете New. В пункте host name, пишите IP адрес вашего iPhone. В user name и password, используете стандартную связку “root” and “alpine”. Остальные поля не трогаете. После этого нажимаете “Login” для установки соединения с вашим iPhone. Нажимаете “Yes” если вам будет предложено добавить host key в кэш.

*** Вместо кнопки “Login” вы можите нажать “Save…” с тем чтобы сохранить сессию для дальнейшего использования.

Нажмите “Yes” если вам будет предложено сохранить ключи.

После подключения вы увидите структуру файловой системы вашего iPhone. Теперь вы можите передавать файлы между вашим iPhone и компьютером простым перетаскиванием файлов между окошками WinSCP.

Хосты:            256    128    64    32    16    8    4    2    1
Бит:            1    1    1    1    1    1    1    1    1
Маска подсети:        0    128    192    224    240    248    252    254    255
Кол-во подсетей:    1    2    4    8    16    32    64
Количество хостов:    254    126    62    30    14    6    2
Маска:            /24    /25    /26    /27    /28    /29    /30    /31    /32

В результате чего мы имеем для бинарной маски /24 маску подсети 0, количество подсетей 1 и 254 хоста в ней.
Если мы смещаемся на один бит вправо, то плюсуем его и получаем /25, для вывода маски прибавляем её к тем что она оставила за собой слева: 0+128=128. Это маска подсети, которых для данной маски 2 по 126 хостов в каждой, поскольку 128 – 2=126 (по одному уходит на адрес сети). Собственно вся хитрость, довольно быстро и практично. Если же хочется совсем простоты, то в инете полно ресурсов, которые с радостью проделают эту работу, за ленивого инженера, например этот.

Собственно картиночка очень наглядно демонстрирует положение дел с масками в A, B и C подсетях. Картиночку есессно тиснул, но очень удачно, отсюда

Нужно понимать, что основное преимущество tcpdump перед другими утилитами заключается в том, что в ней возможен подробный и ручной разбор пакетов. Также нужно помнить что по умолчанию tcpdump использует только первые 68 байт пакета, т.ч. если необходимо видеть больше, то следует использовать ключ -s number , где number количество байт которые следует захватить. В случае задания number 0 , произойдет полный захват пакета, поэтому лучше использовать значение 1514, что даст полный захват стандартного, для сетей Ethernet, пакета.
Список наиболее часто используемых ключей:
-c : задается проверка размера файла захвата перед каждой очередной записью захваченного пакета, если размер больше, то файл сохраняется и запись идет в новый файл
-e : выводится ethernet заголовок (канальный уровень) в каждой строке дампа
-i any : прослушивание всех интерфейсов, на случай если вам необходим весь трафик.
-n : запрещает преобразование адресов в доменные или символьные имена
-nn : запрещает преобразование адресов и портов в доменные или символьные имена
-q : Красткий вывод информации, за счет уменьшения вывода информации о протоколе.
-X : выводит как hex так и ASCII содержимое пакета
-v, -vv, -vvv : задает вывод дополнительной информации о захваченных пакетах, что дает возможность более широкого анализа.
Несколько примеров для использования:

# Стандартный вывод пакетов
tcpdump -nS
# Расширенный стандартный вывод
tcpdump -nnvvS
# Глубокий разбор пакета
tcpdump -nnvvXS
# Наиболее подробная информация о трафике
tcpdump -nnvvXSs 1514

Выражения позволяют производить более целевое сканирование и задавать типы трафика. Умение использовать выражения делает tcpdump весьма продуктивным инструментом, в рукам сисадмина. Существует три основных типа выражений: type, dir, and proto.
Опции выражжения type бывают host, net и port.
Для выражения направления задаваемого dir существующие опции src, dst, src or dst, и src and dst.
Несколько стандартных выражений:

host // анализ трафика на основе IP адреса ( также работает с символьными именами, если не задано -n)
tcpdump host 1.2.3.4

src, dst // анализ трафика тольуо для определенного назначения или передатчика
tcpdump src 2.3.4.5
tcpdump dst 3.4.5.6

net // захват трафика принадлежащего определенной сети
tcpdump net 1.2.3.0/24

proto // работает с tcp, udp, и icmp. Нужно помнить что proto не упоминается
tcpdump icmp

port // анализ трафика с определенного порта (входящего или исходящего)
tcpdump port 3389

src, dst port // фильтр базируется на входящем или исходящем порту
tcpdump src port 1025
tcpdump dst port 3389

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

AND
and or &&
OR
or or ||
EXCEPT
not or !

TCP трафик с ресурса 10.15.123.33 с портом назвачения 3379:

# tcpdump -nnvvS tcp and src 10.15.123.33 and dst port 3379

Трафик переходящий из сети 192.168 с назначением на сети 10 или 172.16:

# tcpdump -nvX src net 192.168.0.0/16 and dst net 10.0.0.0/8 or 172.16.0.0/16

Non-ICMP трафик с точкой назначения 192.168.0.2 и из сети 172.16:

# tcpdump -nvvXSs 1514 dst 192.168.0.2 and src net 172.16.0.0/16 and not icmp

Трафик с хостов Eros or Ares , но не идущий на стандартный SSH порт (для данного выражения требуется разрешение имен):

# tcpdump -vv src eros or ares and not dst port 22

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

Также следует помнить о том, что мы можем строить запросы, включающие группы и пулы опций, заданных в одном запросе. Но для того чтобы утилита tcpdump обращала на них внимание их нужно помещать в скобки, беря выражение в одиночные кавычки:
Трафик идущий с хоста 10.0.2.4 на порты назначения 3379 или 22:
# tcpdump ’src 10.0.2.4 and (dst port 3379 or 22)’

Также возможно производить фильтрацию на основе TCP флагов, например для вычленения SYN или RST пакетов:

Анализировать все URG пакеты:
# tcpdump ‘tcp[13] & 32 != 0′

Анализировать все ACK пакеты:
# tcpdump ‘tcp[13] & 16 != 0′

Анализировать все PSH пакеты:
# tcpdump ‘tcp[13] & 8 != 0′

Анализировать все RST пакеты:
# tcpdump ‘tcp[13] & 4 != 0′

Анализировать все SYN пакеты:
# tcpdump ‘tcp[13] & 2 != 0′

Анализировать все FIN пакеты:
# tcpdump ‘tcp[13] & 1 != 0′

Анализировать все SYN-ACK пакеты:
# tcpdump ‘tcp[13] = 18′

Нужно помнить что фильтр обрабатывает данный запрос следующим образом, проверяет 13 байт заголовка TCP пакета и заданный байт флага, на соответствие условию, например:
tcpdump ‘tcp[13] & 2 != 0′ – просмотр и сравнение 13 и 2 байтов заголовка, на условие что данные не равны 0, т.е. заданы 1.

Анализ специализированного трафика:

Анализировать весь IPv6 трафик:
# tcpdump ip6

Анализировать весь трафик с имеющимися флагами SYN и RST:
# tcpdump ‘tcp[13] = 6′

Анализировать весь трафик с имеющимся “evil bit”:
# tcpdump ‘ip[6] & 128 != 0′

Естественно что приведенные примеры не могут охватить всю полноту использования столь мощного инструмента как tcpdump, поэтому как обычно, лучшим другом сисадмина был и остается:
# man man
надеюсь что данная статья сможет несколько облегчить непростой опыт общения с этой замечательной программой

Можно провести небольшой опыт задав в конфиге сервера sshd_config несколько значений для сервиса:
Port 22
Port 28356

а в фаервольных правилах
-A INPUT -i eth0 -m tcp -p tcp –dport 22 -j LOG –log-level 7 –log-prefix “Logged port 22 ”
-A INPUT -i eth0 -m tcp -p tcp –dport 28356 -j LOG –log-level 7 –log-prefix “Logged port 28356 ”

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

***  Обновление от 27.08:  за 12 часов, прошедших с момента реконфига сервера, правда путем внесения изменений в ipfilter , произошло 1335 попыток подключения на 22 порт и ни одной попытки на 28356 порт.

Эти цифры наглядно демонстрируют то факт, что единицы злоумышленников ищут демонов на не стандартных портах, причем попытка найти демона на порту, отличном от стандартного, с большой вероятностью будет осуществляться за счет сканирования, которое можно предотвратить за счет использования IPS или же сервиса Port Sentry. Следовательно, в случае обнаружения уязвимости сервера SSH типа zero-day шанс того, что эксплоит будет использован против сервиса крутящегося на нестандартном порту,  в тысячи раз ниже чем против сервисов использующих стандартные значения.

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