Эта статья — часть Большого Мануала по настройке lamp-сервера на debian.
Предыдущая часть цикла — Cоздаём пользователей, группы и структуру каталогов на будущее.
Следующая часть цикла — Немного безопасности и паранойи на вашем сервере дешевым способом. Snoopy.
На сервере важно поддерживать более или менее точное время. Чтобы было удобно читать логи, что бы ваш сервер не присылал другим письма из прошлого или из будущего, чтобы… да пофиг — просто важно и всё.
Из-за разных глюков, ошибок в железе, выключений-включений, время на сервере может отставать-спешить относительно атомного времени. Обычно — не более чем на секунду за сутки, на практике — на секунду за месяц, а то и меньше. Но хреново работающее железо может болтать время намного сильнее (вообще сильные колебания времени — повод задуматься о здоровье железки).
Существует два популярных способа синхронизации времени в linux — ntpdate по крону, или постоянно запущенный ntpd. Вы вольны выбрать любой из них, я напишу про оба. Но от себя я всё же советую использовать именно ntpdate по крону, особенно если вам не сильно критично постоянно держать на сервере время с погрешностью менее 0.1с.
C ntpd была связана проблема, когда уязвимость в нём позволяла использовать серверы ntpd для проведения udp amplification-атаки (когда маленький пакет, пущенный в сторону вашего сервера позволял сгенерировать большой udp-пакет в сторону чужого атакуемого сервера) — http://habrahabr.ru/post/209438/
Конечно, ту уязвимость пофиксили (да и написали, как от неё спастись без обновлений ntpd), но где гарантии, что там не осталось подобных проблем? Да и, опять же, ntpd всё ещё работает по udp и атаки похожего типа возможны, хоть и без большого усиления трафика (зато это позволит скрыть атакующего, подставив ваш сервер под абузу). Кстати, я сталкивался с тем, что ntpd, встроенный в ipmi-модуль сервера был подвержен этой атаке и весело ддосил соседей по стране =)
Поэтому, если вы не готовы постоянно читать рассылки безопасности, следить за обновлениями и так далее — всё же не стоит ставить ntpd.
Итак, первый способ: запускаем ntpdate раз в сутки по крону.
Сносим ntpd, если он есть:
Ставим ntpdate:
И создаём файл /etc/cron.d/ntpdate со следующим содержимым:
Теперь каждый день в 6 утра (время и периодичность сами подставьте) часики будут подводиться до актуального состояния.
Второй способ: nptd.
Нам нужно наоборот его поставить:
И написать в конфиг /etc/ntpd.conf более или менее правильную конфигурацию:
disable stats
server 0.ubuntu.pool.ntp.org
server 1.ubuntu.pool.ntp.org
server 2.ubuntu.pool.ntp.org
server 3.ubuntu.pool.ntp.org
После чего перезапускаем его:
Всё, теперь наши часики подводятся в режиме реального времени синхронизируются с пулом ntp-серверов.
Вариант с использованием ntpd является более правильным. Потому, что ntpdate корректирует время резкими скачками, когда ntpd это делает плавно. А это может быть критичным для определенных ролей сервера.
> Потому, что ntpdate корректирует время резкими скачками
На самом деле нет. Скачки там по 0.1с в сутки в самом-самом плохом случае, приложениям это не вредит. Если больше — то это уже проблемы с железом.
Понятное дело, что ЕСТЬ сервера, где ntpd быть обязан, но на дефолтной лампе торчащей голой жопой в интернет он не очень нужен, а в условиях отсутствия штатного админа на постоянной основе — вреден (я в статье писал почему).
http://www.opennet.ru/opennews/art.shtml?num=43182 вот ещё статья на тему «почему ntpd без постоянного админа — зло»
Когда-то раз и навсегда уполз с периодического подвода времени через ntpdate на ntpd — когда очередной перевод времени снёс крышу у dovecot. Почта не работала, пока не пришёл и не разобрался.
Чсх, у dovecot это даже где-то в официальной документации написано — «не переводите время». В подробности не вникал тогда, да и сейчас не хочу.
Я просто люблю ntpd. И Shorewall — долбитесь в закрытые порты кто хочет =))) И fail2ban, который обеспечивает контроль подозрительной активности на открытых портах (контроль путём бана, да =) «скорость на дороге контролируется снайперами») И ipset, который легко и непринуждённо укладывает в бан десяток тысяч ботов. И -j TARPIT, который замечательно подвешивает всем этим ботам все устанавливаемые соединения… гм, куда меня унесло… 8)
> когда очередной перевод времени снёс
Ещё раз статью перечитайте. Да, dovecot как раз тот случай, когда ntpd подойдет лучше.
> гм, куда меня унесло… 8)
А унесло вас в сторону того, что вы умеете поддерживать свои сервера.
«если вы не готовы постоянно читать рассылки безопасности, следить за обновлениями и так далее — всё же не стоит ставить ntpd.»
На богом забытом сервере, в который постоянно не смотрят внимательно — ntpd зло. Тем более, если нет штатного админа. У UDP коннектов нет, подвешивать нечего — так что ни тарпитом, ни банами вы ничего не сделаете. Банами ничего не сделаете по одной простой причине — чуваки, делающие amplification УЖЕ могут подделывать src-addr udp-пакетов глобально (ну то бишь у них есть взломанная тачка в AS-ке, где так можно), так что до вашего iptables им дела нет — адреса менять могут со скоростью пулемета. Оно, наверное, спасет от исходящего amplification, но всё равно что-нибудь придумать можно будет.