Интересно, спасибо. Т.е. я правильно понимаю, что Defense Pipe решение требует как минимум отдельной /24 подсети, выдленной под защищаемый ресурс? Иначе, проанонсировав /24 из «центра чистки» — вы «заберете» туда весь трафик к подсети, и другим ресурсам в этой /24 это может не понравится.
Все это хорошо, но полезность таких железок проявляется только тогда, когда размер атаки не превосходит пропускную способность вашего канала. В данном случае, трафик был несущественный.
Был ли план что делать, если бы атака превысила 0.5Gbit/s (я так понимаю, такова была пропускная способность канала, по крайней мере из конфигурации)?
Да, я не спорю что IT-индустрия тоже «размажется» по миру.
Но говорю о том, что пока есть такое место как Долина — есть смысл использовать ее преимущества для ускорения роста.
Конечно, надеяться на то, что она будет вечной — не дальновидно. Но на текущий момент ставку на нее сделать вполне можно и разумно, что и делают многие компании.
Еще есть разница между тем, чтобы сделать небольшой продукт для продажи — и поддерживать большой массовый сервис. Одни затраты на поддержку и развитие инфраструктуры уже требуют масштаба.
Согласен. По моему опыту в небольших компаниях это тоже не особо работает. Но я думаю процент небольших компаний, где это работает, по сравнению с большими, — все же выше. Поэтому писал в контексте больших компаний, в тему топика.
Возможно, большие компании и пережиток прошлого, но я не особо понимаю как серьезное масштабирование возможно без горизонального роста? Т.е. когда продукт — это один проект, то группа людей может его сделать. Но когда продукт становится массовым — просто физически приходиться расти, даже если все сделано очень эффективно.
А насчет конгломерата компаний в одном месте — мне кажется что это опять таки тот же «человеческий фактор». Люди хотят и предпочитают общаться между собой вживую, хотят видят вокруг себя единомышленников, и т.д. Поэтому и получается такая группировка по интересам. Думаю, неизбежно, через N лет Долину постигнет судьба Детроита, и IT станет еще одной рутинной профессией среди многих. Но пока Долина и индустрия жива — действительно продуктивно делать бизнес там, и это доказано многими компаниями выросшими оттуда.
Мне кажется, что дело еще в человеческой природе, которая не готова перестроится под образ «работы XXI века». Какие бы технологии не предлагались — пока «человеческая натура» будет хотеть «живой контакт» — ничего не изменится.
У меня, к примеру, полное покрытие всех рабочих процессов возможностью удаленной работы. Но время от времени я предпочитаю провести 10 часов в самолете и за неделю личного присутствия решить все те вопросы, которые иначе решались бы месяцами.
В общем, проблема не в технологиях, на мой взгляд. Или если в них, то в том, что они не могут пока гармонично вписаться в то, что нужно психологии человека.
А вообще, тема интересная. Есть ли примеры больших компаний (допустим, от 1000 человек), которые работают полностью удаленно?
Оплот IT свозит сотрудников к рабочим местам, потому что современные технологии еще не готовы преобразовать офисный мир для большинства людей. Эти компании умеют считать деньги, и если бы возможно было перевести всех сотрудников на удаленную работу без потери эффективности труда — это уже было бы сделано.
Я не говорю, что нет людей, которые не могут работать одинаково эффективно удаленно и «из офиса», но для большинства и больших компаний — это не работает. Особенно, когда важна не индивидуальная продуктивность, а результат от группы людей.
Это все, конечно же, оставляет место для исключений для таких сотрудников, которые могут и хотят работать удаленно, если они (исключения) необходимы.
Постараться можно. Помимо датацентров, которые позволяют любой трафик, есть еще и пользователи доступа, и т.д. Если бы найти такого провайдера было сложно — мы бы с вами вообще не беспокоились про ip spoofing и баг, упомянутый в статье, в частности.
Позвольте вас поправить. Провайдер вполне себе может фильтровать _входящий_ пакет от своего абонента и отбрасывать все то, что не принадлежит к его сети (начиная от банального ACL по source, и продолжая, к примеру, uRPF — www.cisco.com/web/about/security/intelligence/unicast-rpf.html).
Но я думаю вопрос bimcom был о том, почему провайдеры это не делают? Это уже вопрос к конкретным провайдерам, которые позволяют spoofed трафик из своих сетей и единого ответа, боюсь, нет.
Такие конфиги генирируются скриптом на, максимум, 50 строчек и поддерживаются им же. Т.к. они сделаны по одному типу, то их поддержка не представляет сложности. Есть условия, когда такой тип конфигурации не избежать.
Rel1cto уже ответил, что первое не верно. Обслуживание OSPF будет не дороже чем EIGRP.
Спокам не нужно держать всю LSDB, я изначально написал, что они будут в totally stub зонах и нагрузка на них будет минимальная.
Насчет второго, если вы завязываетесь на DMVPN, то наверное, в этом случае, уже не проблема подвязываться и на EIGRP.
По-моему несколько разных IGP используются либо от плохого дизайна, либо после поглощения не успели привести сетку в порядок. Ну либо какой-то исключительный случай, который правилом не является. Ну а то что где-то есть и RIP — я не сомневаюсь, только это не значит же, что это хорошо или правильно.
А насчет EIGRP vs OSPF при hub-and-spoke, а в чем преимущество будет в такой топологии? Допустим, по сравнению с OSPF если каждый спок загнать в свою totally stub зону?
Интересно, много ли более-менее крупных сетей используют EIGRP в принципе? За все свое время я имел счастье наблюдать EIGRP только в лабах.
И основная причина — отсутствие совместимости с другими вендрами (зачем связывать себя привязкой к Cisco? Если, конечно, вы не гос.учереждение связанное откатами..). Даже работая в Cisco-ориентированном интеграторе — я не видел массивных деплоев EIGRP.
Есть подозрение, что протокол умирает и это попытка реабилитации.
Так а в чем заключается защита, если не проблема собрать пакет с адресом пира и таким TTL, чтобы он стал 1, когда дойдёт до маршрутизатора?
Даже если учесть, что атаковать можно только с «доверенного» внешнего пира, то если у вас их, например, сотни — это увеличивает вектор возможной атаки. Если кто то контролирует сеть пира, то он может перезагрузить ваши пограничные маршрутизаторы.
Я не вижу где я «плачу» об неизвестных слушающих сервисах. Все как раз известно. Поэтому для меня как раз ясно, что обновление должно быть внеплановым.
Смотрите, речь тут не о BGP. Во-первых, уязвимость на уровне TCP стэка, т.е. потенциально ещё можно эксплуатировать до того как BGP процесс дропнет пакет из-за неправильного TTL. Т.е. не важно насколько хорошо у вас он сконфигурирован, зная адрес пира — уже можно спуфнуть пакет, который потенциально перезагрузит маршрутизатор.
Это же касается и всех других сервисов, включая SSH. Раньше, зная адрес доверенного хоста — ничего сделать было нельзя. Теперь же — можно. Security through obscurity — это плохо.
Но с SSH, конечно, сложнее. С BGP же адрес пира с большой вероятностью можно угадать глядя в trace route к вам.
Поэтому уязвимы все, у кого есть хотя бы BGP с внешним миром. Не считая всех других возможных TCP сервисов.
Естественно. Я лишь привёл информацию о существующей проблеме. Определение степени уязвимости конкретной сети я оставлю её владельцам. Если кто то накатывает новые версии сломя голову и не подумав -, как вы сказали, там уже другие проблемы.
Строить теории о том, какой может быть конфигурация чтобы быть или не быть уязвимой — можно долго. Я уверен, что найдётся не мало конфигураций, которые будут уязвимы в той или иной степени. И, к счастью, такие, которые не уязвимы.
Уязвимость есть и она критическая по своей сути. Является ли возможной ее эксплуатация — зависит от вас :)
С этим багом достаточно одного пакета для эксплуатации. Т.е. фильтры легко обойдутся, если атакующий знает адреса ваших BGP пиров (что достаточно легко). Насчёт TTL — есть еще и multihop, и, снова таки, один единственный пакет можно собрать каким угодно.
Был ли план что делать, если бы атака превысила 0.5Gbit/s (я так понимаю, такова была пропускная способность канала, по крайней мере из конфигурации)?
Но говорю о том, что пока есть такое место как Долина — есть смысл использовать ее преимущества для ускорения роста.
Конечно, надеяться на то, что она будет вечной — не дальновидно. Но на текущий момент ставку на нее сделать вполне можно и разумно, что и делают многие компании.
А насчет конгломерата компаний в одном месте — мне кажется что это опять таки тот же «человеческий фактор». Люди хотят и предпочитают общаться между собой вживую, хотят видят вокруг себя единомышленников, и т.д. Поэтому и получается такая группировка по интересам. Думаю, неизбежно, через N лет Долину постигнет судьба Детроита, и IT станет еще одной рутинной профессией среди многих. Но пока Долина и индустрия жива — действительно продуктивно делать бизнес там, и это доказано многими компаниями выросшими оттуда.
У меня, к примеру, полное покрытие всех рабочих процессов возможностью удаленной работы. Но время от времени я предпочитаю провести 10 часов в самолете и за неделю личного присутствия решить все те вопросы, которые иначе решались бы месяцами.
В общем, проблема не в технологиях, на мой взгляд. Или если в них, то в том, что они не могут пока гармонично вписаться в то, что нужно психологии человека.
А вообще, тема интересная. Есть ли примеры больших компаний (допустим, от 1000 человек), которые работают полностью удаленно?
Я не говорю, что нет людей, которые не могут работать одинаково эффективно удаленно и «из офиса», но для большинства и больших компаний — это не работает. Особенно, когда важна не индивидуальная продуктивность, а результат от группы людей.
Это все, конечно же, оставляет место для исключений для таких сотрудников, которые могут и хотят работать удаленно, если они (исключения) необходимы.
Но я думаю вопрос bimcom был о том, почему провайдеры это не делают? Это уже вопрос к конкретным провайдерам, которые позволяют spoofed трафик из своих сетей и единого ответа, боюсь, нет.
Спокам не нужно держать всю LSDB, я изначально написал, что они будут в totally stub зонах и нагрузка на них будет минимальная.
Насчет второго, если вы завязываетесь на DMVPN, то наверное, в этом случае, уже не проблема подвязываться и на EIGRP.
А насчет EIGRP vs OSPF при hub-and-spoke, а в чем преимущество будет в такой топологии? Допустим, по сравнению с OSPF если каждый спок загнать в свою totally stub зону?
И основная причина — отсутствие совместимости с другими вендрами (зачем связывать себя привязкой к Cisco? Если, конечно, вы не гос.учереждение связанное откатами..). Даже работая в Cisco-ориентированном интеграторе — я не видел массивных деплоев EIGRP.
Есть подозрение, что протокол умирает и это попытка реабилитации.
Даже если учесть, что атаковать можно только с «доверенного» внешнего пира, то если у вас их, например, сотни — это увеличивает вектор возможной атаки. Если кто то контролирует сеть пира, то он может перезагрузить ваши пограничные маршрутизаторы.
Я не вижу где я «плачу» об неизвестных слушающих сервисах. Все как раз известно. Поэтому для меня как раз ясно, что обновление должно быть внеплановым.
Это же касается и всех других сервисов, включая SSH. Раньше, зная адрес доверенного хоста — ничего сделать было нельзя. Теперь же — можно. Security through obscurity — это плохо.
Но с SSH, конечно, сложнее. С BGP же адрес пира с большой вероятностью можно угадать глядя в trace route к вам.
Поэтому уязвимы все, у кого есть хотя бы BGP с внешним миром. Не считая всех других возможных TCP сервисов.
Уязвимость есть и она критическая по своей сути. Является ли возможной ее эксплуатация — зависит от вас :)