У меня было несколько проблем с безопасностью на моем сервере, несколько пользователей SSH настраивали пожары или проблемы.

Я хотел бы:

• Отслеживание пользовательских входов и выходов
• Отслеживайте активность этих SSH, чтобы обнаружить любую вредоносную активность
• Запретить пользователям удалять журналы

Я не являюсь системным администратором и совершенно неопытен в этом вопросе, поэтому любые советы будут очень полезны и полезны. :)

Поскольку мы говорим о SSH-серверах, я дам вам решения для командной строки.

• Отслеживание пользовательских входов и выходов. Это просто, файл /var/log/auth.logдолжен иметь эту информацию.

• Отслеживайте активность этих пользователей: если они довольно невинны, вы можете проверить файл .bash_historyв их домашнем каталоге . Вы увидите список команд, которые они выполнили. Проблема, конечно, в том, что они могут удалить или отредактировать этот файл.

• Запретить пользователям удаление журналов. Пользователи не должны касаться auth.log. Чтобы не дать им поиграть .bash_history, нужно сделать пару трюков .

• Что если пользователю удастся получить root-доступ? : Ты пьян. Если они не совершат ошибку, они смогут скрыть все свои шаги.

[ОТКАЗ] Я понимаю , что я опоздал на вечеринку, но я хотел бы, чтобы вставить ответ , который я дал еще один вопрос , потому что я чувствую , что он может предложить некоторое хорошее представление для читателей, и этот вопрос , кажется, идти к место для базовой информации SSH.

Была похожая проблема, которая поразила меня после прочтения этого вопроса здесь на AskUbuntu и проверки моего VPS, только чтобы увидеть несколько миллиардов попыток перебора. Именно тогда я решил принять меры.

Теперь, в соответствии с вопросом, на который я ссылался, если вы хотите увидеть неудачные попытки входа в систему на вашем компьютере через ssh (это могут быть попытки перебора или что-то в этом роде), попробуйте набрать следующее:

grep sshd.\*Failed /var/log/auth.log | less

Если выходные данные состоят из нескольких строк, то есть множества попыток грубой силы, особенно если они произошли между короткими интервалами, вы можете выполнить следующие действия:

Изменить файл конфигурации ssh

Для этого откройте файл, расположенный в / etc / ssh / sshd_config, в вашем любимом редакторе, например так vim /etc/ssh/sshd_config.

1. Попробуйте переместить ssh из порта 22 : найдите строку с надписью:

# What ports, IPs and protocols we listen for
Port 22

и закомментируйте порт 22, и используйте кого угодно. Пример:

# What ports, IPs and protocols we listen for
# Port 22
Port 28934

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

2. Отключите вход в систему Root через ssh : поскольку имя пользователя root предсказуемо и обеспечивает полный доступ к вашей системе, предоставлять беспрепятственный доступ к этой учетной записи через SSH нецелесообразно. Найдите строку с именем PermitRootLogin и установите для нее значение no .

PermitRootLogin no

3. Отключите аутентификацию по паролю . Создайте и используйте ключи SSH для входа в систему. Если пароли не включены, злоумышленникам потребуется угадать (или украсть) ваш закрытый ключ SSH, чтобы получить доступ к вашему серверу. Нечто очень сложное. Перейдите к строке, которая читает PasswordAuthentication, и установите для нее значение no

PasswordAuthentication no

!ПРЕДУПРЕЖДЕНИЕ! Прежде чем сделать это, пожалуйста, ознакомьтесь с этим руководством здесь о том, как настроить аутентификацию сертификата.

ПРИМЕЧАНИЕ. После внесения изменений используйте sudo /etc/init.d/ssh restart. Для подключения к другому порту с помощью использования SSH: ssh username@hostname.com -p <port_number>.

Настройте брандмауэр

Пожалуйста, ознакомьтесь с этим руководством о том, как настроить чрезвычайно мощный и эффективный межсетевой экран, который интегрирован в Linux, IPTables .

Сценарии установки, чтобы помочь вам с безопасностью

Тот, который я использую лично и быстро приходит на ум, - это Fail2Ban . Fail2ban будет контролировать ваши файлы журнала для неудачных попыток входа в систему. После того, как IP-адрес превысил максимальное количество попыток аутентификации, он будет заблокирован на уровне сети, и событие будет зарегистрировано /var/log/fail2ban.log. Чтобы установить его:sudo apt-get install fail2ban

Проверьте историю команд через ssh

Существует команда linux с именем history, которая позволяет вам видеть, какие команды были введены до этого момента. Попробуйте набрать historyв терминале, чтобы увидеть все команды до этого момента. Это могло бы помочь, если бы вы были root .

Для поиска конкретной команды попробуйте:history | grep command-name

Чтобы вывести список всех команд после ssh :fc -l ssh

Вы также можете редактировать команды, используя vi (я не пробовал vim, хотя я предполагаю, что это также работает):fc -e vi

Вы также можете удалить историю :history -c

ПРИМЕЧАНИЕ. Если вы не являетесь поклонником команды, historyв вашем домашнем каталоге ( cd ~) также есть файл с именем .bash_history (если вы используете bash), в котором вы можете catувидеть все, что было введено в оболочке bash.

Немного излишне, но вы можете увидеть все, что запущено в вашей системе, используя «коннектор событий процесса»:

http://www.outflux.net/blog/archives/2010/07/01/reporting-all-execs/

1. Хавьер уже ответил на это: /var/log/auth.log
2. Я нашел отличную статью об этом здесь .
3. Если ваши пользователи не имеют доступа к root, ваши файлы журналов должны быть в безопасности. Вы можете попытаться создать некоторые пользовательские правила в файле sudoers, чтобы ограничить доступ пользователей и как. Также вы можете увеличить уровень журнала для демона sshd.

Помимо самого входа в систему нет безопасного способа отслеживать / регистрировать действия пользователей после того, как они войдут в систему, при условии, что у них есть базовые знания Linux, они смогут отключить ведение журнала оболочки или просто запускать команды из других оболочек (например, python).

Вместо этого вы должны быть консервативны в отношении предоставления доступа по SSH, им это действительно нужно? Предоставление доступа по ssh не очень распространено, если вы не используете оболочку, предоставляющую бизнес.