SSH прості хитрощі

Інформація здебільшого для новачків, але й у мене руки дійшли до цього тільки зараз.

Є багато засобів захисту SSH від тупих атак "китайських хакерів", найочевидніший – прикрити фаєрволом від "світу", залишивши доступ тільки з відомих довірених мереж/вузлів. Але такий варіант не завжди підходить, наприклад, є машини які використовуються у якості "точок входу" (на випадок коли немає можливості підключитись по VPN). Стійкі паролі досить надійно захищають від грубих атак, але армія роботів все одно спробує переконати сервер що пароль "Мао*Дзедун", їхні спроби засмічують журнали, що в будь-якому разі не є добре.

Найпростіший спосіб направити цю армію по хибному шляху, перенести службу SSH на інший нестандартний порт, наприклад, tcp/227 або будь-який інший не задіяний для стандартних служб.

!!! Будьте обережні, особливо якщо сервер віддалений, при зміні налаштувань не "зарубайте" доступ самому собі. Для цього виконуйте зміни у наступному порядку:

• до конфігурації фаєрволу додайте правило, яке дозволить з'єднання по новому нестандартному порту;
• змініть порт у налаштуваннях SSHd;
• перевірте з'єднання по новому порту;
• і тільки тепер заберіть правило, яке дозволяло з'єднання по стандартному порту.

Але це тільки пів справи, ви надурили армію роботів, але й собі створили незручності, для підключення до сервера вам доведеться вказувати додаткові параметри:

~$ ssh -p 227 server.example.com

Справжні спеціалісти не люблять дурної роботи, тому ми навчимо ssh-клієнт пам'ятати у якого сервер який порт використовується. Для цього допишіть у файл ~/.ssh/config ось такі рядки:

Host server.example.com
Port 227

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

Це не єдина зручність яку дозволяє організувати конфігураційний файл ssh, ви можете створювати псевдоніми для вузлів, автоматично підставляти нестандартне ім'я користувача, тощо.

Host dev
HostName developer.example.com
User vasyadev
Port 227
IdentityFile developer_key

Почитайте man ssh_config. Що краще ви знаєте свій інструмент, то більш ефективною стає ваша робота.

408 - Підступний Chrome

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

Віднедавна я почав помічати на кількох web-серверах (apache2) помилку 408 "Request timeout". Причому кількість помилок поступово зростала. "Фізичний зміст" помилки - браузер встановив з'єднання з сервером, але не надіслав запит протягом відведеного на це часу, тоді сервер закриває з'єднання з помилкою 408.

Перші пояснення, які мені вдалося знайти на форумах, зводилися до (D)DoS атак або злих хробаків. Обидві гіпотези майже зразу спростувалися: сервіси глибоко внутрішні - DDoS-у взятись нема звідки; майже половина машин, які засвітилися з такою помилкою - це робочі станції локальної мережі з ОС Ununtu, які обслуговуються кваліфікованими адміністраторами.

Але другий підхід до цієї проблеми (лишити її так я не міг, Logwatch щодня про неї нагадував) навів мене на справжнього винуватця, ним виявився браузер Chrome від "корпорації добра". Для зменшення часу відкривання сторінок, ця зараза має "фічу" speculative pre-connect, тобто про всяк випадок відкриває з'єднання заздалегідь, сподіваючись що від сервера ще щось знадобиться і тоді треба буде тільки послати запит. На цю "фічу" завели "баг репорт" :)

На цьому місці я зміг посміхнутись і вирішити залишити все як є, навантаження на сервери не велике, Chrome-ів мало. Але для серверів з більшим навантаженням може знадобитись зменшити значення Timeout у конфігурації Apache, щоб зменшити імовірність вичерпання максимальної кількості одночасно підключених клієнтів (MaxClients).

Дуже сподіваюся, що скоро вони таки «improve the accuracy of our preconnect target»

Використовуємо "резервне" місце на ext3/ext4

Сьогодні напишу про дуже просту штуку, але я про неї не зразу згадав, тому можливо і вам буде цікаво.

Є маленький сервер, який використовується для резервного копіювання з допомогою Bacula. Для зберігання резервних копій у нього окремий розділ (515.4 GB) з ext4. Одного дня перестало вистачати місця для зберігання резервних копій протягом 30-днів, забракло якихось 20GB. Я вже заходився підключати новий диск, більший. Аж раптом згадав...

...що при створенні файлових систем ext3/ext4, по замовчуванню 5% резервується на випадок переповнення диску. Ці блоки доступні лише для користувача root, щоб він міг увійти на систему з переповненим диском. Це дуже завбачливо, але є кілька "але":

• 5% це резонна величина для маленьких дисків/розділів, але для 1 TB - це 51 GB;
• для успішного входу супер-користувача місце потрібно на / і /tmp, на інших розділах (/home, наприклад) цього не треба;
• місце резервується для входу супер-користувача, але у більшості сучасних систем для входу використовується звичайний користувач, який потім підвищує свої привілеї, припускаю що резервування не допоможе зайти на таку систему, коли у неї переповниться диск

Тому, діючи дуже обережно, ми зменшимо кількість зарезервованих блоків або відключимо резервування, змінивши налаштування ФС.

Подивимось скільки ж ми "втрачаємо":

# tune2fs -l /dev/sdc5 | grep -i block
Block count:              125828608
Reserved block count:     6291430
Free blocks:              488281
... skip ...
Block size:               4096
... skip ...

Як бачимо, 6291430*4096=25.769.697.280 байт дискового простору "гуляє". Для зміни кількості зарезервованих блоків використовується та ж команда, тільки з опцією -m:

# tune2fs -m <скільки відсотків резервувати> /dev/sdb5

Щоб повністю відключити резервування вкажіть кількість відсотків - 0:

# tune2fs -m 0 /dev/sdс5
tune2fs 1.41.11 (14-Mar-2010)
Setting reserved blocks percentage to 0% (0 blocks)
# tune2fs -l /dev/sdc5 | grep -i block
Block count:              125828608
Reserved block count:     0
Free blocks:              6779711
... skip ...
Block size:               4096
... skip ...

"Звільнилася" купа місця :)

Увага! Зовсім не потрібно бігти відключати резервування на всіх-всіх-всіх розділах, при невисокій ціні на жорсткі диски, 5% не така висока ціна за додаткову надійність. Тому міняйте налаштування резервування блоків тільки тоді, коли точно знаєте що робите.

Я би просто полінувався міняти, але морока зі зміною розділів була більшою ;) Про LVM там теж вчасно не згадали :)

PostgreSQL schema diff

Я з 2008-го року мріяв про інструмент який шукає різниці між схемами БД, а виявляється є такий. Зустрічайте - Another PostgreSQL Diff Tool (apgdiff)!

apgdiff є в репозиторіях Ubuntu. Дуже дивно як я його раніше не знайшов.

Прості правила зберігання даних (Linux)

У часи, коли інформація є одним з найцінніших ресурсів, оберігати її слід дуже пильно. Тому напишу про обов'язкові заходи моніторингу сховищ інформації.

Маємо сервер з ОС Linux та програмним RAID1 або RAID5, хоча поради будуть слушні і для інших типів масивів.

Моніторинг RAID-масиву

Відкрийте файл /etc/mdadm/mdadm.conf, та розкоментуйте і виправте, вказавши потрібну E-mail адресу, наступний рядок:

MAILADDR sysadmin@ваш.домен.ua

Моніторинг стану жорстких дисків (всіх, не тільки з RAID масиву)

Про те, що диск скоро треба буде замінити, хотілося б знати заздалегідь, для цього ми налаштуємо smartd з пакунку smartmontools.

Відкрийте файл /etc/default/smartmontools та розкоментуйте рядок:

start_smartd=yes

, це дозволить smartd запускатись при старті системи.

Стандартна конфігурація smartd передбачає автоматичний пошук дисків, які підтримують S.M.A.R.T., тому вам достатньо відредагувати файл /etc/smartd.conf, встановивши правильну E-mail адресу в опції автопошуку:

DEVICESCAN -m sysadmin@ваш.домен.ua -M exec /usr/share/smartmontools/smartd-runner

Після перезапуску в журналі /var/log/syslog ви побачите приблизно таке:

Jul 19 14:21:21 psi smartd[18491]: smartd version 5.38 [x86_64-unknown-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Jul 19 14:21:21 psi smartd[18491]: Home page is http://smartmontools.sourceforge.net/#012
Jul 19 14:21:21 psi smartd[18491]: Opened configuration file /etc/smartd.conf
Jul 19 14:21:21 psi smartd[18491]: Drive: DEVICESCAN, implied '-a' Directive on line 22 of file /etc/smartd.conf
Jul 19 14:21:21 psi smartd[18491]: Configuration file /etc/smartd.conf was parsed, found DEVICESCAN, scanning devices
Jul 19 14:21:21 psi smartd[18491]: Problem creating device name scan list
Jul 19 14:21:21 psi smartd[18491]: Device: /dev/sda, opened
Jul 19 14:21:21 psi smartd[18491]: Device /dev/sda: using '-d sat' for ATA disk behind SAT layer.
Jul 19 14:21:21 psi smartd[18491]: Device: /dev/sda, opened
Jul 19 14:21:21 psi smartd[18491]: Device: /dev/sda, found in smartd database.
Jul 19 14:21:22 psi smartd[18491]: Device: /dev/sda, is SMART capable. Adding to "monitor" list.
Jul 19 14:21:22 psi smartd[18491]: Device: /dev/sdb, opened
Jul 19 14:21:22 psi smartd[18491]: Device /dev/sdb: using '-d sat' for ATA disk behind SAT layer.
Jul 19 14:21:22 psi smartd[18491]: Device: /dev/sdb, opened
Jul 19 14:21:22 psi smartd[18491]: Device: /dev/sdb, found in smartd database.
Jul 19 14:21:22 psi smartd[18491]: Device: /dev/sdb, is SMART capable. Adding to "monitor" list.
Jul 19 14:21:22 psi smartd[18491]: Device: /dev/sdc, opened
Jul 19 14:21:22 psi smartd[18491]: Device /dev/sdc: using '-d sat' for ATA disk behind SAT layer.
Jul 19 14:21:22 psi smartd[18491]: Device: /dev/sdc, opened
Jul 19 14:21:22 psi smartd[18491]: Device: /dev/sdc, not found in smartd database.
Jul 19 14:21:22 psi smartd[18491]: Device: /dev/sdc, is SMART capable. Adding to "monitor" list.
Jul 19 14:21:22 psi smartd[18491]: Monitoring 0 ATA and 3 SCSI devices

На одному з серверів я мав проблему з автовизначенням, тому довелося закоментувати DEVICESCAN та прописати диски вручну, ось так:

/dev/sda -a -d sat -m sysadmin@ваш.домен.ua
/dev/sdb -a -d sat -m sysadmin@ваш.домен.ua

, де -a — набір стандартних перевірок, -d — для дисків схованих за 'SAT layer' (у сучасних дистрибутивах всі диски виглядають та керуються, як диски з послідовним інтерфейсом), -m — адреса, куди надсилатимуться звіти та попередження.

Запускаємо smartd:

/etc/init.d/smartmontools start

Ось і все, уважно читайте пошту за ранковою кавою :) і ви будете завжди в курсі того, що відбувається з вашими сховищами даних. Проте не забувайте і про необхідність резервного копіювання, бо моніторинг це обов'язкова, але недостатня умова для збереження даних.

Іменування таблиць у базах даних

Стандартні рекомендації щодо іменування об'єктів БД застерігають від використання іменників у множині (наприклад, contracts замість contract). Але у вітчизняних (це я так завуальовано написав про "легасі" частину нашої БС) продуктах іноді зустрічаються назви у множині та ще й транслітеровані з української (наприклад, ugody замість contract). З такими назвами був цікавий казус: один з новачків з круглими від здивування очима спитав мене - що це за поле "угадано", хоча мався на увазі номер угоди "ugodano".

До чого я все це веду, ніколи не називайте об'єкти БД словами у множині і із застосуванням транслітерації, подивіться у словник і виберіть англійський відповідник слова, а якщо об'єкт і має якусь локальну специфіку, опишіть це в документації.

Mac OS X і зовнішній жорсткий диск

Задача: ефективно/зручно використовувати для резервного копіювання і зберігання всяких даних зовнішній жорсткий диск ємністю 1ТБайт у операційних системах Linux, Mac OS X і опціонально Windows.

Теоретична частина (вибір ФС для диску)

З чого будемо вибирати: рідна для Linux — Ext3, рідна для Mac OS X — HFS+, рідна для Windows — NTFS, на FAT не дивимось бо її обмеження у XXI-у столітті виглядають смішними.

1. Ext3 - дуже симпатичний кандидат (OSS4ever!), але вимагає установки милиць у інші ОС, як виявилося пізніше дуже кривих.
2. HFS+ - Apple way, Джобз тріумфує (дай йому Бог здоров'я), для інших ОС знадобляться додаткові танці, але я сподіваюсь Linux, як завжди, потішить, а на Windows нам начхати (зовсім необов'язково)
3. NTFS - "обітєль зла", на Mac треба додатковий софт, на Linux хоч і коробочний, але теж не дуже рідний. Єдиний незначний плюс - можливість запхати в чужий віндовий комп'ютер, але й це скоріше мінус, бо ще всяких "зловрєдів" налізе.

Добряче почухавши потилицю, вибираємо HFS+, подивимось як заведеться під Linux.

Практична частина (зберігаючи хронологію, але без матюків)

Диск був відформатований у Ext3, оскільки раніше я використовував виключно Linux (Ubuntu). На ньому накопичилась купка даних, які треба тимчасово перенести на Mac (більше ніде немає достатньо місця), попутно пробуємо варіант №1 з теоретичної частини.

Спроба № раз — macfuse і ext2fuse

Взагалі, способів установки ПЗ на Mac забагато; і .dmg, і .pkg, для OSS - macports, а віднедавна ще й AppStore. Я, як новачок, ще й досі гублюся... але для OSS вибрав один єдиний "православний" і "кошерний" спосіб — macports.

Вони ж (ports) мене і підвели, як ти їх не умовляй хоч через variants, хоч через macports.conf, все одно збирали модуль ядра тільки для архітектури i386.

Помордувавшись трохи, подумав, біс із ним, перезавантажив систему у 32-бітному режимі. І тут невдача, щось йому там "connection timed out", вирішив далі не розбиратись. Зніс ext2fuse і macfuse.

Спроба № два — Ext2fsx

Проект дохлий, не оновлюється з 2006-го, але знайшлася пара статей за 2010 «ставте все працює» — дзуськи! На Snow Leopard (10.6.7) воно не працює ні разу. Нічого дивного, йдемо далі.

Спроба № три — Paragon (Бог трійцю любить)

За рекомендацією приятеля ставлю комерційний Paragon ExtFS for Mac OS X, "тик-тик-тик", встановлено — працює. Ура!

Не душила б жаба заплатити $40 (але краще "Deore по кругу" для ровера, а якщо й до комп'ютера то Portal 2 ;)), використовував би на диску Ext3 і горя не знав, але ставлю 10-денну демо-версію, щоб тільки раз переписати файли з Ext3 на Mac.

Фініш

На цьому мої поневіряння закінчились, файли переписано, диск переформатовано у HFS+ (без журналювання). Linux побачив HFS+, хоч і без журналювання, зате «з коробки» на читання/запис, чим вкотре підтвердив свою позитивну репутацію «приспособлєнца».