А Вы уточните, какая была настройка OpenVPN, если это TCP, то двойная упаковка tcp приводит к удвоению рукопожатий, поэтому предпочтительней udp. Но не все его ум ют готовить, тот же микротик до сих пор реализует только tcp.
Так политика-то такая у зимбры по-умолчанию. Год назад работал в банке, там пин-код на токен менялся вообще каждый месяц, токен предназначался для авторизации в домене. Тоже бегали разблокировали вместе с безопасницей). А политика по-умолчанию в АД — менять пароль каждые 60 (?) дней.
У зимбры недопиленный клиент, он не подгружает контакты, приходится пользоваться веб-клиентом. Не знаю по какой причине он в браузере запрашивается в каждом случае, но по крайней мере в случае, когда пароль меняется по требованиям политики раз в три месяца. Пароль сменили, а на какой — не помнят. Чего то набирают, раз, два, три — звонок о помощи, в админке — блокировка.
В бан учетку бедного пользуна, забывшего в понедельник свой пароль, она отправляет надёжно, а вот адрес компьютера редко. У нас целые филиалы так иногда попадают, да, это неудобно, но зато можно зимбре довериться. (тьфу-тьфу, чтоб не сглазить). :)
Зимбра (постфикс) в таких случаях с настройками по-умолчанию блокирует учётную запись. А ещё она любит выдавать «ошибку сети», которая на самом деле репрезентует попадание адреса источника в блэклист, откуда его вытаскивают прописью в белом списке.
А что за сервер был? И в домене была отключена политика сложности пароля? Хотя да, конкретно для важняка можно её и отключить, он же нервничает и его все время забывает!)
Мне это кажется невероятным. Все известные мне серверы обеспечивают достаточно надёжную политику — политику сложности пароля, защита от подбора пароля и т.п. А ещё надо угадать и «логин»! В случае трёх неудачных попыток аутентификации учётная запись блокируется или на определенный срок, или до вмешательства администратора. Другое дело, если используют уязвимости в самом сервисе.
Релей поможет для отправки почты, а для приема почты от ddos ничего не поможет, разве что кроме замены оборудования на более мощное и применения балансиров? Потому что у всех контрагентов предприятия, известных или потенциальных, есть адрес, указанный на корпоративном сайте. Зловреды потом отстанут, и придется снова своих клиентов как то уведомлять.
И я не понял, на релее нужно для каждой учётной записи корпоративного почтового сервера тоже создавать учётки?
Ещё Вы пишете об «авторизации на сервере», это правильный в данном случае термин, или все же речь идёт об аутентификации?
Спасибо.
Я так понял, что очереди возникают из-за превышения возможностей роутера вследствие атак на почтовый сервер с множества адресов в целях вызвать отказ в обслуживании. Маршрутизатор и форвардит запросы на почтовый сервер, ведь почтовый не сам смотрит прямо в интернет.
А провайдеры типично блокируют именно входящий трафик на порт 25?
И что значит «эти хосты /релеи/ появляются каждый раз, когда нерадивый админ поднимает почтовый сервер»? Админы не хотят отправлять почту непосредственно от своего mta, а вместо этого специально заводят сервер-посредник? Зачем?
Проведен, конечно, молодец, но он почему-то озабочен только действиями американского правительства. Есть ли у него какие-либо данные по ситуации в России?
Да обсуждаем сейчас проблему очередей в маршрутизаторе, в итоге не отправляется и не доставляется почта. Нужно быстрое решение, а релей ещё надо развернуть, и поможет ли это в данном случае? Встречаются инструкции по смене порта, например, здесь wiki.zimbra.com/wiki/Adding_additional_SMTP_listener_ports
Возникает вопрос — в каких случаях это делается?
Если инициатором соединения является сервер, у которого сменен порт, сервер назначения сможет установить его по smtp-протоколу и отправить почтовое сообщение, если сервер-отправитель указал свой нестандартный порт?
Ещё часто можно встретить упоминания, что порт 25 является «устаревшим», по отношению к чему он «устарел»? И что делать, если провайдер блокирует порт 25/tcp, опять-таки обычно на исходящие или входящие?
Полезная статья, спасибо. Расскажите, пожалуйста, поподробнее, если можно, про протокол обмена между серверами. Стандартный порт для подключения 25, а можно ли его сменить, например, на 2525, будет ли при этом установлено соединение между сервером, сменившим этот порт, и сервером назначения, будет ли выполняться отправка и получение почты, или эта настройка только для почтовых клиентов? Даже в англоязычной Вики описывается процесс общения по smtp только между клиентом и сервером. В этой части у меня большой пробел.
Спасибо.
Wannacry это уже больше к host-based defence, хотя есть еще ips и антивирусы в почтовых серверах. Но вот автор среди пострадавших перечисляет такие vpn: Pulse Secure «Connect» VPN (CVE-2019-11510), the Fortinet FortiOS VPN (CVE-2018-13379), and Palo Alto Networks «Global Protect» VPN (CVE-2019-1579), посмотрел, в основном в них реализован OpenVPN, в одном есть ещё и remote IPSec. OVPN подразумевает сертификаты и пароли как к самим сертификатам, так и к подключению пользователя ppp. Вроде бы попробуй пройди, но атаки велись с использованием уязвимостей в самих программных реализациях, которые разные в каждой линейке и операционной системе. Например, уязвимость CVE-2019-1579 в ОС Pan-OS роутера "… may allow an unauthenticated remote attacker to execute arbitrary code". И.е. хакер не стремится пройти аутентификацию и авторизацию, он находит такой программный кусок, который позволяет ему выполнить его произвольный код.
Teamviewer для небольших организаций плох ещё и тем, что для корпоративного использования спрашивает от 2к рублей ежемесячно. «Бесплатные» варианты я не обсуждаю.). В этом плане chrome remote desktop выигрывает. Кроме того, не контролируется вход (хотя есть возможность организовать сеть из доверенных хостов), возможна компрометации логина-пароля и т.д. а собственный vpn-сервер уже встроен. OASA от Okta все это умеет. Но проблема в том, что когда автор описывает преимущества технологии, он применяет ее для облачного инстанса. Есть и плюшки — услуга у амазона бесплатна, если не превышать определенный порог вычислительных мощностей (количество запросов, время и трафик). Непонятно, как это организовать для сети предприятия. Никакой провайдер интернета услуги ротации публичных адресов не предоставляет, кроме фиксированного пула статических. И хоть один статический нужен, если существует связь с филиалами, значит, мишень для хакеров остаётся. Поправьте меня, если я что-то неправильно понимаю.
Аргумент автора, что причиной уязвимости vpn является неправильная его настройка, вообще рассматриваться не может — нечего экономить на квалифицированном персонале и аудите.
Ещё я встретил упоминание в статье, что чаще всего админы используют организацию vpn-доступа типа мост, хотя это вряд ли. Через бридж червям проще пробираться к хостам в доверенной сети. Если брать пример ASA, то мобильный клиент или clientness получают не всю сеть, а только опубликованные для данного пользователя приложения или другие ресурсы. Есть много препятствий для того, чтобы VPN "умер", хотя решение, предлагаемое автором, интересное и представляет собой этакую эшелонированную защиту.
Так можно делать, но требуются небольшие раз'яснения.
VPN, а какой конкретно (remote ssl, remote ipsec, openvpn, etc) и какой способ аутентификации используется? Если ipsec, то встречаются ли проблемы преодоления nat, и вообще, какой шлюз доступа в Вашей организации?
Настроенный, а параметры подключения и аутентификации как сохраняются на образе livecd usb после перезагрузки? Я имею в виду, что обычно livecd, даже есть он на флэшке, это неизменяемый образ, поэтому интересно, как у Вас конкретно реализовано сохранение вносимых в процессе работы (тот же ввод параметров) изменений.
Какой уровень безопасности установлен в Вашей организации, работает ли она с персональными данными, есть ли безопасности и как они относятся к этому способу мобильного подключения?
Классически из зоны DMZ нет доступа в доверенную сеть. Пример — та же Cisco ASA с ее зонами, из зоны dmz нельзя попасть в зону inside, если иное не прописано в листе доступа, и назначение зоны DMZ это обычно предоставление услуг типа веб-сервера внешним посетителям, часто безо всякой аутентификации.
И я не понял, на релее нужно для каждой учётной записи корпоративного почтового сервера тоже создавать учётки?
Ещё Вы пишете об «авторизации на сервере», это правильный в данном случае термин, или все же речь идёт об аутентификации?
Я так понял, что очереди возникают из-за превышения возможностей роутера вследствие атак на почтовый сервер с множества адресов в целях вызвать отказ в обслуживании. Маршрутизатор и форвардит запросы на почтовый сервер, ведь почтовый не сам смотрит прямо в интернет.
А провайдеры типично блокируют именно входящий трафик на порт 25?
И что значит «эти хосты /релеи/ появляются каждый раз, когда нерадивый админ поднимает почтовый сервер»? Админы не хотят отправлять почту непосредственно от своего mta, а вместо этого специально заводят сервер-посредник? Зачем?
Возникает вопрос — в каких случаях это делается?
Если инициатором соединения является сервер, у которого сменен порт, сервер назначения сможет установить его по smtp-протоколу и отправить почтовое сообщение, если сервер-отправитель указал свой нестандартный порт?
Ещё часто можно встретить упоминания, что порт 25 является «устаревшим», по отношению к чему он «устарел»? И что делать, если провайдер блокирует порт 25/tcp, опять-таки обычно на исходящие или входящие?
Спасибо.
Аргумент автора, что причиной уязвимости vpn является неправильная его настройка, вообще рассматриваться не может — нечего экономить на квалифицированном персонале и аудите.
Ещё я встретил упоминание в статье, что чаще всего админы используют организацию vpn-доступа типа мост, хотя это вряд ли. Через бридж червям проще пробираться к хостам в доверенной сети. Если брать пример ASA, то мобильный клиент или clientness получают не всю сеть, а только опубликованные для данного пользователя приложения или другие ресурсы. Есть много препятствий для того, чтобы VPN "умер", хотя решение, предлагаемое автором, интересное и представляет собой этакую эшелонированную защиту.
Так можно делать, но требуются небольшие раз'яснения.
Классически из зоны DMZ нет доступа в доверенную сеть. Пример — та же Cisco ASA с ее зонами, из зоны dmz нельзя попасть в зону inside, если иное не прописано в листе доступа, и назначение зоны DMZ это обычно предоставление услуг типа веб-сервера внешним посетителям, часто безо всякой аутентификации.