План відновлення після злому

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

1. Ізолюйте мережу. Потрібно відключити всі зовнішні мережеві інтерфейси, в тому числі Internet, WAN, VPN і комутовані, відключити всі лінії маршрутизатора, бездротові точки доступу Access Points (AP) і будь-які інші пристрої, які з'єднують мережу з зовнішнім світом. Ця дія дозволить зупинити активну атаку і перешкодить порушникові скомпрометувати інші системи.
2. Виконайте перевірку поточного стану бездротової мережі. Необхідно скористатися бездротовим сніфера, наприклад Airscanner Mobile Sniffer або NetStumbler.com NetStumbler, для локалізації «скомпрометованої» AP. Важливо переконатися, що сніфер встановлений на мережевої карти, яка підтримує всі поточні бездротові стандарти (тобто 802.11a, 802.11b і 802.11g).
3. Перевірте інші скомпрометовані машини. Слід використовувати методи, описані в даній статті, для пошуку інших скомпрометованих машин.
4. Проаналізуйте настройки брандмауера. Необхідно звернути увагу на незнайомі правила, незаконно відкриті порти для зв'язку із зовнішнім світом і неавторизовані правила Network Address Translation (NAT). Потрібно перевірити журнали брандмауера на будь-яку підозрілу активність. Рекомендую завжди обмежувати вихідний трафік тільки строго необхідними портами і дозволяти відправляти поштові повідомлення з обмеженого числа комп'ютерів через брандмауер.
5. Проінспектуйте AD. Потрібно звернути увагу на неавторизовані облікові записи користувачів і, якщо такі знайдуться, відключити їх.
6. Організуйте примусову зміну паролів для всіх облікових записів в мережі. Для облікових записів з високими привілеями рекомендую створити пароль (або якусь ключову фразу) принаймні з 15 символів. Паролі такої довжини важче зламати, оскільки хеші паролів LAN Manager (LM) не зберігається на сервері, якщо довжина пароля перевищує 14 символів.
7. Замініть жорсткі диски зламаних систем. Заміна дисків ізолює і зупиняє хакерську активність. Дані на старих дисках завжди можна потім переглянути і витягти цінну інформацію про атаку.
8. Визначте і ліквідуйте виявлене слабке місце. Важливо встановити, яким чином хакер отримав доступ в мережу. Як правило, це простіше сказати, ніж зробити. Якщо ідентифікувати вразливість не вдасться, варто подумати про залучення консультанта з безпеки для надання допомоги.
9. Заново переустановите скомпрометовану машину. Повністю очистити зламаний комп'ютер практично неможливо. Якщо один або кілька інструментів зломщика залишилося на комп'ютері, порушник знову може перехопити управління станцією. Єдиний спосіб гарантовано очистити уражену комп'ютер - відформатувати жорсткий диск і перевстановити все з нуля, при цьому треба переконатися, що при відновленню не будуть встановлені раніше виявлені інструменти злому. Всі програми бажано перевстановити з компакт-диска, вручну розгорнути виправлення і відновити тільки файли даних. Ніколи не слід відновлювати реєстр, операційну систему або будь-які інші програми з стрічки.
10. На всіх комп'ютерах запустіть програму антивірусного сканування. Потрібно мати на увазі, що антивірусне програмне забезпечення може іноді ідентифікувати інструменти злому як цілком законні програми. Якщо сканування показало, що все чисто, але в цьому є хоч якісь сумніви, рекомендую встановити всю систему з нуля.
11. Заново підключіть всі лінії WAN. Необхідно підключити лінії WAN і уважно стежити за даними моніторингу, це допоможе переконатися, що прогалини в мережі компанії усунені. Об'єкт особливої ​​уваги - використання смуги пропускання, журнали брандмауера і журнали аудиту на всіх серверах.
12. Проведіть ретельне дослідження зламаних жорстких дисків. Слід встановити зламані жорсткі диски на ізольований комп'ютер і постаратися отримати якомога більше інформації про характер злому. Хоча зловмисники часто використовують техніку спуфинга (отримання доступу обманним шляхом; ситуація, коли користувач отримує доступ до Internet-сервером, proxy-сервером або брандмауером, вводячи помилковий IP-адреса), адреса IP - то, з чого добре починати вибудовувати шлях до джерела атаки . Отримати список IP-адрес можна на Web-сайті Internet Assigned Numbers Authority (IANA) за адресою http://www.iana.org .
13. Сповістіть компетентні органи. У США, наприклад, співробітниками ФБР організований Web-сайт Internet Fraud Complaint Center (IFCC - http://www.ifccfbi.gov/index.asp ) Для складання звітів про підозрілу активність в Internet, а більшість регіональних відділень ФБР мають спеціальні групи протидії хакерам Cyber ​​Action Teams (CAT). Ніхто не відчуває особливої ​​радості, зізнаючись, що його мережа була зламана, однак своєчасне оповіщення компетентних органів допоможе запобігти ще більші руйнування від дій хакерів. У США, наприклад, можна зв'язатися з найближчим відділенням ФБР за адресою http://www.fbi.gov/contact/ fo / fo.htm .

Всі перераховані дії можна використовувати для підготовки індивідуального плану відновлення після виявлення злому. Цей план дій слід узгодити зі специфікою організації і включити його в загальнокорпоративні відновний план заходів.

Навчання на прикладах

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

Атака на IIS в DMZ

Мені подзвонив один з наших рідних і близьких сказав, що користувачі не можуть отримати доступ до деяких каталогах в системі Windows 2000 Server. Коли з'ясувалося, що для цих каталогів були видалені всі права, у мене виникла підозра на злом системи.

Ідентифікація злому. Я відкрив в Microsoft Management Console (MMC) оснащення Active Directory Users and Computers і переглянув облікові записи користувачів. Хтось створив дивну обліковий запис, яка виявилася в складі групи Administrators. Я зрозумів, що порушник зламав мережу, тому всі зовнішні підключення були моментально відключені і почався всебічний аналіз скомпрометованого комп'ютера. Це не забрало багато часу: мій клієнт мав два Web-сервера в демілітаризованій зоні (DMZ). Один з них представляв Web-сторінку компанії; інший вів узгодження часу. Я перевірив розділи реєстру Run і виявив підозрілі BAT-файли на диску С на обох серверах. На сервері з програмним забезпеченням узгодження часу були виявлені дивні FTP- і SMTP-програми і велике число root kits. Цей сервер підключався до системи Microsoft SQL Server по локальній мережі і за допомогою тільки трафіку від SQL Server передавав дані з DMZ в локальну мережу. Цей сервер був Windows 2000 з встановленим пакетом оновлень Service Pack 2 (SP2) і на ньому було відсутнє величезне число критичних виправлень для систем Windows 2000.

Ліквідація наслідків злому. Я перебудував сервер «з нуля», переніс його в локальну мережу за брандмауер і закрив загальний доступ до нього. Потім знову підключив зовнішні зв'язки і встановив моніторинг, відстежуючи будь-яку підозрілу активність.

Робимо Висновки. Перед тім як поміщаті публічній сервер в DMZ, Переконайся, что Виробники програмного забезпечення, вікорістовуваного в вашій системе, віпускають в достатній мірі Безпечні продукти для роботи в режімі Загальна доступу. Необходимо підтрімуваті всі сервери, а не только ті, что знаходяться в DMZ, на Рівні останніх пакетів оновлення и критичних змін. Потрібно переконатися, що додатки використовують SQL Server-інтегровану систему безпеки і не застосовують в коді програм для підключення до сервера SQL рядка з'єднання (connection string - використовується в ODBC для з'єднання із зовнішнім базою даних). Вбудовування зв'язують рядків в код Web-сервера дає зловмиснику прекрасну можливість отримати ім'я та пароль діючої облікового запису. Детальніше про встановлення з'єднання SQL Server з Web-сервера розповідається в статті Microsoft «Recommendations for Connecting to Databases Through Internet Information Services» ( http://support.microsoft.com/? kbid = 258939 ). Слід переконатися, що Microsoft IIS використовує збережені процедури для отримання доступу до даних SQL Server, і не дозволяти сервера IIS запускати оператори SQL. Оскільки всі перераховані кроки дозволяють надати аутентифікованим користувачеві дозвіл Execute тільки для збережених процедур, ви тим самим можете запобігти спробам користувача запустити оператори SELECT на SQL Server.

Атака на клієнта VPN

Ще один мій клієнт (з Exchange 2000 Server) зіткнувся з труднощами при виконанні робіт, пов'язаних з резервуванням даних, а також з дуже низькою продуктивністю сервера при відправці та отриманні електронної пошти. Нам вдалося з'ясувати, що причина того, що відбувається більш серйозна, ніж збої в роботі драйвера стримера або недостатньо потужний сервер. Сервер демонстрував неперевершену дискову активність і високий відсоток використання процесора. Я відкрив Windows Task Manager і розсортував час завантаження процесора по процесам. Store.exe забирав левову частку часу. У компанії не було настільки інтенсивно працює користувача Exchange і на той момент було всього-то 15 підключень до сервера. З такою кількістю користувачів Exchange не повинен був споживати так багато обчислювальних ресурсів, і я запідозрив руйнування в поштовому сховище.

Ідентифікація злому. Я запустив Exchange System Manager (ESM) і вибрав Administrative Groups, Admin_Group_Name, Servers, Server_Name, Protocols, Smtp, Default SMTP Virtual Server, Current Sessions. Попутно я помічаю, що шість сесій підключено до віртуального сервера SMTP вже не менше п'яти хвилин - пряма доказ, яка вказує на те, що хтось неправильно використовує сервер. У типовій ситуації сесія Exchange Server залишається активною лише кілька секунд, якщо тільки не проводиться відправлення або прийом повідомлення з вкладенням великого обсягу. Я переглянув черзі віртуального сервера SMTP за замовчуванням і виявив понад 50 черг в різних стадіях відправки пошти або очікують відновлення роботи. Хтось використовує поштовий сервер як ретранслятор, але як? На сервері встановлено останній пакет оновлень (Windows 2000 SP4 і Exchange 2000 SP3) і найсвіжіші виправлення, тому я запускаю тест Open Relay Database (ORDB) (його можна завантажити за адресою http://www.ordb.org ; тест перевіряє зазначені хости на предмет відкритої ретрансляції), щоб переконатися, що ретрансляція закрита.

Всякий раз, коли я намагався очистити з'єднання на віртуальному сервері SMTP за замовчуванням, воно знову з'являлося, зазвичай з іншим доменним ім'ям, але з тим же самим IP. Перевіряю цей список адрес IP і дізнаюся, що він виділений одним з Internet-провайдерів в далекому Китаї. Переконавшись, що мій сервер не налаштований на відкриту ретрансляцію, я приходжу до висновку, що хтось, мабуть, пройшов аутентифікацію на сервері і тепер розсилає від його імені повідомлення. А процедура Backup видає збої, оскільки весь час намагається створити резервну копію всього спаму, що розсилається. Відкриваю Active Directory Users and Computers і видаляю записи всіх підозрілих користувачів. При цьому помічаю, що деякі неавторизовані користувачі знаходяться в групі Administrators, і видаляю їх. Потім перевіряю реєстр, але не знаходжу нічого поганого в розділах Run. Про всяк випадок запускаю сканування вірусів - програма повідомляє, що сервер чистий.

Щоб не дати спамеру продовжити розсилку нових повідомлень, я відключив брандмауер від Internet і видалив всі активні сесії з сервера Exchange. Потім я спробував було за допомогою ESM видалити повідомлення з черг друку, але на це пішло б надто багато часу. Тоді я просто зупинив всі служби Exchange, відкрив вікно командного рядка і за допомогою команди Del видалив всі повідомлення з каталогу D: exchsrvrmailrootvsi 1queue. Як тільки були зупинені служби Exchange, продуктивність сервера стрибнула вгору. на видалення

10 000 повідомлень з черг пішло більше години. Потім настала черга «спам» -каталог D: exchsrvrmailrootvsi 1admail. На видалення повідомлень з неї пішло ще близько 8 годин. І нарешті, були змінені всі паролі мережевих користувачів і на брандмауері створено правило для блокування трафіку з діапазону IP-адрес, звідки спочатку надходив спам. Після виконання всіх змін я заново підключив брандмауер до Internet і запустив моніторинг сервера. Потік спаму не може бути поновлено.

Дана мережа мала кілька віддалених сайтів, які працювали через тунелі VPN. На одному з сайтів на віддаленій машині були виявлені наступні программивзломщікі: Bat.Mumu.A.Worm, Hacktool, W32.Valla.2048, W32.HLLW. Lovgate.J@mm, Bat.Boohoo.Worm і MSBlast.

Мій клієнт сказав, що даний комп'ютер був включений постійно, тунель VPN на ньому залишається активним. В такому випадку злом системи - це тільки питання часу. Я завжди рекомендую, щоб віддалені клієнти сиділи за брандмауером, особливо якщо вони використовують широкосмугове підключення. Якщо у вас система XP з'єднується по комутованого або бездротовому з'єднанню, необхідно переконатися, що Windows Firewall (колишня назва - Internet Connection Firewall, ICF) захищає комп'ютер при підключенні до Internet.

Ліквідація наслідків злому. Робоча станція була перебудована заново, поміщена за брандмауер TELE3 (виробник - SonicWALL), і на брандмауері була налаштована можливість створювати зворотний тунель до центрального корпоративного офісу. На щастя для клієнта, зловмисник використовував сервер тільки для розсилки спаму.

Робимо висновки. Прийнявши до уваги причини злому, компанія тепер не дозволяє на станціях клієнтів використовувати програмне забезпечення Mobile VPN Client на широкосмуговому з'єднанні без установки брандмауера. Якщо у вас є віддалені сайти з тунелями VPN і широкосмугові з'єднання, слід встановити брандмауер або принаймні наполягати на тому, щоб користувачі відключали свої комп'ютери, коли в них немає необхідності. Крім того, треба навчити користувачів деактивувати тунель VPN, якщо він в даний момент не потрібен.

Атака на Exchange Server (SMTP AUTH)

У третьому випадку клієнт, який використовує Internet-з'єднання, повідомив, що обмін відбувається дуже повільно через надзвичайно інтенсивного трафіку. Після того як я попросив всіх користувачів Internet відключитися, трафік і раніше залишився дуже високим. Я подивився статистику вихідних черг на сервері Exchange 2000 і виявив понад 100 черг, причому в кожної черги була присутня велика кількість повідомлень. За допомогою ESM я проінспектував повідомлення в декількох чергах. З'ясувалося, що в них були присутні повідомлення, в яких відправник і одержувач належали локальному домену, і це означало, що поштовий сервер використовувався зразок ретранслятора поштових повідомлень. За замовчуванням Exchange 2000 і більш сучасні системи допускають ретрансляцію, якщо відправник повідомлення може успішно пройти аутентифікацію на поштовому сервері.

Ідентифікація злому. Хакери можуть застосовувати цілий набір різних методик для захоплення імені користувача та його пароля. Наприклад, вони можуть періодично намагатися вгадати гостьовий пароль або пароль реального користувача і робити це до тих пір, поки не посміхнеться удача або не вийде запустити програму злому для захоплення імені та пароля користувача. Спамеру досить роздобути одне-єдине правильне ім'я і пароль, і тоді вже все одно, налаштований поштовий сервер на ретрансляцію чи ні.

Щоб встановити, яку обліковий запис використовує спамер, я запустив ESM і відкрив Organization, Administrative Groups, Organizational Unit, Servers, потім перейшов в контекстне меню Server Name, Properties і на вкладку Diagnostics Logging. У вікні Services я клацнув MSExchangeTransport і в вікні Categories підвищив рівень реєстрації подій до максимуму для категорій Routing Engine, Categorizer, Connection Manager, Queuing Engine, Exchange Store Driver, протоколу SMTP і драйвера сховища NTFS. Потім я клацнув Event Log і звернув увагу на наявність подій аутентифікації від зовнішнього або відповідної поштової сервера. Невдалі спроби виконати реєстрацію відображаються в журналі Security Log з кодом ID 680. Я виявив, що в процесі аутентифікації на поштовому сервері зловмисник використовував обліковий запис, яка не була локальної обліковим записом Exchange Server.

Ліквідація наслідків злому. Після того як була ідентифікована обліковий запис, через яку йшла аутентифікація, я зробив наступні кроки для забезпечення безпеки сервера Exchange.

1. Змінив пароль облікового запису, який використовував спамер. Якщо припустити, що спамер міг скористатися кількома обліковими записами, тоді можна поміняти паролі для всіх користувачів мережі. Також була відключена обліковий запис Guest і встановлені виділені облікові записи для запуску служб на сервері. Не варто використовувати запис Administrator для запуску служб. Якщо машина буде зламана, обліковий запис, від імені якої запускається служба, може бути скомпрометована.
2. Відключив аутентифікацію на зовнішньому сервері Exchange. Для цього потрібно запустити ESM і вибрати Organization, Administrative Groups, Organizational Unit, Servers, Server Name, Protocols, SMTP, потім відкрити контекстне меню віртуального сервера SMTP за замовчуванням, вибрати Properties, перейти на вкладку Access і клацнути Authentication. Я залишив Anonymous Access включеним, але зняв прапорці Basic Authentication і Integrated Windows Authentication. Зняття цих прапорців фактично призводить до того, що на SMTP-сервері відключається команда Auth.
3. Включив ретрансляцію для інших внутрішніх серверів Exchange, щоб переконатися, що вони можуть посилати пошту на зовнішні (outward-facing) сервери Exchange. Для цього потрібно запустити ESM, відкрити контекстне меню віртуального сервера SMTP та вибрати Properties. На вкладці Access слід клацнути Relay, вибрати Only the List Below і перерахувати внутрішні поштові сервери, яким дозволяється ретранслювати поштові повідомлення на зовнішні сервери.
4. Після всіх цих змін я провів суворе тестування отриманої конфігурації. Був протестований вхідний і вихідний поштовий Internet-трафік, а також поштовий трафік між серверами всередині компанії. Зміни теоретично могли порушити потік поштових повідомлень між серверами, тому є сенс для проведення подібних робіт дочекатися вихідних. А ще краще перевірити внесені зміни в лабораторних умовах до реального втілення в бізнес-середовищі.
5. В даному випадку виявилася станція, яка виявилася дуже серйозно скомпрометована, її довелося перебудовувати «з нуля». У якийсь інший ситуації може знадобитися ідентифікувати всі скомпрометовані станції і або спробувати їх відновити, або перебудувати заново.
6. Перевірив ORDB для того, щоб встановити, чи не виявився клієнт поштового сервера занесеним в «чорний список» для ретрансляції повідомлень. На щастя, я виявив і ліквідував наслідки злому до того, як поштовий сервер клієнта був занесений в «чорний список». Поштовий сервер може бути поміщений в «чорний список», якщо ретрансляція відкрита або якщо поштовий сервер ідентифікується як сервер, який посилає величезний обсяг даних, ідентифікованих як спам. Існує безліч баз даних відкритої ретрансляції. Подивитися список деяких баз даних можна за адресою: http://dmoz.org/computers/internet/abuse/ spam / blacklists .

Коли поштовий сервер поміщається в «чорний список», адміністратору залишається або надіслати запит про видалення сервера з «чорного списку», або змінити зовнішній адресу IP свого поштового сервера. Якщо вирішено змінити адресу поштового сервера, то необхідно також оновити запис Mail Exchanger (MX) Record на цьому сервері, інакше вихідна кореспонденція буде блокуватися.

Робимо висновки. Щоб відновити Exchange Server після атак типу SMTP AUTH і не допустити їх повторення в майбутньому, я строго рекомендую виконати всі перераховані вище кроки. Якщо зловмисник якимось чином роздобув справжнє ім'я і пароль користувача і вміє організувати ретрансляцію пошти, тоді поштовий сервер незабаром виявиться в «чорних списках» електронної пошти. Ви витратите набагато менше часу на запобігання подібних атак, ніж на з'ясування причин, пов'язаних з ненормальною розсилкою поштових повідомлень, шляхом видалення свого сервера з «чорних списків» і ліквідації вразливих місць.

Не потрібно паніки - просто будьте напоготові

План відновлювальних заходів після проведеної атаки - це частина будь-якої ІТ-структури. Він допоможе відшукати ефективний шлях протидії атакам на мережу. Ознайомтеся з утилітами і методами, які використовують зловмисники, і не нехтуйте профілактичними заходами проти атак на мережу.

Що почитати додатково

WINDOWS IT PRO RESOURCES

Щоб швидко вивчити різними аспектами в області безпеки:

Більш докладні відомості про атаки типу «спам»:

«A New Kind of Attack," InstantDoc ID 40507

Аудіопрезентації (Webcast) про захист організації від загроз безпеки:

Microsoft Security Strategies Roadshow http://www.winnetmag.com/roadshows/c omputersecurity2004

Інші ресурси:

Інтерактивні ресурси

Зайдіть на сайт www.windowsitpro.com і введіть в поле InstantDoc ID номер 43875

October 13, 2004, 12:00 noon EST:

Бесіда з фахівцем Windows IT Pro Аланом Сугано (Alan Sugano) про способи виявлення злому і відновлення системи

October-December 2004: Додати

Бесіда з Бреттом Хіллом про протидію хакерам і вирішенні деяких інших проблем безпеки

Нотатки Паули Шерік «Lessons from the Cyber Trenches»