Як я можу захистити від вторгнення та зловмисного програмного забезпечення перед тим, як підключити його до Інтернету (особливо за публічною IP-адресою)?


60

Оскільки велика кількість Raspberry Pis в природі і той факт, що великі групи з них налаштовані однаково (коли щойно прошита SD-карта встановлена ​​з одним з небагатьох доступних зображень), вони, ймовірно, будуть спокусливою ціллю для зловмисне програмне забезпечення, включаючи ботнети.

Що можна зробити, щоб пом'якшити це?

Досить добре відомо, що слід змінити пароль для "pi" користувача (Debian) і "root" (Arch.), Але як щодо інших облікових записів системи (наприклад, "tli", "pnd"?) універсальні паролі, імовірно, однакові для всіх одиниць?

Чи є відомі вразливості в інших пакетах, встановлених у SD-образах, доступних для Pi (наприклад, через обмеження обладнання або скорочені версії цих пакетів?)

Зокрема, мене хвилює ssh, mysql та будь-які інші сервіси, які можуть працювати на нещодавно встановленому зображенні.

Відповіді:


23

Речі, які я помічав поки що про запас зображення Debian Squeeze:

  • / etc / shadow містить купу хешів паролів для облікових записів, які не є pi-обліковим записом (buildbot тощо). Зміна пароля в обліковому записі pi, звичайно, якщо ви ще цього не зробили (або зробите для себе новий обліковий запис користувача та видаліть pi-акаунт), а також відредагуйте інші записи та замініть хеші на * s. Примітка / etc / passwd містить повторювані записи для pi-акаунта, що плутає пекло з adduser / deluser, просто видаліть його.

  • конфігурація демона ssh за замовчуванням дозволяє віддалений кореневий вхід. Це слід вимкнути.

  • варто використовувати netstat для перевірки набору речей, що слухають, на наявність з'єднань; дивовижна кількість матеріалів працює порівняно з типовим мінімальним Debian netinst. Це взагалі хороша ідея , щоб зменшити вплив тільки речей , які ви повинні , тому спочатку відключити або міжмережевий екран вимкнений все , а потім піддавати тільки ті послуги , які ви свідомо хочете видно на інтернет - громадськості ( як правило , тільки SSH або SSH + HTTP).

  • ви хочете змінити ключі хоста ssh, а не використовувати клавіші на зображенні (AIUI останнє зображення фактично відновлює їх під час першого завантаження)


1
Я не бачу проблеми з вашим першим твердженням. Для чого ці додаткові користувачі? Чи не повинні вони бути відключені для входу? Ви можете перевірити, спробувавши suїх.
Відхилення

2
Я дам це -1. Головним чином, ви пропонуєте вручну редагувати тіньовий файл. Що надзвичайно погана ідея.
Відхилення

@ Життя Ні, він цього не робить. Він може так само добре мати на увазі використання vipw; це погана ідея? Ні це не так. +1 для використання vipw.
user2497

41

Існує багато способів вирішити вразливості, але перше, що вам слід знати, це те, що Linux не такий сприйнятливий до вторгнення, як інші операційні системи. В основному це пов’язано з відсутністю зловмисного програмного забезпечення, яке націлює * NIX. Тим не менш, ви хочете бути в курсі способів доступу до вашої системи.

Паролі

По-перше, ви повинні змінити паролі за замовчуванням для всіх користувачів, які можуть увійти в систему. Для Debian це просто користувач Pi за замовчуванням . Для Arch Linux це суперкористувацький корінь . Паролі змінюються при вході в систему як користувач, ввівши passwdкомандний рядок.

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

Непрозорість

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

Все, що тут потрібно зробити, - це зміни портів за замовчуванням для часто використовуваних протоколів. Наприклад, порту SSH за замовчуванням - 22, а FTP - 21. У моїй системі SSH використовує 222 та FTP 221, що повинно затьмарити ці протоколи від будь-якої автоматизованої атаки.

Безпека підключення

По-перше, найважливішим питанням безпеки є те, що кореневий обліковий запис не повинен мати можливість входити через SSH. Ви можете відключити кореневий вхід у /etc/ssh/sshd_configфайл, коментуючи або видаливши цей рядок:

PermitRootLogin yes

За замовчуванням його слід встановити на "не", але краще переконатися.


Якщо ви багато використовуєте SSH і переживаєте за людину в атаках посередині, словникові атаки на ваш пароль, тоді ви можете використовувати SSH Keys.

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

Щоб налаштувати автентифікацію ключів SSH, потрібно спочатку створити пару ключів. Це найпростіше зробити на вашій клієнтській машині (машині, з якою ви хочете отримати доступ до Pi).

# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/pi/.ssh/id_rsa):

Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/pi/.ssh/id_rsa.
Your public key has been saved in /home/pi/.ssh/id_rsa.pub.

Як бачите, це створило два файли, приватний id_rsaі відкритий ключ id_rsa.pub.

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

Тож, що ми хотіли б зробити, це скопіювати відкритий ключ на Raspberry Pi. Це ми можемо зробити дуже легко:

ssh-copy-id pi@address

Де piім'я користувача Raspberry Pi, і addressIP-адреса Pi.

Я ще раз зазначу, ми розповсюджуємо відкритий ключ. Приватний ключ - ваш. Щільно тримайтеся за нього, щоб випустити, що клавіша порушує безпеку системи.

Вікі Arch має чудовий опис того , як це працює:

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

Для отримання додаткової інформації щодо безпеки аутентифікації відкритих ключів у Вікіпедії є ретельне пояснення .

Завдяки безпеці SSH ви можете зробити надзвичайно багато зашифрованих, безпечних передач даних. Практично кожне інше підключення до порту при необхідності може бути прокладено через SSH. Можна навіть переслати X сеанс через SSH, щоб він відобразився на іншій машині.

Як цікавий приклад, вчора я запускав Eclipse на своєму робочому столі, переглядав його на своєму Raspberry Pi та контролював мишу та клавіатуру з мого нетбука. Така сила SSH.

Дозволи

Дозволи на файли - це суть системи безпеки Linux. Вони впливають на те, хто може бачити ваші файли та папки, і можуть бути дуже важливими при захисті ваших даних. Наприклад, увійдіть до програми Raspberry Pi як звичайний користувач та запустіть:

cat /etc/shadow

shadowФайл містить зашифровані паролі для користувачів системи, тому ми не хотіли б тільки про тих , щоб поглянути на нього! Отже, ви повинні побачити цю відповідь:

cat: /etc/shadow: Permission denied

Ми можемо зрозуміти, чому це, переглянувши дозволи файлу:

ls -l /etc/shadow
-rw------- 1 root root 821 Jun 11 22:13 /etc/shadow

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

-rw-------

Це стан дозволів. Перший біт повідомляє нам про тип файлу ( -означає звичайний файл). Наступні три біти представляють дії, доступні власнику файлу. Три інші біти представляють групу , а останні три - для інших або всіх інших. Таким чином, каталог із повними дозволами виглядатиме так:

drwxrwxrwx  10 root root   280 Jun 20 11:40 tmp/

Ось читайте, записуйте та виконайте дозволи для власника, групи та всіх інших.

Наступна важлива частина - це два імені. У нашому випадку root root. Перший користувач - власник файлу. Друга - це група користувачів . Наприклад, було б звичайно бачити:

drwxr-xr-x  10 pi users   280 Jun 20 11:40 home/pi

Це дозволить користувачеві отримати доступ до читання / запису в piйого домашній каталог та доступ для читання для всіх інших користувачів.

На дозволи найчастіше посилаються та керуються за допомогою восьми значень. Наприклад, якщо ми хочемо встановити rw лише для власника, ми введемо:

chmod 600 /path/to/file

Це основний огляд, для отримання більш детальної інформації про дозволи файлів Linux, ось хороша стаття.


Це розуміння важливе при забезпеченні захисту файлів і папок. Наприклад, скажімо, ми щойно встановили ключі SSH. Ми точно не хочемо, щоб інші користувачі бачили всередині нашого ~/.sshкаталогу, інакше вони зможуть взяти наш приватний ключ. Таким чином, ми видаляємо їхні привілеї для читання:

chmod 700 ~/.ssh
ls -la ~/.ssh 
drwx------   2 james users  4096 Jun 18 03:05 .

Я сподіваюся, що це усуне деякі ваші проблеми щодо забезпечення Linux. З цього ви повинні бачити, що це досить захищена система, і якщо ви обережні, у вас не повинно виникнути проблем із безпекою.


10
Я не погоджуюся з вашим зауваженням з питань безпеки, для того, щоб зіставити відкриті порти на вашому пристрої та знайти ваш ssh-сервер, потрібно кілька секунд. Вимкніть вхід із паролем та дотримуйтесь звичайних портів. Я сумніваюся, що вам взагалі потрібен ftp, замість цього використовуйте scp.
Алекс Чемберлен

2
@AlexChamberlain Це тимчасова швидкість для нападників, але аж ніяк не повне рішення.
Відхилення

4
Зміна портів за замовчуванням має тенденцію до нижнього стуку дверей, що часто призводить до словникових атак. Звичайно, це надзвичайно незначний захід безпеки, але він має й інші переваги, тобто він може обмежувати кількість журналу. Це скоріше запобіжна дія, ніж безпека, але все ж заслуговує на розгляд.
Beeblebrox

2
@AlexChamberlain, Під час дебалації ключа ssh debian ми зафіксували багато спроб у порту 22 і ні в якому іншому місці. У такому випадку, біг на інший порт купив би вам багато часу, поки хакери намагалися розібратися, хто з експлуатованих хостів був цінним. SBO не допомагає майже настільки, якщо нападник конкретно націлений на вас.
Джон Ла Руй

1
Я згоден. Моя думка полягала в тому, що це не просто теоретичне - останнім часом був час, коли СБО, безумовно , допомагав, і суттєво змінився .
Джон Ла Руй

6

Щоб запобігти атакам грубої сили, можна встановити та налаштувати fail2ban. Він проаналізує файли журналів (наприклад /var/log/auth.log) і спробує виявити, чи не вдалося кілька спроб входу. Потім він автоматично заборонить IP-адреси джерела iptables.

В Інтернеті є купа хаутів.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.