Комментарии 49
"... злоумышленники попали на главный сервер через открытый порт RDP" - это нормально :)
"... резервные копии хранились на том же сервере" - и это нормально :D
"... у ограниченного списка людей, ... они должны находиться в ... облаке" - люди в облаке? Это надежно!
В итоге- сколько компания потратила на "Аудит" и во сколько раз эта сумма больше суммы выкупа?
Мы провели опрос, чтобы узнать использует ли фирма бекапы... Не использует... Блин, нас взломали и узнали, что фирма не делает бекапы. Фирму тоже взломали. :-D Нам вроде в вузе когда-то говорили, что если кто-то что-то попытается взломать, из вуза выгонят сразу же. Просто нужно проводить профилактические работы и никогда не платить деньги хакерам, чтобы они знали, что за взлом будет только срок если поймают и ничего другого.
все хранить на бумажках, бумажки в сейф. Если налоговая - открыть сейф, кинуть спичку, закрыть сейф (как вариант - сейф стоит за забором в Газеле - если налоговая стучит в дверь, главбух выпрыгивает в окно, садиться в Газель и по газам)
А вот с вашими облаками всегда так - то гугл забанит то эппл прочитает "для повышения качества услуг и борьбе с порнографией"
Компания экономила на системном администраторе..... вот и вся история.
Открытый порт рдп это конечно не здорово, но вообще не проблема (со сложностью решения 5минут). Можете его даже не "менять регулярно". Порт кнокинг, белые списки (не, не слышали)..... да что там - более 5 подключений в час = вечный бан.
И вот уже условные хакеры на перебор пятизначного пароля тратят 10 лет....
Не то, чтоб экономила....Системный администратор был, но выполнял работу в стиле "и так сойдет", а кроме него в этом никто ничего не понимает, поэтому и проверить не могут. К сожалению, часто встречаем такой подход в компаниях.
Порт-нокинг, это, конечно, повышает надежность, но неудобно для внешних клиентов.
А вот черно-серо-белые списки - весьма разумный компромис.
У нас (правда не по RDP) при подключении или при попытке подключения IP заносится в серый список. Если в течение 15 минут попытка с этого IP повторилась, то в серый список рангом повыше. Затем - еще выше. После нескольких попыток (4 попытки за 45 минут) IP блочится на неделю. Сейчас в черном списке около 650 IP. После начала СВО их количество резко выросло с 900 до 2000.
Еще хочу установить ханипоты на RDP и другие Well Known Ports с мгновенным блоком на недельку или больше.
Да, в принципе ловушек и логики блокировки по количеству подключений достаточно в обычном режиме, а белые вообще самодостаточны.
Я, например, использовал не ступенчатые списки, а правила поведенческие... например если клиент подключается раз в 10минут условно, то вообще не будет заблочен.... но если сразу 5 подключений за 30 секунд, то в бан без разбора. Ну и прочие адаптивные варианты.... ориентированные на то, похоже это на человека или нет.
Лет так 6-7 назад обнаружили распределенную атаку на RDP. попытки шли с сотен IP. Не часто - каждые 1-2 секунды суммарно. Повтор попытки с одного IP - не чаще чем через 5 минут. Т.е. ни о каких 5 подключений за 30 секунд речи не шло. Поэтому временной диапазон между допустимыми попытками должен быть гораздо больше.
Это была не инструкция)
А подобные атаки легко отсекаются по упоминавшимся мною поведенческим факторам, у того же микрота, кроме ручных правил, есть весьма интересные решения..... для комплексного подхода подобная атака ниочем.
Но рассказывать это, наверно после некоторого момента, мамкиным хакерам подсказывать пути обхода ( на самом деле нет).
Ставить ханипот на внешний интерфейс бесполезное занятие. Будете собирать десятки IP'шников в час и ни с одного из них попытка доступа не будет повторяться в каком-то обозримом будущем. Я проверял. Не работают уже сейчас так тупо, что бы с одного IP порты перебирать. Вот поставить ханипот на внутренний интерфейс может быть гораздо интереснее и полезнее.
На самом деле - меньше. В пике было почти 2000 IP в ЧС за неделю. Т.е. около 12 в час. Сейчас в 3 раза меньше. Серый список первого уровня (с которых нет повторных попыток вообще) - 1-2 IP. Всего в серых списках всех трех уровней - не больше дюжины IP.
А какой смысл на внутренние интерфейсы ставить? Если есть теоретический крот, то что такого особенному ему даст доступ к шлюзу по внутреннему интерфейсу, что не даст прямой доступ к нужным серверам?
На внутреннем интерфейсе - даст знать если внутри периметра завелась какая-то зараза, которая сканирует всё подряд. Если будет целенаправленно работать "крот", то он будет действовать не так тупо конечно.
На внешнем интерфейсе... Цифры отловленных IP можно конечно обсудить, но смысл от этого не меняется. Ну позаблокировали мы адреса, а толку с этого? В нормальной ситуации и так все порты закрыты файрволом, хоть обсканируйся. И кстати чуть ниже я рассказывал забавный случай после которого я еще более скептически стал относится к таким блокировкам.
Почему это все порты закрыты файерволлом? А как удаленные объекты будут передавать на наши сервера телеметрию? Как будет производиться синхронизация информации?
Просто у нас сделано несколько грубовато и простовато. Есть несколько портов на самом шлюзе, к которым разрешено подключаться только из локалки. Но на внешних интерфейсах попытки подключения к ним все равно отслеживаются.
По хорошему, надо в таком случае сразу IP в бан (т.е. превратить в ханипот эти порты), а не проводить их по серым спискам. Но просто было лень писать еще дополнительные правила. Поэтому отслеживаем попытки множественных подключений скопом - и для этих портов и для легальных одними правилами.
Кстати, сейчас количество IP в BL упало до 300. Зато в GL (во всех) увеличилось до 30. К чему бы это?
Ну сразу скажу, что я не экстрасенс, а вариантов конфигураций может быть множество в т.ч. и достаточно экзотичных. Поэтому говорить за всех дело не благодарное уже по определению. Но говоря, что все порты должны быть закрыты я конечно имел в виду все ненужные порты.
Вообще этот вопрос можно свести к очень простой системе. При правильной настройке (нормально закрытый файрволл) у нас внешние порты либо закрыты вообще все (ну не нужны нам подключения из вне), либо открыты только нужные. Во втором случае мы либо знаем заранее с каких IP к ним будут подключаться и в этом случае используются белые списки (соответственно блокировки теряют всякий смысл). Либо мы не знаем с каких IP буду подключаться, и тогда возникает вопрос - а хорошая ли это мысль блокировать IP'шники? Я так понимаю у Вас случай когда открыты нужные порты и не известно с каких IP будут подключаться. Вы делаете ханипот, ловите попытки подключения к портам которые у вас закрыты (не нужные вам), делаете на основании этого вывод, что это попытка атаки и блокируете этот IP не давая с него подключиться и к нужным портам тоже. Что ж - решение вполне имеет право на жизнь, не спорю. Однако никакой надёжной защитой это не является (ведь могут сразу атаковать нужный порт), а рано или поздно еще и злую шутку сыграть может (почитайте мою историю). Единственную пользу которую этот способ даёт это снижение нагрузки на роутер для отсеивания левых подключений к нужным портам, если Вы от этого сильно страдаете (но с ваших же слов таких IP не так много). А мораль в том, что защита подключений из вне должны быть не на основе блокировки IP, а на основе какого-то другого более высокоуровневого метода (авторизация и т.п.). В идеале это должен быть VPN во всех случаях когда это возможно, а по нему уже данные гоняться. Если Вы говорите, что у вас удалённые объекты подключаются, то поднимайте между этими объектами и головной площадкой VPN и работайте по нему безопасно. Нормально настроенный VPN на современном протоколе (IPsec, L2TP/IPsec, IKEv2 - это из "стандартных") еще вроде никто ломать не научился.
Хорошую идею подсказали. Я, правда, самими контроллерами не занимаюсь, но сейчас посмотрел - новые ПЛК OWEN 210 поддерживают WireGuard и OpenVPN. Надо будет попробовать организовать связь по OpenVPN, если его у нас еще не заблочили полностью.
Ну опять же я не экстрасенс и не знаю как там что у Вас встроено и какие требования. Но если у Вас удалённые площадки на которых есть внутренняя сеть, то правильный путь это поднимать VPN от роутера удалённой площадки до роутера центрального офиса (я предпочитаю делать это на Микротиках, но тут кто во что горазд). При этом всё оборудование из удалённых площадок будет ходить в центральный офис по внутренним адресам. А там уже дальше можно или тоже файрволлом фильтровать или просто безоговорочно доверять всему трафику из внутренний сети удалённого офиса. Это уже по вкусу/по требованиям. Поднимать VPN с отдельных хостов (например с контроллеров про которые Вы упомянули) путь не правильный. Это надо делать только если этот удалённый хост не подключен к сети которую Вы же контролируете (а соответственно не можете поднять VPN роутер-роутер). Например если некий контроллер стоит где-то и подключен к Интернету через 4G свисток. Или подключен к сети здания но сеть эта не ваша. Тогда да - остаётся поднимать VPN прямо с этого контроллера (если это возможно конечно).
Сложно себе это представляю. Меня прям коробит от мысли, что где-то в обслуживаемой мною компании прямо дыра внаружу..... я ж спать нормально не буду....
Даже неопытный, но адекватный админ не будет допускать таких ситуаций, прям уверен в этом (он же вмеру даже малого опыта, представляет последствия и сложности и его же геморрои). Поэтому я скорее за сэкономили или живу в такой-то своей вселенной))
Админу компании постоянно капали на мозг сотрудники бухгалтерии и других служб, что каждый раз нужны "какие-то VPNы и пароли и вообще, слишком много канители". Наверно, он выбрал самый простой способ - не делать ничего.
Кстати, давно и часто замечал что руководители больше прислушиваются к мнению сторонних экспертов, чем к мнению своих. Был и на той и на другой стороне и по моему опыту это практически идеальное совпадение.
Это и по жизни часто случается: по описанию профессионал, а по факту может знать меньше тебя (я, например, про некоторых строителей/установщиков и т.п.)
Насчёт бана. Был у меня случай недавно. Забанил IP с которого периодически к VPN пытался подключиться уволенный сотрудник. Не знаю зачем он это делал (и продолжает делать), ведь учётка VPN была естественно отключена. Мне же надоело периодически видеть алерты и я решил "проблему" таким способом. Ну забанил и забанил. Недели через две (я уже про бан забыл...) мне другой сотрудник (работающий) сообщает, что у него уже несколько дней не подключается VPN. Я говорю - решай со своим провайдером почему у всех подключается, а у тебя нет (а надо заметить прецеденты такие были уже, когда провайдеры косячили). Прошло еще пару дней - провайдер клянётся, что у них всё норм. Начинаем разбираться и вот оно - этот сотрудник подключается с того же IP. Что оказалось. Живут эти люди (уволенный и не уволенный) в разных городах, но ЖК от одного застройщика с единственным допущенным провайдером. А провайдер выпускает абонентов в Интернет через NAT.
Поэтому "вечный бан" по IP - так себе идея.
Лучше временный на несколько суток. Помогает более гибко отслеживать ситуацию, но снижает скорость подбора, практически, до нуля.
А вечный бан никто и не делает как правило (хотя именно в этом конкретном случае я так и сделал). Но даже если Вы блочите скажем на сутки, то в ситуации когда нужный сервис или удалённый сотрудник заблочился на сутки и потом сам разблочился, то от этого не легче.
В общем мораль такова, что надо ко всему подходить с умом - просчитывать вероятные события или оценивать плюсы и минусы в конкретном кейсе. Банить можно но с умом. Как я выше написал - в Вашем кейсе (если я его правильно понял конечно) бан по IP не даёт 100% защиты. А значит надо думать стоит этим заниматься или нет. А например в моём кейсе извне открыты только порты для VPN. Заниматься баном по ханипоту в этом случае не имеет никакого смысла в плане улучшения безопасности. Но я все же это делаю - я баню все подсети Азиатско-Тихоокеанского региона. Потому что во-первых я точно знаю, что ко мне оттуда никто не подключается, а во-вторых из них идёт очень много атак. В плане безопасности я этим абсолютно ничего не решаю. Просто в логах меньше записей о попытке подключиться к VPN по admin/admin (образно).
Подскажите, какая ОС стояла на сервере ?
Не беспечность, а скудоумие и ментальное нищебродство. Сколько работаю с ИБ направлением, большая часть заказчиков считают антивирус это панацея о всего и вся и таких заказчиков полно. Объяснять им бесполезно они не слушают доводы, потому что надо тратить. Ментальные нищеброды всегда спрашивают, а сколько я потрачу
Простите, вы уверены, что написали статью для Хабра, а не Пикабу?
Единственная причина взлома - это простой пароль администратора.
Порты всегда открыты, те или иные, если нужен доступ извне. Просто констатация факта. И этот факт сам по себе не негативен.
Виртуальные машины требуют дополнительных ресурсов. И не дают никаких преимуществ, кроме бэкапов образа всей системы. И то, преимущество сомнительное. Что лучше - иметь больше копий или меньше, но каждую с системой?
Вообще довольно легко определить ламеров, которые считают себя крутыми специалистами по ИБ: они везде пихают виртуалки и ad. И кричат, какие они специалисты по безопасности.
В статье ни слова про маршрутизатор и его настройки. Этим всё сказано.
Статья не призвана сообщить какие мы молодцы и как все здорово настроили после всей этой ситуации. Уверены, что в сообществе очень много грамотных специалистов. Мы лишь обращаем внимание, что в любой компании и офисе нужны хотя бы минимальные элементы ИБ, потому что АВОСЬ не поможет в данном случае.
Думаю, что причиной была дырявая версия РДП на старой винде. Недавно такой же фейл был на знакомой конторе: рдп наружу, вин2008, 1с и вся бухгалтерия на серваке. Все пошифровали. Но! это была виртуалка, а бэкап я настроил (ибо спать не мог без бэкапа!!!). Все восстановил с бэкапа, владелец отделался легким унынием, тк собирался платить деньги хакерам. Итого: я получил премию, а хакеры шиш без масла ж-)))
зы в простейшем случае можно сделать файлопомойку на старом компе с Линем и с помощью VeeamOne делать копии сервака на линь сервак - у них есть бесплатная версия, несколько компов покрывает.
Недавно надо было на компе домашней сетки кое чего рашарить. Для этого сдуру оживил пользователя User с паролем 123 (это нужно чтобы можно было с десятки на шару зайти). При том что на домашний комп есть RDP. Уже на следующий день какая то редиска залогинилась на моих изумленных глазах. Понятно, тупняк был тут же исправлен и сделаны выводы, но это жесть какая то. Кругом злодеи :)
Сидел потом ещё анализировал чего мог успеть натворить нежданный гость за 10 минут.
Вариантов было два. Скинуть на комп и запустить шифровальщик, но ресурсы вроде никто не жрал. Хотя процесс может и не спешить. Второй - скинуть какую-нибудь утилиту для слива инфы, но тут нужно было бы прописаться в файрволе, чего не было обнаружено. В итоге решил что пронесло. Но ощущение полных штанов не покидало ещё долго.
Жадность и глупость - жадный платит N-раз. Особенности "бЫзнеса" (
Есть множество вариантов бэкапа от открытого ПО до платного, но нет - "доРаГА"! Наблюдаю такое через раз точно (
P.s. Для по-файлового бэкапа пользуем kopia (умеет в s3 - у меня minio), для ВМ\lxc на proxmox - pbs от них же (маунт с nfs - nas на truenas scale). Стоимость перечисленного ПО - 0 (нуль), только на железо надо потратиться (можно б\у ). Всё.
Для доступа извне - единая точка входа (ОДИН открытый вовне порт для всего). Это то-что-нельзя-упоминать-из-трех-букв или\и что-то типа apache guacamole, kasm workspaces.
Также "опасные" сервисы можно\нужно вынести в dmz. На proxmox это делается в пару кликов созданием вирт. сетевого интерфейса и привязкой оного к нужным ВМ\lxc.
P.p.s. Про proxmox и не только https://forum.netgate.com/topic/163435/proxmox-ceph-zfs-pfsense-и-все-все-все-часть-2/
Как мы вели переговоры с хакерами или сколько стоит беспечность для компании