Ssh server для простых смертных (безопасное использованию сервера OpenSSH)

Для начало вспомним наши конфигурационные файлы:
/etc/ssh/sshd_config — конфигурационный файл сервера OpenSSH
/etc/ssh/ssh_config — конфигурационный файл клиентской части OpenSSH
~/.ssh/ – конфигурационная директория пользователей ssh.
Расмотрим несколько советов по безопасному использованию сервера OpenSSH.
Открываем наш конфиг и смотрим:
$ nano /etc/ssh/sshd_config
1. SSH порт, используемый по умолчанию: : TCP 22 ssh server, меняем так как многие brute forcing заточен под 22 порт и по крайней мере введет в заблуждения «кул хацкеров»
# What ports, IPs and protocols we listen for
Port 2280

По умолчанию sshd принимает подключения на всех интерфейсах, если не требуется заходить на сервер «из вне», то можно ограничить его нужным нам IP адресам, (например 192.168.100.1).
Внимание: это указание ssh-демону, какой ip-адрес использовать для входящих соединений. Т.е. если твой сервер имеет два интерфейса:
– внешний (подключение в Интернет) — с реальным ip-адресом,
– внутренний (локальная сеть) — с приватным (например 192.168.100.1) и ты хочешь, чтоб по ssh к серверу можно было добраться только c хостов, находящихся в локальной сети — в конфиге указываешь ListenAdress — адрес на котором сервер принимает запросы на соединение. И этот параметр не имеет почти никакого отношения к ограничению доступа к серверу по протоколу ssh !
ListenAddress 192.168.100.1
Дополнительно через двоеточие можно указать и номер порта. В данном примере используется значение порта, заданное глобально параметром Port.
2. Используйте только протокол SSH 2
Protocol 2
3. Ограничение доступа ssh server суперпользователя
В большинстве дистрибутивов в целях безопасности доступ суперпользователю(root) по SSH закрыт (PermitRootLogin no), и при попытке зарегистрироваться под root получаем сообщение об ошибке. Для выполнения задач, требующих привилегий администратора, приходится заходить под обычным пользователем и использовать su или sudo. Красиво выйти из ситуации поможет директива Match. В качестве аргумента ей передается критерий отбора (User, Group, Host, Address), его значение и параметр, который нужно применить. Для примера разрешим подключение под root только с localhost и из локальной подсети 192.168.100.0/24:
PermitRootLogin no
Match Host 192.168.100.*,127.0.0.1
PermitRootLogin yes

или просто запрещаем региться под root’oм
PermitRootLogin no
4. Ограничение доступа пользователей ssh server через SSH
Будет полезно всем, кто заводит пользователей в системе например для mail или ftp и etc,во многих системах по умолчанию пользователям разрешено иметь доступ через SSH с использованием пароля или открытого ключа.AllowUsers (пользователи, которым разрешен доступ).
Для того, чтобы доступ в систему через SSH был разрешен только пользователям user1,user2 и тд:
AllowUsers user1 user2
так же возможно использовать и такую конструкцию с IP-адресом
AllowUsers *@192.168.2.*
Так же можно, наоборот, разрешить всем пользователям, но для определенных запретить:
DenyUsers user10 user20
5. Авторизация и подключения
LoginGraceTime 45
Параметр LoginGraceTime определяет, по истечению какого времени простаивающее подключение будет разорвано (в секундах), т.е : позволенный для регистрации промежуток времени, за который надо ввести пароль, значение по умолчанию 120 явно завышено, думаю что будет 45 сек будет достаточно.
MaxStartups 2:50:10
Количество параллельных не идентифицированных подключений к серверу контролируется при помощи MaxStartups. Запись параметра имеет форму «start:rate:full». В нашем случае она означает отключение с вероятностью 50% при наличии двух не идентифицированных связей, с линейным ростом вероятности до 100% при достижении 10.
Для тех у кого будет много подключений по SSH можно сконфигурировать время закрытия неработающей сессии:
ClientAliveInterval 300
ClientAliveCountMax 0

устанавливаем таймаут в секундах (300 секунд = 5 минутам). После того, как указанное время истечет, бездействующий пользователь будет отключен от системы
6. Отключение прослушивания IPv6 адресов ssh server
ИМХО IPv6 пока ни неактуальный (по крайней мере, для меня), поэтому предлагаю его отключить
По умолчанию sshd слушает как на IPv4 так и на IPv6 адресах. Для того что бы его отключить необходимо изменить параметр AddressFamily (если значение AddressFamily не указано в конфигурационном файле, то оно принимается равным any):
AddressFamily any # default (IPv4 и IPv6)
AddressFamily inet # IPv4 only
AddressFamily inet6 # IPv6 only

Ну и на последок так же можно добавьте предупреждающий баннер, расскоментируйте строчку, в sshd_config, либо указать иной путь к своему баннеру :
Banner /etc/issue

Также можно ограничить доступ к нужному сервису через hosts

Edit /etc/hosts.allow and add your subnet

sshd : 192.168.0.

Edit /etc/hosts.deny , and deny all

ALL : ALL

(c)linuxjournal

Pirate Bay рекламирует потоково-файлообменный видеосервис

Известный торрент-ресурс The Pirate Bay при помощи дополнительных ссылок на страничках торрентов с фильмами начал продвигать некий сайт Tube+. Он представляет собой сервис потокового видео, база данных которого также содержит ссылки на соответствующие фильмы и сериалы на торрентах, файловых хостингах и в сети ed2k (eMule).

Достаточно беглого взгляда, чтобы прийти к выводу о явно “пиратской” направленности нового ресурса. На главной странице Tube+ вывешены самые свежие фильмы и последние серии популярных сериалов, при этом деньги с пользователей не собираются. Во всяком случае, они не собираются явным способом, потому что реклама на Tube+ присутствует.

Также на сайте обнаружена страничка, посвящённая вопросу соответствия Tube+ законодательству, а именно пресловутому DMCA — Закону США об авторском праве в цифровую эпоху. Правообладателям предлагается самостоятельно выкладывать на сайт свои материалы, а также собственными же силами выискивать выложенные туда без их ведома фильмы и жаловаться администрации Tube+.

источник

Хакеры взломали сервера WordPress.com

Официальные сервера известного блогхостинга WordPress подверглись взлому, от которого могут пострадать миллионы пользователей. Сотрудники компании Automattic (владеющие wordpress.com) оставили краткую заметку об инциденте:

“Сегодня мы сообщаем суровые новости: несколько серверов Automattic были взломаны на низком уровне (получен root), возможно какие-то данные с этих серверов могли быть раскрыты. Мы усердно анализируем логи и записи о взломе, чтобы определить, какая именно информация утекла и что нужно сделать, чтобы этого не повторилось. Наши исходные коды были вскрыты и скопированы. Несмотря на то, что большая часть проектов открыта, есть слабые места в нашем и партнерском коде. Тем не менее, раскрытая информация была довольно ограниченной.”

Несмотря на то, что ситуация обрисована довольно скупо, можно понять, что злоумышленниками получен доступ к исходным кодам сайтов, внутренним документам, паролям и различным приватным данным. Неизвестно, каким образом хакеры получили root на этих серверах (некоторые предполагают перебор или кражу паролей).

источник

Scroll to top