ru.unix.bsd

From: Alex Korchmar Eugene Grosbein wrote: EG> Попробуй вот это в дополнение к моему предыдущему патчу: EG> https://svnweb.freebsd.org/base?view=revision&revision=365830 судя по содержимому, он же не позволит мне увидеть разделы до необратимых изменений ? Тогда сорри, отложено в долгий ящик - где-то найти ненужный sata, все это воссоздать и пытаться потом чинить. В принципе, к декабрю из штатов приедет новая порция, можно будет на них экспериментировать. > Alex P.S. если кому бриджей-коробок - обращайтесь, в Москве бесплатно при условии самовывоза, в дальнюю пердь - почтой за ваш счет. Питальник, напоминаю, американский.

16 сент. 2020, среда, в 21:21 NOVT, Alex Korchmar написал(а): EG>> Вот эти сектора и дай, только чтобы мне не пришлось вручную их впихивать AK> http://linux.e-moe.ru/wrk/sdc Попробуй вот это в дополнение к моему предыдущему патчу: https://svnweb.freebsd.org/base?view=revision&revision=365830 Eugene -- Choose no life

16 сент. 2020, среда, в 14:50 NOVT, Dmitry Dolzenko написал(а): DD> А комп на старом 775 сокете типа ASUS p5k увидит 6 гигабайтный диск, DD> если он 2й, не системный? Увидит, даже если он загрузочный. Это даже не 8GB. Eugene -- И друзей успокоив и ближних любя, Мы на роли героев вводили себя.

From: Alex Korchmar Eugene Grosbein wrote: EG> Вот эти сектора и дай, только чтобы мне не пришлось вручную их впихивать http://linux.e-moe.ru/wrk/sdc > Alex

From: Dmitry Dolzenko Приветствую, А комп на старом 775 сокете типа ASUS p5k увидит 6 гигабайтный диск, если он 2й, не системный? FreeBSD 12. /D

15 сент. 2020, вторник, в 21:38 NOVT, Ruslan Suleimanov написал(а): RS> с правилами выше что я скинул показывает чудесные результаты, tcp.blackhole в RS> значении 2 вообще крутая вещь ! :) Да, крутая, пока ты не столкнёшься с софтом, писанным людьми, которые понятия не имеют о системном администрировании (это почти все программисты), типа веб-фреймворка, который работает в связке с базой данных и автор которого свято уверен, что подключаться к MySQL надо обязательно по TCP на 127.0.0.1, а уж если это не выходит, то так уж и быть, можно поглядеть в собственные настройки. Пока tcp.blackhole не выставлено в 2, это даже работает, потому что отлуп (TCP RST) при подключении к несуществующему сокету на 127.0.0.1:3306 приходит моментально и веб-юзер не ощущает задержки перед второй попыткой подключения к правильному адресу базы. Hо если ты выставил tcp.blackhole=2, то фреймворк отвалится от первой попытки только по долгому таймауту, достаточному, чтобы юзеровский браузер бросил ждать раньше. RS> единственное както неправильно работает allow ip from any to any setup limit RS> src-addr 10 при том что у меня по умолчанию ipfw allow для всего. RS> Подскажи пжлст как правильно перестроить правило чтобы разрешать с одного IP RS> делать не больше 10 подключений ? Во-первых, не забывай добавлять направление (in или out) и имя интерфейса, тобы самого себя не резать, во-вторых, слово "setup" осмыслено не для любых IP-пакетов, а только для TCP. В UDP, GRE и прочих ESP нету никакого setup. В третьих, ставь такое правило с limit src-addr 10 в начало, типа такого: ipfw add 2000 skipto 2100 tcp from any to any setup in recv $extif limit src-addr 10 ipfw add 2010 reset tcp from any to any setup in recv $extif остальные правила с номера 2100 и далее, включая "allow для всего". Это позволяет в дополнение к лимиту на количество соединений ещё какие-нибудь фильтры применять при необходимости. Eugene

Привет, Eugene! Ответ на сообщение Eugene Grosbein (2:5006/1) к Ruslan Suleimanov, написанное 15 сен 20 в 04:58: EG> 14 сент. 2020, понедельник, в 23:37 NOVT, Ruslan Suleimanov EG> написал(а): RS>> # Запрет X-сканирования: RS>> add 1001 reject log tcp from any to any tcpflags fin, RS>> syn, rst, psh, ack, urg RS>> # Запрет N-сканирования: RS>> add 1002 reject log tcp from any to any tcpflags !fin, RS>> !syn, !rst, !psh, !ack, !urg RS>> # Запрет FIN-сканирования: RS>> add 1003 reject log tcp from any to any not established RS>> tcpflags fin EG> Чушь полная. Ты на своей стороне не можешь запретить сканировать себя EG> никаким образом. Самое большое, что ты можешь сделать, это дропнуть EG> входящие пакеты после того, как они *УЖЕ* пришли к тебе, EG> но это вовсе не правило reject log tcp - хуже "решения" и придумать EG> сложно, потому что оно мало того что шлет TCP RST в ответ, EG> потенциально заставляя твою систему флудить невинную жертву EG> по подставленному адресу источника, но ещё и нагружает твой CPU EG> бессмысленной генерацией логов. EG> А дропнуть бессмысленный входящий флуд ядро может само без всякого EG> файрвола, тем более что чем больше правил в файрволе, тем больше EG> нагрузка на обработку этих правил. EG> Открой для себя sysctl net.inet.tcp.blackhole и EG> sysctl net.inet.udp.blackhole, а так же подумай, EG> почему они не включены по умолчанию. с правилами выше что я скинул показывает чудесные результаты, tcp.blackhole в значении 2 вообще крутая вещь ! :) единственное както неправильно работает allow ip from any to any setup limit src-addr 10 при том что у меня по умолчанию ipfw allow для всего. Подскажи пжлст как правильно перестроить правило чтобы разрешать с одного IP делать не больше 10 подключений ? WBR, Ruslan Suleimanov. JabberID: rs@captflint.com

From: Alex Korchmar Ruslan Suleimanov wrote: RS> Это правило для декстопа без инета ) можно и для сервера - без инета. Hо суть ты уловил верно - нет интернета - тебя никто не просканирует. А если интернет есть - надо учиться жить с интернетом. По большей части, если это не граничный маршрутизатор, ipfw тут вообще не нужен, гораздо больше толку от hosts.allow, но и он лишь дополнительный уровень поверх просто грамотной настройки сервисов. RS> Лучшее решение: нет, это вредная и опасная чушь (как и 90% впопеннетовских рецептов, а остальные 10 требуют понимания что ты делаешь и зачем) Тебя она ни от чего ни защищает, засыпает тебе мусором логи, а вот остальным так настроенный хост может понасоздавать проблем. > Alex

14 сент. 2020, понедельник, в 23:37 NOVT, Ruslan Suleimanov написал(а): RS> # Запрет X-сканирования: RS> add 1001 reject log tcp from any to any tcpflags fin, syn, rst, psh, RS> ack, urg RS> # Запрет N-сканирования: RS> add 1002 reject log tcp from any to any tcpflags !fin, !syn, !rst, RS> !psh, !ack, !urg RS> # Запрет FIN-сканирования: RS> add 1003 reject log tcp from any to any not established tcpflags fin Чушь полная. Ты на своей стороне не можешь запретить сканировать себя никаким образом. Самое большое, что ты можешь сделать, это дропнуть входящие пакеты после того, как они *УЖЕ* пришли к тебе, но это вовсе не правило reject log tcp - хуже "решения" и придумать сложно, потому что оно мало того что шлет TCP RST в ответ, потенциально заставляя твою систему флудить невинную жертву по подставленному адресу источника, но ещё и нагружает твой CPU бессмысленной генерацией логов. А дропнуть бессмысленный входящий флуд ядро может само без всякого файрвола, тем более что чем больше правил в файрволе, тем больше нагрузка на обработку этих правил. Открой для себя sysctl net.inet.tcp.blackhole и sysctl net.inet.udp.blackhole, а так же подумай, почему они не включены по умолчанию. Если очень зудит, можешь попробовать использовать что то типа такого в /etc/sysctl.conf для маршрутизатора, который не предоставляет никаких сервисов сам на четвертом уровне TCP/IP (ssh не в счёт): net.inet.ip.random_id=1 net.inet.ip.redirect=0 net.inet.ip.ttl=80 net.inet.icmp.drop_redirect=1 net.inet.icmp.icmplim=80 net.inet.tcp.blackhole=1 net.inet.tcp.drop_synfin=1 net.inet.tcp.ecn.enable=1 net.inet.tcp.path_mtu_discovery=0 Hа современной FreeBSD 11 это обламывает nmap со сканированием и tcp-stack fingerpringint (удалённым определением OS), но это нельзя использовать на серверах с активным использованием TCP типа веб-прокси, почтовых серверах и прочих. Eugene

14 сент. 2020, понедельник, в 22:14 NOVT, Alex Korchmar написал(а): AK>>> так и делалось. Вот installworld я не делал - потому что не считал это AK>>> нужным. EG>> Это и не нужно, а может оказаться и вредно. AK> вредно - в том плане, что я теперь не могу вернуть то состояние, блин :-( Hа самом деле перепроверял я только на тот случай, если что-то не то смержили в stable/11 в самые последние дни (и оказалось, не так), потому что в последние пару недель я обновлял сорцами множество совершенно разных систем на разных процессорах, включая древние, без подобных проблем. Это у тебя что-то локальное было. Eugene