Чи нормально отримувати сотні спроб прориву в день?

Я щойно перевірив сервер /var/log/auth.logі виявив, що я отримую понад 500 невдалих повідомлень про спробу пароля / пробивання в день! Мій сайт невеликий, а його URL-адреса неясна. Це нормально? Чи слід вживати якихось заходів?

У сучасному Інтернеті це сумно. Існують орди ботнетів, які намагаються увійти на кожен сервер, який вони знаходять у цілих IP-мережах. Зазвичай вони використовують просту атаку словника на відомі облікові записи (наприклад, root або певні акаунти програм).

Цілі атаки не знаходяться через записи Google або DNS, але зловмисники просто випробовують кожну IP-адресу в певній підмережі (наприклад, відомих хостингових компаній root-сервера). Тож не має значення, що ваша URL-адреса (отже, запис DNS) досить неясна.

Ось чому так важливо:

• заборонити root-вхід у SSH ( howto )
• використовувати надійні паролі всюди (також у своїх веб-додатках)
• для SSH використовуйте аутентифікацію відкритого ключа, якщо це можливо, і повністю відключіть авторизацію пароля ( howto )

Крім того, ви можете встановити fail2ban, який скануватиме authlog, і якщо він знайде певну кількість невдалих спроб входу з IP, він продовжить додавати цей IP до /etc/hosts.denyiptables / netfilter, щоб заблокувати атаку на кілька хвилин.

Окрім SSH-атак, також стає звичайним сканувати веб-сервер на наявність вразливих веб-додатків (деякі програми для блогів, CMS, phpmyadmin тощо). Тому не забудьте постійно підтримувати ці оновлення та безпечно налаштовувати їх!

Кілька 100 - це просто чудово ... Минулого місяця я виявив, що на одному з моїх серверів було 40 тис. Спроб. Я перейшов через проблему їх побудови: Карта

Як тільки я змінив ssh-порт і застосував Port Knocking, кількість знизилася до 0 :-)

Я, наприклад, використовую "tarpit" на додаток до того, що дозволяю лише автентифікацію відкритого ключа та забороняє входити в систему.

В netfilterє recentмодуль, який можна використовувати з ( INPUTланцюга):

iptables -A INPUT -i if0 -p tcp --dport 22 -m state --state NEW -m recent --set --name tarpit --rsource
iptables -A INPUT -i if0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 180 --hitcount 6 --name tarpit --rsource -j DROP
iptables -A INPUT -i if0 -p tcp --dport 22 -j ACCEPT

Це означає, що кожна спроба підключитися до порту 22 перерахована recentмодулем з IP та деякими іншими речами під назвою "tarpit" (якщо вам цікаво, дивіться /proc/net/xt_recent/tarpit). Очевидно, ви можете використовувати й інші імена.

Для списку чи виключення списку IP використовуйте:

echo "+123.123.123.123" > /proc/net/xt_recent/tarpit
echo "-123.123.123.123" > /proc/net/xt_recent/tarpit

Ця швидкість обмежує спроби 5 на 300 секунд. Зауважте, що користувачів із наявним підключенням не турбує цей ліміт, оскільки вони вже мають встановлене з'єднання і їм дозволено створювати більше (навіть вище межі швидкості).

Пристосуйте правила за своїм смаком, але переконайтесь, що вони додані в такому порядку (тобто при додаванні потім використовуйте їх у цьому порядку, при вставлянні потім у зворотному порядку).

Це надзвичайно зменшує шум. Він також забезпечує фактичну безпеку (від жорстокого насильства) на відміну від сприйнятої безпеки зміни порту. Однак я все-таки рекомендую змінити порт, якщо це можливо у вашому оточенні. Це також зменшить рівень шуму ...

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

Редагувати:

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

iptables -A INPUT -i if0 -p tcp --dport <knockport> -m state --state NEW -m recent --name tarpit --remove

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

Так . Сьогодні це цілком нормально.

Будь ласка, використовуйте лише автентифікацію відкритого ключа для адміністративних цілей, якщо це можливо. Створіть приватний ключ на робочій станції:

$ ssh-keygen -t dsa

Скопіюйте вміст ~ / .ssh / id_dsa.pub на ваші сервери ~ / .ssh / санкціоновані_keys (та /root/.ssh/authorized_keys, якщо вам потрібен прямий вхід у систему root).

Налаштуйте ваші сервери / etc / ssh / sshd_config, щоб вони приймали лише автентифікацію відкритого ключа:

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin without-password

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

Подивіться на Denyhosts і fail2ban, щоб заблокувати повторні спроби входу в SSH, і перегляньте Snort, якщо вам потрібен повний IDS / IPS.

використовувати http://denyhosts.sourceforge.net/

і так, слід використовувати аутентифікацію відкритого ключа та відключити автентифікацію пароля.

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

Я б сказав, що отримати лише 500 - це дуже низько.

У попереднього роботодавця один із дослідників комп'ютерної безпеки назвав постійний потік спроб вривання "Інтернет-еквівалентом космічного шуму ". Він описав це як нормальний безперервний потік шкідливого трафіку, який шукав системи в Інтернеті і автоматично використовував сценарії для спроби викрадення системи. Бот-мережі та інші шкідливі системи постійно будуть сканувати та переглядати Інтернет для вразливих систем, на зразок SETI.

так,

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

Уникайте IP-адрес, пов’язаних з DNS

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

Використовуйте VPN для доступу до SSH

Якщо ви перебуваєте в середовищі, в якому можете реалізувати IPsec / VPN до приватної мережі у вашому серверному середовищі, це ідеально. Вимкніть увесь доступ до Інтернету SSH, переконайтеся, що у вас є інтегроване рішення для освітлення. Налаштуйте VPN і дозвольте SSH отримати доступ лише з VPN.

Реалізуйте правила IP-адреси для доступу до SSH

Якщо VLAN не є параметром, налаштуйте ваш маршрутизатор або правила брандмауера, щоб дозволити з'єднання SSH лише з відомого діапазону IP-адрес.

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

Цілком нормально бачити сотні невдалих SSH-з'єднань.

Якщо у вас є можливість, я просто змінюю свій порт SSH на щось нестандартне. Це не обов'язково робить ваш сервер більш захищеним, але він впевнено очищає журнали (і дозволяє вам бачити, хто навмисне намагається зламати!)

Окрім використання автоматизованого механізму блокування, як-от fail2ban, у вас є ще один варіант: фактично зв’язатися з адресою зловживання провайдером зловмисника. Це може здатися абсолютно безрезультатним, але у випадку сценарію-малюка їхній Інтернет-провайдер більш ніж готовий вжити заходів щодо них.

Щоб знайти адресу зловживання, почніть з arin.net та знайдіть IP-адресу, використовуючи whois. Ви можете бути перенаправлені до іншого регіонального реєстру, але врешті ви зможете знайти відповідального провайдера IP-блоку, який містить адресу. Шукайте адресу зловживання @ або просто надішліть технічний контакт.

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

Я б рекомендував не використовувати fail2ban, а запускати SSH (та інші) на нестандартному порту. Я не вірю в безпеку через невідомість, але вважаю, що це відмінний спосіб зменшити шум у ваших журналах.

Помилкові входи в нестандартні порти будуть нечисленні і далеко між собою, а також можуть вказувати на більш націлені атаки.

Ви можете навіть піти на крок далі встановити медовий горщик SSH, такий як Kippo, щоб «пустити» грубих сил і подивитися, що вони зроблять, даючи шанс.

Так, це нормально. Що я розповідаю клієнтам у вашій ситуації з невеликими веб-сайтами.

Завжди будьте готові до злому.

Майте копію свого веб-сайту на сервері розробок. Це може бути ваш робочий стіл Windows за допомогою XAMPP, який ви можете отримати безкоштовно.

ЗАВЖДИ вносите зміни на сервер розробників, а потім завантажуйте їх на свій веб-сайт, що живе Якщо це такий CMS, як Wordpress, робіть свої публікації на сервері розробок, а потім скопіюйте та вставіть їх на живий сервер.

НІКОЛИ не завантажуйте нічого зі свого веб-сайту, що живе в реальному часі, на сервер розробників

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

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

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

Сподіваюся, це допомагає.

Ще один спосіб зупинити його (оскільки я особисто не люблю переміщувати порт SSH): вирішіть, чи зможете ви перерахувати всі мережі, з яких ви коли-небудь захочете увійти, тоді дозвольте їм лише отримати доступ до вашого порту SSH.

Записи WHOIS локальних провайдерів допомогли мені зменшити атаки до 1-2 спроб входу в місяць (тоді це було близько 1 к / день). Я виявив їх, все ще використовуючи затримки .

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

Приклад:

AllowUsers admin jsmith jdoe

Опція AllowUsers вказує та контролює, яким користувачам можна отримати доступ до служб ssh. Кілька користувачів можуть бути вказані, розділені пробілами.

Так, це нормально. Ти можеш :

• Зменшіть можливість атаки за допомогою fwknop

Fwknop є однією з кращих реалізацій стукіт портів, оскільки він не піддається підробці та фактично підтверджує автентифікацію на відміну від простого авторизації з'єднання.

• Ви можете змінити порт, який використовує Openssh, але ви не дуже покращуєте безпеку.

• Підтвердьте аутентифікацію ssh за допомогою Google-автентифікатора чи wikid

Це захистить атаки, засновані на паролі, та можливість визначеної атаки / націленої атаки компрометують вашу адміністраторну машину та вкрадуть комбінацію ssh-ключа та пароля.

Просто перегляньте останній комп’ютер pwn2own, щоб побачити, наскільки кваліфікованому зловмисникові легко компрометувати ваше повністю виправлене вікно адміністратора.

На жаль, це цілком нормально. Вам слід подумати про те, щоб додати щось подібне до fail2ban до вашої системи, щоб автоматично виявляти та забороняти нападників. Якщо ви цього ще не зробите, вам слід також розглянути можливість використання лише ssh з відкритими ключами та не дозволяти кореневому входу через ssh. Якщо ви використовуєте ftp для передачі файлів у систему, розгляньте замість цього використання scp / sftp.

Я реалізував стукіт портів і маю кілька зондів на день. Вони не мають зв'язку, тому вони йдуть геть. Я реєструю та повідомляю про весь доступ до залучених портів.

Я також запустив fail2ban разом із Shorewall як брандмауер, щоб тимчасово набити чорний список стійких нападників.

Якщо вам не потрібен доступ до Інтернету до SSH, відключіть його. Якщо у вас є кілька відомих адрес, яким потрібен віддалений доступ, обмежте доступ до цих адрес.

Обмеження доступу до авторизованих ключів також може бути корисним.

Я використовую pam_ablдля тимчасового чорного списку грубих форсажів, і це чудово працює. Я думаю, що краще мати авторизацію в PAM, використовуючи власну базу даних, а не залежати від hosts.denyабо iptables.

Ще одним плюсом є те, pam_ablщо не залежить від сканування файлів журналів.

Це цілком нормально в ці дні.
Ви можете встановити ліміт "прориву" на брандмауері для вхідних нових з'єднань на порту SSH,
або встановити один з багатьох аналізаторів журналу a'la fail2ban або змінити порт SSH;).

Останній - найпростіший. На важко завантажених машинах такі спроби взлому можуть дуже сильно впливати на всю систему.

-
З повагою,
Роберт

Так, це нормально.

Я щойно змінив ssh-порт від стандартного 22. Мій сервер, мої правила :) просто відредагуйте / etc / ssh / sshd_config, змініть порт і перезапустіть послугу. Єдиний нижній бік полягає в тому, що ви повинні пам'ятати, щоб додати цей порт до конфігурації до кожного клієнта ssh, який ви використовуєте.

• Вимкнути вхід у систему root (У кожного користувача кореневої системи Linux, тому боти можуть легко вгадати ім’я користувача). Після входу в систему як звичайний користувач, ви можете перейти на root або через su, або sudo.

• змінити порт за замовчуванням на 22

• Дозволити доступ до ssh лише з відомих ip-файлів

• Використовуйте сильний альфа-числовий пароль для користувача, що має доступ до ssh