Я випадково забороняю з'єднання SSH з віддаленим сервером ... Що далі?


61

Скажімо це ще раз, всі ми робимо помилки , і я щойно зробив одну.

Коротка історія: я робив деякі речі на VPS (Debian), який я орендую, коли помітив якусь дивну поведінку. За допомогою netstatкоманди я побачив несанкціонований зв’язок через SSH. Я не знав, що робити, тому вирішив перервати його зв’язок, використовуючи iptables:

iptables -A INPUT -p tcp --dport ssh -s IP -j DROP

Але я втомився, і писав

iptables -A INPUT -p tcp --dport ssh -j DROP

і я вигнав себе (і всіх інших) ...

Як це виправити?



1
ні, тому що він блокує всі пакети ssh на машині. у неправильно налаштованій підмережі, ви просто введете tcpdump для цієї мак-адреси, отримаєте підмережу, на яку вона аргументується, а потім налаштуйте віртуальний нік для тієї ж підмережі і поговоріть з нею.
jfalcon aka Don Fanning

50
Ну, ви, безумовно, видалили доступ для принаймні несанкціонованої особи.
CVn

2
Наступного разу, можливо , було б зручно перемикач мертвого чоловіка .
Уейн Конрад

2
Хто ваш господар? Багато хостів VM пропонують послідовну консоль, яка дозволяє вам SSH у випадках, коли ви не можете з віддаленого місця.
Джон

Відповіді:


60

Є кілька альтернатив:

  • Подивіться, чи є у них доступ до консолі IPMI / "KVM" / консолі, що дозволяє вам керувати ним, як якщо б у нього підключена фізична клавіатура.
  • Якщо вони цього не пропонують, подивіться, чи можете ви завантажувати VM на компакт-диск з відновленням Linux (деякі провайдери пропонують це), а потім виправляйте правила брандмауера таким чином, а потім завантажуйте його як звичайне.
  • Якщо у вас немає доступу до консолі, перед тим, як завантажуватись до відновлення чи приєднувати гучність до іншого VM (як у випадку Amazon, відповідь користувача user3550767), ви можете спробувати відповідь Ankh2054 про перезавантаження спочатку, якщо ви не зберегли правила ( швидше за все, так як ви вигнали себе, перш ніж у вас був шанс врятувати). Використовуйте панель керування або попросіть когось перемкнути живлення, використовуючи неграційне скидання / перезавантаження (так само жорстке перезавантаження або жорстке відключення), якщо сценарій init автоматично зберігає правила при вишуканому перезавантаженні (Credit @jfalcon, @joshudson).

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


1
Залежно від vps-сервера, може не бути віддаленого доступу, до якого він може отримати. такі системи, як vmware, kvm, xen тощо, мають консолі, але не налаштовані для громадського споживання. що закриває, що дозволяє використовувати таку форму громадського контролю - це атака.
jfalcon aka Don Fanning

4
що сказав, якщо він знаходиться в просторі Amazon / google, він може зробити знімок накопичувача та встановити його з іншої віртуальної машини, щоб зробити виправлення.
jfalcon ака Дон Феннінг

47

Якщо ви ще не зберегли правило IPtables, ви можете перезавантажити сервер на VPS (якщо такий є), і правило повинно зникнути.


якщо тільки сценарій init не зберігає iptables під час відключення.
jfalcon aka Don Fanning

3
@jfalcon: Ось чому ви можете попросити їх витягнути віртуальний штекер.
Джошудсон

22
@jfalcon Тому також погана ідея автоматичного збереження при відключенні ... зробіть збереження свідомим рішенням sysadmin, а не щось, що сліпо виконується системою.
CVn

@joshudson: Ви повинні сказати мавпі перезавантаження, що потрібно робити, і вимкнути живлення. Не просто ініціювати відключення.
jfalcon aka Don Fanning

@ MichaelKjörling: Ця філософія також неправильна. Це VPS, тому, швидше за все, він піскує своїми програмами і не має контролю над тим, хто потрапляє на вимикач живлення. І ви поняття не маєте, як хостинг VPS налаштовував свої конструкції. Немає нічого поганого в економії при відключенні. Його помилка була його помилкою. Перш за все розумним кроком було б поставити SSH на нестандартний порт або використовувати fail2ban, а не реагувати на панічну реакцію.
jfalcon aka Don Fanning

30

Це те, для чого призначені співробітники з питань допомоги персоналу. Зателефонуйте постачальнику послуг і попросіть одного з їх операторів видалити правило для вас.


3

Загальний спосіб виправити зламаний екземпляр - це закрити його та приєднати кореневий том до робочої інстанції. Потім ви зможете встановити гучність там і переглянути журнали чи редагувати файли конфігурації. Потім можна від'єднати гучність і запустити її в власному екземплярі.


2
Вірно для AWS VPS; як правило, не відповідає дійсності.
MadHatter

@MadHatter Точні деталі можуть відрізнятися, але якщо постачальник VPS не пропонує жодного способу завантажуватись із відомим робочим зображенням, з якого можна змонтувати та виправити свою кореневу файлову систему, то я б очікував, що вони припинять свою діяльність після того, як клієнти дізналися про це обмеження.
kasperd

Зазвичай вони роблять це, пропонуючи доступ до консолі, тому ви можете завантажуватися в режимі однокористування або з рятувальних носіїв (як правило, абстрагуються як ISO). Я стверджую, що це насправді набагато нормальніше, ніж дивним способом вирішення проблеми AWS, де друга VPS є (тимчасово) вимогою.
MadHatter

@MadHatter Який із двох підходів здається дивним, дуже може залежати від того, що вам найбільше знайоме. І будь-який підхід виконує роботу. Яке найпоширеніше я не можу коментувати, оскільки досі мені потрібен такий доступ лише для одного постачальника VPS.
kasperd

@kasperd: Ні, те, що ви використовуєте, залежить від того, який постачальник VPS підтримує; це не питання вибору. Якщо ви використовуєте AWS, ви встановлюєте гучність на іншій VPS; якщо ви використовуєте більш звичайного постачальника послуг VPS, ви завантажуєте однокористувача або з рятувальних носіїв. Я не вважаю, що ця думка є дурнем (ну, не цілком), але тому, що важливо розуміти, що треба з'ясувати, що підтримують методи, які підтримує постачальник, а потім використовувати їх. Намагаючись використовувати метод AWS з, скажімо, Hetzner просто не вийде , тому що один Hetzner vserver не може бачити FS іншого (afaik).
MadHatter

3

Формальна відповідь: перейдіть на панель управління VPS, якось отримайте локальний доступ (віртуальний KVM) або зателефонуйте їм.

Пояснення кроків / правил, щоб не допустити потрапляння на нього знову:

  1. Існують зміни правил ip, маршрутизації та брандмауера, які можуть погіршити та заблокувати ваш доступ.
  2. і це стосується і спеціальної конфігурації мережевих пристроїв, а не лише VPS

Так що, якщо ви не 100% впевнені , що ви можете відновити .. Я рекомендую завжди зробити так , щоб скинути мережеву конфігурацію в колишньому стані .. як, відкритий фоновий сеанс з будь-яким screen, nohupабо tmuxнавіть cronможете працювати для цього, і додати iptables -Fабо інші бажані засоби, щоб повернути що-небудь до попереднього стану.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.