Рубрика «сетевая безопасность» - 2

Google учит пользователей распознавать фишинговые e-mail - 1

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

Самый простой способ попасть в защищенную среду для киберпреступника — отправить сотруднику целевой организации специальным образом сформированное сообщение. Оно может быть от начальника, партнера, клиента и т.п. Основной элемент такого e-mail — зловред, замаскированный под видом документа в приложении или же ссылка на вредоносный сайт. Google решил научить своих пользователей распознавать проблемные сообщения.
Читать полностью »

Это вторая часть главы «Сетевая безопасность» (которая в свою очередь является третьей частью цикла статей «Как взять сетевую инфраструктуру под свой контроль»). В первой части этой главы мы рассмотрели некоторые аспекты сетевой безопасности сегмента «Data Center». Эта глава будет посвящена «Internet Access» сегменту.

image

Internet access

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

При аудите этого сегмента обратите внимание на следующие аспекты:

  • дизайн
  • настройки BGP
  • DOS/DDOS защита
  • фильтрация трафика на фаерволе

Читать полностью »

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

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

Читать полностью »

Т.к. эта глава получается довольно объемной, то я решил публиковать ее по частям.
Сетевая безопасность. Часть первая.

image

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

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

Но, напомню, что сейчас мы не говорим о создании сети. В соответствии с нашими начальными условиями у нас уже выбран дизайн, выбрано оборудование, и создана инфраструктура, и на этом этапе мы, по возможности, должны «жить» и находить решения в контексте выбранного ранее подхода.

Наша задача сейчас – выявить риски, связанные с защищенностью на уровне сети и снизить их до разумной величины. Читать полностью »

Раздается недавно звонок:
— Добрый день! Я бы хотел получить спецификацию на межсетевой экран Cisco ASA. У меня уже есть спецификации от компании <имярек> и я хочу сравнить их и выбрать подходящую. Вы можете мне помочь в этом?
— Да, конечно. А для чего вам нужна Cisco ASA?
— Мне необходимо заблокировать Tor.
— А вам нужна именно Cisco ASA для этого?
— Ну а как? Вот компания <имярек> говорит, что ее межсетевой экран блокирует Tor. Поэтому я хочу сравнить стоимость их экрана с вашим.
— То есть вам нужно заблокировать Tor и вы ищите для этого нужное вам решение?
— Да-да (раздраженно). Так вы можете мне составить спецификацию? Какие исходные данные вам нужны?
— Для решения именно этой вашей задачи, если другие перед вами не стоят, необязательно использовать Cisco ASA. Блокировать работу с Tor вы можете с помощью различных наших решений — Cisco Web Security Applaince, Cisco Umbrella Security Internet Gateway, Cisco Cloud Web Security, Cisco Meraki MX, Cisco Firepower, Cisco AMP for Endpoints… В конце концов вы можете с помощью скрипта подгружать адреса узлов сети Tor в маршрутизатор Cisco ISR и блокировать их с помощью ACL. В последнем случае вам и тратить ничего не придется.
— Да? Вот блин. Мне надо тогда подумать…
— Давайте мы с вами вместе составим перечень задач, которые вам надо решить, и угроз, с которыми надо бороться, и тогда уже выберем наилучшим образом подходящий продукт?
— Хорошо, давайте. Вы сможете к нам подъехать завтра к 10-ти утра?
— Конечно.
Читать полностью »

Видео-инструкция по Check Point Security CheckUP R80.10. Аудит безопасности сети - 1
Как мы и обещали ранее, подготовлена подробная видео-инструкция по самостоятельному проведению аудита безопасности сети с помощью Check Point Security CheckUP R80.10. Ранее были опубликованы три части:

Однако с помощью текста и картинок весьма трудно создать подробное описание. Специально для этого мы подготовили видео-инструкцию, которая также состоит из трех частей:Читать полностью »

Состояние сетевой безопасности в 2016 году, подробный отчёт Qrator Labs и Wallarm - 1

«Хабраэффект» наоборот — атаки на Хабрахабр за год (сверху) и на Гиктаймс (снизу). В феврале 2017 на Гиктаймс была нейтрализована атака в 17,5 Гбит/с.

Состояние сетевой безопасности в 2016 году, подробный отчёт Qrator Labs и Wallarm - 2

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

Инциденты, связанные с атаками типа «отказ в обслуживании» вновь на слуху — но теперь грамотно выполненные атаки уже угрожают доступности целых регионов. На проблему вновь нужно обращать повышенное внимание — словно мы вернулись на 5—7 лет назад в прошлое.

До прошлого года могло показаться, что проблема DDoS уже достаточно хорошо решена.

Но мощность атак и их сложность в минувшем году выросли радикально. В прошлом даже мощные атаки в 100—300 Гбит/с не вызывали особой «головной боли». Сложные типы атак на протоколы прикладного уровня случались редко. А в 2016 году мир впервые увидел атаки в 1 Тбит/с, и атаки на уровень L7 стали куда более распространёнными.
Читать полностью »

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

Технологии безопасности сети на 2-ом уровне OSI. Часть 1 - 1

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

Под катом перечень механизмов, которые помогут выполнить данную функцию.
Читать полностью »

Пример базы Keepass для сетевого администратора - 1

Все мы храним или хранили пароли от сетевых устройств в excel файлах. Бывает конечно и так, что хранить ничего не надо так как учетная запись на всех устройства одинаковая, надеюсь читатели поняли, что я говорю не про RADIUS или TACACS, а про ситуацию, когда учетная запись действительно одна.

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

Хорошо если в вашей компании есть ресурсы и обозначен стабильный рост. В таком случае в какой-то момент вы разворачиваете приложение для управлению сетью. Но кто-то, в конечном итоге, так и остаётся на уровне «контролцэ-контролвэ», из-за отсутсвия ресурсов, а может и по другим причинам. Именно для этих людей данная статья. Я расскажу как уйти от excel, сделать хранение паролей более удобным и получить некоторую автоматизацию типовых телодвижений. Заметка: все описания для Windows окружения.
Читать полностью »

В начале этого года команда Blue Coat Security Labs запустила эксперимент, целью которого было получение статистики о времени жизни DNS-имен. В рамках этого исследования в течении 90 дней было проанализировано более 660 млн. уникальных имен. 470 млн. из них (71%) просуществовали не более 24 часов. Такие узлы были названы «однодневками».

Создание короткоживущих имен — обычная практика для некоторых Интернет-сервисов, поэтому в присутствии в выборке некоторого количества таких узлов нет ничего необычного. Но 71 процент! Неожиданно, да? Почему их столько? Что это — ошибочные запросы к несуществующим сайтам? Или случайным образом сгенерированые ботами субдомены, используемые для связи с C&C-серверами?
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js