throughtheether

желательно уровня AES2048+

Что вы подразумеваете под AES2048?

В любом случае, обратите внимание на tox.

Поясните, какую конкретно задачу вы решаете.

То есть, по характерной последовательности данных сказать - вот тут у нас передавался траффик ICMP? Или же вынести такое заключение можно только после того, как принятый IP-пакет будет разобран?

А определение протокола - это разве не разбор пакета (хотя бы частичный)?

А можно ли обнаружить в RAW-пакете сам факт передачи определённых данных, не анализируя протоколы? То есть, по характерной последовательности данных сказать - вот тут у нас передавался траффик ICMP?

В вашем случае надо смотреть на поле Protocol пакета IP, это, по-моему, байт номер 10, считая от 1. В случае ICMP там будет значение 1.

на предприятии где они запрещены

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

необходимо обнаружить сотовые телефоны, всех диапазонов и ОПСОС

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

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

использовать глушилки не вариант.

Почему?

Вопрос кто-нибудь сталкивался с такой задачей?

Примерные мероприятия (из тех, что наблюдал лично) по обеспечению "тишины в эфире" я вам описал.

есть ли такие датчики вообще?

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

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

UPD:

Конкретная цель очень простая, например колония.

Например или колония? Специфика может кучу нюансов привнести.

Глушилки использовать не вариант, так как рядом могут находится другие дома, которые подпадают под действие глушилок,

Что значит "могут находиться"? Если есть заданная колония, то рядом с ней жилые дома или есть или нет. Или вы разрабатываете общий проект?

плюс медики против.

Что значит "медики против"? Какие именно показатели ЭМ поля их не устраивают? Какие стандарты нарушаются? Далее, вам никто не предлагает подгонять РЭБовский комплекс и жарить эфир. Сейчас, насколько мне известно, существуют маломощные интеллектуальные средства подавления мобильных телефонов (грубо говоря, "палочки" на экране есть, а позвонить не получается). Заводское изделие не подскажу, видел продукты мелкосерийного-полукустарного производства.

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

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

Написал пятнашки, крестики нолики в консоли с применением мега мелькающей дефолтной графики по средствам раскрашивания askii.

Может подскажите что можно написать ради себя, ради души и практики,

Напишите игру/демку, кторая рендерится в ascii-символы, вот пример.

Как сейчас распространяются вирусы?

Если говорить о распространении банковских троянов, DDoS-ботов, троянов для мошенничества с рекламой, то одна из схем примерно такова:
Сайт с живыми пользователями -> Ссылка/фрейм/попандер на эксплоит-пак -> Эксплуатация уязвимости (Flash, браузер, и т.д.) -> загрузка и исполнение шифрованного бинарника.

Думаю, можно "отключить" (null route, на windows делается примерно так) маршрут по умолчанию. Для доступа к VPN-серверу, прописать до него специфичный статический маршрут (как упомянул kodi).

Во-первых, хорошо было бы узнать, откуда задача возникла, и какой смысл в ее решении (т.е. что вам даст/должно дать знание топологии). Трафик снимается из одной точки сети или из нескольких? Пример дампа можете привести?

Я предполагаю, что в сети используется IPv4, инкапсулированный в Ethernet. В таком случае, на мой взгляд, сначала имеет смысл построить граф взаимодействия Ethernet-хостов (аналог в wireshark: statistics -> conversations -> ethernet). Затем, для каждого ethernet-хоста (определяемого unicast MAC-адресом) ставите в соответствие IPv4-адрес инкапсулированного IPv4-пакета (MAC-адресу источника ставите в соответствие IPv4-адрес источника, аналогично с адресами назначения). У вас получается вид топологии сети из точки, в которой происходил захват трафика. На мой взгляд, если нужна топология всей сети, то и трафик захватывать надо с каждого L2-домена.

Считая сначала md5, затем crc32, вы, по моему мнению, увеличиваете вероятность коллизии. Коллизия может возникнуть в функции md5 (одинаковые значения для разных входных данных), что сразу приведет к коллизии на выходе crc32 (одинаковые значения для одинаковых входных данных). Кроме того, коллизия может возникнуть в функции crc32b (одинаковые значения на выходе для двух разных результатов md5). Не знаю, как работает функция md5 в php, но мне представляется, что ее вывод имеет некую структуру (32 шестнадцатеричные цифры), что может увеличить вероятность коллизии crc32b.

Зачем использую crc32b? Чтобы ссылки были как можно короче - для использования в смс-рассылке.

На вашем месте, если нужен детерминизм, я бы:
1) использовал хэш-функции из семейства SHA-2 (SHA-256,SHA-512).
2) использовал бы N последних бит (например, 48, сложность подбора заданного хэша в среднем 2^48 попыток, сложность нахождения двух произвольных пользователей с совпадаюшими хэшми, как отметил @eandr_67 в комментарии, значительно меньше, 2^24 попыток в среднем, в силу квадратичного количества пар)
3) транслировал бы эти 48 бит в 8 символов 64-символьного алфавита (латинские буквы в обоих регистрах + цифры + 2 символа)
4) использовал бы полученную 8-символьную строку
Пункты 2,3,4 можно подогнать под ваши специфические требования.

UPD:

При изменении статусов заказа эти ссылки приходят клиенту на емейл/смс - поэтому будет не очень хорошо если ссылка каждый раз разная будет (таким образом клиент не сможет зайти в кабинет по ссылке из прошлого письма).

Во-первых, непонятно, почему отслеживаются заказы, а хэш вы считаете от товара. Сегодня, например, клиент заказывает один товар одновременно, а завтра, когда концепция поменяется - два и более. Более логичным представляется отслеживание заказов (примерные характеристики заказа - номер телефона/email пользователя, список товаров, срок и адрес доставки и прочая).
Далее, непонятно, почему решено использовать хэширование. Я предполагаю, что проблем с хранением данных нет. Почему бы не хранить вместе с данными заказа соответствующую ему 'секретную' ссылку, сгенерированную при помощи ГПСЧ?
Далее, если вы планируете использовать короткую ссылку в смс, то имеет смысл использовать для ее составления специализированный алфавит, отобрав из набора a-z,A-Z,0-9 наиболее удобные в плане UX. Например, буквы I и l бывают трудноразличимы. Здесь важно также максимизировать мощность множества возможных значений строки-ссылки (равное A^l, где A - количество символов в алфавите, l - длина строки-ссылки). В случае 32 символов в алфавите и 8 символов в строке получаем 2^40 вариантов, сложность нахождения пары пользователей с совпадающими ссылками в среднем 2^20 попыток (вероятности релевантных коллизий, соответственно, обратны этим значениям).
Далее, можно разделить функциональность страницы заказа, при простом доступе по ссылке показывать только статус/общую информацию, а важные действия (отменить заказ, изменить адрес, и т.д.) разрешать после прохождения дополнительной проверки (например, на известный номер телефона/e-mail клиента пересылается короткоживущий секрет, который должен быть введен на странице для продолжения).
Такие мысли.

В результате сайт полег от атаки через пару часов.

Вы уверены, что это именно целенаправленная атака? Исходя из каких данных вы делаете такой вывод? В моем опыте были пациенты, у которых сервер генерировал главную страничку при помощи SQL-запроса с множеством операторов join, с полным отсутствием кэширования, со специфической конфигурацией (nginx на windows). Сайт переставал работать при 30 одновременных клиентах. Естественно, внешние мероприятия по фильтрации трафика могли гарантировать работоспособность сервера только при условии его доступности узкому кругу веб-клиентов. Как правило, объяснить это таким людям было затруднительно.

Я вчера подключила couldflare, не знаю поможет ли это при уже идущей атаке

Может помочь. Но, насколько мне известно, можно узнать ip-адрес, на который cloudflare переадресовывает трафик, и соответственно направить атаку. Соответственно, нужны дополнительные меры защиты на вашем хостинге (запретить входящий трафик, кроме перенаправляемого с cloudflare)

Атака http - флуд. Есть ли какие-то еще способы защиты?

Я как сетевик выскажу свое мнение (стоит учитывать проф. деформацию личности). Я полагаю, что говорить о дополнительных мерах защиты (аппаратные решения и прочая) имеет смысл только если входящий трафик на сервер составляет значительную долю (50-60%) пропускной способности интерфейса. Я полагаю, что сервер, в идеале, должен выдерживать line-rate объем трафика, то есть объем трафика, полностью утилизирующего пропускную способность сетевого интерфейса. И только исчерпав возможности оптимизации сервера, имеет смысл обращаться к внешним решениям. Незрелая оптимизация в данном случае, я полагаю, вредна. Однако, учитывая наличие сервисов вроде cloudflare, использовать их в ряде случаев (вроде вашего) полезно.

Слышала о каких-то фаерволах, плагинах для wordpress (сайт на нем стоит

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

Дорогой хостинг пока нет возможности купить...

У вас используется shared-хостинг? Если да, то задумайтесь о покупке VPS, настроив кэширование при помощи cloudflare. Это даст вам гибкость настроек. Хотя в редких случаях shared-хостинг может быть более устойчив к некоторым атакам, нежели дешевый VPS.

Вкратце - вы сделали что могли (подключили сервис cloudflare). Для дальнейшей настройки необходимо понимать многие нюансы работы вашего сайта. DDoS-атаки в вашем случае может и не наличествовать. Вам стоит задуматься об организации грамотной поддержки вашего сайта (нанять системного администратора или самостоятельно углубиться в этом направлении).

Расскажу про то, с чем работал сам.

Интересно узнать, сохраняется ли история моих посещений\скачиваний у провайдера?

Я полагаю, любой вменяемый провайдер собирает т.н. flow-данные с целью учета трафика (netflow, s-flow и т.д.). В этих данных содержится информация о времени начала/окончания "flow" (грубо говоря, "flow", "поток", "сессия" задается IP-адресами источника/адресата, номером протокола (TCP, UDP, ICMP, etc), номерами портов источника и адресата), об объеме переданной информации (в байтах, в пакетах) и т.д. Понятно, что с точки зрения полезного (с точки зрения пользователя) трафика это метаданные. Соответственно исходя из этих данных, нельзя сказать, что и где вы писали на форуме, к примеру, можно лишь сказать, обращались ли вы тогда-то и тогда-то по такому-то порту такого-то сервера и если да, то какой(количественно) трафик потребляли/генерировали.

Сколько времени история может храниться на сереверах провайдера и как часто они удаляют информацию?

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

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

Нет, нельзя.

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

Если необходимо найти именно место расположения клиента, то можно предположить применение направленной антенны (для дифференциации по азимуту) и анализатора трафика (для дифференциации по MAC-адресам).