1. В том году в операционной системе Windows Vista был найден, не документированный, код канонического имени для панели управления, который с легкой руки журналистки Ины Фрид получил условное имя God Mode, за то что он выводит все настройки операционки единым списком. Оказалось что он также работает и в Windows 7. Для того чтобы получить данный листинг, необходимо создать каталог, которому присвоить имя GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}  или какое либо другое слово перед фигурной скобкой, например odminblog.{ED7BA470-8E54-465E-825C-99712043E01C} . После переименования каталог преобразуется в иконку, входя в которую получаешь доступ ко всем настройкам системы. В принципе довольно удобная штука, которую можно иметь например в главном меню. На системах x64 существует проблема стабильности, в случае если данная иконка находится на рабочем столе, результатом чего является невозможность загрузить систему в штатном режиме, кроме как безопасного, до момента удаления этой иконки.

Также на сайте мелкомягких можно просмотреть канонические имена панели управления, доступные для систем Windows 7 или Windows Vista.

2. В системе Windows XP была возможность создать не видимую папку, причем не просто скрытую, которая тем не менее была видна из под специально настроенного профиля, а именно папку невидимку- которую можно расположить как на рабочем столе, так и в подпапке. Делается это путем создания папки и переименования её с использование NumPad-клавиатуры. Кто не в курсе, то это дополнительная клава с цифрами, расположенная на большой стандартной клавиатуре справа, и которая включается клавишей NumLock (её еще очень любят юзать бухгалтера, озадачивая с ходу проблемой, что у них не печатают цифры). После создания папки, переименовываем её с использованием этой самой клавы в пустое имя, путем набора Alt+ 255. Смысл этого преобразования прост- нумпадом с альтом вводятся различные символы, и в данном случае мы ставил пробле, который Windows воспринимает как символ. После этого мы идем в свойства папки:  правым кликом мышки -> свойства -> настройка -> сменить значок -> и выбираем иконку без значка (она там есть, надо просто промотать вправо), после чего папка исчезает. Если положить её куда нить в конец системной папки, или во глубине диска E: (тут главное перенести её в конец списка, иначе она будет светить в его начале пустым списком), то её не найдет никто. Естественно что она выбирается например в корневой папке командой Ctrl + A, но для этого надо знать что и где искать. На рабочем столе она будет также выбираться, либо же надо будет кликать в ту область, где вы знаете что она находится. Также её можно выбрать, если например растянуть курсор выделения на область.

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

Замечу, что я Asus совсем не жалую, после одной истории, рассказанной мне моим надежным поставщиком, влетевшим на бабки от Asus, которые лет 6-7 назад прикупили у какого китайского ноунейма емкостей для своих плат, за 40-50% от рыночной стоимости. Но как оказалось хитрый ноунейм толи купил у кого то схемы бетаверсии, то ли просто говоря тихо по-китайски спер, но у них оказался один момент- они работали лучше других только пол года, после чего вылетали. И таким вот образом у Asus вылетела огромная партия матерей которые они скидывали по бросовым ценам и Asus не нашел ничего лучшего, как заявить что матери паленые и они такие серии не выпускали, так что большое количество народа на этом накололось. Не знаю что правда, а что нет, но после пары общений с их суппортом, я тему Asus’a для себя закрыл.

Но она предпочла открыться самой.

Так вот дрова от Asus F5R не подтягивались Windows 7, так что пришлось лезть на сайт производителя, где самые свежие дровишки были для Vista 32 bit, и если камера подхватилась с полпинка, то дрова для видеокарты ATI Radeon Xpress 1100 встав, начали грузить проц, и, что еще более убивало, дергать курсором по экрану, то есть он мелко и мерзко вибрировал, и при этом крутился кружок, показывавший что память занята каким то процессом. Пришлось идти на сайт ATI и пытаться найти дровишки для данной карты, но их не было за давностью лет. Скачав последний “все для всех” от ATI, я установил Catalist, но карта не подхватывалась. Таким вот макаром я перепробовал несколько видов драйверов, но все было также. При попытке обновить драйверок ручками из диспетчера устройств, система говорила что обновление не требуется, так как в системе и так стоит отличный драйвер XPress 1100.

В этой связи пришлось вспомнить пляски с бубном при установке сетевухи Adaptec под Windows 95, когда брендовый драйвер тоже не хотел подменять родной виндовый. Собственно устанавливаем драйвер для видеокарты XPress 1100 следующим образом: Пуск -> правым кликом мыши на Компьютер -> Свойства -> Диспетчер устройств -> Видеоадаптеры -> открываем установленный -> вкладка Драйвер -> Обновить -> Выполнить поиск драйверов на этом компьютере -> Выбрать драйвер из списка уже установленных драйверов -> Установить с диска после чего указываем путь до папки с последними драйверами для Windows 7 и выбираем Xpress 1050 или Xpress 1200, и устанавливаем любой из этих драйверов.

Для Xpress 1100, видимо прогресс остановился на Viste, так что по аналогии с драйвером для HP LJ 4V который рулит почти на всех моделях принтеров- заменяем родной драйвер видоизмененным. Конечно придет вопрос о том, действительно ли вы хотите поставить не стандартный драйвер и не боитесь ли что все накернится, но неумолимо отвечайте ДА -УСТАНОВИТЬ.

И придет щасте.

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

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

Для начала крайне желательно что бы каждый сайт на хостинге принадлежал отдельному пользователю, и под каждый сайт была бы заведена отдельная SQL база с различными правами доступа. Крайне желательно, чтобы движок сервера баз данных использовал для своей работы только соединение через localhost. Права на все файлы в папках ваших сайтов должны быть выставлены на чтение, кроме тех где необходимы права на исполнение или запись. Для каждого сайта желательно иметь собственного пользователя FTP, который бы имел доступ только в корневую папку сайта. По хорошему- общий доступ к папке сайтов лучше отключить, или привязать к своему IP. Если у вас IP динамический, то перепривязать его из панели управления займет лишнюю минуту, но это обезопасит ваш сайт от взлома ftp аккаунта или кражи пароля из ftp клиента.

После этого можно приступать к настройке защиты через консоль управления хостингом. Я расскажу про cpanel, ибо я предпочитаю использовать именно её, так как меня устраивает функционал и интерфейс, при том что на моем хостинге она стоит на 4 бакса дороже чем никакой DirectAdmin. Итак в cpanel есть раздел Security Center, который и отвечает за закручивание гаек в системе безопасности веб-сервера. О всех рассказывать не стану, так как там довольно много разделов, а поведаю о наиболее, на мой взгляд, важных:

1. mod_userdir Protection : здесь можно отключить возможность чтобы ваши домены были доступны по имени пользователя под которым заведен сайт, по адресу: хттп://дефолтныйхостнейм/~username
В принципе этот функционал советуют отрубать, иначе все переходы по данным урлам будут засчитаны для дефолтного домена, то есть в случае реселла вас смогу легко накалывать благодарные юзвери. Но если вы используете хостинг только для себя, я не уверен что это так уж и страшно.
2. Compiler Access: отрубает доступ к компилятору С на веб-сервере, для не привилегированных юзверей, в том числе и владельцев сайта. Очень полезная штука, ограничивающая возможности злоумышленника при попытке взлома со стороны пхпшных шеллов.
3. cPHulk Brute Force Protection: одна из самых полезных штук, позволяющая предотвращать атаку переборки паролей. Включив этот твит- вы будите удивлены тому, как часто вам пытаются ломануть аккаунт, так что в итоге я выставил 3 максимальные попытки, после которых идет бан по IP адресу на 2 недели. Также можно настроить уведомления о логинах рута и отловленных атаках, тогда в этих случаях будет приходить письмо в линками на бан IP и сеток по маскам 16 и 24. Но вам надо будет настроить в зоне домена сервисный субдомен для бана, а также привыкнуть к тому, что вам будет падать уведомление и о системных входах рута.
4. Host Access Control: фактически фаервол, позволяющий настроить права доступа для определенных сервисов к хостингу. В случае динамических адресов, может стать проблемой, так как придется либо открывать сетке, либо пересоздавать правила каждый раз.
5. Manage root’s SSH Keys: очень полезная штука, позволяющая обезопасить ssh соединение с сервером, путем использования аутентификации не паролями, а на уровне сертификатов. Для начала надо сгенерировать сертификаты, путем клика на Generate a New Key и следуя указаниям (пароль и логин следует запомнить, а лучше записать). Создав их – говорим для ключей download key, после чего копируем представленный текст в блокнот и сохраняем под одним именем файла: Public Keys с расширением pub, а  Private Keys без расширения файла. После чего ныкаем файлы куда-нить вглубь операционки. После чего заводим новое соединение, выбрав в качестве метода аутентификации сертификат, и указываем публичный ключ (он должен находиться в одной директории с приватным), после чего вводим имя пользователя которым хотим залогиниться в систему, например root, и пароль который мы вводили при создании сертификата. Если соединение прошло успешно, то идем в раздел SSH Password Authorization Tweak и отключаем аутентификацию по паролю. Так что теперь к нашему ssh серверу мы можем подключиться исключительно с использованием сертификатов.
6. Quick Security Scan: здесь можно просканить сервер на предмет не нужных портов и сервисов, запущенных по умолчанию.
7. Scan for Trojan Horses: очень полезная штука, позволяющая сканить ваши директории, на предмет выявления троянов, подсунутых вам в систему. Рекомендуется эпизодически запускать, чтобы быть уверенным что у вас на сайте не шуршит какая нибудь нечисть.
8. Shell Fork Bomb Protection: полезная штука для ресселеров, позволяющая предотвратить запуск из шела каких либо циклов и процессов, способных переполнить память и тем самым привести к краху системы.
9. Security Questions: также полезная опа, для предотвращения несанкционированного доступа к системе, путем создания листа разрешенных IP адресов, и при попытке логина с не зарегистрированного IP адреса выдающего вопрос. В случае правильного ответа- пользователь входит в систему, а IP вносится в базу разрешенных адресов.
10. SMTP Tweak: заточка SMTP, которую также можно произвести на странице настроек – Server Configuration >> Tweak Settings, которые я настоятельно  рекомендую просмотреть, так как там можно поотключать много чего не нужного.

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

После внесения изменений в правила фаервола, данные правила можно применить без перезагрузки фаервола, просто перечитав файл правил, причем это может быть как дефолтовый файл, так и рандомный:
# ipf -Fa -f /etc/ipf.rules
где,
-Fa сброс всех правил фаервола.
-f указывает фаайлец с новыми правилами фаервола (так что не ошибитесь, ибо как вы помните фаервол мы собираели с блоком по умолчанию)

Полную статистику работы фаервола с момента загрузки системы  можно просмотреть командой
# ipfstat
При этом ключ -ih выдаст количество входящих пакетов, со статистикой прохождения или блокировок с попаданием в правила,
ключ -oh выдаст туже статистику для исходящих пакетов. Это отличное подспорье в оптимизации работы фаервола, путем помещения наиболее часто используемых правил фаервола наверх таблицы.
Обнулить эту статистику можно командой
# ipf -Z
Просмотреть проходящие пакеты в режиме реального времени, можно командой
# ipmon
собственно её вывод и пишется в логфайл.

При использовании ключа  -n адреса и порты будут преобразованы в хостнеймы и сервисы, что довольно удобно для мониторинга того- кто где сидит в данный момент,
а при использовании ключа -x данные проводящих пакетов будут выводиться в hex-коде, что тоже может доставить много интересных минут сисадмину.
Используя команду ipnat можно просматривать таблицу состояния адрес трансляций:
# ipnat -l выведет все открытые на данный момент трансляции адресов
# ipnat -s выводит статистику работы адрес трансляции
# ipnat -F обнуляет все активные соединения из актуальной таблицы адрес трансляций

У ipnat есть, по умолчанию вшитое, количество возможных открытых сессий, и проверить его можно командой:
# ipf -T list | grep nattable
и вероятнее всего вы получите ответ что максимальное число открытых сессий 30к, что для большой сети не так уж и много, так что увеличить это число можно добавив в файл rc.conf следующую строчку:
ipfilter_flags=”-D -T ipf_nattable_sz=10009,ipf_nattable_max=200000 -E”
и перегрузив ipfilter, тем самым увеличив число сессий до 200к.
Также если ваш ipnat.rules предполагает более 127 правил, которые установлены по умолчанию, вам необходимо  также добавить в переменную ipfilter_flags файла rc.conf ключики ipf_natrules_sz=1023,ipf_rdrrules_sz=1023
Еще один момент касаемый уменьшения таймаута TCP сессии, что также позволит оптимизировать работу NAT, так как многие сессии сохраняются в таблице не смотря на то что соединение уже давно закончилось. Для этого добавляем во флаги, также ключи fr_tcptimeout=180,fr_tcpclosewait=60,\
fr_tcphalfclosed=7200,fr_tcpidletimeout=172800
В итоге на выходе в rc.conf имеем следующее выражение:
ipfilter_flags=”-D -T ipf_nattable_sz=10009,ipf_nattable_max=200000,fr_tcptimeout=180,\
fr_tcpclosewait=60,fr_tcphalfclosed=7200,fr_tcpidletimeout=172800,\
ipf_natrules_sz=1023,ipf_rdrrules_sz=1023 -E”

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

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

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

Итак- настраиваем программный фаервол на базе FreeBSD.

Ставить буду ipfilter, исключительно по идейным соображениям работы ipfw с NAT и тем что сам функционал ipfilter для меня проще и давно изучен (опять же про установку PF расскажу как нить позже, но его ставить на конторский фаервол усомнился, так как имеются траблы с многопоточностью). Описывать процедуры я буду не полностью, так как, о части работ я уже писал ранее, так что просто отошлю к этим постам.

Для начала поднимаем сервер FreeBSD (я для последнего раза выбрал систему FreeBSD 8.2), на котором проводим обновление системы и дерева портов, после чего раздракониваем нашу систему на предмет повышения безопасности. После этого пересобираем ядро системы, отключая не нужные нам дрова (тут не лишне будет перелопатить dmesg на предмет наличия устройств, чтобы не забанить что-нить архиважное- например IPv4 вместо IPv6), и предварительно включив в ядре поддержку ipfilter:
options     IPFILTER # поддержка IPFilter
options     IPFILTER_LOG # поддержка логирования IPFilter
options     IPFILTER_DEFAULT_BLOCK # блокируем все пакеты по умолчанию
options     IPFILTER_LOOKUP
также, если не добавляли при настройке усиленной системы, то ставим следующие опции ядра
options IPSTEALTH # не увеличивает счетчик TTL при прохождении пакета
options TCP_DROP_SYNFIN # дропаем SYN/FIN пакеты, но не работает вроде как с 7 ветки
options SC_DISABLE_REBOOT # запрет перезагрузки сервера через Ctrl+Alt+Del
options         SOFTUPDATES # включение технологиии softupdate для тюнинга работы системы

По хорошему, перед правкой ядра стоит на всякий случай почитать следующие файлы, хотя бы для повышения личной образованности, а уж в случае наличия ошибок при сборке ядра- однозначно:
/usr/sys/UPDATING
/usr/src/sys/conf/NOTES

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

Затем включаем в системе поддержку фаервола, путем добавления следующих операндов в файл /etc/rc.conf :
######################################
ipfilter_enable=”YES”
ipnat_enable=”YES”
ipfilter_rules=”/etc/ipf.rules”
ipnat_rules=”/etc/ipnat.rules”
gateway_enable=”YES”
icmp_bmcastecho=”YES”
ipmon_enable=”YES”
ipmon_flags=”-D /var/log/ipmon.log &”
########################################

Создаем вышеупомянутые файлы ipf.rules и ipnat.rules , делаем их владельцем root и задаем на них права 644. Затем создаем правило полного доступа для всех в файле /etc/ipf.rules. Естественно что помимо lo0, добавляем все имеющиеся в системе интерфейсы и особенно те, через которые мы и настраиваем сервер- в моем случае это внутренний интерфейс rl0.
#################################
pass in quick on lo0 all
pass out quick on lo0 all
pass out quick on rl0 all
pass in quick on rl0 all
#################################

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

Далее несколько подправляем работу ядра через файл настроек  /etc/sysctl.conf для добавления всяческих фич противодействия DoS и DDoS атакам, а также повышению безопасности системы, которые сохраняются, благодаря файлу, в системе и после перезагрузки. Здесь их подробно описывать не буду, а как нить позже приведу полный разбор полетов- пока просто вписываем в указанный файл следующие значения (файл создаем при его отсутствии):

net.inet6.ip6.redirect=0
kern.ipc.somaxconn=32768
net.inet.tcp.blackhole=1
net.inet.udp.blackhole=1
net.inet.tcp.msl=7500
net.inet.tcp.sendspace=32768
net.inet.tcp.recvspace=32768
net.inet.tcp.syncookies=1
net.inet.tcp.log_in_vain=1
net.inet.udp.log_in_vain=1
net.inet.tcp.sack.enable=1
net.link.ether.inet.max_age=1200
net.inet.ip.redirect=0
net.inet.ip.sourceroute=0
net.inet.ip.accept_sourceroute=0
net.inet.ip.ttl=64
net.inet.ip.random_id=1
net.inet.ip.forwarding=1
net.inet.ip.check_interface=1
net.inet.icmp.bmcastecho=0
net.inet.icmp.maskrepl=0
net.inet.icmp.maskrepl=0
net.inet.icmp.icmplim=30
net.inet.icmp.icmplim_output=0
net.inet.icmp.drop_redirect=1
net.inet.icmp.log_redirect=1

net.inet.tcp.drop_synfin=1 # если подключили в ядре опцию TCP_DROP_SYNFIN

Затем настраиваем ротацию логов фаервола, для чего устанавливаем пакет logrotate:
# cd /usr/ports/sysutils/logrotate/
# make && make install && make clean
Создаем и настраиваем конфиг ротации логов:
# cp /usr/local/etc/logrotate.conf.sample /usr/local/etc/logrotate.conf
добавляем в файл logrotate.conf следующие строки
############### logrotate.conf
/var/log/ipmon.log {
Daily # какова периодичность ротации логов
rotate 14 # какое количество логов хранить
missingok # игнорировать отсуствие файла ipmon.log
notifempty #  не обрабатывать лог файл, если он пустой
noolddir # содержать все файлы логов в одном каталоге
compress #  сжимать обработанные логи
postrotate # описание что делать  с ipmon после ротации
/sbin/killall -HUP ipmon # в нашем случае перезапустить ipmon
endscript #  конец описания действия после ротации
} #   конец описания ротации файла протокола ipfilter
###########################

Добавляем наш ротатор логов в крон:
0 1 * * * /usr/local/sbin/logrotate -s /var/lib/logrotate.status /usr/local/etc/logrotate.conf

Создаем сам лог файл через команду
# touch /var/log/ipmon.log
ибо автоматом он не создастся, и с чувством глубокого удовлетворения переходим к настройке правил фаервола и адрес-трансляции пакетов.

Начем с правил NAT ибо их меньше и они проще (предположим что внешний интерфейс fxp0). Надо отметить что правило проксирования исходящих ftp-сессий ставится первым, за ним идут адрес-трансляции для внутренних серверов (адрес Server-FW_external_IP поднимается алиасом на внешнем интерфейсе фаервола), если их необходимо представить в инете, а за ними уже следуют правила ната для сетки:
####### /etc/ipnat.rules #######

map fxp0 internal_NET_IP/24 -> FW_external_IP/32 proxy port ftp ftp/tcp
### Безусловная трансляция на внутренний адрес
map fxp0 Server_exnternal_IP/32  -> Server-FW_external_IP/32
bimap fxp0 Server_external_IP/32 -> Server-FW_external_IP/32
##########
### Редирект порта с внешнего интерфейса фаервола на внутреннюю машину (как пример RDP)
rdr fxp0 external_GW_IP port 3389 -> Server_internal_IP port 3389 tcp
#########
map fxp0 internal_NET_IP/24 -> 0.0.0.0/32
map fxp0 internal_NET_IP/24 -> FW_external_IP/32 portmap tcp/udp 20000:64000 # натим порты
############################

Теперь переходим к настройке самого муторного- правилам фаервола. Помним о том, что в классическом фаерволе перебор правил идет сверху вниз, поэтому все блокировки помещаем вниз, кроме единственных закрывающих атаки cifs. Также разрешаем внутрисетевой трафик в нашей локальной сети, что мы уже определили первыми правилами в самом начале (rl0 у нас внутренний интерфейс):
####### /etc/ipf.rules #######
### Разрешаем внутрисетевой трафик
pass in quick on lo0 all
pass out quick on lo0 all
pass out quick on rl0 all
pass in quick on rl0 all
### Лочим все прорезки в виндовые уязвимости
block in log quick on fxp0 proto tcp from any to any port = 113
block in log quick on fxp0 proto tcp/udp from any to any port = 135
block in log quick on fxp0 proto tcp/udp from any to any port = 136
block in log quick on fxp0 proto tcp/udp from any to any port = 137
block in log quick on fxp0 proto tcp/udp from any to any port = 138
block in log quick on fxp0 proto tcp/udp from any to any port = 139
block out log on fxp0 proto tcp/udp from any to any port = 135
block out log on fxp0 proto tcp/udp from any to any port = 136
block out log on fxp0 proto tcp/udp from any to any port = 137
block out log on fxp0 proto tcp/udp from any to any port = 138
block out log on fxp0 proto tcp/udp from any to any port = 139
block out log on fxp0 proto tcp/udp from any to any port = 445
### Разрешаем NS-запросы из сети
pass out quick on fxp0 proto tcp from any to DNS1 port = 53 flags S keep state keep frags
pass out quick on fxp0 proto udp from any to DNS1 port = 53 keep state keep frags
pass out quick on fxp0 proto tcp from any to DNS2 port = 53 flags S keep state keep frags
pass out quick on fxp0 proto udp from any to DNS2 port = 53 keep state keep frags
### Разрешаем выход пассивного FTP протокола
pass out quick on fxp0 proto tcp from any to any port = 20 flags S keep state keep frags
pass out quick on fxp0 proto tcp from any to any port = 21 flags S keep state keep frags
### Разрешаем работу по ssh на нашем фаерволе на своем порту
pass in quick on fxp0 proto tcp from any to any port = 19212 flags S keep state
### Разрешаем протокол smtp только к почтовому серверу, для предотвращения работы потенциальных спам-ботов
pass out quick on fxp0 proto tcp from any to MAIL_SERVER_IP port = 25 flags S keep state keep frags
#### Разрешаем работу whois из сети
pass out quick on fxp0 proto tcp from any to any port = 43 flags S keep state keep frags
#### Разрешаем просмотр сайтов по http
pass out quick on fxp0 proto tcp from any to any port = 80 flags S keep state keep frags
### Получаем почту по pop3
pass out quick on fxp0 proto tcp from any to any port = 110 flags S keep state keep frags
### Разрешаем работу по протоколу https
pass out quick on fxp0 proto tcp from any to any port = 443 flags S keep state keep frags
pass out quick on fxp0 proto tcp from any to any port = 591 flags S keep state keep frags
### Разрешаем работу по FTP в пассивном режиме, когда сервер выбирает порт для работы
pass out quick on fxp0 proto tcp from any to any port > 1023 flags S keep state keep frags
# Разрешаем работу traceroute
pass out quick on fxp0 proto udp from any to any port 33434 >< 33525 keep state keep frags
# Разрешаем пинг во вне
pass out quick on fxp0 proto icmp from any to any keep state keep frags
### Разрешаем вход внутрь сетки по RDP
pass in log quick on fxp0 proto tcp from any to RDP_Server_IP port = 3389 flags S keep state keep frags
### Разрешаем из сети работу линейки
pass out quick in fxp0 proto tcp/udp from Client_IP to  217.117.182.1 port > 10 keep state
pass in quick on fxp0 proto tcp/udp from  217.117.182.1 to GW_internal_IP port > 10 keep state
pass out quick in fxp0 proto tcp/udp from any to any port = 2106 keep state
pass in quick on fxp0 proto tcp/udp from any to any port = 2106 keep state
### Обрабатываем работу icmp протокола
pass in on fxp0 proto icmp from any to any icmp-type echo
pass in on fxp0 proto icmp from any to any icmp-type echorep
pass in quick on fxp0 proto icmp from any to any icmp-type 3 keep state keep frags
pass in quick on fxp0 proto icmp from any to any icmp-type 11 keep state keep frags
block return-icmp (3) in proto udp from any to any port > 30000
block return-icmp (3) in on fxp0 proto icmp from any to any icmp-typenunreach code 3
block in proto icmp all
### Блокируем все остальное
block out log first quick on fxp0 all
block in quick on fxp0 from 192.168.0.0/16 to any    #RFC 1918 private IP
block in quick on fxp0 from 172.16.0.0/12 to any     #RFC 1918 private IP
block in quick on fxp0 from 10.0.0.0/8 to any        #RFC 1918 private IP
block in quick on fxp0 from 127.0.0.0/8 to any       #loopback
block in quick on fxp0 from 0.0.0.0/8 to any         #loopback
block in quick on fxp0 from 169.254.0.0/16 to any    #DHCP auto-config
block in quick on fxp0 from 192.0.2.0/24 to any      #reserved for docs
block in quick on fxp0 from 204.152.64.0/23 to any   #Sun cluster interconnect
block in quick on fxp0 from 224.0.0.0/3 to any       #Class D & E multicast
block in log quick on fxp0 all with frags
block in log quick on fxp0 proto tcp all with short
block in log quick on fxp0 all with opt lsrr
block in log quick on fxp0 all with opt ssrr
block in log first quick on fxp0 proto tcp from any to any flags FUP
block in log quick on fxp0 all with ipopts
block in log quick on fxp0 proto icmp all icmp-type 8
block in log first quick on fxp0 all
block in log all
block out log all
#####################

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

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

З.Ы. Хотел написать об этом моменте в отдельном посте, но решил что это будет не очень корректно, так что привожу в виде небольшого послесловия. Дело в том, что файл правил фаервола ipf поддерживает набор переменных, что конечно же гораздо удобнее для системного администратора, так как позволяет переносить файл правил с одного шлюза на другой, корректируя только объявления переменных в самом начале файла. Одна беда, что сам пакет ipf не понимает переменные и файл с ними надо сохранять в отдельный скрипт /etc/ipf.rules.script, запуская который пользователь создает или обновляет правила в файле ipf.rules. В сам скрипт пишется следующее:
### ipf.rules.script ###

### Описание переменных
oif=”fxp0″ # имя внешнего интерфейса
odns=”DNS1-IP” # IP адрес внешного DNS сервера
mynet=”172.168.0.0″ # Внутренняя сетка
ks=”keep state”
fsks=”flags S keep state”
###
cat > /etc/ipf.rules << EOF
# Доступ из сети к внешнему DNS серверу
pass out quick on $oif proto tcp from any to $odns port = 53 $fks
pass out quick on $oif proto udp from any to $odns port = 53 $ks
# Разрешить выход из сети во вне по http
pass out quick on $oif proto tcp from $mynet to any port = 80 $fks
#### ну и так далее

После изменения правил фаервола необходимо запустить данный скрипт, что бы правила перечитались и файл ipf.rules обновился:
# sh /etc/ipf.rules.script

Седня как раз ездил по причинам того, что тетеньки не смогли наладить связь между клиент-банком и программой 1С. При ом что я вроде все настроил. А секрет оказался в том, что параметры из глобальных настроек не переходят в свойства импорта/экспорта, так что там их пришлось прописывать по новой. И после этого импорт в банк-клиент Сбербанка поднялся, а вот экспорт нет. Ибо платежки выгружались нормально, а выписки никак не хотели. Покопавшись на форумах, обнаружил, что у людей существует проблема, что из системной папки пропадает файло ответственное за выгрузки – ConvIn1C.dll, причем найти они его никак не могут. Поэтому я выкладываю этот файл у себя для тех кому он действительно необходим, да простят меня хозяева Клиент-Сбербанка. Но у меня оказалось файл в папке есть, но проблема заключалась в том, что при выборе Выписок раздел Импорт/Экспорт становился неактивным. И собственно решение оказалось в том, что выписки импортируются не из раздела Выписки (левое нижнее меню), а из Выписки и операции -> Операции по счетам -> Все операции. Если курсор поставить на эту позицию, то импорт станет доступен.  В диалоге выбираем движок для импорта в 1С файл ConvIn1C.dll и все работает. Главное чтобы в обоих программах были выбраны одинаковые папки.

Для начала понимаем что это вообще за класс операционки, путем вывода универсальной для всех Unix-систем команды:
$ uname -a
которая нам выведет что то типо такого:
Linux hostname.com 2.6.18-194.17.4.el5PAE #1 SMP Mon Oct 25 16:35:27 EDT 2010 i686 i686 i386 GNU/Linux
или
FreeBSD hostname.com 5.5-STABLE FreeBSD 5.5-STABLE #0: Wed Dec  5 20:00:38 MSK 2007  email@hostname.com:/usr/obj/usr/src/sys/GENERIC  i386
или
AIX svcas07 3 4 000145364C00
OS Name Release Version Machine ID
из чего нам либо станет понятно кто это, либо перейдем к более подробному изучению линуха, для того чтобы уже конкретно определить версию линукса:
$ cat /proc/version
Linux version 2.6.18-194.17.4.el5PAE (mockbuild@builder10.centos.org) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Mon Oct 25 16:35:27 EDT 2010
то есть нам понятно семейство линуха и версия ядра, тем более что у семейства шапки есть более подробная команда, для того чтобы узнать версию linux:
$ cat /etc/redhat-release
CentOS release 5.6 (Final)
По хорошему это исчерпывающий ответ, но в шапке также имеется дополнительная утилита ставящаяся в полном комплекте, которая выведет более подробную информацию про версию linux:
$ lsb_release -a
LSB Version:    :core-3.1-ia32:core-3.1-noarch:graphics-3.1-ia32:graphics-3.1-noarch
Distributor ID: CentOS
Description:    CentOS release 5.5 (Final)
Release:        5.5
Codename:       Final

Если с логон скриптом все более менее понятно- выкачиваем исполняемый файл, кладем его в доступную шару, после чего прописываем в логон скрипт следующую строку:
start /wait \\сервер\шара\пакетный-файл.ехе /K /B

то через AD все делается несколько сложнее. Для начала нам нужен не обычный exe’шник, а виндовый установщик MSI- то есть мы выкачиваем дистрибутив с расширением msi или же собираем его из exe  с помощью внешних утилит (например Advanced Installer, EMCO MSI Package Builder Enterprise или Prism Deploy Editor).
Для скайпа msi доступен в разделе Загрузить Skype -> Загрузка бизнес-версии
Для Adobe- flashplayer доступен со страницы загрузки всех версий Adobe Flash Player

Получив msi дистрибутив, выкладываем его на доступную для пользователей шару (сетевой ресурс, доступный для пользователей домена AD), после чего переходим к настройке Group Policy AD.  Запускаем GP Managment после чего создаем групповую политику Computer Configuration -> Software Settings -> Software installation где указываем путь до нашей шары (не перепутать с локальным размещением файла). После применения система спросит про метод разворачивания- где мы указываем Assigned.

После этого ждем минут 10-15, или же форсим апдейт GP запуском из “Win + R” команды gpupdate /force
После этих действий- при перезагрузке участника домена, в фоновом режиме, еще до входа в систему на компы будет установлены указанные для обновления программы, и главное без участия пользователя и требования предоставления админского пароля.

Единственный момент, если надо будет переустановить новую версию, то надо будет удалить ранее созданную политику, после чего создать новую. Этот способ отлично подходит для всего многообразия пакетов, которые могут понадобиться в жизни офиса- различные adobe’вские плюшки- flashplayer, reader, аськи и квипы, skype, различные бродилки и много чего еще.

Настроиваем логин: K Menu -> System -> Login Screen
Во вкладке Remote, меню Style выставляем  Same as Local
Во вкладке Security, ставим галку Allow local system administrator login

После этого запускаем сервер Xming на стороне виндовой машины и настраиваем подключение, запустив программу XLaunch:
Multiple Window -> Start a program -> в Run Remote выбираем Using PuTTY и прописываем логин информацию к CentOS серверу через SSH  -> Additional parametrs можем оставить пустыми, либо прописать свойства терминала Х и ssh соединения ->  Готово

После нажатия Готово к нам вылетит окно стандартного текстового терминала юниксового сервера xterm, в котором мы можем запускать любые приложения, также как и в окне ssh сессии, с тем условием, что в случае запуска гуевых приложений, предназначенных для работы в X-окружении, в ssh сессии мы бы получили сообщение об ошибке, а в данном случае это приложение будет запущено на нашем виндовом рабочем столе. Для этого набираем любое юниксовое приложение:

# xeyes &
или
# blackjack &

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

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

В процессе настройки в какой то момент в логах появилось неприятное сообщение о том, что пакеты дропаются стороной CentOS сервера, что вылечилось добавлением в файл X-сервера Xming виндусовой машины C:\Program Files\Xming\X0.hosts строчки, содержащей IP адрес нашего CentOS сервера. Но это скорее исключение из правил, ибо все работает и без этого.

В итоге ребутнули сервак 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 клиент, не требующий уже никаких вводов логина и дополнительных настроек.

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

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

Но как было объяснить бургу, не имея под рукой английского MS Word где ему отключить просмотр исправлений, было не совсем понятно, так что единственный путь устранить этот ужасающий вид- была возможность принять эти исправления, что делается следующим образом,
для 2003 офиса:  Сервис -> Исправления -> в появившемся тулбаре выбираем Принять выделенные исправления -> Применить все изменения в документе
для 2007 офис: Рецензирование -> Принять -> Принять все изменения

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

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

1. На сайте VLSC скачивается исходник необходимой Windows XP, но есдинственно что на сайте имеется только exe вариант, который можно либо запустить из уже установленной Windows 7, либо сторонними средствами перегнать в ISO и записав на диск поставиться с него.

2. Поставиться со старого Windows XP находящегося на балансе конторы, ибо хотя мелкомягким на это дело наплевать, тем не менее проверяющие могут вздрючить за то что у вас использован например чужой VLS ключ. Так что если у вас нет копоративной XP, либо используйте пункт 1, либо ставьтесь с любой OEM версии Windows XP и активируйте её по телефону, сообщив что это downgrade и назвав серийник Windows 7. Народ правда в инетах пишет о том что могут послать если вы пользовали забаненный серийник XP, но это опционно, ибо серийник операционки на которую вы скатываетесь у меня ни разу не спрашивали. Видимо все зависит от того, внушает ли ваш голос доверие индийскому колл-центру.

На 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

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

После этого вроде как все должно начать летать и видиться, но у меня картина осталась той же самой, так что это не дало мне ни малейшего результата. После чего я решил таки рискнуть пропатчить систему найденным патчером для ядра.  Вкратце суть работы такова, на машине с процессором поддерживающим технологию PAE, данный патч  создает копию имеющегося  ntkrnlpa.exe после чего патчит его и по его мотивам создает новый файл ntkr128g.exe , который и грузит через скрипт AddBootMenu.cmd, который добавляет в boot-меню, так что при загрузке системы появится два типа загрузки – обычная и с поддержкой до 128GB . Для внесения изменений в систему запускаем патчик, говорим  ДА на тему внесения изменений, после чего в появившемся досовском окошке надо будет сказать Y, тем самым дав разрешение на вышеупомянутый патч. После этого система перегружается и при загрузке машина выдает 4GB (доступно 3,86Gb)

Для избавления от меню выбора идем в свойства «мой компьютер» там говорим Дополнительные параметры системы -> Загрузка и восстановление -> Параметры. Снимаем галку Отображать список операционных систем. Перегружаемся.

После всех этих манипуляций у меня появилась надпись в правом нижнем углу, гласившая  «Test Mode Windows 7 Build 7600» -не скажу что она мне доставляла неудобство, но чувство эстетического дискомфорта я все же при виде её испытывал, поэтому говорим WIN_окошко (что между правым Ctrl и Alt) + R и вбиваем  mcbuilder. Говорим ок, ждем выполнения и перезагружаем машину.

Собственно все- машина видит 4 гига, рапортует о том, что доступны 3.86Gb и главное что может пользовать эту область памяти для выполнения своих процессов- запустил три машины по 1.2Gb и все нормально шуршало- исключая хостовую операционку ибо она сама подтормаживала, как и должна была бы при использовании 256 метров.

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

Но тут возникает интересный момент- система видит единственный datastore размеров в 800Gb, и все. То есть в девайсах показывает что есть рейд контроллер, есть рейд массив на 2.8TB, но попытка обнаружения новых datastore не увенчивается успехом, так что в системе доступны только 800 гиг. Гуглю, лезу по форумам и обнаруживаю интересный момент, что VMware не может создавать хранилища больше двух террабайт, то есть у системы VMware и имеется ограничение на создание файлов размером более 2TB.

Чертыхаюсь, перегружаюсь- вижу что VMware видит том на аппаратном уровне, так что попытка разбить его на слайсы сразу будет увенчана неудачей. Собственно залезаю снова в рейдовский биос, сношу том и нарезаю его двумя кусками в 900Gb и 1900GB, после чего запускаю снова инсталлер. VMware видит оба куска, и я ставлю её на тот что  размером 900Gb. Все устанавливаю, загружаю систему, подключаюсь гипервизором- все замечательно: в системе два хранилища данных datastore, размерами в 900Gb и 1900Gb.

Резюме: Система виртуализации VMware ESXi не может создавать хранилища данных LUN размером превосходящие 2TB, в данном случае сказывают ограничения по размеру создаваемого файла. При этом если том превышает своими размерами 2TB, то система берет то количество дискового пространства, которое выходит за пределы 2TB и из них создает хранилище, отбрасывая 2TB за ненадобностью. В этой связи единственный способ борьбы- нарезка имеющегося дискового пространства массивами не превышающими 2TB, в этом случае VMware подхватывает их без проблем, и нарезанные массивы подключаются к настроенным системам, средствами VMware путем добавления новых дисков.

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

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

Собственно для начала можно попытаться открыть ссылочку хостнейм/?q=admin/settings/clean-urls и зайти оттуда админом, но вероятнее всего ничего не получится, но если по этому адресу высветится такая панель логина- то это оно самое.
Для начала проверяем .htaccess на предмет записи вида:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
</IfModule>

Если оно есть и все равно ничего не работает, то вооружаемся кофием и идем в phpMyAdmin, где ищем по базе строчку clean_url, скорее всего она находится в табличке variable со значение s:1:”1″; которое мы меняем на значение s:1:”0″; после чего очищаем кэш всем табличкам начинающимся с префикса cache_ выбрав Очистить или TRUNCATE. После этого все начинает открываться, но без использования чистых ссылок, то есть в виде /?q=имя страницы
Собственно теперь последний момент- идем в админку и снова включаем чистые ссылки в настройке сайта: Administer > Site configuration > Clean URL.

Старый сервер однопроцессорный, второй двухпроцессорный.

Стали выяснять, оказалось что помимо R65 Adv Routing клиент устанавливает также HFA70, то есть получается что утилита upgrade_import на старой машине и новой различается версиями.  Собственно не смотря на поучения нашего продакта, который полез в глубины кластеризации шлюзов, посоветовал клиентам попробовать использовать одинаковые версии утилиты upgrade_import.

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

В этой связи возникла задача переписать стандартное правило автоповторов для exim. Для этого открываем конфигурационный файл и идем в самый его конец, в секцию RETRY. Там мы видим следующие строки:

########################################
#                      RETRY CONFIGURATION                           #
########################################
begin retry
# Domain               Error       Retries
*                 refused_A   F,2h,20m;
*                      *           F,2h,15m; G,16h,1h,1.5; F,4d,6h

Это стандартное правило автоповторов для exim, и оно всегда имеет две звездочки, для того чтобы описать общее правило для всех доменов и ошибок, не описанных отдельным полем. Об этом описании мы поговорим позже, а в данной записи получается что в случае любой ошибки для любого домена повтор отправки будет осуществляться каждые 15 минут в течении двух часов, после чего с интервалами от одного часа до 16 часов, с множителем в 1,5, после чего в течении 4 дней попытка будет осуществляться каждые 6 часов. После истечения времени автоповтора exim отбивает адрес доставки и скитывает отправителю отлуп.

Само правило автоповтора создается по следующему шаблону:
<Domain><Error><Retries>
Первым пункт может включать как имя домена, так и, для сужения задачи, адрес получателя.
Второй пункт описывает специфическую ошибку, которые бывают следующих типов:
auth_failed – при неудачной аутентификации в случае отправки на хост из списка  hosts_require_auth
data_4xx   – при ошибке которая получается для команды smtp диалога DATA, или сразу же после команды
mail_4xx   – при ошибке которая получается для команды smtp диалога MAIL.
rcpt_4xx    – которая получается для команды smtp диалога RCPT
Также в этих трех ошибках, ошибка может задаваться полным номером, для сужения правила применения автоповтора.
lost_connection – при неожиданном закрытии SMTP-сессии со стороны сервера
refused_MX – при отказе в соединении к хосту определенному как почтовый сервер по данным из MX записи
refused_A – при отказе в соединении к хосту полученному не из MX записи
refused – при любом отказе в соединении
timeout_connect_MX – при таймауте попытки соединения с хостом определенномв MX-записи
timeout_connect_A – при таймауте попытки соединения с хостом полученным не из MX-записи
timeout_connect – при таймауте любой попытки соединения
timeout_MX – при таймауте во время соединения или в процессе SMTP-сессии с хостом, полученным из MX-записи
timeout_A – при таймауте во время соединения или в процессе SMTP-сессии с хостом, полученным не из MX-записи
timeout – при таймауте во время соединения или в процессе SMTP-сессии
tls_required – в сессии соединения сервер должен был использовать TLS (сервер определен в списке  hosts_require_tls), но либо TLS не был предложен, либо сервер прислал ответ 4xx на команду STARTTLS
quota  – при локальной доставке транспортом “ appendfile ” была превышена квота почтового ящика пользователя
quota_<time> – при локальной доставке транспортом “ appendfile ” была превышена квота почтового ящика, и к почтовому ящику не обращались время равное <time>
Также после этого поля возможно определить отправителя, тем самыв сузив правило автоповтора, например для приоритезации руководства компании:
senders=<address list>
Тогда правило автоповтора будет выглядеть
kremlin.ru  rcpt_452  senders=”mainperson@odminblog.ru”  G,8h,10m,

Третий пункт отпределяет само правило автоповтора:
<letter>,<cutoff time>,<arguments>
Буквой задает алгоритм вычисления правила автоповтора:
F – повторять автоповтор с определенным интервалом. Первое число определяет в течении какого периода осуществлять автоповтор, второе задает интервал.
G -  повторять автоповтор в геометрически увеличивающихся интервалах. Первое число определяет максимальное значение для интервала, второе начальное значение интервала, третье число множитель, используемый для увеличения интервала при каждом повторении.Если первое число не задано, то интервал увеличивается до значения параметра retry_interval_max, который не может быть больше 24h.
H – повторять отправку повтора со случайными интервалами. Используемые аргументы – такие же как для  G. Для каждого повтора, предыдущий интервал умножается на фактор, для получения максимума следующего интервала. Минимальный интервал – первый аргумент параметра, и актуальный интервал выбирается случайным образом из диапазона между ними.
Если в поле правила автоповтора ничего не задано, то сразу после неудачной попытки отправки, генерируется рикошет и уходит в сторону отправителя.

Исходя из всего вышеописанного создаем новое правило автоповторов:
####################################################
#                      RETRY CONFIGURATION                           #
####################################################
begin retry
# Domain               Error       Retries
alloffice@odminblog.ru    *
odminblog.ru    quota
*                 refused_A   F,2h,20m;
*                      *           F,2h,15m; G,16h,1h,1.5; F,4d,6h

По этому правилу на все ошибки препятствующие доставки на адрес alloffice@odminblog.ru будет генерироваться рикошет, а при переполнении ящика кого либо из пользователей домена odminblog.ru также будет генерироваться рикошет

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

Схема работы простая: есть юниксовый сервер UNIX-Server под управлением CentOS на котором крутится X-клиент/сервер; есть виндовая машинка Win-XP на которой поднимается X-сервер Xming с помощью которого мы подключаемся к клиентской части UNIX-Server и по идее должны получить картинку с X-терминалом на рабочем столе виндовой машины.

Для начала скачиваем и устанавливаем на нашу Win-XP рабочую станцию X-сервер  Xming, откуда нить с инетовского зеркала, благо их предостаточно разбросано по инету. После установки пробуем настроить работу через Xdmcp.  Это специфический незашифрованный протокол, используемый для аутентификации и подключения Х-сервера к Х-клиенту.  Поскольку он не является закрытым, то его не рекомендуется использовать в открытых сетях, но это ограничение убирается при использовании сторонних средств шифрования. Ибо это наше первое знакомство, то не будем запариваться на безопасность и попробуем хотя бы запустить данный сервис.

Для этого на UNIX-Server открываем файло  /usr/share/config/kdm/kdmrc и в разделе [Xdmcp] проверяем, чтобы активность равенства Enable=true
После этого добавляем в файлы следующие поля:

/etc/gdm/custom.conf
[xdmcp]
Enable=true

/etc/X11/fs/config
# no-listen = tcp

Настроиваем логин: K Menu -> System -> Login Screen
Во вкладке Remote, меню Style выставляем  Same as Local
Во вкладке Security, ставим галку Allow local system administrator login

Перегружаем Х-сервер
# /etc/rc.d/init.d/xfs restart
после чего переходим к настройке виндового сервера. Запускаем приложение XLaunch, в котором выбираем
One Window -> Open session via XDMCP -> в Connect to host прописываем IP адрес UNIX-Server и ставим галку Use indirect connect (народ пишет, что её надо снять но в нашем случае заработало только с ней) -> можем оставить пустыми, либо прописать свойства терминала Х, например в Remote font server наш IP UNIX-Server, а в Additional parametrs for Xming строку инициализации десктопа без кавычек “-screen 0 800×600″ ->  Готово

Если все настроили правильно, то на выходе получаем консоль с приглашением нашего X-терминала.

# wget ‘http://www.splunk.com/index.php/download_track?file=4.1.4/freebsd/splunk-4.1.4-82143-FreeBSD-i386.tgz&ac=&wget=true&name=wget&typed=releases’
# tar -xzvf splunk-4.1.4-82143-FreeBSD-i386.tgz

Поскольку, как оказалось, пакет пришел нам в уже собранном виде, то оправляем его по месту постоянного жительства:
# cp -R splunk /usr/local/

Перед запуском системы необходимо внести изменения в конфигурационные файлы:

/boot/loader.conf
kern.maxdsiz=”2147483648″ # 2GB
kern.dfldsiz=”2147483648″ # 2GB
machdep.hlt_cpus=0

/etc/sysctl.conf
vm.max_proc_mmap=2147483647

После этого перегружаем сервер для того чтобы изменения вступили в силу. При желании можем создать ручками пользователя от которого будет работать splunk, а также и его группу, но мне что то сегодня в ломы. Поэтому запускаем сервис: перед первым запуском сервера необходимо согласиться с лицензионным соглашением, для этого стартуем:
# $SPLUNK_HOME/bin/splunk start –accept-license

После некоторого диалога, сервер сообщит, что он теперь запущен на http://our_server_hostname:8000 хотя зайти можно и по адресу http://our_server_IP:8000. В данном случае 8000 это дефолтный порт нашего веб сервера.

Теперь переходим к настройке сервера.
Логин и пароль по умолчанию для входа в web-консоль:
username: admin
password: changeme

В верхнем правом углу белеет на темном фоне кнопочка Manager, нажав на которую мы попадаем в общирное меню, позволяющее нам настроить наш сервер в разделе System configurations, а также добавить необходимые модули Apps, собития, поиски и прочая в разделе Apps and knowledge.

В System settings задается хостнейм и настраиваются веб-морда сервера, а также параметры индексирования. Также настраивается отправка алертов по почте и всевозможные уровни логирования, которых доступно шесть вариантов: DEBUG, INFO, WARN, ERROR, CRIT, FATAL.

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

И вот при использовании утилиты стали возникать эпизодические проблемы связанные с тем, что политики там или иначе не открывались в InfoView, сопровождая это матерной руганью “Error occured while trying to copy local_plugins_list.C from Gui library” и “The connection has been refused because the database could not been opened”. Собственно удалось побороть это следующим образом: первое сообщение убралось после того, как клиент установил на своем сервере последнюю версию утилиты cpinfo (на данный момент cpinfo_911000096_2) и снова собрал данные по своей системе. Второе сообщение появилось первый раз при открытии, но после того как выпав в Demo-режим, ручками указывалось что следует открывать вариант InfoView, открылась корректно, после чего повторно стала открываться без ошибок.

Так что получается что проблемы лечатся установкой последних версий cpinfo и InfoView, хотя у коллеги на рабочем XP (я пробовал на своем Server 2003 и двух чистых виртуалках XP и 2Yk) выскакивает ошибка, указывающая на то что при открытии возникают какие то проблемы с буффером памяти, что вероятнее всего находится в зависимости от каких то установленных программ или патчей.

Кстати, в процессе копания вскрылся интересный момент что cpinfo собранный на R65 открывается нормально в версии R65.3 SmartDashboard, в то время как в обычной R65, открытие политик приводит к возникновению ошибки The connection has been refused because the database could not been opened.

Собственно в CentOS процесс загрузки работает по принципу System V и расписан в файле  /etc/inittab, точнее расписано то как процесс INIT отрабатывает уровни загрузки. В системе фалы загрузки находятся в каталоге /etc/rc.d и носят названия rc0.d, rc1.d, rc2.d, rc3.d, rc4.d, rc5.d, и rc6.d. Пользователи могут размещать файлы в этих каталогах которые будут контролировать запуск сервисов в системе.В свою очередь эти фалы линкуются на каталог /etc/rc.d/init.d и содержащиеся в них скрипты запуска процессов. В этой связи для запуска сервиса необходимо создать полноценный файл запуска сервиса в /etc/init.d, после чего задать символический линк на него из папки соответствующей тому уровню запуска, на котором необходимо стартовать данный сервис. Файлик запуска сервиса будет выглядеть следующим образом, хотя можно расписать все  пару строк просто строкой запуска сервиса:

#!/bin/bash
#
# chkconfig: 35 90 12
# description: Foo server
#

exit 0

Если нет желания заморачиваться с написанием скрипта, то можно добавить строку инициализации запуска сервиса в файл /etc/rc.local. Это файл будет отработан в самом конце загрузки системы, но перед выдачей меню логина.

Для добавления сервисов находящихся в попдапках rc0.d – rc6.d в автозагрузку в системе есть специальная утилита chkconfig, с помощью которой можно добавлять или исключать сервисы.

# chkconfig -l service_name # просмотреть уровни автозагрузки сервиса
# chkconfig  –level 34 service_name on|off|reset # вкключить или выключить сервис на 3 и 4 уровнях
# chkconfig  –del service_ name # удалить службу
# chkconfig  service_name on|off # включить или выключить службу на всех уровнях
ну и есессно главная команда:
# man chkconfig

Помимо этого можно воспользоваться утилитой ntsysv , для редактирования всех уровней или задач редактирования для определенного уровня:
# ntsysv –level 34

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

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

Итак на “Завалинку” прикрутил Поиск, который у меня по каким то причинам не работал. Собственно по-началу не мог понять чем это вызвано, поскольку поиск не искал ничего, и любой запрос получал 0 результатов. Проковырявшись какое то время в сторону того что поиск не ищет по utf-8 я допетрил, что в Joomla все крайне взаимосвязано, и включив модуль в разделе модулей, также необходимо активировать соответствующие ему плагины.  Так что собственно после включения плагина Search – Content все начало нормально искаться.

Туда же я прикрутил отличный модуль RokAjaxSearch, позволяющий осуществлять поиск как по содержимому сайта, так и по Google. Причем найденные страницы он выводит сразу же по мере набивания текста, в ниспадающем меню, что крайне удобно и позволяет не прибегать к каким нибудь сторонним поисковым формам.  Модуль абсолютно бесплатный и крайне удобный в настройке и использовании. Единственное что, надо его заставить говорить по русски, а то слово Search среди русских букв слишком бросается в глаза.  Для этого берем файл language/en-GB/en-GB.mod_rokajaxsearch.ini (для другого модуля файло будет называться соответственно), в котором меняем правую часть выражений на русские варианты. Далее файл сохраняем в кодировке UTF-8, иначе все будет козякозябрами. Для этого в блокноте, при сохранении, в нижнем выпадающем меню кодировка выбираем UTF-8. Сохраняем- заливаем обратно на сайт- и все работает.

После этого я подключил страницу о 404 ошибке, которая не смотря на мои пылкие терзания файла .htaccess не возымела никакого действия. Довольно странно, ибо получается что отработка движка  joomla каким то образом превалирует над правилами файла управления .htaccess
Собственно пути для получения страницы ошибки два:

1. Через файл .htaccess в который мы добавляем строчки:

ErrorDocument 401    /error401.php
ErrorDocument 403   /error401.php
ErrorDocument 404   /error401.php
ErrorDocument 500   /error401.php

2. Через движок Joomla

Изменяем вид стандартного документа об ошибке, который выдает CMS Joomla. Файлец находится по маршруту templates/system/error.php
Открываем его и заменяем его содержимое на следующий код:
######################################

<?php ($error->code == ‘404′) ;
{header (‘Location: http://odminblog.ru/error404.html’);
exit;
} ?>

######################################
где адрес http://odminblog.ru/error404.html путь к сконфигурированной до этого странице ошибки.

При правом клике мышью на объект в Windows 7, выскакивает обычное меню предлагающее определенный функционал, в том числе и стандартный набор раздела меню Отправить.

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

Этот функционал нам дает несколько большее пространство для пересылки файла в один клик. Если же мы хотим, что какие то другие элементы отображались в обычном меню, то нам необходимо создать соответствующий необходимому объекту ярлык в следующем элементе: shell:sendto , или если исходить из стандартной установки, то в папке C:\Users\anchous\AppData\Roaming\Microsoft\Windows\SendTo

Итак UAC отключается двумя способами, из командной строки и используя панель управления, так что каждый выбирает для себя более простой способ.
По мне командная строка быстрее так как вызывается она набором клавиш <Win> + <R> и в открывшемся окошке пишем:

Отключение UAC
C:\Windows\System32\cmd.exe /k %windir%\System32\reg.exe ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 0 /f

Включение UAC
C:\Windows\System32\cmd.exe /k %windir%\System32\reg.exe ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 1 /f

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

То же самое можно произвести из панели управления, путем кликанья по разным кнопкам:

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

Итак, что я могу сказать по %subject%. Приятный интерфейс установки, явно видно, что создатели постарались над базой драйверов, которая без лишних вопросов увидала мой SCSI винт, хотя я и скачал с офф.сайта все возможные драйвера для него, но довольно долгая загрузка системы и задумчивость в процессе. Установка упрощена до максимума, так что от пользователя, в данном варианте, требуется только жать на next, тем более что других кнопок там и нет. И вот тут то, база драйвером сыграла со мной злую шутку: система на окончании установки стала просто безвозвратно залипать, то есть пишется Completing installation, система минут 5 шуршит винтом, определяет видео карточку, снова шуршит, а потом наглухо виснет. После перезагрузки, система говорит, что раз установка завершилась некорректно, то начните её снова, то есть таким образом, тем более если учитывать, что сама установка от и до идет порядка 40 минут (на виртуалке все ставилось само собой в разы быстрее), я просто потерял 2 часа, пока не скумекал отключить все что можно и только после этого загрузка завершилась удачно.

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

Вобщем, ощущения пока на слабенькую четверочку и завтра продолжу свои изыскания на ниве исследования операционки Windows 7.

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

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

И вот сегодня решил привести в порядок одну из имеющихся у меня хостинг площадок, для чего залез на неё и стал чикать не нужные мне сайты и порталы. Заодно решил обновить имеющиеся движки. Актуальным обновлением для системы оказалась версия 1.5.15 и хотя на офф.сайте Joomla уже имеется версия 1.6, я обновился до предлагаемой версии.

И что вы думаете? Мало того, что сайт стал побыстрее крутиться и гораздо приятнее отображаться, так САМОЕ ГЛАВНОЕ: исчезла проблема того, что Joomla не показывала картинки!!! Так что все теперь отображается корректно, и Joomla снова стала моей любовью.

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

ЗЫ: для недовольных деятелей хочу сделать одно замечание, которое возможно придаст данному посту большую осмысленность. Если вы полагаете что совет обновить Joomla полная херь, то открою страшную тайну- Joomla является лишь CMS и то что в ней не отображаются картинки- является только ошибкой корректности отображения html кода, который вводили вы и интерпретирует CMS.  В этой связи откройте исходный код нужной страницы в браузере и сравните с им же в самой Joomla- вероятнее всего Joomla или вы изменили местоположение страницы в иерархии сайта, так что относительный путь к изображению ведет куда то вдаль, поэтому юзайте абсолютные пути для вставки изображений, с использованием доменного имени: Сайт/имаджес/изображение.jpg; а также проверяйте правильность синтаксиса img src, ибо движок Joomla опять же добавляет свои классы изображений, которые препятствуют корректному отображению картинок.

Как вариант, существует решение проблемы, путем добавления строки в файл configuration.php
var $live_site = vashsite.ru

UPD: столкнулся буквально на днях с подобной же проблемой, которую умельцы решали путем правки строки в файле libraries/joomla/document/html/renderer/head.php

заменяя стоку
$strHtml .= $tab.’<base href=”‘.$document->getBase().’”></base>’.$lnEnd;
на
$strHtml .= $tab.’<base href=”‘.JURI::root().’” />’.$lnEnd;
хотя по некоторым данным после подобных телодвижений, перестает отрабатывать навигация через якоря.

Утилита CPinfo собирает содержимое файлов находящихся в root директории установки программного обеспечения шлюза, включая директорию размещения логов $FWDIR/log/* files, а также специфические настройки самой системы.
Таблицы маршрутизации
Вывод команды netstat
Вывод команды ipconfig /all
Версию операционной системы шлюза и установленных патчей и хотфиксов.
Данный памяти и CPU
Вывод команды fw ctl pstat
Вывод системных логов

Утилита портирована для всех систем, поддерживающих систему Check Point, и для каждой системы имеется своя версия, которую необходимо тщательно выбрать именно для своей системы. Боьшинство проблем установки утилиты CPinfo на систему, связаны с тем, что администратор пытается установить не правильную версию утилиты. CPinfo можно установить на следующие системы:

• SecurePlatform
• Linux
• Solaris
• IPSO
• Windows 2000/XP, 2003

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

Установка Linux/SecurePlatform

Скачиваем с офф.сайта последнюю версию CPinfo. Если скачать невозможно, то будем производить установку из идущего в комплекте дистрибутива: /sysimg/CPwrapper/linux/CPinfo/CPinfo-10-00.i386.rpm или копируем с диска, содеражащего комплект утилит Check Point: /linux/CPinfo/CPinfo-10-00.i386.rpm

Для начала сносим имеющуюся в системе версию (на тот случай если она у нас представлена)
#  rpm -e CPinfo-10-00
Заходим в директорию, содержащую установленный файл и распаковывываем архив.
#  gunzip cpinfo_X.tgz
#  tar -xvf cpinfo_X.tar

Устанавливаем утиту cpinfo
#  rpm -ivh CPinfo-10-00.i386.rpm
также можно использовать следующую команду
#  rpm -Uvh –force CPinfo-10-00.i386.rpm

Проверяем корректность установки утилиты, путем поиска в выводе пакета CPinfo-10-00
#  rpm -qa | grep CP
Если утилита установилась без ошибок, но в листинге отсутствует, то перегружаем базу rpm и после этого перезаходим в сессию, путем завершения сессии и нового логина в систему
#  rpm -v –rebuilddb

Проверяем версию установленной утилиты CPinfo
#  cpvinfo /opt/CPinfo-10/bin/cpinfo
Версия билда должна быть где то в районе 9110000xx

После этого перегружаем машину и загрузившись, создаем файл cpinfo путем ввода команды
#  cpinfo -n -z -o hostname.cpinfo

Установка на Solaris

Скачиваем последнюю версию cpinfo с офф.сайта или копируем с диска утилит  /solaris2/CPinfo/CPinfo.tgz.

Просматриваем установлена ли утилита cpinfo и если да, то удаляем имеющуюся версию cpinfo командой pkgrm <package name>
bash-2.05# pkginfo | grep Check
application CPfw1-R55W Check Point VPN-1/FireWall-1 NG with Application Intelligence (R55W)
application CPinfo-R55W Check Point CPinfo NG with Application Intelligence (R55W)
application CPrtm-R55W Check Point SmartView Monitor NG with Application Intelligence (R55W)
application CPshrd-R55W Check Point SVN Foundation NG with Application Intelligence (R55W)
# pkgrm CPinfo-R55W

Заходим в папку с архивом скаченной утилиты и распаковываем её
#  gunzip cpinfo_X.tgz
#  tar -xvf cpinfo_X.tar

Устанавливаем утилиту cpinfo
#  pkgadd -d /var/
как вариант, кладем TAR в директорию /var/spool/pkg и устанавливаем командой pkgadd

После этого проходим установочный диалог, мало чем отличающийся от виндового и установив, проверяем наличие утилиты в системе pkginfo | grep Check command.
bash-2.05# pkginfo | grep Check
application CPfw1-R55W Check Point VPN-1/FireWall-1 NG with Application Intelligence (R55W)
application CPinfo-10 Check Point CPinfo
application CPrtm-R55W Check Point SmartView Monitor NG with Application Intelligence (R55W)
application CPshrd-R55W Check Point SVN Foundation NG with Application Intelligence (R55W)

Проверяем версию билда установленной утилиты
#  cpvinfo /opt/CPinfo-10/bin/cpinfo command.
Версия билда должна быть 9110000xx.

Перезаходим в сессию, перед началом использования cpinfo

Генерим файл cpinfo

cpinfo [-v] [-l] [-n] [-o ] [-r | -t [tablename]] [-c cma ... | -x vs]

-z: сжимать файл вывода с помощью gzip (наиболее эффективно с опцией -o).
-r: включать регистр (для Windows получится большой вывод).
-v: выводить информацию о версиях
-l: включать записи логов (результат- объемный вывод).
-n: Не резолвить IP адреса (быстрый вывод)
-t: вывод состоит только из таблиц (только для SR)
-c: получать информацию о CMA (для Provider-1).
-x: получать информацию о (для VSX)

Получаем вывод cpinfo:
#  cpinfo -n -z -o hostname.cpinfo

Возможные варианты использования утилиты cpinfo:

Получить версию утилиты CPinfo:
#  cpinfo -v

Вывести результат исполнения утилиты в файл cpinfo.out (без разрешения адресов):
#  cpinfo -n -o cpinfo.out

Сжать вывод в файл cpinfo.out.gz:
#  cpinfo -z -o cpinfo.out

Получить информацию о CMA My_Cma и Your_Cma (для Provider-1):
#  cpinfo -c My_Cma -c Your_Cma -o cpinfo.out

Получить информацию о VS 5 (для VSX):
#  cpinfo -x 5 -o cpinfo.out

Открываем админку Wordpress, далее Appearance -> Editor в правой часте приведен список файлов используемой темы, в которой мы находим файл с названием 404 Template (404.php) или что то вроде, после чего подправить в нем сообщение об ошибке.

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

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

<?php get_header(); ?>
<div id=”content”>
<h2>Error 404 – Not Found</h2>
</div>
<?php get_sidebar(); ?>
<?php get_footer(); ?>

или что-нибудь посложнее

<get_header();?>
<div id=”contentContainer”>
<div id=”allContentWidth”>
<div id=”menuUnder”></div>
<div id=”mainContent”>
<div></div>
<div>
<div>
<h2>Error 404 – Not Found</h2>
Go to <a href=”<?php echo get_option(‘home’); ?>/”>the start page</a> or <a href=”javascript:history.go(-1);”>go back</a>.
</div>
</div>
</div>
<?php get_sidebar(); ?>
<div></div>
</div>
</div>

<?php get_footer(); ?>

Сохраняем, заходим бродилкой, ошибаемся, проверяем, радуемся.

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

Для начала мы ставил чистую систему FreeBSD 7.2 и поднимаем на ней стандартный сервер sshd2, чтобы не сидеть в консоли. После этого приступаем к настройкам:

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

# mv /var/tmp/* /tmp/
# rm -rf /var/tmp
# ln -s /tmp /var/tmp

Следом отрубаем возможность входа в консоль под пользователем root, ибо заход под ним дает пользователю сразу же неограниченные права на систему. Поэтому пользователь должен подключаться под собой и только после это забирать права с помощью использования команды su. Для это открываем файл  /etc/ttys и меняем каждую запись “secure” на “insecure”, что запретит пользователю root подключаться к консоли. Это же изменение будет будет требовать пароль пользователя root при рагрузке в однопользовательском режиме системы (single-user mode), что в свою очередь значительно усложнит изменение пароля суперпользователя.

# vi /etc/ttys
#########################################################
console none                            unknown off insecure
#
ttyv0   “/usr/libexec/getty Pc”         cons25  on  insecure
# Virtual terminals
ttyv1   “/usr/libexec/getty Pc”         cons25  on  insecure
ttyv2   “/usr/libexec/getty Pc”         cons25  on  insecure
ttyv3   “/usr/libexec/getty Pc”         cons25  on  insecure
ttyv4   “/usr/libexec/getty Pc”         cons25  on  insecure
ttyv5   “/usr/libexec/getty Pc”         cons25  on  insecure
ttyv6   “/usr/libexec/getty Pc”         cons25  on  insecure
ttyv7   “/usr/libexec/getty Pc”         cons25  on  insecure
ttyv8   “/usr/X11R6/bin/xdm -nodaemon”  xterm   off insecure
# Serial terminals
# The ‘dialup’ keyword identifies dialin lines to login, fingerd etc.
ttyd0   “/usr/libexec/getty std.9600″   dialup  off insecure
ttyd1   “/usr/libexec/getty std.9600″   dialup  off insecure
ttyd2   “/usr/libexec/getty std.9600″   dialup  off insecure
ttyd3   “/usr/libexec/getty std.9600″   dialup  off insecure
# Dumb console
dcons   “/usr/libexec/getty std.9600″   vt100   off insecure
#########################################################

Закручиваем безопасность для ssh сервера. Как его вывести на совсем параноидальный режим, буду разбирать позднее. Пока же ограничиваем пользователей имеющих право на вход в консоль, запрещаем вход с пустым паролем и вход пользователю root. Также ограничиваем время отводимое на подключение к серверу и количество попыток.  Включаем вторую версию SSHv2 вместо идущей по умолчанию первой, т.к. она обеспечивает более высокую безопасность соединения. Поскольку использовать X11 на рабочем сервере мы не планируем то отключим опцию форвардинга.

# vi /etc/ssh/sshd_config
#########################################################
Protocol 2
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 15s
PermitRootLogin no
AllowUsers anchous
StrictModes yes
MaxAuthTries 3
PermitEmptyPasswords no
PrintLastLog yes
UsePrivilegeSeparation yes
UseDNS yes
X11Forwarding no
#########################################################

Теперь переходим к политикам хранения паролей. По умолчанию FreeBSD использует алгоритм md5 для хэширования паролей. Это стойкий и надежный 128-битный алгоритм, но некоторое время назад были найдены слабости в его реализации, поэтому рекомендуется использовать алгоритм blowfish для хранения паролей. Для перевода системы хранения паролей в этот алгоритм, нам следует изменить несколько файлов. парои кстати не будут автоматически сконвертированы в blowfish, и будут храниться в md5 до следующего изменения.

# echo “crypt_default=blf” >> /etc/auth.conf

После этого необходимо задать в файле /etc/login.conf параметр хранения паролей по умолчанию в класс blf.  Также меняем политику применяемых паролей: минимальная длинна, использование верхнего и нижнего регистра, время действия пароля в три месяца и отключения пользователя после 10 минут бездействия.  Также меняем маску прав доступа по умолчанию umask для того чтобы предотвратить доступ пользователей для всех. Маска пробразуется в формат chmod, и все новые созданные файлы и папки будут иметь права доступа 0750, т.е. у “остальных” пользователей не будет никаких прав на данные файлы.

# vi /etc/login.conf
#########################################################
default:\
:passwd_format=blf:\
:copyright=/etc/COPYRIGHT:\
:welcome=/etc/motd:\
:setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES:\
:path=/sbin /bin /usr/sbin /usr/bin /usr/games /usr/local/sbin /usr/local/bin /usr/X11R6/bin ~/bin:\
:nologin=/var/run/nologin:\
:cputime=unlimited:\
:datasize=unlimited:\
:stacksize=unlimited:\
:memorylocked=unlimited:\
:memoryuse=unlimited:\
:filesize=unlimited:\
:coredumpsize=unlimited:\
penfiles=unlimited:\
:maxproc=unlimited:\
:sbsize=unlimited:\
:vmemoryuse=unlimited:\
:priority=0:\
:ignoretime@:\
:minpasswordlen=8:\
:mixpasswordcase=true:\
:passwordtime=90d:\
:accounted=true:\
:autodelete=90d:\
:warnpassword=14d:\
:idletime=10:\
:umask=027:
#########################################################

Обновляем базу логинов:

# /usr/bin/cap_mkdb /etc/login.conf

После смены пароля пользователя в файле их хранения in /etc/master.passwd  записи паролей будут начинаться с $2a. Это будет свидетельствовать о том, что для данного пользователя включилось хеширование blowfish.

Теперь переназначаем правда доступа для пользователей к планировщику задач. Планировщик задач является удобным и в тоже время чрезвычайно мощным средством администрирования *nix платформ. Его неправомочное и неправильное использование может привести сервер в неработоспособное состояние. Это может быть неправильно составленые задания, так и злонамеренное зацикливание выполнения задания, способное привести машину к отказу в обслуживании.

Назначаем права на планирование задач только для пользователя root

# echo “root” > /var/cron/allow
# echo “root” > /var/at/at.allow
# chmod o= /etc/crontab
# chmod o= /usr/bin/crontab
# chmod o= /usr/bin/at
# chmod o= /usr/bin/atq
# chmod o= /usr/bin/atrm
# chmod o= /usr/bin/batch

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

# chmod o= /etc/fstab
# chmod o= /etc/ftpusers
# chmod o= /etc/group
# chmod o= /etc/hosts
# chmod o= /etc/hosts.allow
# chmod o= /etc/hosts.equiv
# chmod o= /etc/hosts.lpd
# chmod o= /etc/inetd.conf
# chmod o= /etc/login.access
# chmod o= /etc/login.conf
# chmod o= /etc/newsyslog.conf
# chmod o= /etc/rc.conf
# chmod o= /etc/ssh/sshd_config
# chmod o= /etc/sysctl.conf
# chmod o= /etc/syslog.conf
# chmod o= /etc/ttys

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

# chmod o= /var/log
# chflags sappnd /var/log
# chflags sappnd /var/log/*

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

# chmod o= /usr/bin/users
# chmod o= /usr/bin/w
# chmod o= /usr/bin/who
# chmod o= /usr/bin/lastcomm
# сhmod o= /usr/sbin/jls
# chmod o= /usr/bin/last
# chmod o= /usr/sbin/lastlogin

Также надо заблокировать несколько сервисов:

# chmod ugo= /usr/bin/rlogin
# chmod ugo= /usr/bin/rsh

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

# chmod o= /usr/local/bin/nmap
# chmod o= /usr/local/bin/nessus

В правами вроде бы закончили, теперь перейдем к горячо любимому файлу /etc/rc.conf в котором мы прикроем некоторые сервисы запущенные в системе по умолчанию, но нам ненужные.
Отключаем MTA, которым по умолчанию является sendmail. Если этот сервис необходим, то имеет смысл использоваться exim или qmail

# echo ’sendmail_enable=”NONE”‘ >> /etc/rc.conf

###############################
***Примечание от 13.012010
По данному синтаксису может возникнуть спор, аналогичный тому что возник у меня с Алексеем ака tess, т.к. по разным версиям фришного мануала sendmail отрубается разным синтаксисом:  по самому man sendmail v.8 рекомендуется использовать приведенный выше, по руководству к самой операционке FreeBSD рекомендуется использовать следующий синтаксис, добавленный в /etc/rc.conf (его же следует использовать если вы хотите чтобы отключить демона работающего на прием почты, а например логи вам высылались ежедневно на почту):

sendmail_enable=”NO”
sendmail_submit_enable=”NO”
sendmail_outbound_enable=”NO”
sendmail_msp_queue_enable=”NO”
###############################

По умолчанию уровень безопасности системы (kernel level) равен -1, т.е. мало защищенный. Если предполагается использовать защищенный уровень, то рекомендуется использовать 2, или даже 3 – как наиболее защищенный.

# echo ‘kern_securelevel_enable=”YES”‘ >> /etc/rc.conf
# echo ‘kern_securelevel=”2″‘ >> /etc/rc.conf

Если не планируется на сервере использовать систему NFS, то отключаем его и демона portmap:

# nfs_server_enable=”NO” >> /etc/rc.conf
# nfs_client_enable=”NO” >> /etc/rc.conf
# echo ‘portmap_enable=”NO”‘ >> /etc/rc.conf

Запрещаем inetd, демон отвечающий за сетевые сервисы (network daemon dispatcher), в виду того что его использование несет много уязвимостей

# echo ‘inetd_enable=”NO”‘ >> /etc/rc.conf

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

# echo ‘clear_tmp_enable=”YES”‘ >> /etc/rc.conf

Если не пишем логи на удаленную машину, то задаем демону syslogd не занимать сетевые сокеты

# echo ’syslogd_flags=”-ss”‘ >> /etc/rc.conf

Cообщения ICMP redirect могут быть использованы для атаки, поэтому игнорируем и логируем их

# echo ‘icmp_drop_redirect=”YES”‘ >> /etc/rc.conf
# echo ‘icmp_log_redirect=”YES”‘ >> /etc/rc.conf

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

# echo ‘log_in_vain=”YES”‘ >> /etc/rc.conf

Чтобы при входе в консоль не выводилась версия OS и координаты ядар, запрещаем обновление файла с сообщением дня (Message of Day)

# echo ‘update_motd=”NO”‘ >> /etc/rc.conf

Задаем несколько параметров ядра путем редактирования файла /etc/sysctl.conf . Для начала запрещаем обычным пользователям просмотр процессов запущенных с иным UID

# echo “security.bsd.see_other_uids=0″ >> /etc/sysctl.conf

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

# echo “net.inet.tcp.blackhole=2″ >> /etc/sysctl.conf
# echo “net.inet.udp.blackhole=1″ >> /etc/sysctl.conf

Генерируем произвольный ID для IP пакета для того чтобы исключить возможность fingerprint и затруднить возможность злоумышленника систематизировать пакеты.

# echo “net.inet.ip.random_id=1″ >> /etc/sysctl.conf
# echo “net.inet.icmp.maskrepl=0″ >> /etc/sysctl.conf

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

# echo ‘tcp_drop_synfin=”YES”‘ >> /etc/rc.conf

Вносим небольшие правки в ядро, которое придется пересобрать. Первой мы иключаем возможность перезагрузки от ctrl+alt+del, второй устанавливаем генерацию ID для сетевых пакетов (вариант с sysctl.conf работает только на системах от 5.3, на всех предыдущих необходимо перебирать ядро). Также включаем сброс SYN/FIN и режим stealth forwarding, который позволяет переправлять пакеты через хост без изменения из TTL, т.е. эта функция подойдет например для сокрытия фаервола от команды tracerote

# vi /usr/srs/sys/i386/conf/Custom_KERNEL

#########################################################
options SC_DISABLE_REBOOT # Disable Ctrl+Alt+Del
options RANDOM_IP_ID             # Enables random IP ID generation
options TCP_DROP_SYNFIN     # Enables the ability to drop SYN/FIN packets
options IPSTEALTH                     # Enable stealth forwarding
#########################################################

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

DNS TTL это параметр по аналогии с параметром жизни сетевого пакета (Time To Live) отвечающий за существование записи DNS зоны в кеше DNS сервера, без дополнительных изменений.  По достижении установленного времени, кеширующий сервер запрашивает DNS сервер, содержащий доменную зону, информацию о зоне.
В стандартной настройке $TTL равно 86400 секунды, т.ч. если минимальный параметр TTL на вашем доменном сервере DNS и кэширующем сервере удаленного хоста установлен по умолчанию в значение 86400, то обновление произойдет на сервере через день.

Типичная SOA запись выглядит таким образом:
$TTL    3600

@       IN      SOA     ns.domain.com. abuse.ns.domain.com.  (
2009120200      ; Serial
3600                       ; Refresh
900                          ; Retry
3600000              ; Expire
3600 )                    ; Minimum

Перед запланированными процедурами, первую строку SOA записи следует изменить на значение $TTL    600 , или меньше, после чего изменить serial number и перегрузить зоны, т.е. рестартовать DNS сервер и спокойно идти за чаем в ожидании истечения времени указанного для TTL первоначально. После того как эти данные обновятся, что можно проверить с помощью команды dig, можно начинать производить необходимые процедуры по миграции серверов. Изменение IP адресов произойдет в течении указанного времени.

После того как все процедуры по переезду и миграции будут произведены, значение  TTL можно перевести в большее значение с тем, чтобы снизить нагрузку на DNS сервер и избежать слишком большого сетевого трафика при обновлении зон.

После этого с ManageEngine скачиваем SupportCenter (http://www.manageengine.com/products/support-center/download.html) естественно для Linux. Кладем наше богатство в папку /tmp и устанавливаем путем который я описывал ранее в установке приложений для Linux систем:

# mv ManageEngine_SupportCenter_Plus.bin /tmp/
# cd /tmp/
# chmod 754 ManageEngine_SupportCenter_Plus.bin
# ./ManageEngine_SupportCenter_Plus.bin

Последняя команда вызовет диалог установки приложения.
Путь установки: /root/AdventNet/ME/SupportCenter
Выбираем тип установки FreeEdition, который дает возможность завести один технический аккаунт и сколько угодно много аккаунтов клиентов.  Порт веб-сервера выберем произвольный, например 4896, и в качестве используемого СУБД – MySQL.

Установка закончена, теперь необходимо запустить сервер:

# cd /root/ManageEngine/ServiceDesk/bin/
# sh run.sh

Процесс запуска занимает несколько минут, после чего мы можем через бродилку обратиться к серверу: http://localhost:4896
Логин для входа в администраторский раздел:
Username     :     administrator
Password     :     administrator

Мы сразу же попадаем в раздел администрирования, где запускается мастер настройки системы там мы расставляем галочки по мере необходимости тех или иных опионов нашего сервис деска, а также настраиваем внешнее подключение к сервису: Organization Settings -> Settings, там мы выставляем настройки контактов и адреса сервера.

После недели гугления получился небольшой списочек из 4-5 кандидатов на звание самого – самого, естественно что меня интересовали бесплатные и условно бесплатные движки. Перепробовав весь список и даже больше, ибо на Hostgatore, как оказалось в состав предлагаемых движков доступных через Fantastico de Luxe помимо множества бордов, CMS и магазинов, также входит 7 различных систем Service Desk, правда все они оказались этакими кастрированными версиями для организации службы поддержки, быстро и на коленке. Наиболее меня впечатлила система osTicket, на её базе вполне можно организовать простенький сервис деск исключительно для общения со службой поддержки через сайт. Но я искал более продуманную систему, поэтому поразмысли остановился на системе SupportCenter Plus от компании ManageEngine.

Система доступна в вариантах под Windows и под Linux, и представляет огромный функционал: почтовые ответы с использованием внешних почтовых систем, базу знаний, интеграцию с форумами, центральное управление учетными записями, каталог продукции, синхронизация БД, интеграция с AD и Outlook, генерацию отчетов. На сайте компании ManageEngine доступны два ознакомительных варианта: 30-ти дневный trial (двух версий Standard и Professional), а также так называемый Free Edition, дающий возможность управления 25 аккаунтами и функционал Standard Edition.

Система устанавливается на RedHat Linux 7.x и Debian 3.0, а также Windows 2000 Prof и XP, Server 2000/2003. В установочном комплекте идет движок БД MySQL, а также поддержка MS SQL 2000/2005 и большинства серверов SQL.

По стоимости получается: от 500 бачинcких за двух технарей в Standard Edition и от $1000 за двух инженеров в Professional Edition.

Наиболее простой способ выяснился после разглядывания подробностей файла /etc/crontab
простая установка директивы  MAILTO= в описании основных параметров отправит всю почту на указанный мейл, но в моем случа нужно давать эпизодического пендаля хозяину сервера, чтобы он следил за своей вотчиной, а я за своей, в этой связи обнаружилось два способа:

корявенький, с указанием директивы mailto в поле команды:
3    1  * * * root MAILTO=xxx@odminblog.ru /root/scripts/mailcleaner.sh
и на мой взгляд более корректный с перенаправлением вывода исполнения скрипта:
3    1  * * * root /root/scripts/mailcleaner.sh 2>&1 | mail -s “Mail base cleaning” xxx@odminblog.ru

, также можно перенаправить вывод выполнения скрипта в лог файл:
3    1  * * * root /root/scripts/mailcleaner.sh >> /var/log/cron.log 2>&1

################################

while [ 0 -eq 0 ]; do

[ -z "`ps axu | grep имя процесса | grep имя владельца процесса | grep -v grep`" ] && команда для запуска
sleep 5
done

################################

Для закрепления пройденного материала накропим скриптик для рестарта веб-сервера под апачем:
Имя процесса – httpd
Пользователь родительского процесса – root
Команда для старта – apachectrl startssl
Соответственно:

#!/bin/sh
while [ 0 -eq 0 ]; do
[ -z "`ps axu | grep http | grep root | grep -v grep`" ] && apachectrl startssl
sleep 5
done

Для автоматизации загрузки этого процесса – прописываем его в  /etc/rc.local.

После того как обновление закончилось, следуем в папку /usr/src. Все изменения версий описаны в файле UPDATING.
Далее просто листинг команд:
1. cd /usr/obj
2. rm -rf *
Если при удаление выдало ошибки по поводу установленных флагов, то необходимо выполнить команду
chflags -R noschg *
и потом повторить удаление.
3. cd /usr/src
Вот теперь мы собственно и начнем собирать систему:
4. make buildworld
конфигурим ядро:
5. make buildkernel KERNCONF=YOUR_KERNEL_HERE (YOUR_KERNEL_HERE – название ядра которое лежит в папке /usr/src/sys/i386/conf. Но заметьте, вы путь не указываете, а указываете только имя файла. Советую переименовать файл, чтобы скомпилилось новое ядро, а не то что было до обновления системы)
инсталлируем ядро:
6. make installkernel KERNCONF=YOUR_KERNEL_HERE
7. reboot (загрузиться в single mode)
В следующем пункте будьте осторожны, здесь проверяются конфигурационные файлы и предлагается заменить файлы вашей системы файлами новой системы; оставить старые файлы; объединить. Таким макаром можно удалить всех своих пользователей, поэтому все делаем аккуратно:
8. mergemaster -p
Инсталлим новую систему:
9. make installworld
И снова правим файлы:
10. mergemaster
И последняя перезагрузка
11. reboot

Собственно все- имеем рабочую машину с обновленным ядром

Примечание:
На рабочем, а тем более удаленном сервере пункты 7 и 8 можно опустить, переходя сразу к 9. У меня за многочисленные разы никаких проблем не возникало.

Порт – это наиболее удобный способ установки приложений в среде FreeBSD, причем приложение устанавливается со всеми выпущенными на данный момент заплатками и патчами. Процесс установки начинается командой make в корневой директории порта и сводится к поиску подходящих исходниках на зеркалах, скачиванию, разархивированию, компиляции и, после задания команды make install, установки с преднастроенными параметрами, и регистрацией в каталоге /var/db/pkg/(база установленных пакетов) .

Собственно для обновления дерева портов, необходимо поставить основной порт, отвечающий за данную процедуру- cvsup.

# cd /usr/ports/net/cvsup-without-gui
# make install

После этого нам необходимо настроить конфигурационный файл cvsupfile, находящийся в каталоге /etc
######################################
*default host=cvsup.FreeBSD.org
*default base=/usr
*default prefix=/usr
*default release=cvs
*default tag=.
*default delete use-rel-suffix

src-all
*default tag=.
ports-all
doc-all
######################################
Параметры конфига таковы:
*default host=cvsup.FreeBSD.org – адрес сервера откуда мы тащим обновления.
*default tag=RELENG_6_3 – до какой версии обновляемся
RELENG_4 – обновление до FreeBSD-4-Stable
RELENG_4_10 – обновление до FreeBSD-4-10
RELENG_5 – обновление до FreeBSD-5-Stable
RELENG_5_3 – обновление до FreeBSD-5-3
RELENG_6_3 – обновление до FreeBSD-6-3
. – обновление до Current версии (по преданиям на рабочих серверах этого лучше не делать) Если обновляются только порты, то нужно ставить точку, если же вы нацелились на make world, то необходимо указывать версию системы.
src-all – обновить исходники системы
*default tag=. – указатель до какой версии обновить порты, если указать что то вместо точки, то порты благополучно потрутся, и придется поновой обновляться чтобы получить их назад.
ports-all – указываем что хотим обновить все порты

После того как конфиг сохранили, следует запустить обновление ситемы:
# /usr/local/bin/cvsup -g -L 2 /etc/cvsupfile

после этого можно спокойно идти пить чай-кофе-пиво (нужное подчеркнуть), т.к. процесс будет идти минут 15-20 как минимум, в зависимости от канала.

Теперь чтобы поддерживать актуальную коллекцию портов (звучит очень комильфо), необходимо засунуть задачу в cron, для это в каталоге /usr/local/sbin/ создаем файло например ports_update.sh, прописываем в него указанную выше строку, и пишем в cron

35 23 * * 6            root            /usr/local/sbin/cvsup_up.sh

хотя можно засунуть файл и в /etc/periodic/weekly/
Естетсвенно в обоих случаях файлу следует дать права на исполнение.

Для работы с установленными пакетами используются команды семейства pkg_ :
просмотр версий пакетов, устаревших и актуальных
# pkg_version -v

Если необходимо обновить какой либо порт, то идем в директорию его порта, и говорим следующее:

# make clean
# make
# pkg_delete -f имя_пакета  (имя пакеты выводится при листинге pkg_version  )
# make install
# make clean

***Примечание:
При обновлении портов, можно опустить неиспользуемые порты с языковыми поддержками, путем добавления в файл /usr/sup/refuse следующих строк:

ports/arabic
ports/chinese
ports/french
ports/german
ports/hebrew
ports/hungarian
ports/japanese
ports/korean
ports/portuguese
ports/polish
ports/vietnamese

• Пакетные файлы rpm
• Самораспаковывающиеся двоичные файлы bin
• Файлы архивов tar

Пакетные файлы в среде Linux устанавливаются с помощью пакетного менеджера, т.е. процесс установки мало чем отличается от установки виндового exe’шника, два клика, автостарт и набор yes – next. Работа с пакетным менеджером крайне удобна, т.к. позволяет производить управление пакетами, обновление устаревших версий и многое другое. Но иногда менеджер либо не кушает rpm, либо в принципе отсутствует на машине, и тогда приходится возвращаться назад к предтечам, ака терминальной сессии:

Наиболее прямой способ установки пакета, без изысков:

# rpm -ivh sample.i386.rpm

Если пакет уже установлен, или при возникновении каких то ошипок следует задать игнор оных:

# rpm -ivh –replacepkgs sample.i386.rpm

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

# rpm -ivh –replacefiles  sample.i386.rpm

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

Удаление пакета производится с помощью той же команды:

# rpm -e sample

Установщик может начать ругаться о том, что удаляемый пакет связан с существующими в системе, для этого в установке нужно задать игнор зависимостей, уже знакомым нам ключом –nodeps

Обновление пакета производится аналогичным способ:

# rpm -Uvh sample.i386.rpm

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

# rpm -Uvh –oldpackage sample.i386.rpm

или если вы хотите обновиться до новой версии:

# rpm -Fvh sample.i386.rpm

И естетсвенно как обычно рулит  # man rpm

Самораспаковывающиеся двоичные файлы bin устанавливаются простым образом. Переходите в терминале в папку с этим файлом, задаете ему права на запуск:

# chmod a+x sample.bin

и после этого запускаете сам файл

#./sample.bin

Файлы архивов tar устанавливаются большим числом манипуляций, но позволяют более тонко настроить систему в процессе установки. Архивы обычно идут в формате tar.gz Для распаковки архива необходимо задать команду распаковки

# tar -xzvf sample.tar.gz ( или добавить ключ “-c /path-to-unpack” чтобы задать путь для распаковки)

После чего заходите в папку и внимательно читаете мануалы. Обычно синтаксис установки следующий:

# ./configure

# make

# make check

# make install (так же возможные варианты синтаксиса  sudo make install или su -c ‘make install’)

Для вывода доступных функций конфигурации пакета следует задать команду:

# ./configure –help

Также имеется возможность конвертации пакетов rpm в архивы tar, и наоборот, но об этом несколько позже