USB DOS boot disk

Наконец-то я это запишу…

В который раз при необходимости прошить новый BIOS на материнской плате сталкиваюсь с проблемой: как сделать загрузочную флешку с DOS’ом? Google в ответ на ключевые слова “dos usb boot” вываливает тонну разных советов, которые можно кратко охарактеризовать как “удаление гланд через одно место”. При этом в процессе поиска я помню, что есть простой способ сделать загрузочную флешку, но как это делается – напрочь забыл и найти не могу. Так вот…

Простой способ создать загрузочную флешку с DOS

Качаем архив.

В архиве файл HPUSBFW.EXE и папка dos. HPUSBFW.EXE – это утилита “HP USB Disk Storage Format Tool”, которая отформатирует флешку и сделает ее загрузочной. В папке dos лежат системные файлы DOS’а, которые будут записаны на флешку после форматирования.

Процесс создания загрузочной флешки прост до безобразия: запускаем утилиту (в Vista и выше запускать от имени администратора), отмечаем галками нужные опции, указываем путь к каталогу dos и нажимаем start:

Установка и настройка MySQL 5.1 (UTF-8) в FreeBSD

В /etc/make.conf добавляем:

.if ${.CURDIR} == "/usr/ports/databases/mysql51-server"
    WITH_CHARSET=utf8
    WITH_COLLATION=utf8_general_ci
    WITH_XCHARSET=all
.endif

собираем порт:

cd /usr/ports/databases/mysql51-server/
make install clean

в /etc/rc.conf добавляем:

mysql_enable="YES"

создаем конфигурационный файл MySQL:

touch /var/db/mysql/my.cnf

добавляем в /var/db/mysql/my.cnf:

[mysqld]
init-connect="SET NAMES utf8"
skip-character-set-client-handshake

запускаем MySQL:

/usr/local/etc/rc.d/mysql-server start
Блог переехал

Блог переехал на домен wolandblog.com. В честь этого события “ожила” одна деталь оформления. Слабо найти какая? :)

Бесплатные SSL сертификаты. Палю тему :)

www.startssl.com – бесплатные сертификаты со сроком действия 1 год. Сертификат распознается всеми браузерами кроме оперы, что не есть хорошо, но зато действует год и может быть продлен.

freessl.su – бесплатные сертификаты COMODO со сроком действия 3 месяца. Сертификат распознается всеми браузерами без исключения, но придется каждые 3 месяца генерировать новый, впрочем вся процедура отнимает минут 10 времени.

 

Процедура получения сертификата на startssl.com

1. Регистрация в системе.
Control panel -> Sign-up. Заполняем все поля, нажимаем Continue. На следующей странице вводим код, который придет по почте. На следующей странице генерируем приватный ключ и устанавливаем его. После установки нам будет предложено на всякий случай сохранить резервную копию только что установленного сертификата и предложат ссылку на FAQ, где будет рассказано как это делать.

2. Валидация домена.
На этом нужно пройти валидацию домена, подтвердив, что мы являемся владельцами домена для которого будет генерироваться ключ. Идем в Validations Wizard, выбираем Domain Name Validation, на следующей странице вводим домен, нажимаем Continue. Нам предложат на выбор список адресов на которые может быть выслано письмо для валидации. Выбираем нужный, нажимаем Continue. На следующей странице вводим код, который пришел в письме. Нам сообщают что домен успешно валидирован.

3. Генерация сертификата.
Идем в Certificates Wizard, выбираем “Web Server TLS/SSL Certificate”, нажимаем Continue, вводим пароль для ключа. Полученные ключ копируем к себе на сервер в файл ssl.key и нажимаем Continue. На следующей странице выбираем домен для которого будет выдан сертификат. На следующей странице вводим 1 поддомен (например, www), которому будет на котором можно будет использовать этот же сертификат, нажимаем Continue, нам покажут страницу с итоговой информацией, проверяем и, если все правильно, нажимаем Continue. Всё. Запрос на выпуск сертификата подан. Ожидаем пока на e-mail придет извещение и выпуске сертифката (обещают уложиться в 3 часа, но обычно минут 15-20).

4. Установка на сервер.
Идем в “Tool box”. В разделе “Retrieve Certificate” получаем сертификат для нашего домена. Сохраняем его на сервер в файл ssl.crt. Далее в разделе “StartCom CA Certificates” стягиваем “StartCom Root CA (PEM encoded”), сохраяем на сервер как ca.pem; стягиваем “Class 1 Intermediate Server CA”, сохраняем на сервер как sub.class1.server.ca.pem. Итак, мы имее на сервере 4 файла: ssl.key, ssl.crt, ca.pem, sub.class1.server.ca.pem. ssl.key у нас закрыт паролем, это значит, что apache будет каждый раз при старте спрашивать пароль. Чтобы этого избежать снимаем парольную защиту с ключа:

openssl rsa -in ssl.key -out ssl.key

вводим пароль, который мы использовали в пункте 3. Защита снята. Далее все 4 файла копируем в директорию с конфигами apache и настаиваем virtualhost:

SSLCertificateFile    /path/to/configs/ssl.crt
SSLCertificateKeyFile /path/to/configs/ssl.key
SSLCertificateChainFile /path/to/configs/sub.class1.server.ca.pem
SSLCACertificateFile /path/to/configs/ca.pem

Перезапускаем apache.

Процедура получения сертификата на freessl.su

1. Создание ключа и запроса.
Создаем у себя на сервере ключ:

openssl genrsa -out domainname.key 1024

Формируем запрос:

openssl req -new -key domainname.key -out domainname.csr

Внимание! При создании CSR запроса в поле “common name” нужно ввести точное название домена для которого будет выдан сертификат.

2. Получение сертификата Идем на freessl.su, заполняем форму. В поле CSR копируем всё содержимое из полученного выше файла domainname.csr. Нажимаем далее. Выбираем почтовый ящик, на который будет выслано письмо для валидации домена, нажимаем далее. Проверяем все ли данные верны, нажимаем далее. По электронной почте придет письмо со ссылкой-подтверждением. Переходим по ссылке. Через несколько минут придет письмо с сертификатом и инструкциями по установке.

Как не превратить свой почтовый сервер в рассадник спама

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

Когда раньше зомби машины рассылали письма напрямую, то с ними было относительно легко бороться. Часть из них не имела обратной записи и отфильтровывалась на проверках ip, часть на грейлистинге, часть на других фильтрах. Сейчас вредоносное ПО умнеет и в некоторых случаях зомби машины рассылают сообщения через почтовые сервера, которые указаны в настройках почтовых клиентов (Outlook, The Bat! и т.д.). Поскольку почтовый сервер имеет очередь сообщений, корректные DNS записи и т.д. – это позволяет спам сообщению проходить грейлистинг и многие другие фильтры, что доставляет лишних хлопот получателям таким сообщений. Но несоизмеримо больше хлопот такой спам доставляет тем администраторам, через чьи сервера он рассылается.

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

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

Поясню на примере postfix’а. Я не буду объяснять как настроить postfix с поддержкой виртуальных пользователей и авторизации, вместо этого я буду полагать, что Вы уже имеете postfix настроенный таким образом. Так вот, если перед рестрикшном “permit_sasl_authenticated” добавить рестрикшн “reject_authenticated_sender_login_mismatch”, чтобы они выглядели примерно так:

...
reject_authenticated_sender_login_mismatch,
permit_sasl_authenticated,
...

то будет следующая картина: если пользователь авторизуется как user1@domain.com и попытается передать письмо в котором в качестве обратного адреса указан user2@domain.com, то в ответ получит ошибку:

5.7.1 <user2@domain.com> Sender address rejected: not owned by user user1@domain.com

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

Rambler's Top100