Профиль пользователя заблокирован сроком «навсегда» без указания причины
  • Странные данные SMART у SSD, из-за чего и когда менять диск?

    Gavric
    @Gavric
    Wear_Leveling_Count у Samsung 850 EVO рассчитывается исходя из того, что производитель считает ячейки TLC 3D V-NAND способными на 2100 циклов перезаписи. Реальные же тесты выносливости (https://3dnews.ru/938764) показывают, что в реальности они переносят в 6-7 раз больше перезаписей, и на 850 EVO даже ёмкостью 250 Гбайт можно записать более 2 Пбайт данных. Так что причин для беспокойства нет никаких.
    Расхождение же возможно по миллиону причин. Например, у дисков с завода разный объём резервной области. Это нормально, т.к. часть флеша, установленного в накопителе, всегда битая. И её отключают программным образом. Это прямо влияет на коэффициент усиления записи и вызывает расхождения в циклах перезаписи. Но в любом случае волноваться с Вашими показателями S.M.A.R.T. совершенно не о чем.
    Ответ написан
    Комментировать
  • Странные данные SMART у SSD, из-за чего и когда менять диск?

    Jump
    @Jump Куратор тега Твердотельные накопители
    Системный администратор со стажем.
    Wear_Leveling_Count не самый надежный параметр, все их считают по разному, и зачастую он то обнуляется, то вообще погоду показывает.
    Смотрите на Total_LBAs_Written, судя по нему записано на оба диска по 50тб, разница в записи 300гб.
    В принципе такое расхождение может быть вызвано тем что TRIM не доходит до одного из дисков.
    Хотя если у вас сервер, то лучше бы не полагаться на трим, а оставить приличный over provisioning.

    Как определить, когда пора менять проблемный диск?

    Ориентируйтесь по Total_LBAs_Written и отслеживайте нездоровые движения по Reallocated_Sector, Used_Rsvd_Blk_Cnt_Tot, Erase_Fail_Count_Total
    Ответ написан
    2 комментария
  • Фаервол iptables, модуль state - можно использовать как вид защиты?

    zhovner
    @zhovner
    Гик, задрот и богомол
    Во первых, не нужно светить рекурсивным DNS в интернет.

    Для bind это выглядит так:

    //disable recursive requests from outside
            allow-recursion { 127.0.0.1; 
                                       ::1; };


    Приведенные вами правила iptables никак не решают задачу защиты от dns amplification.


    В следствии, iptables разрешит принять запрос на 53 порт с сервера злоумышленника, а вот далее при отправке ответа на подставной сервер iptables сбросит ли соединение? Ответ ведь разрешен только на тот сервер, с которым установлено соединение.


    Так как в случае этой атаки используется UDP, никакие соединения не устанавливаются. Атакующий отправляет ОДИН UDP пакет с запросом (в котором source адрес заменен на атакуемый ip) и ваш сервер отправляет один пакет с ответом на этот запрос, на тот адрес который был указан в source. Состояние NEW,ESTABLISHED в таком случае вполне корректно.

    Атака с подменой source адреса не возможна в случае с TCP, так как для установления соединения используется несколько пакетов в обе стороны. SYN->ACK<--SYN_ACK и только после этого открывается соединение. А так как в случае с подменой исходящего адреса ответ сервера на SYN уйдет по другому адресу, соответственно на него никто не ответит SYN_ACK.

    Для решения вашей задачи нужно использовать ограничение запросов с одного адреса:

    # Requests per second
    RQS="15"
    
    # Requests per 7 seconds
    RQH="35"
    
    iptables -I INPUT -p udp --dport 53 -m state --state NEW -m recent --set --name DNSQF --rsource
    iptables -I INPUT -p udp --dport 53 -m state --state NEW -m recent --update --seconds 1 --hitcount ${RQS} --name DNSQF --rsource -j DROP
    iptables -I INPUT -p udp --dport 53 -m state --state NEW -m recent --set --name DNSHF --rsource
    iptables -I INPUT -p udp --dport 53 -m state --state NEW -m recent --update --seconds 7 --hitcount ${RQH} --name DNSHF --rsource -j DROP
    Ответ написан
    1 комментарий
  • Фаервол iptables, модуль state - можно использовать как вид защиты?

    vvpoloskin
    @vvpoloskin
    Инженер связи
    Подмена как раз делается на сетевом. Классическая маршрутизация проверяет только адрес назначения, соответственно на адрес источника ей наплевать. Это можно сделать, например, средствами NAT на любой железке, либо самостоятельно сгенерировать запрос скриптом.
    Конкретно по Вашей теме, что мешает повесить правила с разными состояниями, попробовать сделать запросы и посмотреть счетчики?

    P.S. используйте уже conntrack вместо state)
    Ответ написан
    1 комментарий