It can be. This this case however it is limited to eth0, tcp, port 22. If any of those don't match there will be no parsing and thus no impact. Another mitigating factor is that we are only looking at specific byte regions of the packet so parsing is minimized. On busy SFTP servers I would probably avoid using such rules if CPU load is becoming a problem. For most people this will not even register in htop or vmstat. There are also ways to use this string check in combination with ipset and/or xt_recent to minimize the times we see a packet from a bot. Here is an example using an IPSet called "bots" that we drop early on in the raw table and also use in the filter outbound rules to reset openssh trying to respond the first time we see the bad string so we close the socket earlier.

In a startup / init script / systemd unit file:

    # IPv4
    ipset flush bots 2>/dev/null
    ipset create bots hash:ip hashsize 2048 maxelem 65536 timeout 604800 netmask 24 2>/dev/null

    # IPv6
    ipset flush bots6 2>/dev/null
    ipset create bots6 hash:ip hashsize 2048 maxelem 65536 timeout 604800 netmask 64 family inet6 2>/dev/null

In this example I am using a bigger netmask much in the way name servers rrl rate limit.

In the raw table, drop bots we saw for a week:

    -A PREROUTING -i eth0 -p tcp -m tcp --dport 22:80 -d [server ip] -m set --match-set bots src,dst -j DROP
    -A PREROUTING -i eth0 -p tcp -m tcp --dport 22 -d [server ip] -m string --string "SSH-2.0-libssh" --algo bm --from 10 --to 60 -j SET --add-set bots src --exist --timeout 604800

In the filter table outbound rules:

    -A OUTPUT -o eth0 -p tcp -m tcp --sport 22 -m set --match-set bots dst -j REJECT --reject-with tcp-reset

This should only be performed on servers that one has console / out-of-band access to, after exhaustive testing.