Soltik

Если не ошибаюсь, по http вообще транслировать невозможно. http (как и более подходящий RTSP) начнет передавать по запросу. Если нужна реальная трансляция, невзирая на запрос клиента, тогда что-то из UDPшного, вплоть до мультикаста.

Указываешь на поправку, что не в состоянии блочить урл, и показываешь отсутствие пинга на IP.

А одинаковые записи в реестре - это теперь тоже будет нормально? id=198 и id=786 отличаются только слешем в конце урла, приняты одной конторой в один день под разными номерами документов )))

24млн соединений??? нее, что-то там не так. Пусть будет 10тыс юзеров, получается по 2400 соединений на каждого, это анриал какой-то. Хотя сомневаюсь, что одна линуксовая машина столько народу тянет.

Действительно, я тоже порывался в csv превратить, но вовремя остановили. Формат будет меняться сто раз, это вам не IETF со своими RFC )) А xml хотя бы будет работать, хоть и без новых полей.

Сколько же народу за этим одним натом сидит? Может тогда подрезать им количество одновременных сессий, а то же торренты, например, совершенно ненасытны. Кроме того, имеет смысл обратить внимание на таймауты tcp и udp сессий (net.ipv4.netfilter.ip_conntrack_***), нынче инет не на диалапе чтоб счет вести на десятки минут, а то и на часы. Можно поанализировать файл /proc/net/ip_conntrack, там третье поле - длительность висящей сессии, если там большое количество записей с сильно большими числами - надо сокращать таймауты. Вот что-то такое например: cut /proc/net/ip_conntrack -d" " -f8 | sort -n | uniq -c если разбивать по пробелам, у меня это поле восьмым вышло, поэтому -f8

Интересней, что они с самим реестром делают, что он у них каждый час обновленным считается ))

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

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

Есть возможность писать свои собственные скрипты сигнатур, но это такие дебри, что в них лезть совсем неохота. К тому же это мне надо вначале посетить этот хттпс, слить его сертификат, а потом его еще и пережевывать? Да ну их лесом! Для них буду ип блочить и все тут. DNS тоже не панацея, не только чужие днс и хостс спасают, но и просто сокс-прокси.

Какой-то чатланин гравицапу прощелкал, или машинку перемещения с кучей зарядов, вот нашедшего счастливчика и взяли.

Это она для постоянного тока, который в тестере замкнутая, а для радиоволны соответствующей длины - там два плеча с максимальной амплитудой на кончиках, так что получающемуся переменному току живется в ней очень даже комфортно. А относительно рефлектора - он просто обязан быть продолжением земли, что касается переизлучения поглощаемого ЭМИ (читай-отражения), то там все нормально в любом случае, а вот всякие наводки будут стекать куда им и положено - в землю.

Не, они снифер тоже ставить не будут. Они открывают браузер, открывают линк, а потом говорят, что за нафиг!?!? ну! ну! ну!

Дык дядьки "оттуда" не будут проверять мои конфиги и убеждаться, что я его внес, они тыкнут на него в браузере, а он откроется, ибо никакой снифер его не проснифит в SSL-потоке. Остается помимо DPI еще и обычный блеклист на домены и IP ставить, и в таких случаях блочить по ним. Вопрос к max1976, Дятел, alks, с кем обсуждали реализацию блеклиста на SCE через CLI-FTP-CSV. Есть идеи (у меня была:) )?