Comments 87
Бухгалтеры могут заходить из дома по RDP на сервер для удаленной работы в 1С
Вот зачем им это? На работе работы мало? А голый RDP наружу выставлять — ССЗБ.
Кстати, а как решался вопрос с клиентскими лицензиями? Каждые 90 бухи дней чистили реестр от временных лицензий?
Вот зачем им это? На работе работы мало?
Например, отпуск или болезнь + внезапная задача.
Вот зачем им это? На работе работы мало?
Внезапно: подавляющее число бухгалтеров — женского пола. Внезапно-2: у них вполне себе могут быть дети/родители, которые вполне себе могут заболеть, а оставить их не с кем. Внезапно-3: временами из дома работать ЗНАЧИТЕЛЬНО удобнее, нежели из офиса.
У меня (пока) Всё ;)
Внезапно: подавляющее число бухгалтеров — женского пола. Внезапно-2: у них вполне себе могут быть дети/родители, которые вполне себе могут заболеть, а оставить их не с кем. Внезапно-3: временами из дома работать ЗНАЧИТЕЛЬНО удобнее, нежели из офиса.
У меня (пока) Всё ;)
Вопрос с RDP лицензиями решается одним патченным файлом.
А зачем вообще сотруднику с такими обязанностями протирать штаны в офисе?
Я бы спросил зачем им RDP если бухгалтерия 1Сная уже пару лет может публиковаться на веб сервере двумя кликами (IIS тот же везде есть) и работать с ней можно через веб клиент или веб морду. Пароль на сайт, пароль на логин в базу и все…
может дороже, или потому, что админ приходящий и ему нет желания заниматься лишней работой?
Настройка всего минут 10 займет, и справится даже эникей по мануалу в 1 страницу. Единственный вариант, древняя версия бухгалтерии которая такого не умеет, но это уже самодурство, т.к. обновляется она бесплатно (если не считать оплату специалисту который этим займется), а регулярно ее обновлять дешевле чем оплачивать программиста, который будет ее переписывать.
Порой переписывать совсем невозможно (нецелесообразно). Если в компании используется сильно переписанная типовая конфигурация, например на базе КА1 или УТ10. Та же свежая Комплексная автоматизация 2 отличается от версии 1.1 как подлодка от жигулей.
Обновиться все таки дешевле (тем более, что львиная доля этих переписок оказывается не нужна при более глубоком анализе), чем платить взломщикам, шифровальщикам и программистам которые нужны на каждый чих. Особенно если взлетят расширения, с которыми можно без проблем обновлять и сильно переписанные конфигурации.
Мсье, похоже, никогда не настраивал веб-базы 1С =)
Первая проблема, с которой столкнётся мсье — это «зависающие» лицензии 1С, пользователь открыл базу в соседнем табе — минус одна лицензия, польхзователь перезапустил базу — минус ещё лицензия
Вторая проблема — внешние обработки.
Третья проблема — общая «адекватность» работы через веб-клиент (частично лучше работает тонкий клиент 1с)
И несть аким проблемам числа.
Первая проблема, с которой столкнётся мсье — это «зависающие» лицензии 1С, пользователь открыл базу в соседнем табе — минус одна лицензия, польхзователь перезапустил базу — минус ещё лицензия
Вторая проблема — внешние обработки.
Третья проблема — общая «адекватность» работы через веб-клиент (частично лучше работает тонкий клиент 1с)
И несть аким проблемам числа.
Может там у них 7.7 до сих пор стоит.
… удаленный доступ лучше организовать по VPN и использовать токен дополнительно к паролю. Затрат это практически не потребует, а защищенность вырастет порядочно…
Токены не бесплатны(аля securid), теряются и лочатся. Имхо лучше через сертификат на локальную машину.
Токены не бесплатны(аля securid), теряются и лочатся. Имхо лучше через сертификат на локальную машину.
Не могу согласиться. Хранение сертификата на локальной машине — это, по сути, то же самое, что оставленные в портах USB токены. Это распространенная практика у бухгалтеров и большое подспорье хакерам, которые выводят деньги со счетов компаний через банк-клиент.
Токен стоит недорого, для юрлица и вовсе копейки. В том же Китае законодательно запрещен доступ в интернет-банк без аппаратного токена даже для физлиц. Китайцы привыкли и давно этому не удивляются. Определенно, это существенно повышает безопасность удаленного доступа к системе ДБО. Возможно, нашему ЦБ тоже стоило бы об этом подумать.
Токен стоит недорого, для юрлица и вовсе копейки. В том же Китае законодательно запрещен доступ в интернет-банк без аппаратного токена даже для физлиц. Китайцы привыкли и давно этому не удивляются. Определенно, это существенно повышает безопасность удаленного доступа к системе ДБО. Возможно, нашему ЦБ тоже стоило бы об этом подумать.
Главное, чтобы токены не глючили из-за своей дешёвости.
При низком качестве изделий, как правило целые серии подвержены разного рода дефектам и болезням.
Представляю ситуацию, когда человеку надо срочно сделать платёж, но благодаря не к месту сдохнувшему токену, он побегает, попортит себе нервы и возможно даже попадёт на проценты за просрочку. И непременно поделится своим негативным опытом с окружающими. А организация при частом отмирании токенов, также скорее всего понесёт убыток.
При низком качестве изделий, как правило целые серии подвержены разного рода дефектам и болезням.
Представляю ситуацию, когда человеку надо срочно сделать платёж, но благодаря не к месту сдохнувшему токену, он побегает, попортит себе нервы и возможно даже попадёт на проценты за просрочку. И непременно поделится своим негативным опытом с окружающими. А организация при частом отмирании токенов, также скорее всего понесёт убыток.
Ситуация аналогична глючащему в других местах онлайн-банкингу: если организация экономит на системе онлайн-банкинга (подвисает сайт/не отправляются смс/ломаются физ. токены) — то компания теряет клиентов. И обеспечить достаточную надежность токенов ИМХО не намного сложнее чем надежность любой другой части системы.
Есть и бесплатные реализации софта для двойной аутентификации (не супер-секьюрные конечно, но вполне годные для небольшой компании). Пример — google authentificator + LinOTP.
А причём тут 1С?
Злоумышленники целенаправленно охотятся именно на базы 1С.
Это такой признак -«Лох, заплатит?»
Троянец отслеживает активность пользователя в следующих приложениях:
* 1С версии 8;
* 1С версии 7 и 7.7;
...
Название трояна — Trojan.PWS.Spy.19338
А почему не включены во втором случае политики безопасности AD, которые блокируют учётную запись после определённого количества неверных вводов пароля?
Эта политика действительно зачастую считается лучшей практикой, но по моему опыту зачастую создает больше проблем, чем пользы. При массовом бруте учеток они также массово блокируются, парализуя работу ИТ-инфраструктуры. Если есть возможность, лучше фиксировать факт перебора и устранять его причину.
Типа, DMZ без включения серверов в домен?
При массовом бруте учеток они также массово блокируются
Именно поэтому такую политику нужно дополнять скриптами на уведомление ответственных лиц о блокировке той или иной учетки. Да и пусть учетка лучше заблокируется, чем падет жертвой брут-форса.
В энтерпрайзе это решается мониторингом и правилами на SIEM. У меня был кейс у одного из заказчиков, когда политика блокировки учеток в AD привела к полному параличу компании на несколько дней (что-то около 1500 сотрудников отдыхало). Случилось вирусное заражение. Вирус смог выгрузить список всех учеток в AD и начал их брутить по кругу. Заблокировалось всё. Компания переезжала на новую ИТ-инфраструктуру в это время, что добавило хаоса.
Так что тут надо взвесить все за и против.
Так что тут надо взвесить все за и против.
Из своей админской юности: резервные копии (настоящие резервные копии, а не архивы «для скорости») должны писаться на неперезаписываемые носители. Да-да, на обычные болванки. Только отсутствие физической возможности «стереть» гарантирует, что данные не перезатрут случайно. Да, постепенно размер хранилища растёт, но, в отличие от большинства СХД, складское хранение отлично делает scale out — закончилась одна коробка, начинаем следующую.
Когда я уходил, было около 300кг бэкапов (начинали ещё задолго до моего прихода и продолжили после).
Когда я уходил, было около 300кг бэкапов (начинали ещё задолго до моего прихода и продолжили после).
Не было проблем с порчей дисков со временем? Время жизни CD-R, как подсказывает google, что-то между 2-5 лет, даже если он в коробке лежит.
Зависит от бренда. Ноунеймы дохнут быстро, качественные болванки живут 10+ лет. На самом деле никого не интересует живость данных пятилетней давности, всех интересует, чтобы предыдущий бэкап БЫЛ. Перезаписываемые медиа сильно рискуют быть перезаписанными. Записанные и верифицированные болванки (была такая обязательная процедура) рискуют быть только уничтоженными физическими мерами, а с этим, на удивление, проще бороться. Положили бэкап и заклеили бумагой с печатью. Всё, все «случайно» отметаются при этом.
Болванки при этом не отменяют электронный бэкап (он быстрее и доступнее), но являются финальным fail-safe.
Болванки при этом не отменяют электронный бэкап (он быстрее и доступнее), но являются финальным fail-safe.
UFO just landed and posted this here
Сейчас трэнд такой: Бэкапы складывать в облако.
1с продвигает свой сервис бэкапов встроенный в 1с, но он требует монопольного доступа к базе на время бэкапа. Поэтому я использую для файловых версий копирование папки с базой, в отдельную папку при этом на чтение файл/файлы баз доступны и копию можно снять в любой момент, затем копия папки архивируется, кладется в папку где автоматически настроена синхронизация.
Допустим с дропбоксом, почему с дропбоксом? потому что он поддерживает даже в бесплатных аккаунтах хранения истории файлов, соответственно если базы например 2: торговля и бухгалтерия архивы, которых занимают около 1гб, в один момент хранится 2 копии базы на физическом хранилище. И даже при удалении из физического хранилища по истории можно поднять около 20 последних версий файла бэкапа в веб интерфесе.
Яндекс диск яндекс диск ты где сделай уже эту штуку, 2гб все таки маловато для хранения бэкапов, а вот была бы у яндекса история хранения файлов, как в дропбоксе, сразу бы забросил свой 20гб аккаунт дропа.
Единственная оговорка, как показали последние события, посыпая голову пеплом, при получении доступа к рдп сервера, ребята уже не просто шифруют все подряд, а смотрят куда делаются бэкапы и удаляют учетные записи дропбокса если по глупости, моей они запущены на этом же сервере.
Плюс у дропа совершенно не вменяемая поддержка для халявщиков типа меня, пишеш им так мол и так, все что в факе сделал, не могу тото и тот, и все что в инструкции сделал. А они через сутки спрашивают, сделали ли я все что в факе, а затем просто игнорят.
Соответственно чтобы обезопасить себя, необходимо делать файловое хранилище, куда будут складываться копии папок на отдельный сервер и уже на этом хранилище будут в не расшареные папки кластся архивы, но при этом нужно обозначить что сам сервер с бэкапами в отличии от терминального сервера должен быть, неприступен. Думаю даже роутер с флэшкой подойдет для этой задачи.
Это я рассматриваю самые экономные задачи. Для внедрения, естественно намного лучше делать впн с токенами итп, но мелкий бизнес не готов тратить деньги на это, а я время поскольку для меня это просто сопутствующая задача.
Для скл версии добавлю только один момент с 2008 версии сам скл поддерживает архивирование своих bak файлов, и их можно сразу складывать в папку для синхронизации с облаком. Не используя внешнию тулзы. Единственно что скорее всего bak файл в дропбокс у вас уже не получится?
1с продвигает свой сервис бэкапов встроенный в 1с, но он требует монопольного доступа к базе на время бэкапа. Поэтому я использую для файловых версий копирование папки с базой, в отдельную папку при этом на чтение файл/файлы баз доступны и копию можно снять в любой момент, затем копия папки архивируется, кладется в папку где автоматически настроена синхронизация.
Допустим с дропбоксом, почему с дропбоксом? потому что он поддерживает даже в бесплатных аккаунтах хранения истории файлов, соответственно если базы например 2: торговля и бухгалтерия архивы, которых занимают около 1гб, в один момент хранится 2 копии базы на физическом хранилище. И даже при удалении из физического хранилища по истории можно поднять около 20 последних версий файла бэкапа в веб интерфесе.
Яндекс диск яндекс диск ты где сделай уже эту штуку, 2гб все таки маловато для хранения бэкапов, а вот была бы у яндекса история хранения файлов, как в дропбоксе, сразу бы забросил свой 20гб аккаунт дропа.
Единственная оговорка, как показали последние события, посыпая голову пеплом, при получении доступа к рдп сервера, ребята уже не просто шифруют все подряд, а смотрят куда делаются бэкапы и удаляют учетные записи дропбокса если по глупости, моей они запущены на этом же сервере.
Плюс у дропа совершенно не вменяемая поддержка для халявщиков типа меня, пишеш им так мол и так, все что в факе сделал, не могу тото и тот, и все что в инструкции сделал. А они через сутки спрашивают, сделали ли я все что в факе, а затем просто игнорят.
Соответственно чтобы обезопасить себя, необходимо делать файловое хранилище, куда будут складываться копии папок на отдельный сервер и уже на этом хранилище будут в не расшареные папки кластся архивы, но при этом нужно обозначить что сам сервер с бэкапами в отличии от терминального сервера должен быть, неприступен. Думаю даже роутер с флэшкой подойдет для этой задачи.
Это я рассматриваю самые экономные задачи. Для внедрения, естественно намного лучше делать впн с токенами итп, но мелкий бизнес не готов тратить деньги на это, а я время поскольку для меня это просто сопутствующая задача.
Для скл версии добавлю только один момент с 2008 версии сам скл поддерживает архивирование своих bak файлов, и их можно сразу складывать в папку для синхронизации с облаком. Не используя внешнию тулзы. Единственно что скорее всего bak файл в дропбокс у вас уже не получится?
Супер. И как это спасёт от удаления аккаунта, воровства пароля или других айтишных глупостей? Оффлайновый бэкап на неизменяемые носители нельзя заменить онлайновыми волатильными технологиями.
воровства пароля от логина с двухфактурной авторизацией?
удаление аккаунта, если есть почта к которой привязан номер телефона?
Просто вся схема должна быть.
Как и ваша схема с кучей болванок, сервис для бэкапов должен работать, cd-rw привод должен работать, админа не должны обижать чтобы он сам не оставил для себя бэкдор, это общий правила, реализация на текущий момент не требует физичиских носителей в чистом виде, даже я для большой розничной сети бэкапы на ленту ни разу не восстанавливал, в виду того что сервер зеркалировался в азуре и при его поломке просто поднималась его копия.
Это я к тому, что болванки это уже не круто, этом может стать круто если резко пропадет весь интернет.
Но тогда и риски для которых делаются облачные бэкапы также станут не актуальными.
удаление аккаунта, если есть почта к которой привязан номер телефона?
Просто вся схема должна быть.
Как и ваша схема с кучей болванок, сервис для бэкапов должен работать, cd-rw привод должен работать, админа не должны обижать чтобы он сам не оставил для себя бэкдор, это общий правила, реализация на текущий момент не требует физичиских носителей в чистом виде, даже я для большой розничной сети бэкапы на ленту ни разу не восстанавливал, в виду того что сервер зеркалировался в азуре и при его поломке просто поднималась его копия.
Это я к тому, что болванки это уже не круто, этом может стать круто если резко пропадет весь интернет.
Но тогда и риски для которых делаются облачные бэкапы также станут не актуальными.
Бэкдора на болванках не бывает, это раз. Сломавшийся привод — это всего лишь поломка оборудования и меняется на равных основаниях с любыми другими устройствами, это два.
Если вы никогда не делали в своей жизни Большой Ошибки «промахнувшись сервером» — ну, повезло. Не всем везёт.
Упор не на слово «болванки», а на слово «неизменяемый носитель». Если бы лента была бы write once, я бы её так же любил бы.
Если вы никогда не делали в своей жизни Большой Ошибки «промахнувшись сервером» — ну, повезло. Не всем везёт.
Упор не на слово «болванки», а на слово «неизменяемый носитель». Если бы лента была бы write once, я бы её так же любил бы.
бэкдоры оставляют себе сами админы, или вредоносный софт принесеный из интернета или с внешних носителей, ну или сама политика безопасности или ее отстутсвие может быть бэкдором, как примеры описанные в статье.
Я делал слишком много ошибок в своей жизни, чтобы пропустить эту статью и не начать рассказывать про свой опыт.
Я просто хочу сказать, что неизменяемый носитель не лучше, а скорее хуже чем текущие облачные решения. При достаточно быстром канале и грамотной настройке, система работает сама и не требует вмешателства. Только контроль. А про болванке я приведу вам пример. Предположим приезжает ОБЭП описывать сервера, что происходит у меня. Я обьяснять вам не буду.
Но что произойдет у вас со всеми этими килограммами дисков и не перезаписываемых носителей, а так же как человек, который в буквальном смысле делал обыск скажу, что многие данные лежат в организациях в чистом виде, копия базы снятая бухгалтером на рабочий стол, диск забытый в столе компьютера с подписью март 2015 БП, ООО «АЛЬФА», или коробка поломанных флэшек в пустой серверной могут дать достаточно для того чтобы пропукаться всем.
Понятно что ОБЭП это не тот, риск который мы тут обсуждаем, но лишние данные это ЛИШНИЕ данные.
Я делал слишком много ошибок в своей жизни, чтобы пропустить эту статью и не начать рассказывать про свой опыт.
Я просто хочу сказать, что неизменяемый носитель не лучше, а скорее хуже чем текущие облачные решения. При достаточно быстром канале и грамотной настройке, система работает сама и не требует вмешателства. Только контроль. А про болванке я приведу вам пример. Предположим приезжает ОБЭП описывать сервера, что происходит у меня. Я обьяснять вам не буду.
Но что произойдет у вас со всеми этими килограммами дисков и не перезаписываемых носителей, а так же как человек, который в буквальном смысле делал обыск скажу, что многие данные лежат в организациях в чистом виде, копия базы снятая бухгалтером на рабочий стол, диск забытый в столе компьютера с подписью март 2015 БП, ООО «АЛЬФА», или коробка поломанных флэшек в пустой серверной могут дать достаточно для того чтобы пропукаться всем.
Понятно что ОБЭП это не тот, риск который мы тут обсуждаем, но лишние данные это ЛИШНИЕ данные.
Никакой бэкдор не может испортить записанный на -R болванку бэкап. При чём тут бэкдор, вообще?
ОБЭП к сохранности данных никак не относится, и для решения этой проблемы есть во-первых 9.5 правил ведения бизнеса в РФ, а во-вторых шифрование.
ОБЭП к сохранности данных никак не относится, и для решения этой проблемы есть во-первых 9.5 правил ведения бизнеса в РФ, а во-вторых шифрование.
Никакой админ не может испортить записанный на R болванку бэкап? Никакой пожар не может испортить коллекцию болванок? бэк дор = задняя дверь. т.е. инструмент получения доступа к данным минуя официальные главные двери.
Я с вами согласен я не спорю, я просто в реализации вашего примера добавил лет 15 прогресса. 9.5. правил не опровергают ни ваш ни мой вариант реализации резервного копирования.
Я с вами согласен я не спорю, я просто в реализации вашего примера добавил лет 15 прогресса. 9.5. правил не опровергают ни ваш ни мой вариант реализации резервного копирования.
Такая лента бывает, называется WORM (write once, read many).
>а безалаберность или ошибки самих администраторов
Или начальства, например. Которое не всегда хочет слушать администраторов, а топает ножками и кричит «Я не хочу такой сложный пароль», «я не хочу менять пароль раз в N-месяцев», «Я не хочу покупать жетские диски для резервных копий, у меня денег нет» и т.п.
Или начальства, например. Которое не всегда хочет слушать администраторов, а топает ножками и кричит «Я не хочу такой сложный пароль», «я не хочу менять пароль раз в N-месяцев», «Я не хочу покупать жетские диски для резервных копий, у меня денег нет» и т.п.
Тяжело не согласиться. В конечном итоге руководство организации несет ответственность вообще за все в компании. Ответственность не делегируется, как известно. И обычно, пока гром не грянет, никто ничего по части информационной безопасности и DR не делает. И это касается не только мелких компаний.
Вот вот вот!!!
У нас как то уволили админа которые заставил делать, сложные пароли.
У нас как то уволили админа которые заставил делать, сложные пароли.
У нас другим путём пошли: «СложныйПароль1116». И всё. Меняй себе циферки. И хрен что людям объяснишь.
Это большая проблема, кстати. Формальное удовлетворение требованиям стойкости пароля и реально стойкий пароль — совершенно разные вещи. Решения могут быть разные.
В ряде систем при вводе нового пароля идет проверка на словарность. В случае с классическим AD иногда администраторы ИБ сами проводят брут паролей по их хешам на регулярной основе. Для этого хеши выгружаются на выделенную машину без доступа по сети, которую берегут как зеница око, чтобы не дай бог кто-то к ней не получил доступа.
Если пользователи не получают по шее за пароли вроде «M@sha123», то все это, разумеется, становится бесполезным.
В ряде систем при вводе нового пароля идет проверка на словарность. В случае с классическим AD иногда администраторы ИБ сами проводят брут паролей по их хешам на регулярной основе. Для этого хеши выгружаются на выделенную машину без доступа по сети, которую берегут как зеница око, чтобы не дай бог кто-то к ней не получил доступа.
Если пользователи не получают по шее за пароли вроде «M@sha123», то все это, разумеется, становится бесполезным.
Безалаберность страшная сила. Как-то искал документы гуглом по ключевым словам. Выскочила ссылка на ФТП. Оказалось это был ФТП для обмена файлами в организации (территориально значительно разобщенная контора). Бухгалтерская отчётность (и прочая), документы для служебного пользования, даже фотки с телефона замдиректора. Нашёл в штатном расписании контакты их сисадмина, связался, быстренько поправили. Конечно ничего сверхсекретного там не было, но если бы наткнулись какие гбшники наши, то по шапке получили бы знатно.
В эпоху расцвета файлообменных DC сетей и взламывать ничего не надо было.
Мама на компе иногда работает работу. Логины и пароли хранит в папке в моих документах или на рабочем столе в папке «Флешка с работы»
Дите ставит DC расшаривает диск Ц всем и все. Нате пользуйтесь. Никакой секурити аудит не найдет откуда была утечка.
Один раз был даже случай. Наткнулся так на кучу документов одной фирмы, которые были клиентами по IT знакомых франчайзи\аутсорсеров. Из анализа было видно, что юрист взял домой поработать все что смог =))
Отсыпал им всего этого — они пришли, к директору и предложили провести секурити аудит или чето там такое.
Вообщем наверное поимели с этого профит или + в карму.
Другой раз нашел планы конкурентов по развитию рынка. Тоже была взята «работа на дом»
Мама на компе иногда работает работу. Логины и пароли хранит в папке в моих документах или на рабочем столе в папке «Флешка с работы»
Дите ставит DC расшаривает диск Ц всем и все. Нате пользуйтесь. Никакой секурити аудит не найдет откуда была утечка.
Один раз был даже случай. Наткнулся так на кучу документов одной фирмы, которые были клиентами по IT знакомых франчайзи\аутсорсеров. Из анализа было видно, что юрист взял домой поработать все что смог =))
Отсыпал им всего этого — они пришли, к директору и предложили провести секурити аудит или чето там такое.
Вообщем наверное поимели с этого профит или + в карму.
Другой раз нашел планы конкурентов по развитию рынка. Тоже была взята «работа на дом»
UFO just landed and posted this here
Доступ к 1С из дома очень нужная вещь, но нельзя «голую» винду выставлять на всеобщее обозрение. Доступ должен быть органзован через защищенные VPN IP-sec соединения. Контору, в которой я ранее работал и где был упрощён доступ, не давно так же взломали. Кончилось благополучно, но в следующий раз может уже и не повезти.
нельзя «голую» винду выставлять на всеобщее обозрение
Если очень хочется, то можно. Сам RDP в наше время достаточно стоек, и уязвимости в нем находят очень редко. Но, конечно, должна быть настроена политика блокирования учетной записи при переборе паролей, плюс уведомление IT-отдела о факте блокировки, плюс валидный сертификат у RDP-сервера, плюс обучение пользователей.
Не стал бы так рисковать и дело даже не в RDP. Сама Windows не являевляется безопастной системой. Лучше её «скрывать» за хорошими аппаратными или программными сетевыми экранами, которые будут защищать весь офис. Можно скачать готовую бесплатную сборку на основе Linux'a. Если нет отдельного компьютера, можно создать виртуальную машину и пропускать весь интернет трафик через неё. Вариантов много и всегда можно «выкрутится» даже если нет денег.
А без удалённого доступа сейчас тяжело — ни начальство с Кипра не может посмотреть, как идут дела, ни программиста 1С-ка не подлючишь, да и с VPN'ом можно все филиалы подключить к одной базе.
А без удалённого доступа сейчас тяжело — ни начальство с Кипра не может посмотреть, как идут дела, ни программиста 1С-ка не подлючишь, да и с VPN'ом можно все филиалы подключить к одной базе.
А су шествуют ли брелки тика флешки
на брелке 10 цифр 0-9. Вставил брелок, набрал мастер пароль. Защел на сайт и комбинацию 1047.
А брелок вводит 18-16 значный пароль ))
Вроде такую идею уже видел.
на брелке 10 цифр 0-9. Вставил брелок, набрал мастер пароль. Защел на сайт и комбинацию 1047.
А брелок вводит 18-16 значный пароль ))
Вроде такую идею уже видел.
Чем это принципиально отличается от вышеупомянутых токенов?
Пин-код вводится на стороне железного токена, а не в софте, для противодействия закладкам в клавиатуре или кей-логгерам.
Для противодействия кейлоггерам в токен вшит сертификат. Для противодействия краже сертификата — есть пин с требованиями по сложности. Так чем принципиально отличается от брелка, содержащего длинный пароль?
Ну хотя бы тем, что на таком брелке может быть зашито несколько паролей. Например один и тот же брелок передается буху в следующей смене. И каждый ходит под своим паролем.
На токен можно положить несколько контейнеров и к каждому будет свой пин. Все еще не вижу принципиальных различий.
Физический ввод пина, невозможность его отслеживания с компьютера. Не понял, как защитит сертификат от кейлоггера?
ну проблема здесь скорее в неспособности руководства обеспечить свою фирму хорошим админом, пусть даже и приходящим
Наверное, я и есть тот приходящий админ из 1 примера в аналогичной фирме)
У себя разобрался и внедрил многое — начиная от блокировки пользователей и сложных паролей, и заканчивая уведомениями на почту при появлении каких-то событий, политикой ограниченного использования программ, архивирование с сервака в облако и на другой комп в подсети, который доступен только для записи, но не для чтения (разве такой способ архивирования позволяет удалить записанный архив в случае компрометации самого сервера?). Короче все кроме VPN.
Буду очень благодарен, если кто нибудь предложит реализацию VPN, чтобы она была максимально проста в использовании со стороны клиента. Смотрел в сторону OpenVPN, но в этом случае на стороне клиентского компьютера необходимо ставить их софт. Есть ли альтернативы?
У себя разобрался и внедрил многое — начиная от блокировки пользователей и сложных паролей, и заканчивая уведомениями на почту при появлении каких-то событий, политикой ограниченного использования программ, архивирование с сервака в облако и на другой комп в подсети, который доступен только для записи, но не для чтения (разве такой способ архивирования позволяет удалить записанный архив в случае компрометации самого сервера?). Короче все кроме VPN.
Буду очень благодарен, если кто нибудь предложит реализацию VPN, чтобы она была максимально проста в использовании со стороны клиента. Смотрел в сторону OpenVPN, но в этом случае на стороне клиентского компьютера необходимо ставить их софт. Есть ли альтернативы?
Ответил на этот вопрос в ответ на ваше личное сообщение.
Если нет возможности ставить клиент, то можно посмотреть, например, в сторону RDP over HTTPS. Очень многие TeamViewer используют. Решений миллион. Но если, как вы писали, постоянно рвется соединение с офисом, то все это будет работать нестабильно. Экстремальный вариант: перенести сервер в облако.
Если нет возможности ставить клиент, то можно посмотреть, например, в сторону RDP over HTTPS. Очень многие TeamViewer используют. Решений миллион. Но если, как вы писали, постоянно рвется соединение с офисом, то все это будет работать нестабильно. Экстремальный вариант: перенести сервер в облако.
Спасибо за ответ.
Teamviewer имеет проблематичность использования, если его использовать коммерческим образом. Т.е. либо мучиться с заменами мак-адреса и переустанавливать его постоянно, либо покупать лицензию (от 250$ — сам я ее себе позволить не могу, а контора не понимает зачем платить за то что и так бесплатно работает).
Teamviewer имеет проблематичность использования, если его использовать коммерческим образом. Т.е. либо мучиться с заменами мак-адреса и переустанавливать его постоянно, либо покупать лицензию (от 250$ — сам я ее себе позволить не могу, а контора не понимает зачем платить за то что и так бесплатно работает).
А чем не устраивает SSTP VPN?
UFO just landed and posted this here
А почему в обоих примерах не указано, каким образом недоброжелатели выходили на RDP порт? У них что стандартные порты стояли и на шлюзе небыло кроссовых пробросов?
Да, торчали в интернет стандартные порты.
Ну это совсем края крайние! Это насколько надо быть ленивым и тупым, чтоб даже этого не сделать?
2 схожих случая и 2 одинаковые ошибки «приходящего» админа — слабые пароли
если бы пароли были бы сложные — шанс взлома сократился бы на порядок. сам сталкивался с подобной ситуацией и скажу, что схема классическая — «перебрать пароли, войти под слабым паролем бухгалтера Васи (потому что ему лень запоминать\записывать сложный пароль) и навредить жертве с последующим вымогательством (удаление\перенос\шифрование)»
если бы пароли были бы сложные — шанс взлома сократился бы на порядок. сам сталкивался с подобной ситуацией и скажу, что схема классическая — «перебрать пароли, войти под слабым паролем бухгалтера Васи (потому что ему лень запоминать\записывать сложный пароль) и навредить жертве с последующим вымогательством (удаление\перенос\шифрование)»
Кому интересно Описание подобного шифровальщика с методом проникновения
Sign up to leave a comment.
Кибершпана атакует бухгалтерию. Разбор случаев атак на базы 1С