ИТ Безопасность - Информационный портал Vectormm.net

Site to site соединение между NSX Edge и FortiGate

Thu, 28 Nov 2019 15:30:39 +0300

Настроим подключение Site to site между NSX Edge версии не ниже 6.3.5 и FortiGate версии не ниже 6.0.2

Используются следующие данные в данном примере настройки:

FortiGate public IP: 1.1.1.1
FortiGate local subnet: 192.168.1.0/24
NSX Edge public IP: 2.2.2.2
NSX Edge local subnet: 192.168.2.0/24

Создаем настройку VPN на стороне NSX Edge

Зайдите в консоль NSX и нажмите на Networking.
Нажмите на Edge Gateway, который Вы хотите подключить по VPN.
Нажмите на выпадающее меню Actions в правом верхнем углу и выберите IPSEC VPN.
Нажмите на Add Tunnel в окне конфигурации IPSEC VPN.
Введите наименование и описание тоннеля VPN.
Выберите внутренние подсети, подключенные к NSX Edge
и введите подсети со стороны FortiGate, которые будут доступны по VPN.
Выберите Local Endpoint, который будет подключен к NSX Edge.
Local ID это внешний IP адрес NSX Edge. Введите внешний Peer IP адрес от FortiGate.
Выберите Encryption Protocol (по умолчанию: AES256).
Введите Pre-Shared Key для VPN тоннеля. Укажите MTU (по умолчанию: 1500).
Нажмите на кнопку Add VPN Tunnel
и не забудьте поставить галочку Enabled. Нажмите Submit и ждите пока не появится зеленая галочка.
После этого нажмите на зеленую галочку для завершения настройки.

Настройка VPN на стороне FortiGate, через GUI

Создаем тоннель IPsec. Выбираем секцию VPN в левой колонке.
Выбираем IPsec Tunnels. Нажимаем на кнопку Create New вверху экрана.
Вписываем наименование VPN тоннеля. Выбираем Template Type как Custom.
Настраиваем VPN тоннель. Указываем внешний IP адрес со стороны NSX Edge. Отключите Local Gateway, Mode Config и NAT Traversal.
Установите Authentication Method в режим Pre-shared Key и введите его.
Установите IKE Version в 1. Установите Mode в Main.
Создайте Phase 1 Proposal с использованием AES256 иSHA1 с указанием Diffie-Hellman Group 14.
Установите Key Lifetime в 28800.
Создайте Phase 2 с локальной подсетью FortiGate в качестве Local Address и с локальной подсетью NSX Edge в качестве Remote Address.
Создайте Phase 2 Proposal с указанием AES256 иSHA1 с включенным PFS и указанием Diffie-Hellman Group 14.
Установите Key Lifetime в 3600.
Создайте статический маршрут для трафика VPN.
Выберите раздел Network в левой колонке. Выберите Static Routes.
Нажмите на кнопку Create New наверху экрана.
Настройте статический маршрут.
Введите Destination как целевую подсеть, подключенную со стороны NSX Edge в VPN тоннеле.
Установите Interface в интерфейс тоннеля, созданный ранее.
Установите Status в Enabled.
Создаем политику доступа для VPN трафика. Нажмите раздел Policy & Objects в левой колонке. Выберите IPv4 Policy.
Нажмите на кнопку Create New вверху экрана.
Настроим политику для входящего трафика VPN.
Введите наименование политики.
Выберите интерфейс, созданный ранее, как Incoming Interface.
Установите в качестве Outgoing Interface LAN порт FortiGate.
Установите в качествеSource подсеть со стороны NSX Edge с той стороны VPN тоннеля.
Установите в качестве& Destination локальную подсеть со стороны FortiGate.
Установите Service как ALL. Выберите Action как ACCEPT.
Отключите NAT.
Настроим политику для исходящего VPN трафика.
Введите наименование политики.
Укажите Incoming Interface как LAN порт FortiGate.
Установите в качестве Outgoing Interface интерфейс тоннеля, созданный ранее.
Выберите Source как подсеть со стороны FortiGate.
Установите в качестве Destination подсеть со стороны NSX Edge с той стороны VPN тоннеля.
Укажите Service как ALL.
Укажите Action как ACCEPT.
Отключите NAT.

Создание VPN тоннеля на FortiGate через CLI

Создаем объекты для локальной и удаленной подсетей.

config firewall address edit "local_subnet" set subnet 192.168.1.0 255.255.255.0 next edit "remote_subnet" set subnet 192.168.2.0 255.255.255.0 next end

Настраиваем Phase 1 для VPN тоннеля.

config vpn ipsec phase1-interface edit "VPN to NSX Edge" set interface "port1" set keylife 28800 set peertype any set proposal aes256-sha1 set dhgrp 14 set nattraversal disable set remote-gw 2.2.2.2 set psksecret [key] next end

Настраиваем Phase 2 для VPN тоннеля.

config vpn ipsec phase2-interface edit "VPN to NSX Edge" set phase1name "VPN to NSX Edge" set proposal aes256-sha1 set dhgrp 14 set keylifeseconds 3600 set src-subnet 192.168.1.0 255.255.255.0 set dst-subnet 192.168.2.0 255.255.255.0 next end

Создаем статический маршрут для VPN трафика.

config router static edit 2 set dst 192.168.2.0 255.255.255.0 set device "VPN to NSX Edge" next end

Создаем политики для входящего и исходящего VPN трафика.

config firewall policy edit 1 set name "vpn_inbound" set srcintf "VPN to NSX Edge" set dstintf "port2" set srcaddr "remote_subnet" set dstaddr "local_subnet" set action accept set status enable set schedule "always" set service "ALL" next edit 2 set name "vpn_outbound" set srcintf "port2" set dstintf "VPN to NSX Edge" set srcaddr "local_subnet" set dstaddr "remote_subnet" set action accept set status enable set schedule "always" set service "ALL" next end

Проверка статуса VPN подключения

Проверяем статус VPN подключения в консоли NSX:

Логинимся в консоль и нажимаем на Networking.
Нажмите на Edge Gateway Вашего VPN тоннеля.
Нажмите на выпадающее меню Actions в правом верхнем углу и выберите пункт IPSEC VPN.
Проверьте, что VPN тоннель находится в статусе Enabled и Tunnel Status находится в состоянии Up.

Проверяем статус VPN подключения на FortiGate через GUI:

Выберите раздел VPN в левой колонке. Нажмите на IPsec Tunnels.
Для Вашего VPN тоннеля в колонке Status должно быть написано Up.
Выберите раздел Policy & Objects в левой колонке.
Нажмите на IPv4 Policy. Вы должны видеть ранее созданные политики для Вашего VPN тоннеля.
Колонка Bytes показывает объем проходящего трафика, подпадающего под конкретное правило.
Нажмите на раздел Log & Report в левом меню.
Выберите пункт VPN Events. Вы увидите все события, относящиеся к VPN тоннелю.
Там должны присутствовать сообщения об успешных событиях Phase 1 иPhase 2 для этого VPN тоннеля.

Проверка статуса VPN подключения на FortiGate через CLI:

Проверка общего состояния VPN тоннеля на FortiGate.

FGVM01 # get vpn ipsec tunnel summary 'VPN to NSX Edge' 2.2.2.2:0 selectors(total,up): 1/1 rx(pkt,err): 756/0 tx(pkt,err): 756/0

Проверка детальной статистики VPN тоннеля на FortiGate.

FGVM01 # get vpn ipsec tunnel details gateway name: 'VPN to NSX Edge' type: route-based local-gateway: 1.1.1.1:0 (static) remote-gateway: 2.2.2.2:0 (static) mode: ike-v1 interface: 'port1' (3) rx packets: 765 bytes: 116280 errors: 0 tx packets: 765 bytes: 64260 errors: 0 dpd: on-demand/negotiated idle: 20000ms retry: 3 count: 0 selectors name: 'VPN to NSX Edge' auto-negotiate: disable mode: tunnel src: 0:192.168.1.0/255.255.255.0:0 dst: 0:192.168.2.0/255.255.255.0:0 SA lifetime/rekey: 3600/2959 mtu: 1438 tx-esp-seq: 2e7 replay: enabled inbound spi: 788f302f enc: aes-cb 93b1e0816f0bade22604838d02f14fe1a5e52a322a7074af9aca2cc008b9d785 auth: sha1 ffcc03adef239383fd30f498623cf8b7e94a3723 outbound spi: da92f5fe enc: aes-cb 4858c15a42c8dfda8833a631f26bd3b5da451ff857a7d733a6688fe614b5c16c auth: sha1 514b25f1ac83a1ef813dfb76064851e969a18693 SA lifetime/rekey: 3600/2917 mtu: 1438 tx-esp-seq: 18 replay: enabled inbound spi: 788f302e enc: aes-cb ea5ab3e2aa6d2796a621dd368e0a4fd9d6d65a13f698a4ca0d0cb7d328968b0d auth: sha1 7cdfd2a462ce6ff6d8cde6c50627cc39cc67ff8d outbound spi: a41c9f8e enc: aes-cb f71014a53e547923f49c0c917d77064391146dd4a2e6c467a9ee339895ade5e3 auth: sha1 9a08b103b4064ef14ddebc1c91131eb3022a9e75

Прохождение трафика через созданный VPN тоннель можно проверить с помощью пинга удаленного оборудования.

вебинар "Практические советы операторам при проверке соответствия обработки персональных данных требованиям законодательства РФ"

Fri, 20 Jul 2012 15:42:34 +0400

Для тех, кому интересно:

"Практические советы операторам при проверке соответствия обработки персональных данных требованиям законодательства РФ"

Блоги по Информационной безопасности

Thu, 03 May 2012 13:18:55 +0400

Может кому интересно будет, небольшая подборка блогов по ИБ:

http://infowatch.livejournal.com/

http://secinsight.blogspot.com/

http://lukatsky.blogspot.com/

http://www.tsarev.biz/

http://personal-data.livejournal.com/

http://anvolkov.blogspot.com/

http://avetjan.livejournal.com/

http://xpomob.blogspot.com/

http://shaurojen.blogspot.com/

http://sborisov.blogspot.com/

http://infowatch.livejournal.com/

http://secinsight.blogspot.com/

http://lukatsky.blogspot.com/

http://www.tsarev.biz/

http://personal-data.livejournal.com/

http://anvolkov.blogspot.com/

http://avetjan.livejournal.com/

http://xpomob.blogspot.com/

http://shaurojen.blogspot.com/

http://sborisov.blogspot.com/

Электронная торговля и ИБ

Mon, 26 Dec 2011 12:29:58 +0400

На данный пост меня сподвигла статья Евгения Царева "Как я использовал закон 152-ФЗ о персональных данных в реальной жизни или российский интернет-бизнес", а так же постоянно встречающиеся отрицательные отзывы покупателей по поводу "деанонимизации" при оформлении или возврате заказов.

В статье правильно указано на избыточность запрашиваемой информации при регистрации на сайте. Если следовать логике, то при регистрации на сайте электронного магазина вполне достаточно имени клиента, его контактного телефона и email адреса для различных маркетинговых манипуляций и информирования о состоянии заказов.

Адрес доставки потребуется только при собственно заказе, т.е. если человек ничего не заказывает, то и его адрес магазину совершенно не нужен.

В результате мы получаем достаточно информации для персонализации заказчика, но при этом никаким образом не контролируем правильность и не выдуманность его данных (в качестве имени можно указать "Вася Пупкин", телефонную карточку купить в переходе без паспорта, а email использовать любой временный. А при заказе указать совершенно любой адрес (ни что не мешает дождаться курьера, сидя на лавочке у дома рядом с метро).

В итоге получаем достаточную анонимность заказчиков, абсолютно не мешающую коммуникации между ними и продавцом.

Но!!!! Это если следовать общепринятой логике.

А теперь посмотрим, какие требования должны соблюдать продавец и покупатель, если опираться на нормы Закона 152-ФЗ:

Учитывая, что для продажи и доставки товаров и услуг конечному потребителю, все субъекты интернет-коммерции должны как-то идентифицировать клиента, все они могут попасть под определение оператора персональных данных, принятое в ФЗ-152: «...юридическое или физическое лицо, организующее и (или) осуществляющее обработку персональных данных, а также определяющее цели и содержание обработки персональных данных».

Проблемы электронной коммерции в терминах ФЗ-152

Если интернет-магазин является оператором персональных данных, то на него распространяются все обязанности, налагаемые законом:

- предоставить доказательство получения согласия субъекта на обработку его персональных данных;

- обработать персональные данные в целях продвижения товаров, работ, услуг на рынке путем осуществления прямых контактов с потенциальным потребителем с помощью средств связи можно только при условии предварительного согласия субъекта.

Итак, интернет-магазину надо доказать, что у него есть согласие конкретного физического лица, которое попросило предоставить ему товар (услугу). При этом чаще всего установить это самое лицо у магазина нет возможности — его или его представителя увидит только курьер при доставке товара, а до этого момента пройдет много времени, в течение которого персональные данные будут обрабатываться. Как здесь быть с анонимностью, сказать трудно.

Заказ клиент делает чаще всего двумя простыми способами: заполняя форму на сайте магазина или позвонив по указанному там же телефону, и в обоих случаях точно идентифицировать его невозможно. Часто заказ формируется в интересах третьего лица (выгодоприобретателя), которому с использованием возможностей Интернета делается подарок или в качестве контактных указываются данные третьего лица (например родственник или сосед). Главный контролер в области законодательства о персональных данных — Роскомнадзор по этому поводу думает следующее: «При заполнении веб-формы заявки на покупку товара на сайте интернет-магазина ... критерием, свидетельствующим о получении оператором согласия субъекта персональных данных на обработку его персональных данных, является файл электронной цифровой подписи. Кроме того, оператор вправе ввести в веб-форму заявки обязательные для заполнения дополнительные поля, устанавливающие условие согласия субъекта персональных данных на обработку его персональных данных, при условии последующего проведения мероприятий по проверке достоверности представленных персональных данных. В остальных случаях согласие на обработку персональных данных, равно как и его отзыв, может оформляться только в письменной форме. Получение согласия на обработку персональных данных по телефону, посредством SMS действующим законодательством Российской Федерации не установлено».

Про согласие по телефону и говорить нечего — бизнес огромного количества предприятий, занимающихся поставкой товаров по телефонному заказу, бронированием и предоставлением услуг, оказывается вне закона. Строго говоря, нельзя записать продиктованную по телефону фамилию клиента. Достаточно ли при регистрации сообщать клиенту, что указываемые им данные следовало бы как-то обезличить или использовать псевдоним? С точки зрения Гражданского кодекса, предусматривающего свободу договора, данная ситуация также не очень вяжется — договор однозначно может быть заключен в устной форме, если кодекс или закон не требуют иного. Заключить устно можно, а сообщить реквизиты сторон — нельзя. Вот такие парадоксы.

На вопрос «Вправе ли физическое лицо представлять персональные данные своих близких родственников?» Роскомнадзор на своем сайте четко и однозначно отвечает: «Предоставление физическим лицом оператору персональных данных близких родственников возможно только при наличии письменного согласия указанных лиц либо в случаях, установленных федеральными законами». Если кто-то захочет сделать через интернет-магазин подарок родителям, детям или другим членам семьи, он должен получить на это их письменное согласие (кстати, опять вопрос — почему, ведь закон этого не требует?) и при заказе передать это согласие в интернет-магазин. Естественно, если абсолютно то же самое делается через Amazon, ничего этого не требуется, передавайте ему все, что хотите.

Учитывая то, что для продажи и доставки товаров и услуг конечному потребителю, все субъекты интернет-коммерции должны как-то идентифицировать клиента, все они с легкостью могут попасть под определение оператора персональных данных: «...юридическое или физическое лицо, организующее и (или) осуществляющее обработку персональных данных, а также определяющее цели и содержание обработки персональных данных».

- предоставить доказательство получения согласия субъекта на обработку его персональных данных;

Итак, интернет-магазину надо доказать, что у него есть согласие конкретного физического лица, которое попросило предоставить ему товар (услугу). При этом в подавляющем большинстве случаев установить это самое лицо у магазина нет возможности — его или его представителя увидит только курьер при доставке товара, а до этого момента пройдет много времени, в течение которого персональные данные будут обрабатываться. Часто заказ формируется в интересах третьего лица (выгодоприобретателя), которому с использованием возможностей Интернета делается подарок или в качестве контактных указываются данные третьего лица (например родственник или сосед). Главный контролер в области законодательства о персональных данных — Роскомнадзор по этому поводу говорит следующее: «При заполнении веб-формы заявки на покупку товара на сайте интернет-магазина ... критерием, свидетельствующим о получении оператором согласия субъекта персональных данных на обработку его персональных данных, является файл электронной цифровой подписи. Кроме того, оператор вправе ввести в веб-форму заявки обязательные для заполнения дополнительные поля, устанавливающие условие согласия субъекта персональных данных на обработку его персональных данных, при условии последующего проведения мероприятий по проверке достоверности представленных персональных данных. В остальных случаях согласие на обработку персональных данных, равно как и его отзыв, может оформляться только в письменной форме.

Получение согласия на обработку персональных данных по телефону, посредством SMS действующим законодательством Российской Федерации не установлено».

Ясно, что для интернет-магазина такие требования неприемлемы. При этом ФЗ-152 определяет исчерпывающий перечень случаев, в которых необходимо согласие субъекта в письменной форме, и данная ситуация к ним однозначно не относится. Наличие у клиента сертификата ЭЦП или подписанного ЭЦП файла сводит на нет все преимущества электронных продаж, не требующих предварительного установления отношений между покупателем и продавцом. Про согласие по телефону и говорить нечего — бизнес огромного количества предприятий, занимающихся поставкой товаров по телефонному заказу, бронированием и предоставлением услуг, оказывается вне закона. Строго говоря, нельзя записать продиктованную по телефону фамилию клиента.

Достаточно ли при регистрации сообщать клиенту, что указываемые им данные следовало бы как-то обезличить или использовать псевдоним? С точки зрения Гражданского кодекса, предусматривающего свободу договора, данная ситуация также не очень вяжется — договор однозначно может быть заключен в устной форме, если кодекс или закон не требуют иного. Заключить устно можно, а сообщить реквизиты сторон — нельзя. Вот такие парадоксы.

На вопрос «Вправе ли физическое лицо представлять персональные данные своих близких родственников?» Роскомнадзор на своем сайте четко и однозначно отвечает: «Предоставление физическим лицом оператору персональных данных близких родственников возможно только при наличии письменного согласия указанных лиц либо в случаях, установленных федеральными законами». Если кто-то захочет сделать через интернет-магазин подарок родителям, детям или другим членам семьи, он должен получить на это их письменное согласие (кстати, опять вопрос — почему, ведь закон этого не требует?) и при заказе передать это согласие в интернет-магазин. Естественно, если абсолютно то же самое делается через любой иностранный интернет-магазин, ничего этого не требуется, передавайте ему все, что хотите.

Получается очень интересная ситуация - для того, чтобы электронным магазинам что-то продавать на территории РФ, им необходимо во всех местах жительства потенциальных покупателей разместить что-то типа киосков, в которые должны будут приходить потенциальные покупатели со своими паспортами, и регистрироваться только в указанных местах, с обязательным приложением копии документов...

В этом случае оператор ПДн будет однозначно отслеживать полноту и правильность регистрационных данных своих клиентов. Но вот сколько этих самых клиентов у интернет-магазина будет при такой системе регистрации???

Какой путь выбрать - решает каждый самостоятельно, мы для себя выбрали путь явного отказа от контроля правильности клиентских данных, минимизировав их объем и уйдя к анонимизации.

В результате можно с боооольшой натяжкой рассчитывать на непопадание под определение "оператор персональных данных" и остутствие необходимости заниматься описанной выше ерундистикой.

Но это только наше мнение, нет абсолютно никакой гарантии, что у контролирующего органа (Роскомнадзора) не возникнет своего мнения, полностью противоположного нашему ...

А по поводу требования копии паспорта при возврате товаров по почте - это требование взято не с потолка, а является одним из обязательных для возможности возврата денег покупателю в рамках действующего законодательства. К сожалению, тут ничего для сохранения анонимности придумать нельзя. Либо так, либо живите там, где у интернет-магазинов есть собственные службы доставки, позволяющие ознакомиться с приобретаемым товаром до его оплаты.

Ну, или жить за пределами СНГ ...

Как говорится в одной передаче - "выводы делать только вам".

Удобный сервис для секретной переписки

Fri, 14 Oct 2011 13:10:52 +0400

Если требуется обмениваться информацией "не для всех" по открытым каналам связи, то прекрасно подойдет вот этот сервис.

Все просто - пишите тект, и шифруете его паролем.

Само послание и пароль передаете адресату по различным каналам.

Выставки по ИБ - вырождение?

Fri, 30 Sep 2011 15:13:00 +0400

В пятницу побывал на Infosecurity Russia 2011.

Последний раз был в 2009 году - была полноценная выставка, много полезного почерпнул.

В прошлом году променял ее на Инфобез, и серьезно пожалел.

Хотя по нынешнему Инфосеку - сравнялись по убожеству с Инфобезом (судя по плану Инфобез 2011 - практически повторение прошлогодней по размерам), только ресурсы экспонентов распаляют.

А объединяться не желают. Как обычно у нас - пусть мне будет хуже, но и сосед обломается.

Единственную полезность для себя нашел - семинар по защите персональных данных.

Как соберусь с силами - напишу опус на эту тему, давно собираюсь. Слишком много несуразностей и белых пятен.

Яндекс оправдал свой рекламный слоган

Mon, 15 Aug 2011 18:20:34 +0400

Молодцы, отрабатывают свою зарплату.

Вот уж действительно

Есть ли защита от DDoS?

Sat, 05 Mar 2011 11:58:50 +0300

Поделились тут интереснейшей историей.
Вот что было в новостях:
http://lenta.ru/news/2010/10/08/yandex/
http://lenta.ru/news/2010/10/08/ddos/
А вот что нашлось в кэше Гугла (соответственно тоже, как и оригинал, скоро исчезнет)
http://webcache.googleusercontent.com/search?q=cache:vHFTWxc7cfsJ:m.habrahabr.ru/post/105830/+yandex+ddos+site:habrahabr.ru&cd=2&hl=ru&ct=clnk&gl=ru
Выкладываю содержимое:

μHabr / Хостинг
100+ Гбит/с DDoS и net neutrality
Скажите, Вы когда-нибудь сталкивались со 100 гигабитной атакой на подсеть?
Когда-нибудь кто-нибудь видел как лежит yandex? rtcomm? ukrtel? darpa? evoswitch? webazilla? Сеть в мир небольшой европейской страны?
И не дай-бог Вам увидеть подобное.
Если кто-то думал, есть ли термоядерное оружие в интернет — оно есть.

Затишье перед бурей

25 сентября 2010 г.:

18:25
На один IP адрес в нашей сети начинается атака, стандартный UDP flood случайными пакетами. Просим дц закрыть UDP траффик на IP, никто больше 10 гбит/с не атакуют верно?
18:35
Дц рапортует о блокировки с красивым графиком падения нагрузки на порт.
18:40
Предпоследний вопрос получил ответ — неверно! На IP дали 40 гбит/с UDP flood на всю подсеть (512 IP /23). Провайдер null рутнул всю подсеть. Подсеть не с нашей AS. Сделать ничего невозможно.

27 сентября 2010 г.:

17:30
После объяснительной нашу сеть включают, естественно атакованного попросили уйти, сменить А запись и забыть про наш хостинг еще 25-ого, пару дц положил он гуляя (кажется netdirekt и какой-то украинский).

Doomsday

7 октября 2010 г.:

10:30
На клиента-хостера, а точнее его клиента (code-named товарищ) в небольшой подсети дали атаку в 10 гбит/с, т.к. мы на «испытательном сроке», с PA подсетями туго, решили блокировать IP, попросили нуллрутнуть. Не тут-то было, старый друг вернулся. Венгерские каналы за рубеж для многих сайтов закрылись, обратно тоже самое. Атака в 100 гбит/с положила международные каналы проверки EU VAT, банковские каналы, основной канал фондовой биржи, ADSL сети и несколько ДЦ. Для локальных пользователей пол-Европы не было видно. Нас рутят в ноль.
13:44
По данным дц, спустя 1 час после дропа IP атака продолжалась на другие подсети их AS. По данным от клиента они попытались перенести сайт на Leaseweb, IP сменили. Evoswitch частично лег моментально, пока не зануллраутили IP. При смене A записи у домена атака начиналась моментально в 10 гбит/с постепенно увеличиваясь.
19:17
Товарищ сделали 127.0.0.1 у домена.

Утро вечера не мудренее

8 октября 2010 г.:

10:30
Клиент сообщает, что после переноса сайта товарища в дц webazilla на него опять полилось 60 гбит/с
11:57
Вебазилла умоляет убрать из домена A запись, т.к. магистральщики умирать начинают — льется больше 100 гбит/с.

Весело да?

После этого товарищ попрыгал по антиддосерам (укртелеком и еще какие-то вроде sharktech и еще кто-то), сайты которых быстро валились и подсети тоже.
Напомню смена A записи моментальна давала атаку, а нулрут — атаку на под-сеть, мулти-запись А — мулти-атаку!
Тут увидел что яндекс не открывается, как оказалось все довольно просто: когда товарищ уже видимо от безысходности и глупости вписывал IP адреса darpa.mil, yandex.ru, голдентелекома, google и еще кого-то, атака продолжалась на эти IP, никто не продержался.
Представьте у Вас шланг — в виде A записи, с возможностью направить куда угодно и уничтожить почти, что угодно. Попросил клиента уговорить товарища (т.к. не смыслил он, что творил, или смыслил?) прекратить делать окружающим также плохо как и ему и прописать 0.0.0.0 или 127.0.0.1.

Чудо случилось к 21:00 — darpa.mil поднялась, а ддос магически исчез.

Встает вопрос: как в условиях net neutrality бороться с этим, без nullрута подсетей?

P.S.: Мои подсети до сих пор не включили, магистральщики боятся и просят ждать 72 часа. Дц боится вообще прикасаться к ним, оно и ясно, у них SLA 99.9% дважды нарушено, выходит они и нам должны и остальным клиентам, проще им с нами судиться, чем если что, с тысячами их клиентов.

Пару ссылок по теме:
lenta.ru/news/2010/10/08/ddos/
lenta.ru/news/2010/10/08/yandex/

P.P.S.: Может кто-то помочь со срочным анонсом BGP и некст-хопом BGP до наших IP здесь? Готовы заплатить.
equand, Сегодня в 03:14

комментарии (9)

lasthero, Сегодня в 03:29
А чем вы занимаетесь? Как думаете, кому вы дорогу перешли?
equand, Сегодня в 03:33
Это не я, а попались на впс клиенту такие клиенты…
А отвечать приходится мне, т.к. подсети мне выданы. Как назло все случилось именно перед расширением и акквайрингом ASки…
То есть своей AS еще не дали, а подсети частично в дауне, по-крайней мере на 10-гбитном канале.
Почти все восстановили на бекапных подсетях на бекапном канале, но BGP не удалось, т.к. дц отказывается делать что-либо со всеми сервисами, которые были на том канале…
xReaper, Сегодня в 03:35
А поискать плохишей нереально, или это был ботнет?
ofiginuri, Сегодня в 03:38
Это была целая страна ботнетов, судя по красочному описанию.
equand, Сегодня в 03:39
Около миллиона IP, то что успели посчитать . Поди поищи.
Вполне может быть, можно по DNS вычислить папу, но надо как минимум 150 гбит/с канал, чтобы попереключать по подсетям и отловить козла по странным прямым запросам к ДНСу, хотя возможно запрос будет не странным, и с разных серверов мира.
Кстати ботнет скорее всего русский, т.к. атака была на русскоязычный сайт, при беглом осмотре, что-то вроде адалт-тематики, нелегала не нашел. Второй адалт уже за неделю и тот же ботнет. Первый правда ToS нарушал, а к этому даже придраться невозможно было, хорошо что товарищ все-таки убрал IP из днса.
kibizoidus, Сегодня в 03:40
Страшно подумать, чем занимаются ваши клиенты.
equand, Сегодня в 03:43
Страшно, взял клиента на заметку, т.к. уже второй случай такой атаки и на его IP адреса.
kibizoidus, Сегодня в 03:45
Насколько большой проект по посещениям?
Sartor, Сегодня в 03:41
Вот это блокбастер! Прочитал на одном дыхании!
μHabr / Хостинг

Делаем выводы ...

Защищенность Банк-клиентов

Sat, 05 Mar 2011 11:51:44 +0300

Не секрет, что электронные банковские платежи сейчас распространены, как никогда.
Все уважающие себя банки обеспечивают клиентов-организации как минимум одним видом банк-клиентов (веб интерфейс, тонкий и толстый клиенты, и т.п.).
Поскольку речь идет о громадных деньгах, проходящих одномоментно через эти системы, то и ожидания клиентов вполне оправданы: защищенность транзакций должна быть обеспечена не только внешними системами, вроде антивируса, файерволла, выделенных VLAN, но и самым банк-клиентом.

Но, к нашему удивлению, это совсем не так!!!!!!
Проведенные эксперименты показали, что даже у самых крупных банков выявляются такие огрехи, что даже не специалисту в программировании должно быть стыдно...

К сожалению, подробности пока опубликовать не могу, надо осмыслить до конца результаты, возможно передать полученную информацию производителям - увод денег "налево" оказался настолько элементарным, и незаметным для бухгалтерий, что диву даешься ...

Прокси серверы для предприятий

Sat, 05 Mar 2011 11:47:57 +0300

Любой компании в настоящее время необходим, в той или иной степени, доступ сотрудников в сеть Интернет.
Как минимум, он нужен для работы бухгалтерии с Банк-клиентами, для осуществления платежей.
Но и остальным подразделениям требуется доступ, хоть и специально ограниченный.
Одним из типичных "ограничителей" и консолидаторов доступа является прокси сервер в любой конфигурации.
Сейчас на рынке представлено очень много программных продуктов, способных выполнять данную функцию (либо как основной функционал, либо как одна из многих функций).
Опишу несколько испытанных мной прокси серверов, с выделением некоторых их особенностей, преимуществ и недостатков.

На форуме можете рассказать о своих предпочтениях.

1. Прокси сервер Squid

http://www.squid-cache.org/
Наиболее распространенный во всем мире прокси сервер. Разработка начата еще в 1990 году.
В настоящее время поддерживаются стабильные версии 2.7 и 3.1
Разрабатываются 2.8 и 3.2

Основные преимущества:
Бесплатность.
Распространенность, большое cummunity.
Кроссплатформенность.
Относительная простота развертывания, есть большое число мануалов под любую платформу.

Основные недостатки:
Требует серьезного допиливания руками для обеспечения доменной авторизации, кластеризации, и других возможностей, не входящих в стандартный конфиг.
Нет ACL, ориентированных на Российский рынок (например блокировка социальных сетей и их зеркал) - требуется много рутинной ручной работы.
Требуются дополнительные модули для обеспечения сканирования на вирусы, установки активной фильтрации контента, организации системы отчетности, и т.п.

Так же существуют платные разновидности (SafeSquid, и т.п.), по заверениям производителей, более приспособленные к работе в корпоративной среде.

Эксплуатация на 500+ пользователях с AD авторизацией требует слишком много усилий от админов - переполнения памяти, проблемы с авторизацией на группе доменников, сложность и статичность ограничительных правил, и т.п.

2. Blue Coat Web Security Bundle

Появившееся в 2010 году интересное предложение Blue Coat Web Security Bundle представляет собой идеальный вариант для защиты компаний малого и среднего бизнеса от веб-угроз.

Решения с непревзойденным функционалом, легкой установкой и преимущества "облачной службы защиты" WebPulse теперь доступны и для компании с менее чем 1500 пользователей.
Новое bundle предложение от Blue Coat включает удобный и практичный набор продуктов и сервисов для защиты вашего бизнеса по доступной цене!

В Web Security bundle включены следующие продукты и сервисы BlueCoat:

- Устройство Proxy плюс лицензия SG SSL
- Устройство Proxy AV
- Лицензия WebFilter на 3 года
- Лицензия Proxy AV на 3 года
- Reporter
- Proxy Client
- SW поддержка устройств SG и AV на 3 года - на выбор standard 24*7 Blue Touch или BTSP
- HW поддержка устройств SG и AV на 3 года - на выбор same day ship Blue Touch или BTSP
- Поддержка для Reporter на 3 года

Представляет собой программно-аппаратный комплекс с несложной предварительной настройкой и полноценной интеграцией с AD и различными системами безопасности (например DLP Websense, Infowatch), обладает возможностью расшифровывать SSL трафик.

3. CYAN SECURE WEB

www.cyan-networks.ru
Не слишком широко известная в России компания, поэтому видимо и стоимость предложений у них вполне адекватная.

CYAN SECURE WEB это высокопроизводительный прокси сервер, который спроектирован для предоставления общей адаптивной безопасности, и удовлетворяет специфичным для масштаборуемых веб-фильтров требованиям. Мощное, всё в одном решение защищает вашу компанию как от уже существующих, так и от постоянно появляющихся веб угроз и несоответствующего использования Интернет. CYAN SECURE WEB позволяет вам получить контроль над использованием Интернета в вашей компании, и в тоже время даёт возможность следить за его использованием. Другими словами, этот продукт не только защищает вас от угроз извне, но также поставит конец неправильному использованию Интернета в вашей компании. Таким образом, Вы можете как защить себя от угроз, которые приходят изнутри. CYAN SECURE WEB подходит как для маленьких и средних компаний, так и для больших предприятий.

Функциональность CYAN SECURE WEB гарантируется CYAN Secure List, CYAN Reporting и Аддонами.

Полноценно не тестировал, поэтому особо отметить ничего не могу.

4. ContentKeeper Web

www.ContentKeeper.com
www.softbcom.ru
Тоже не сильно дорогой (в рамках бизнес и энтерпрайз сегмента) продукт, известный в узких кругах.

ContentKeeper™ Web - это масштабируемое, отказоустойчивое решение корпоративного уровня по фильтрации Интернет, разработанное для того, что бы помогать большим предприятиям, имеющим сложные сети с высокой пропускной способностью, осуществлять мониторинг, управление, контроль и защиту в процессе использования ими Интернет-ресурсов.
ContentKeeper™ Web предоставляет предприятиям инструментальные средства, позволяющие в максимальной степени использовать новейшие технологии, обеспечивая при этом защиту от развивающихся Интернет-угроз. Если Вам необходимо масштабируемое, надежное, отказоустойчивое и высокопроизводительное решение, ContentKeeper™ Web – это решение для Вас.

Тоже программно-аппаратный комплекс, вполне отрабатывает свою стоимость, не уступая более именитым, и поэтому дорогим, конкурентам.

5. Zscaler Web Security

www.zscaler.com
Очень интересный продукт, по словам разработчиков, позволяющий выкинуть все локально используемые прокси.
Работает по "облачному" принципу, т.е. полная балансировка нагрузки с повышенной отказоустойчивостью.
Для меня не ясен вопрос с защитой данных от перехвата между периметром ЛВС компании и облачным сервисом Zscaler.
Во время тестирования показал себя местами даже шустрее локального прокси.

40 датацентров по всему миру о многом говорят.

Гарантируют задержку обработки запросов внутри своей инфраструктуры (проверка на вирусы, анализ категорий, и т.д.) не более 10 микросекунд.

Выдают месячный бесплатный тестовый доступ, практически без ограничений на число пользователей.