Недавно нам удалось изучить две скомпрометированные системы, на которые были осуществлены схожие атаки. На их примере рассмотрим, как действуют злоумышленники, и какие ошибки позволили им успешно проникнуть на серверы организаций.
Жертва 1
Небольшая компания (менее 50 сотрудников). 1 сервер под управлением Win 2008. На сервере установлена 1С Бухгалтерия, развернуты файловые шары. Домен не развернут, на АРМ и сервере используются локальные учетные записи для сотрудников. Бухгалтеры могут заходить из дома по RDP на сервер для удаленной работы в 1С. Администратор приходящий. В целом, картина довольно характерная.
В понедельник утром у бухгалтеров не стартует 1С. Такое бывает. По инструкции администратора бухгалтер заходит в папку с базами 1С, чтобы их «передернуть». Не знаю, что это за режим работы 1С, который требует «передергивать» базы, и что это вообще значит, но баз в папке не обнаруживается. Вместо них лежит файл «ЧИТАТЬ!!!!!!.txt». В нем написано (без всякого уважения к орфографии и пунктуации), что базы похищены. При желании вернуть базы предлагается обратиться по указанному email-адресу (в стиле vasyanpetrov2001@mail.ru).
Начинается паника. Администратор вызван в компанию и безуспешно пытается разобраться, что случилось, и восстановить работу системы. Директор пишет письмо хакеру. Хакер лаконично запрашивает IP-адрес сервера и требует затем 30 000 руб. за возврат баз. Честно говоря, мы полагали, что требовать должны на порядок больше, но злоумышленники, очевидно, лучше знают своих жертв.
Нашего специалиста попросили помочь. Администратор вернул сервер в офис из дома, куда он увозил его для анализа, и сам присоединился к нашему специалисту. Анализ жесткого диска показал, что восстановить удаленные базы уже затруднительно. Из-за многократного включения сервера, попыток восстановления бекапов и прочих манипуляций, удаленные файлы перезаписались новыми. Никаких следов заражения системы, руткитов и т.п. обнаружено не было. В логах (их не почистили) было ясно видно, что в пятницу вечером стартовал перебор логинов/паролей на RDP. В воскресенье незамысловатый пароль одного из бухгалтеров был подобран. Перебор продолжился и закончился только после логина злоумышленника на машину в ночь на понедельник.
Здравый смысл подсказывал, что логика «бизнеса» злоумышленника не предполагала возврата баз, да и вообще их копирования на удаленный сервер. Вирусам-шифровальщикам нужна хорошая репутация для роста платежей, так как они работают массово и жертвы могут почитать о них в интернете. Здесь же логично было на месте хакера просто потребовать еще денег после получения первого транша. Для проверки этой версии были запрошены данные из биллинга провайдера. Действительно, базы никто не скачивал. Их просто удалили. Общение с не уважающим Розенталя хакером, соответственно, было свернуто.
Дальнейшее исследование показало, что в панике все почему-то решили, что последний бекап был пару месяцев назад. Причем базы бекапа лежали на том же жестком диске, что и боевые базы, и были доступны хакеру, но он не удосужился их поискать. На самом же деле бекап был сделан за 1 рабочий день до взлома и информацию можно быстро восстановить. Все мысленно пожелали хакеру мучительной смерти и радостные разошлись.
Рекомендации, которые можно было бы дать пострадавшей компании (с учетом ее скромного размера):
- бекапы должны делаться регулярно и храниться отдельно;
- права пользователей должны быть минимизированы (все бухгалтеры имели полный доступ ко всему на сервере);
- удаленный доступ лучше организовать по VPN и использовать токен дополнительно к паролю. Затрат это практически не потребует, а защищенность вырастет порядочно.
Жертва 2
Крупная компания, располагающая серверы на коллокации в одном из коммерческих ЦОДов Москвы. От ЦОДа поступает информация, что с одного из белых IP компании фиксируется поток вредоносного трафика (подробностей не предоставили). Нас попросили помочь администраторам разобраться, что происходит.
Анализ показал, что трафик идет с виртуального сервера с консолью управления Антивирусом Касперского. Те, кто работал с этим продуктом, знают, что чаще всего контроль над консолью дает администраторские права на всех машинах, где установлен антивирус. Ясно, что седых волос от такой новости у группы администрирования сильно прибавилось. Немедленно был создан снимок виртуальной машины с сохранением данных оперативной памяти. После этого машину в рабочей сети погасили и начался анализ копии в изолированном сегменте.
Каково же было наше удивление, когда мы обнаружили, что взлом был также осуществлен через перебор пароля на RDP из интернета. Администраторы уверяли, что сервер в интернет не публиковался. Параллельно стали изучать последствия взлома и то, как RDP оказался доступен из внешней сети.
Второе выяснилось быстро. Оказалось, что сетевой администратор редактировал листы доступа (ACL) на граничном маршрутизаторе Cisco через консоль. После окончания работ он накатил ACL на интерфейс… наоборот. То есть входящий и исходящий были перепутаны местами, открыв полный доступ к набору серверов из интернета. Этого никто не заметил.
Пароль был подобран очень быстро. В компании была принята парольная политика, но тут про нее почему-то забыли. Затем на сервере были созданы 4 учетные записи с правами локального администратора (Adm1n, Default User, Register, ASPNET). Через какое-то время злоумышленник зашел под учеткой ASPNET. Не обнаружив баз 1С (далее станет ясно, как мы поняли, что здесь также орудовали охотники на 1С), хакер вручную открыл браузер, запустил speedtest.net для понимания пропускной способности канала к серверу, и залил на сервер утилиту для перебора паролей на RDP. Вручную пошаманив с настройками, хакер запустил атаку на внешние серверы. Никаких следов попыток развить атаку на внутреннюю сеть или воспользоваться консолью Касперского не было. Если бы злоумышленник хоть немного пораскинул мозгами, он бы смог в итоге вымогать у жертвы куда больше, чем 30 000 руб.
Для брута паролей использовалась утилита, скаченная с популярного «хакерского» форума. Хакер вручную загрузил словари для перебора и стартовал атаку. Перебор шел для учеток с говорящими именами: Администратор, User1, User2, Buh, Buh1, Buh2, Buhgalter, Glbuh.
Можно посмеяться над примитивностью подходов, полным отсутствием автоматизации и слабыми техническими знаниями взломщика, но все это оказалось достаточно эффективным. За время работы утилиты были взломаны 4 реальных сервера российских компаний (с паролями вроде 12345). Злоумышленник вручную заходил на взломанный сервер, с которого шла атака, и проверял улов, который складывался в файл в папке с утилитой.
В целом, компания сделала выводы после инцидента:
- Стало вполне очевидно, что наличие политик не гарантирует их выполнение. Необходимо вводить контрольные процедуры.
- Начался процесс зачистки внутренней сети от незащищенных машин. Все убедились в том, что злоумышленник может добраться и до них при определенных обстоятельствах.
- Была введена процедура автоматического контроля сетевых изменений на периметре сети (автоматическое сканирование 2 раза в сутки).
- Были дополнены процедуры контроля изменений.
- Было введено регулярное сканирование на уязвимости снаружи и внутри сети.
- В целом не помешала бы и какая-то система обнаружения вторжений, которая бы пресекла перебор пароля во время атаки.
Заключение
Причиной обоих взломов являются скорее не жадные до легких денег скрипткидди, а безалаберность или ошибки самих администраторов. Будет возможность поживиться, найдутся и желающие. Особенно, если для этого не требуется особых усилий. Да и поверхностный подход к взломам можно объяснить не ленью и непрофессионализмом хакеров, а потоковым подходом к атакам: проще перебрать лишнюю сотню серверов, чем копаться с одним.
В любом случае, даже такие простые атаки могут стоить компании любого размера очень дорого. В оффлайне банки строят подземные сейфы, а на ларек на ночь вешают амбарный замок.
Нараспашку двери никто не оставляет. В интернете же до сих пор все несколько иначе. На радость злоумышленникам всех мастей и уровней профессионализма.
Янкин Андрей, itsecurity
Комментарии (87)
Shizit
22.11.2016 16:32… удаленный доступ лучше организовать по VPN и использовать токен дополнительно к паролю. Затрат это практически не потребует, а защищенность вырастет порядочно…
Токены не бесплатны(аля securid), теряются и лочатся. Имхо лучше через сертификат на локальную машину.SecurityJet
22.11.2016 16:42+1Не могу согласиться. Хранение сертификата на локальной машине — это, по сути, то же самое, что оставленные в портах USB токены. Это распространенная практика у бухгалтеров и большое подспорье хакерам, которые выводят деньги со счетов компаний через банк-клиент.
Токен стоит недорого, для юрлица и вовсе копейки. В том же Китае законодательно запрещен доступ в интернет-банк без аппаратного токена даже для физлиц. Китайцы привыкли и давно этому не удивляются. Определенно, это существенно повышает безопасность удаленного доступа к системе ДБО. Возможно, нашему ЦБ тоже стоило бы об этом подумать.servermen
22.11.2016 22:01Главное, чтобы токены не глючили из-за своей дешёвости.
При низком качестве изделий, как правило целые серии подвержены разного рода дефектам и болезням.
Представляю ситуацию, когда человеку надо срочно сделать платёж, но благодаря не к месту сдохнувшему токену, он побегает, попортит себе нервы и возможно даже попадёт на проценты за просрочку. И непременно поделится своим негативным опытом с окружающими. А организация при частом отмирании токенов, также скорее всего понесёт убыток.ariklus
23.11.2016 14:33Ситуация аналогична глючащему в других местах онлайн-банкингу: если организация экономит на системе онлайн-банкинга (подвисает сайт/не отправляются смс/ломаются физ. токены) — то компания теряет клиентов. И обеспечить достаточную надежность токенов ИМХО не намного сложнее чем надежность любой другой части системы.
Foggy4
23.11.2016 15:41Есть и бесплатные реализации софта для двойной аутентификации (не супер-секьюрные конечно, но вполне годные для небольшой компании). Пример — google authentificator + LinOTP.
Honomer
22.11.2016 16:42А причём тут 1С?
SecurityJet
22.11.2016 16:43Злоумышленники целенаправленно охотятся именно на базы 1С.
Ugrum
22.11.2016 16:48Это такой признак -«Лох, заплатит?»
SecurityJet
22.11.2016 17:33+4Злоумышленники выделили критический и плохо защищенный актив и наладили схему вымогательства денег. Им проще атаковать лишнюю сотню компаний, чем разбираться с каждым уникальным случаем и искать что-то кроме баз 1С.
teecat
24.11.2016 16:57Троянец отслеживает активность пользователя в следующих приложениях:
* 1С версии 8;
* 1С версии 7 и 7.7;
...
Название трояна — Trojan.PWS.Spy.19338SecurityJet
25.11.2016 00:44Не понял, при чем тут этот троян?
teecat
25.11.2016 09:47Один из вариантов, интересующихся информацией пользователей, паролями и прочим в целях шантажа/продажи информации
Imbecile
22.11.2016 16:49А почему не включены во втором случае политики безопасности AD, которые блокируют учётную запись после определённого количества неверных вводов пароля?
SecurityJet
22.11.2016 17:58+1Эта политика действительно зачастую считается лучшей практикой, но по моему опыту зачастую создает больше проблем, чем пользы. При массовом бруте учеток они также массово блокируются, парализуя работу ИТ-инфраструктуры. Если есть возможность, лучше фиксировать факт перебора и устранять его причину.
Imbecile
22.11.2016 18:24Типа, DMZ без включения серверов в домен?
SecurityJet
22.11.2016 21:32В данном случае так и было. Меня больше удивило то, что сервер управления Каспесперского находился в DMZ. При этом он, естественно, никуда не публиковался.
realscorp
23.11.2016 10:09При массовом бруте учеток они также массово блокируются
Именно поэтому такую политику нужно дополнять скриптами на уведомление ответственных лиц о блокировке той или иной учетки. Да и пусть учетка лучше заблокируется, чем падет жертвой брут-форса.SecurityJet
23.11.2016 16:32В энтерпрайзе это решается мониторингом и правилами на SIEM. У меня был кейс у одного из заказчиков, когда политика блокировки учеток в AD привела к полному параличу компании на несколько дней (что-то около 1500 сотрудников отдыхало). Случилось вирусное заражение. Вирус смог выгрузить список всех учеток в AD и начал их брутить по кругу. Заблокировалось всё. Компания переезжала на новую ИТ-инфраструктуру в это время, что добавило хаоса.
Так что тут надо взвесить все за и против.
amarao
22.11.2016 17:03Из своей админской юности: резервные копии (настоящие резервные копии, а не архивы «для скорости») должны писаться на неперезаписываемые носители. Да-да, на обычные болванки. Только отсутствие физической возможности «стереть» гарантирует, что данные не перезатрут случайно. Да, постепенно размер хранилища растёт, но, в отличие от большинства СХД, складское хранение отлично делает scale out — закончилась одна коробка, начинаем следующую.
Когда я уходил, было около 300кг бэкапов (начинали ещё задолго до моего прихода и продолжили после).SecurityJet
22.11.2016 17:36+1Не было проблем с порчей дисков со временем? Время жизни CD-R, как подсказывает google, что-то между 2-5 лет, даже если он в коробке лежит.
amarao
22.11.2016 19:21+5Зависит от бренда. Ноунеймы дохнут быстро, качественные болванки живут 10+ лет. На самом деле никого не интересует живость данных пятилетней давности, всех интересует, чтобы предыдущий бэкап БЫЛ. Перезаписываемые медиа сильно рискуют быть перезаписанными. Записанные и верифицированные болванки (была такая обязательная процедура) рискуют быть только уничтоженными физическими мерами, а с этим, на удивление, проще бороться. Положили бэкап и заклеили бумагой с печатью. Всё, все «случайно» отметаются при этом.
Болванки при этом не отменяют электронный бэкап (он быстрее и доступнее), но являются финальным fail-safe.Sergey_datex
23.11.2016 00:33учитывая «удобство» работы с болванками, на предприятии должен быть отдельный «бекап-менеджер». Который будет их ставить, писать, вынимать, складировать, подписывать, в общем заниматься дурной работой.
Areso
23.11.2016 06:42+1На все это нужен всего 1 час «дурной» работы. Как часто этот час нужен зависит от политики бэкапов. К примеру, у нас ручные бэкапы делаются в пятницу (на внешний носитель) и автоматические — каждый день.
shamash
22.11.2016 21:35Сейчас трэнд такой: Бэкапы складывать в облако.
1с продвигает свой сервис бэкапов встроенный в 1с, но он требует монопольного доступа к базе на время бэкапа. Поэтому я использую для файловых версий копирование папки с базой, в отдельную папку при этом на чтение файл/файлы баз доступны и копию можно снять в любой момент, затем копия папки архивируется, кладется в папку где автоматически настроена синхронизация.
Допустим с дропбоксом, почему с дропбоксом? потому что он поддерживает даже в бесплатных аккаунтах хранения истории файлов, соответственно если базы например 2: торговля и бухгалтерия архивы, которых занимают около 1гб, в один момент хранится 2 копии базы на физическом хранилище. И даже при удалении из физического хранилища по истории можно поднять около 20 последних версий файла бэкапа в веб интерфесе.
Яндекс диск яндекс диск ты где сделай уже эту штуку, 2гб все таки маловато для хранения бэкапов, а вот была бы у яндекса история хранения файлов, как в дропбоксе, сразу бы забросил свой 20гб аккаунт дропа.
Единственная оговорка, как показали последние события, посыпая голову пеплом, при получении доступа к рдп сервера, ребята уже не просто шифруют все подряд, а смотрят куда делаются бэкапы и удаляют учетные записи дропбокса если по глупости, моей они запущены на этом же сервере.
Плюс у дропа совершенно не вменяемая поддержка для халявщиков типа меня, пишеш им так мол и так, все что в факе сделал, не могу тото и тот, и все что в инструкции сделал. А они через сутки спрашивают, сделали ли я все что в факе, а затем просто игнорят.
Соответственно чтобы обезопасить себя, необходимо делать файловое хранилище, куда будут складываться копии папок на отдельный сервер и уже на этом хранилище будут в не расшареные папки кластся архивы, но при этом нужно обозначить что сам сервер с бэкапами в отличии от терминального сервера должен быть, неприступен. Думаю даже роутер с флэшкой подойдет для этой задачи.
Это я рассматриваю самые экономные задачи. Для внедрения, естественно намного лучше делать впн с токенами итп, но мелкий бизнес не готов тратить деньги на это, а я время поскольку для меня это просто сопутствующая задача.
Для скл версии добавлю только один момент с 2008 версии сам скл поддерживает архивирование своих bak файлов, и их можно сразу складывать в папку для синхронизации с облаком. Не используя внешнию тулзы. Единственно что скорее всего bak файл в дропбокс у вас уже не получится?amarao
22.11.2016 21:49Супер. И как это спасёт от удаления аккаунта, воровства пароля или других айтишных глупостей? Оффлайновый бэкап на неизменяемые носители нельзя заменить онлайновыми волатильными технологиями.
shamash
22.11.2016 21:56воровства пароля от логина с двухфактурной авторизацией?
удаление аккаунта, если есть почта к которой привязан номер телефона?
Просто вся схема должна быть.
Как и ваша схема с кучей болванок, сервис для бэкапов должен работать, cd-rw привод должен работать, админа не должны обижать чтобы он сам не оставил для себя бэкдор, это общий правила, реализация на текущий момент не требует физичиских носителей в чистом виде, даже я для большой розничной сети бэкапы на ленту ни разу не восстанавливал, в виду того что сервер зеркалировался в азуре и при его поломке просто поднималась его копия.
Это я к тому, что болванки это уже не круто, этом может стать круто если резко пропадет весь интернет.
Но тогда и риски для которых делаются облачные бэкапы также станут не актуальными.amarao
22.11.2016 22:00Бэкдора на болванках не бывает, это раз. Сломавшийся привод — это всего лишь поломка оборудования и меняется на равных основаниях с любыми другими устройствами, это два.
Если вы никогда не делали в своей жизни Большой Ошибки «промахнувшись сервером» — ну, повезло. Не всем везёт.
Упор не на слово «болванки», а на слово «неизменяемый носитель». Если бы лента была бы write once, я бы её так же любил бы.shamash
22.11.2016 22:08бэкдоры оставляют себе сами админы, или вредоносный софт принесеный из интернета или с внешних носителей, ну или сама политика безопасности или ее отстутсвие может быть бэкдором, как примеры описанные в статье.
Я делал слишком много ошибок в своей жизни, чтобы пропустить эту статью и не начать рассказывать про свой опыт.
Я просто хочу сказать, что неизменяемый носитель не лучше, а скорее хуже чем текущие облачные решения. При достаточно быстром канале и грамотной настройке, система работает сама и не требует вмешателства. Только контроль. А про болванке я приведу вам пример. Предположим приезжает ОБЭП описывать сервера, что происходит у меня. Я обьяснять вам не буду.
Но что произойдет у вас со всеми этими килограммами дисков и не перезаписываемых носителей, а так же как человек, который в буквальном смысле делал обыск скажу, что многие данные лежат в организациях в чистом виде, копия базы снятая бухгалтером на рабочий стол, диск забытый в столе компьютера с подписью март 2015 БП, ООО «АЛЬФА», или коробка поломанных флэшек в пустой серверной могут дать достаточно для того чтобы пропукаться всем.
Понятно что ОБЭП это не тот, риск который мы тут обсуждаем, но лишние данные это ЛИШНИЕ данные.amarao
22.11.2016 22:25-1Никакой бэкдор не может испортить записанный на -R болванку бэкап. При чём тут бэкдор, вообще?
ОБЭП к сохранности данных никак не относится, и для решения этой проблемы есть во-первых 9.5 правил ведения бизнеса в РФ, а во-вторых шифрование.shamash
22.11.2016 22:29Никакой админ не может испортить записанный на R болванку бэкап? Никакой пожар не может испортить коллекцию болванок? бэк дор = задняя дверь. т.е. инструмент получения доступа к данным минуя официальные главные двери.
Я с вами согласен я не спорю, я просто в реализации вашего примера добавил лет 15 прогресса. 9.5. правил не опровергают ни ваш ни мой вариант реализации резервного копирования.
Retifff
22.11.2016 20:13>а безалаберность или ошибки самих администраторов
Или начальства, например. Которое не всегда хочет слушать администраторов, а топает ножками и кричит «Я не хочу такой сложный пароль», «я не хочу менять пароль раз в N-месяцев», «Я не хочу покупать жетские диски для резервных копий, у меня денег нет» и т.п.SecurityJet
22.11.2016 21:38Тяжело не согласиться. В конечном итоге руководство организации несет ответственность вообще за все в компании. Ответственность не делегируется, как известно. И обычно, пока гром не грянет, никто ничего по части информационной безопасности и DR не делает. И это касается не только мелких компаний.
DRDOS
23.11.2016 16:33Вот вот вот!!!
У нас как то уволили админа которые заставил делать, сложные пароли.StalkerJS
28.11.2016 11:54У нас другим путём пошли: «СложныйПароль1116». И всё. Меняй себе циферки. И хрен что людям объяснишь.
SecurityJet
28.11.2016 12:02Это большая проблема, кстати. Формальное удовлетворение требованиям стойкости пароля и реально стойкий пароль — совершенно разные вещи. Решения могут быть разные.
В ряде систем при вводе нового пароля идет проверка на словарность. В случае с классическим AD иногда администраторы ИБ сами проводят брут паролей по их хешам на регулярной основе. Для этого хеши выгружаются на выделенную машину без доступа по сети, которую берегут как зеница око, чтобы не дай бог кто-то к ней не получил доступа.
Если пользователи не получают по шее за пароли вроде «M@sha123», то все это, разумеется, становится бесполезным.
blik13
22.11.2016 22:19Безалаберность страшная сила. Как-то искал документы гуглом по ключевым словам. Выскочила ссылка на ФТП. Оказалось это был ФТП для обмена файлами в организации (территориально значительно разобщенная контора). Бухгалтерская отчётность (и прочая), документы для служебного пользования, даже фотки с телефона замдиректора. Нашёл в штатном расписании контакты их сисадмина, связался, быстренько поправили. Конечно ничего сверхсекретного там не было, но если бы наткнулись какие гбшники наши, то по шапке получили бы знатно.
ZekaVasch
23.11.2016 04:23+1В эпоху расцвета файлообменных DC сетей и взламывать ничего не надо было.
Мама на компе иногда работает работу. Логины и пароли хранит в папке в моих документах или на рабочем столе в папке «Флешка с работы»
Дите ставит DC расшаривает диск Ц всем и все. Нате пользуйтесь. Никакой секурити аудит не найдет откуда была утечка.
Один раз был даже случай. Наткнулся так на кучу документов одной фирмы, которые были клиентами по IT знакомых франчайзи\аутсорсеров. Из анализа было видно, что юрист взял домой поработать все что смог =))
Отсыпал им всего этого — они пришли, к директору и предложили провести секурити аудит или чето там такое.
Вообщем наверное поимели с этого профит или + в карму.
Другой раз нашел планы конкурентов по развитию рынка. Тоже была взята «работа на дом»
AcidVenom
23.11.2016 10:41Опыт подсказывает, что не стоит делать добро. К тому же на таких ФТП можно найти массу полезного.
GarrySeldon
23.11.2016 08:21Доступ к 1С из дома очень нужная вещь, но нельзя «голую» винду выставлять на всеобщее обозрение. Доступ должен быть органзован через защищенные VPN IP-sec соединения. Контору, в которой я ранее работал и где был упрощён доступ, не давно так же взломали. Кончилось благополучно, но в следующий раз может уже и не повезти.
realscorp
23.11.2016 10:15+2нельзя «голую» винду выставлять на всеобщее обозрение
Если очень хочется, то можно. Сам RDP в наше время достаточно стоек, и уязвимости в нем находят очень редко. Но, конечно, должна быть настроена политика блокирования учетной записи при переборе паролей, плюс уведомление IT-отдела о факте блокировки, плюс валидный сертификат у RDP-сервера, плюс обучение пользователей.GarrySeldon
23.11.2016 20:04Не стал бы так рисковать и дело даже не в RDP. Сама Windows не являевляется безопастной системой. Лучше её «скрывать» за хорошими аппаратными или программными сетевыми экранами, которые будут защищать весь офис. Можно скачать готовую бесплатную сборку на основе Linux'a. Если нет отдельного компьютера, можно создать виртуальную машину и пропускать весь интернет трафик через неё. Вариантов много и всегда можно «выкрутится» даже если нет денег.
А без удалённого доступа сейчас тяжело — ни начальство с Кипра не может посмотреть, как идут дела, ни программиста 1С-ка не подлючишь, да и с VPN'ом можно все филиалы подключить к одной базе.
Arxitektor
23.11.2016 09:30А су шествуют ли брелки тика флешки
на брелке 10 цифр 0-9. Вставил брелок, набрал мастер пароль. Защел на сайт и комбинацию 1047.
А брелок вводит 18-16 значный пароль ))
Вроде такую идею уже видел.
MAXInator
23.11.2016 12:56Чем это принципиально отличается от вышеупомянутых токенов?
kotandvla
23.11.2016 19:59Пин-код вводится на стороне железного токена, а не в софте, для противодействия закладкам в клавиатуре или кей-логгерам.
MAXInator
24.11.2016 08:07Для противодействия кейлоггерам в токен вшит сертификат. Для противодействия краже сертификата — есть пин с требованиями по сложности. Так чем принципиально отличается от брелка, содержащего длинный пароль?
SirStefan
24.11.2016 16:22Ну хотя бы тем, что на таком брелке может быть зашито несколько паролей. Например один и тот же брелок передается буху в следующей смене. И каждый ходит под своим паролем.
MAXInator
24.11.2016 16:27На токен можно положить несколько контейнеров и к каждому будет свой пин. Все еще не вижу принципиальных различий.
SirStefan
25.11.2016 12:19Физический ввод пина, невозможность его отслеживания с компьютера. Не понял, как защитит сертификат от кейлоггера?
MAXInator
25.11.2016 12:31А чем злоумышленнику поможет знание пина без доступа к контейнеру?
SirStefan
25.11.2016 16:14Ну например можно отследить пин, потом им воспользоваться. Особенно когда бухгалтера оставляют воткнутые ключи банк-клиентов в комп.
MAXInator
26.11.2016 10:12Ровно так же можно воспользоваться оставленным вставленным «брелоком типа флешки». Мы говорили о противодействии кейлоггерам, а не о злоумышленнике, имеющем полный (в том числе и физический) доступ.
MegaShIzoID
23.11.2016 10:04+2ну проблема здесь скорее в неспособности руководства обеспечить свою фирму хорошим админом, пусть даже и приходящим
TheWorld
23.11.2016 18:13Наверное, я и есть тот приходящий админ из 1 примера в аналогичной фирме)
У себя разобрался и внедрил многое — начиная от блокировки пользователей и сложных паролей, и заканчивая уведомениями на почту при появлении каких-то событий, политикой ограниченного использования программ, архивирование с сервака в облако и на другой комп в подсети, который доступен только для записи, но не для чтения (разве такой способ архивирования позволяет удалить записанный архив в случае компрометации самого сервера?). Короче все кроме VPN.
Буду очень благодарен, если кто нибудь предложит реализацию VPN, чтобы она была максимально проста в использовании со стороны клиента. Смотрел в сторону OpenVPN, но в этом случае на стороне клиентского компьютера необходимо ставить их софт. Есть ли альтернативы?SecurityJet
23.11.2016 18:25Ответил на этот вопрос в ответ на ваше личное сообщение.
Если нет возможности ставить клиент, то можно посмотреть, например, в сторону RDP over HTTPS. Очень многие TeamViewer используют. Решений миллион. Но если, как вы писали, постоянно рвется соединение с офисом, то все это будет работать нестабильно. Экстремальный вариант: перенести сервер в облако.TheWorld
23.11.2016 18:34Спасибо за ответ.
Teamviewer имеет проблематичность использования, если его использовать коммерческим образом. Т.е. либо мучиться с заменами мак-адреса и переустанавливать его постоянно, либо покупать лицензию (от 250$ — сам я ее себе позволить не могу, а контора не понимает зачем платить за то что и так бесплатно работает).
AcidVenom
24.11.2016 16:21Mikrotik и L2TP/IPSec. Настраивается по мануал, пользователям раздается инструкция на 1 листе А4. Можно привязать к учеткам Radius если есть домен. Цена вопроса — 5 т.р.
PumpON
23.11.2016 18:25А почему в обоих примерах не указано, каким образом недоброжелатели выходили на RDP порт? У них что стандартные порты стояли и на шлюзе небыло кроссовых пробросов?
SecurityJet
23.11.2016 18:25Да, торчали в интернет стандартные порты.
PumpON
23.11.2016 18:53Ну это совсем края крайние! Это насколько надо быть ленивым и тупым, чтоб даже этого не сделать?
SecurityJet
23.11.2016 18:59Люди вообще не осознают проблему. Да и переставлять порты на нестандартные — тоже очень сомнительное с точки зрения ИБ решение. На этом безопасность строить нельзя.
PumpON
24.11.2016 13:16Кросс портов, ограничение количества попыток ввода и пароль со спец символами, нестандартные учетки. Мне пока хватает для нормальной работы по RDP.
Lordbl4
24.11.2016 16:232 схожих случая и 2 одинаковые ошибки «приходящего» админа — слабые пароли
если бы пароли были бы сложные — шанс взлома сократился бы на порядок. сам сталкивался с подобной ситуацией и скажу, что схема классическая — «перебрать пароли, войти под слабым паролем бухгалтера Васи (потому что ему лень запоминать\записывать сложный пароль) и навредить жертве с последующим вымогательством (удаление\перенос\шифрование)»
DanXai
Вот зачем им это? На работе работы мало? А голый RDP наружу выставлять — ССЗБ.
Кстати, а как решался вопрос с клиентскими лицензиями? Каждые 90 бухи дней чистили реестр от временных лицензий?
MAXInator
Например, отпуск или болезнь + внезапная задача.
SecurityJet
Согласен. В небольших компаниях часто заменить бухгалтера некем.
Удаленный доступ для бухгалтеров используется в каждой второй небольшой компании.
BiOMeX
Вот зачем им это? На работе работы мало?
Внезапно: подавляющее число бухгалтеров — женского пола. Внезапно-2: у них вполне себе могут быть дети/родители, которые вполне себе могут заболеть, а оставить их не с кем. Внезапно-3: временами из дома работать ЗНАЧИТЕЛЬНО удобнее, нежели из офиса.
У меня (пока) Всё ;)
Areso
Вопрос с RDP лицензиями решается одним патченным файлом.
aapazhe
А зачем вообще сотруднику с такими обязанностями протирать штаны в офисе?
DimmiSfai
Я бы спросил зачем им RDP если бухгалтерия 1Сная уже пару лет может публиковаться на веб сервере двумя кликами (IIS тот же везде есть) и работать с ней можно через веб клиент или веб морду. Пароль на сайт, пароль на логин в базу и все…
Protos
может дороже, или потому, что админ приходящий и ему нет желания заниматься лишней работой?
DimmiSfai
Настройка всего минут 10 займет, и справится даже эникей по мануалу в 1 страницу. Единственный вариант, древняя версия бухгалтерии которая такого не умеет, но это уже самодурство, т.к. обновляется она бесплатно (если не считать оплату специалисту который этим займется), а регулярно ее обновлять дешевле чем оплачивать программиста, который будет ее переписывать.
SuhoffGV
Порой переписывать совсем невозможно (нецелесообразно). Если в компании используется сильно переписанная типовая конфигурация, например на базе КА1 или УТ10. Та же свежая Комплексная автоматизация 2 отличается от версии 1.1 как подлодка от жигулей.
DimmiSfai
Обновиться все таки дешевле (тем более, что львиная доля этих переписок оказывается не нужна при более глубоком анализе), чем платить взломщикам, шифровальщикам и программистам которые нужны на каждый чих. Особенно если взлетят расширения, с которыми можно без проблем обновлять и сильно переписанные конфигурации.
SuhoffGV
Месье теоретик? «Обновите» ка КА1.1 на КА2, с учетом что в КА1.1 клиентом дописано процентов 15 уникального функционала (для учета специфики своей отрасли) которого нет и никогда не будет ни в КА11 ни в КА2.
DimmiSfai
Я как раз практик, мне за такие обновления деньги платят, а вот откуда вы взяли, что это не возможно, очень интересно.
SuhoffGV
Я ведь не зря уточнил что «нецелесообразно». Технически, возможно переписать любые доработки в любую конфу. Но зачем?
nett00n
Мсье, похоже, никогда не настраивал веб-базы 1С =)
Первая проблема, с которой столкнётся мсье — это «зависающие» лицензии 1С, пользователь открыл базу в соседнем табе — минус одна лицензия, польхзователь перезапустил базу — минус ещё лицензия
Вторая проблема — внешние обработки.
Третья проблема — общая «адекватность» работы через веб-клиент (частично лучше работает тонкий клиент 1с)
И несть аким проблемам числа.
DimmiSfai
О боже, с чем то у кого то бывают проблемы. Ну тогда это не возможно.
Foggy4
Может там у них 7.7 до сих пор стоит.