EvilMan

var points = [{x: 0, y: 0}, {x: 0, y: 50}, {x: 10, y: 50}, {x: 10, y: 0}];
var segLen = [];
var totalLen = 0;
for (var i = 0; i < points.length-1; i++) {
    var l = Math.sqrt((points[i+1].x-points[i].x)*(points[i+1].x-points[i].x)+
                      (points[i+1].y-points[i].y)*(points[i+1].y-points[i].y));
    segLen.push(l);
    totalLen += l;
}
var percent = 55;
var needLen = totalLen*percent/100;
for (var i = 0; i < points.length-1 && needLen > 0; i++)
    if (needLen >= segLen[i]) {
        // пройти путь points[i] - points[i+1]
        needLen -= segLen[i];
    } else {
        x = points[i].x+(points[i+1].x-points[i].x)*needLen/segLen[i];
        y = points[i].y+(points[i+1].y-points[i].y)*needLen/segLen[i];
        // пройти путь points[i] - {x, y}
        needLen = 0;
    }

echo c > /proc/sysrq-trigger

and на or замените. and оставляет отмеченные в маске биты неизменными, остальные обнуляет, or переводит отмеченные в 1 остальные оставляет неизменными.

SYN_RECV - это состояние tcp-соединения во время three-handshake, означающее что сервер принял пакет с установленным флагом SYN (запрос на соединение), отправил SYN/SYN-ACK клиенту и ожидает от клиента пакет с флагом ACK.

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

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

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

Если говорить обобщенно, то в Вашем случае, я думаю, проблему можно решить с помощью модуля recent в iptables. Уверен, его функционала Вам будет достаточно. Сможете обойтись несколькими правилами. Алгоритм следует применить примерно такой:

1. Сначала разрешаете входящий tcp-трафик по соединениям в состояниях ESTABLISHED и RELATED (модуль conntrack).

iptables -I INPUT 1 -p tcp -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

2. Открываете нужные порты, разрешая пропуск пакетов по этим правилам только в случаях если:
- установлен флаг SYN (опция --syn);
- соединение находится в состоянии NEW (модуль conntrack);
- не превышен лимит соединений с одного ip-адреса (модуль recent).
Примерно так:

iptables -A INPUT -p tcp -m multiport --dports 80,443 --syn -m conntrack --ctstate NEW -m recent --name webtraffic --update --seconds 5 --hitcount 16 -j DROP

iptables -A INPUT -p tcp -m multiport --dports 80,443 --syn -m conntrack --ctstate NEW -j ACCEPT

Первое правило будет применено только к пакетам с установленным флагом SYN, которые приходят с отдельно взятого IP-адреса со скоростью более 16 пакетов в течение 5 секунд. Этим правилом будет отброшен флуд.

Второе правило пропустит пакеты, не подошедшие под предыдущее правило (легитимный трафик).

Разумеется, все нужно адаптировать под Ваши условия и нагрузку. Подробности по модулям смотрите в man iptables-extensions. Настоятельно рекомендую ознакомиться с описанием модуля recent для лучшего понимания.

3. Дропаете весь остальной tcp-трафик либо отдельным правилом, либо политикой по-умолчанию.

Также, дабы легитимных пользователей не откидывало при попытке подключения, Вы можете увеличить очередь SYN-пакетов в sysctl, в соответствии с имеющимися системными ресурсами. За это отвечает параметр net.ipv4.tcp_max_syn_backlog, и уменьшить таймаут для соединений в состоянии SYN_RECV, за что отвечает параметр net.netfilter.nf_conntrack_tcp_timeout_syn_recv.
Рекомендуемые параметры индивидуальны для каждой системы. У меня используются такие:

net.ipv4.tcp_max_syn_backlog = 262144
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 20

Готовый загрузчик, конечно. Иначе так на нем и остановитесь, проверенно много раз многими людьми)

Удалите правило в цепочке INPUT с целью NFQUEUE
iptables -D INPUT 1

Никак не могу найти образ от свичей аля 2960 для gns3

А с каких пор там свитчи поддерживаются?

Ставьте роутер с etherswitch модулем, будет типа-свитч.

Или переходите на L2IOU, который малость получше будет, чем GNS3.

Что входы, а что состояния в данном случае- вопрос исключительно терминологический. Проблема в том, что в рамки классического описания/синтеза КА счетчики не вписываются. Поэтому в академическом стиле их описывают отдельно, т.е. КА имеет выход для управления этим счетчиком и вход, являющийся значением счетчика. Поэтому если вам необходимо синтезировать КА «на бумажке», то лучше поступить именно так.
Другое дело, если вы описываете ваш автомат «на практике» на каком-нибудь языке программирования или описания аппаратуры. Здесь плодить лишние сущности смысла никакого нет и счетчик с его сигналом управления интегрируется непосредственно в описание КА.
Я бы рекомендовал вам перерисовать ваш автомат в виде графа, а не таблицы — станет намсного нагляднее. Ну а для начала потренироваться на более простой версии — просто детектирования нажатия с дебаунсом.