Как я могу защитить себя от вторжений и вредоносных программ перед их подключением к Интернету (особенно на общедоступных IP-адресах)?


60

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

Что можно сделать, чтобы смягчить это?

Достаточно хорошо известно, что нужно изменить пароль для пользователя «pi» (Debian) и «root» (Arch.). Но как насчет других системных учетных записей (например, «tli», «pnd»?). универсальные пароли, которые предположительно одинаковы для всех устройств?

И есть ли известные уязвимости в других пакетах, которые установлены в образах SD, доступных для Pi (например, из-за аппаратных ограничений или урезанных версий этих пакетов?)

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

Ответы:


23

Вещи, которые я заметил до сих пор об стоковом образе Debian Squeeze:

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

  • конфигурация демона ssh по умолчанию разрешает удаленный вход в систему root. Это должно быть отключено.

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

  • Вы захотите изменить ключи хоста ssh, а не использовать ключи на образе (AIUI, последний образ фактически восстанавливает их при первой загрузке)


1
Я не вижу проблемы с вашим первым заявлением. Для чего нужны эти дополнительные пользователи? Разве они не должны быть отключены для входа? Вы можете проверить, пытаясь suк ним.
Jivings

2
Я собираюсь дать это -1. Главным образом потому, что вы предлагаете вручную редактировать теневой файл. Это ужасно плохая идея.
Jivings

@Jivings Нет, он не делает. Он также может подразумевать использование vipw; это плохая идея? Нет, это не так. +1 для намека на использование vipw.
user2497

41

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

Пароли

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

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

неясность

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

Все, что нужно сделать здесь, это изменить порты по умолчанию для часто используемых протоколов. Например, порт SSH по умолчанию - 22, а FTP - 21. В моей системе SSH использует 222 и FTP 221, что должно скрывать эти протоколы от любой автоматической атаки.

Безопасность соединения

Во-первых, наиболее важной проблемой безопасности является то, что корневая учетная запись не должна иметь возможность войти в систему через SSH. Вы можете отключить root-логин в /etc/ssh/sshd_configфайле, комментируя или удаляя эту строку:

PermitRootLogin yes

По умолчанию он должен быть установлен в no, но лучше убедиться в этом.


Если вы часто используете 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
Я не согласен с вашим замечанием Obscurity: потребуется несколько секунд, чтобы сопоставить открытые порты на вашем устройстве и найти ваш ssh-сервер. Отключите логин паролей и придерживайтесь обычных портов. Я сомневаюсь, что вам вообще нужен ftp, вместо этого используйте scp.
Алекс Чемберлен

2
@AlexChamberlain Это временное ограничение скорости для злоумышленников, но ни в коем случае не полное решение в одиночку.
Jivings

4
Изменение портов по умолчанию приводит к снижению уровня стука в дверь, что часто приводит к атакам по словарю. Конечно, это очень незначительная мера безопасности, но у нее есть и другие преимущества, т. Е. Она может ограничить распространение журнала. Это скорее превентивное действие, чем безопасность, но все же заслуживает рассмотрения.
Библброкс

2
@AlexChamberlain, Во время разгрома Debian с помощью ключа ssh мы зарегистрировали множество попыток для порта 22 и нигде больше. В этом случае работа на другом порту выручила бы вам много времени, пока хакеры пытались определить, какие из эксплуатируемых хостов были ценными. SBO почти не помогает, если злоумышленник нацелен на вас конкретно.
Джон Ла Рой

1
Я согласен. Моя точка зрения в том , что это не просто thereotical - там было время в последнее время , где SBO определенно сделал помощь, и сделал существенную разницу.
Джон Ла Рой

6

Чтобы предотвратить атаки грубой силы, вы можете установить и настроить fail2ban. Он проанализирует файлы журнала (например, /var/log/auth.log) и попытается определить, не удалось ли несколько попыток входа в систему. Затем он автоматически заблокирует исходные IP-адреса с помощью iptables.

В интернете куча хулиганов.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.