У мене було декілька проблем із безпекою на моєму сервері, кілька користувачів SSH створювали пожежі, які створювали проблеми.

Я хотів би:

• Відстежуйте вхід користувачів та вихід із системи
• Відстежуйте активність цих SSH, щоб виявити будь-яку шкідливу діяльність
• Не дозволяти користувачам видаляти журнали

Я не дуже сис-адмін, і я досить недосвідчений в цьому питанні, тому будь-які поради будуть дуже вітаються і дуже корисні. :)

Оскільки ми говоримо про SSH-сервери, я дам вам рішення командного рядка.

• Відстежуйте вхід користувачів та вихід із системи. Це просто, файл /var/log/auth.logповинен мати цю інформацію.

• Відстежуйте активність цих користувачів: Якщо вони досить невинні, ви можете перевірити файл .bash_historyу їхньому домашньому режимі. Ви побачите список команд, які вони виконували. Проблема, звичайно, у тому, що вони можуть видалити або відредагувати цей файл.

• Забороняйте користувачам видаляти журнали: користувачі не повинні мати можливість торкатися auth.log. Для того, щоб вони не .bash_historyмогли грати з вами, потрібно зробити пару трюків .

• Що робити, якщо користувачеві вдається отримати кореневий доступ? : Ти накручений. Якщо вони не помиляться, вони зможуть приховати всі свої кроки.

[ВІДПОВІДАЛЬНІСТЬ] Я розумію, що я спізнююсь на вечірку, але хотів би вставити відповідь, яку я дав на інше запитання , тому що я відчуваю, що він може запропонувати читачам гарне розуміння, і це питання, здається, є передумовою місце для основної інформації про 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. Вимкнути кореневі реєстрації через ssh : оскільки ім'я користувача root передбачувано та забезпечує повний доступ до вашої системи, надавати безперебійний доступ до цього облікового запису через SSH нерозумно. Знайдіть рядок, що читає PermitRootLogin, і встановіть її на ні .

PermitRootLogin no

3. Вимкнути автентифікацію пароля : Створюйте та використовуйте SSH-ключі для входу в систему. Без включених паролів зловмисникам потрібно буде відгадати (або вкрасти) ваш приватний ключ SSH, щоб отримати доступ до вашого сервера. Щось, що дуже дуже важко. Перейдіть до пошуку рядка, який читає пароль і встановіть його на " ні"

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термінал, щоб побачити всі команди до цього моменту. Це могло б допомогти, якщо ви вкоренилися .

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

Щоб перерахувати всі команди після ssh :fc -l ssh

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

Ви також можете видалити історію :history -c

ПРИМІТКА. Якщо ви не шанувальник команди, historyу вашому домашньому каталозі ( cd ~), який називається .bash_history (якщо ви використовуєте bash), також є файл, який ви можете catбачити все, що було введено в bash shell.

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

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 доступ не дуже часто, якщо ви не перебуваєте в службі, що надає оболонки.