Hello,

I am using this as "inteligent" firewall from attacks on port 22 but it can also be used for telnet and more... I always open only port 22 from "everywhere". Because it add dynamic address to address list, after reboot all is droped, so everyday it converting all blacklisted to static. If you have any tip for doing it better, I will be glad for it

ros code

/ip firewall filter
add action=reject chain=input comment=\
    "SSH PublicIP reject if blacklisted" connection-state=\
    new dst-address-list=PublicIP dst-port=22,8291 protocol=tcp \
    reject-with=icmp-admin-prohibited src-address-list=ssh_blacklist
add action=add-src-to-address-list address-list=ssh_blacklist chain=\
    input comment="SSH to PublicIP blacklisting blacklist" \
    connection-state=new dst-address-list=PublicIP dst-port=22 \
    protocol=tcp src-address-list=ssh_stage2
add action=add-src-to-address-list address-list=ssh_stage2 \
    address-list-timeout=1m chain=input comment=\
    "SSH to PublicIP blacklisting stage 2" connection-state=\
    new dst-address-list=PublicIP dst-port=22 protocol=tcp \
    src-address-list=ssh_stage1
add action=add-src-to-address-list address-list=ssh_stage1 \
    address-list-timeout=1m chain=input comment=\
    "SSH to PublicIP blacklisting stage 1" connection-state=\
    new dst-address-list=PublicIP dst-port=22 protocol=tcp
add chain=input comment=\
    "SSH to PublicIP accept if not blacklisted" \
    connection-state=new dst-address-list=PublicIP dst-port=22 \
    protocol=tcp src-address-list=!ssh_blacklist
/system scheduler
add comment="Auto convert dynamic blacklist to static" interval=1d \
    name=blacklist-forever on-event=":global IP\r\
    \n:foreach DIP in [/ip firewall address-list find list=ssh_blackli\
    st dynamic=yes]\\\r\
    \ndo { \\\r\
    \n\r\
    \n:set IP [/ip firewall address-list get \$DIP address]\r\
    \n/ip firewall address-list remove \$DIP\r\
    \n/ip firewall address-list add list=ssh_blacklist address=\$IP\r\
    \n\r\
    \n}" policy="ftp,reboot,read,write,policy,test,winbox,password,sni\
    ff,sensitive,api" start-date=apr/10/2014 start-time=01:01:00

Don't use port 22 for ssh.

Don't use port 22 for ssh.

I want to use standard port as usual I'm not enemy for RFC Port 22 is for SSH as same as 25 for SMTP. I was thinking about better script or rules not this

Then you will have standard security - as usual

Then you will have standard security - as usual

I don't think that blacklisting is usual security Port numbers aren't for fun. Every port has specific purpose

Then you will have standard security - as usual

I don't think that blacklisting is usual security Port numbers aren't for fun. Every port has specific purpose When company uses ISO standards, you must also think twice and uses other standards as they are.

ssh port on network devices should NOT be accessible from everywhere. to limit the access to any kind of management interface (ssh,web,api,....) is best you can do for security. furthermore it good to monitor logs. once your ssh is only accessible from your office/network operating center/vpn you don't face the usual scans and multiple failed logins should trigger an alert.

ssh port on network devices should NOT be accessible from everywhere. to limit the access to any kind of management interface (ssh,web,api,....) is best you can do for security. furthermore it good to monitor logs. once your ssh is only accessible from your office/network operating center/vpn you don't face the usual scans and multiple failed logins should trigger an alert.

I know that... This is only one device with opened access to ssh from everywhere. This device is backdoor. I had port knocking, but it is complicated sometimes. Bruteforces are stopped using rules above. I am asking for any tips for improvments rules or script not technology used

Lighten up.

Security by obscurity its not security.

The issue i have found with dynamic blacklist for ssh ports is your ip can end up on the list as well even if for a limited time. if you were to do many ssh's within your time frame

Does slow down password hack attempts.

Best to also only use root with nopassword, and/or force every one to use keys instead of passwords

plus why not move all the ssh check to its own chain then call it from the input ... really depends on the size of your chain etc

Back to security
Do what you think is best for you, but know what the risks are..

Lighten up.

Security by obscurity its not security.

The issue i have found with dynamic blacklist for ssh ports is your ip can end up on the list as well even if for a limited time. if you were to do many ssh's within your time frame

Does slow down password hack attempts.

Best to also only use root with nopassword, and/or force every one to use keys instead of passwords

plus why not move all the ssh check to its own chain then call it from the input ... really depends on the size of your chain etc

Back to security
Do what you think is best for you, but know what the risks are..

Totally agree with all these points.

If you have an open SSH-service you want to blacklist even if you have strong password or keybased login only, just because the bruteforce/dictionary attack taking cpu resources and flooding your logs.
I prefer also key based login for ssh. We also use smartcards to store the rsa-key. Unfortunately ROS does not support rsa kes for ssh auth

Back to topic: have you ( the author ) any problem with you current approach? As already mentioned by AlexS it's a it risky to backlist forever as you may lockout yourself. So you could use one blacklist with a 10-30 minutes timeout. That's usually enough that the attacker ( which is mostly an automatic process somewhere on an already compromised system ) give up.

Lighten up.

Security by obscurity its not security.

The issue i have found with dynamic blacklist for ssh ports is your ip can end up on the list as well even if for a limited time. if you were to do many ssh's within your time frame

Does slow down password hack attempts.

Best to also only use root with nopassword, and/or force every one to use keys instead of passwords

plus why not move all the ssh check to its own chain then call it from the input ... really depends on the size of your chain etc

Back to security
Do what you think is best for you, but know what the risks are..

Totally agree with all these points.

If you have an open SSH-service you want to blacklist even if you have strong password or keybased login only, just because the bruteforce/dictionary attack taking cpu resources and flooding your logs.
I prefer also key based login for ssh. We also use smartcards to store the rsa-key. Unfortunately ROS does not support rsa kes for ssh auth

Back to topic: have you ( the author ) any problem with you current approach? As already mentioned by AlexS it's a it risky to backlist forever as you may lockout yourself. So you could use one blacklist with a 10-30 minutes timeout. That's usually enough that the attacker ( which is mostly an automatic process somewhere on an already compromised system ) give up.

Thanks for your reply, I locked connection for me few times in history. What expire time for blacklistng you prefer? You think 10-30 minutes is good enough?

Thanks for your reply, I locked connection for me few times in history. What expire time for blacklistng you prefer? You think 10-30 minutes is good enough?

Something like that i used in the past, it's usually good enough. Most of those attacks try to find user accounts with weak passwords on linux/unix boxes. Once they get into an account they download some scripts to use your host for ddos attacks and so. Such attacks are not targeted. The attacker don't want to compromise your server/device they just want some device. If your system is not answering anymore they just move over to the next target.

If someone really wants to get exactly in your systems a blacklist will not help much against it. For targeted attacks you use other ways to protected your network. Such as IDS,log monitoring, etc