iptables-save > /root/firewall_rules.backup

For older Linux kernels you have an option of stopping service iptables with service iptables stop but if you are on the new kernel, you just need to wipe out all the policies and allow all traffic through the firewall. This is as good as you are stopping the firewall.

Use below list of commands to do that.
iptables -F
iptables -X
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

Where –

-F: Flush all policy chains
-X: Delete user-defined chains
-P INPUT/OUTPUT/FORWARD: Accept specified traffic

Once done, check current firewall policies. It should look like below which means everything is accepted (as good as your firewall is disabled/stopped)
iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

 Chain FORWARD (policy ACCEPT)
 target     prot opt source               destination

 Chain OUTPUT (policy ACCEPT)
 target     prot opt source               destination

If you are using other Linux distribution such as Debian / Ubuntu / Suse / Slackware Linux etc., try the following generic procedure. First, save the current firewall rules, type:

    iptables-save > /root/firewall.rules

OR

    sudo iptables-save > /root/firewall.rules

Next, type the following commands (login as the root) as bash prompt:

iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT 

Or create a shell script as follows and run it to disable the firewall:

First, a mini-primer on iptables.

iptables is both a command and the name of the Linux firewall subsystem. The command is used to set up firewall rules in RAM. The iptables firewall rules are arranged first into tables: there is the default filter table, but also nat, mangle, raw and security tables, for various purposes. fail2ban is doing traffic filtering, so it uses the filter table.

The tables are then further divisible into filter chains. Each table has certain standard chains: for the filter table, the standard chains are INPUT, FORWARD and OUTPUT. The FORWARD chain is only used when the system is configured to route traffic for other systems. The INPUT chain deals with incoming traffic to this system.

If fail2ban added its rules directly to the INPUT chain and wiped that chain clean when all the bans expired, then you would have to turn over full control of your firewall input rules to fail2ban - you could not easily have any custom firewall rules in addition to what fail2ban does. This is clearly not desirable, so fail2ban won't do that.

Instead, fail2ban creates its own filter chain it can fully manage on its own, and adds on start-up a single rule to the INPUT chain to send any matching traffic to be processed through fail2ban's chain.

For example, when configured to protect sshd, fail2ban should be executing these commands at start-up:

 iptables -N f2b-sshd
 iptables -A f2b-sshd -j RETURN
 iptables -I INPUT -p tcp -m multiport --dports <TCP ports configured for sshd protection> -j f2b-sshd

These commands create a f2b-sshd filter chain, set RETURN as its last rule (so that when any fail2ban rules have been processed, the normal processing of INPUT rules will continue as without fail2ban, and finally, add a rule to the beginning of the INPUT table to catch any SSH traffic and send it first to the f2b-sshd chain.

Now, when fail2ban needs to ban an IP address for SSH use, it will just insert a new rule to the f2b-sshd chain.

If you are using firewalld or some other system that manages iptables firewall rules for you, or if you clear all the iptables rules manually, then these initial rules, and possibly the entire f2b-sshd filter chain, may be wiped out. You should make sure that any firewall management tool you might be using maintains that initial rule in the INPUT chain and doesn't touch the f2b-sshd chain at all.

I know this is an old thread but this is what pops up on a google search for this subject. I didn't see anyone give the most correct answer (imo) so here it is.

To change the Linux named port definition globally go to
/etc/services

ssh             22/tcp
ssh             22/udp

There is no need to change anything in the fail2ban configuration or in any other application that uses Linux named ports.

While connecting to your server through SSH can be very secure, the SSH daemon itself is a service that must be exposed to the Internet to function properly. This comes with some inherent risk and offers a vector of attack for would-be assailants.

Any service that is exposed to the network is a potential target in this way. If you pay attention to application logs for these services, you will often see repeated, systematic login attempts that represent brute-force attacks by users and bots alike.

A service called Fail2ban can mitigate this problem by creating rules that automatically alter your iptables firewall configuration based on a predefined number of unsuccessful login attempts. This will allow your server to respond to illegitimate access attempts without intervention from you.

In this guide, we’ll cover how to install and use Fail2ban on a CentOS 7 server.

Any service that is exposed to the internet is susceptible to attacks from malicious parties. If your service requires authentication, illegitimate users and bots will attempt to break into your system by repeatedly trying to authenticate using different credentials.

A common example of this is with SSH, which will be the subject of bot attacks that attempt to brute force common account names. Luckily, services like fail2ban were created to help us mitigate these attacks.

Fail2ban works by dynamically altering the firewall rules to ban addresses that have unsuccessfully attempted to log in a certain number of times. In a previous guide, we discussed how to get fail2ban up and running on Ubuntu 14.04.

In this guide, we’ll discuss in more depth how fail2ban actually works and how you can use this knowledge to modify or extend the behavior of this service.

The Basic Concept
The basic idea behind fail2ban is to monitor the logs of common services to spot patterns in authentication failures.

When fail2ban is configured to monitor the logs of a service, it looks at a filter that has been configured specific to that service. The filter is designed to identify authentication failures for that specific service through the use of complex regular expressions.

Here we will discuss how to block website on MikroTik? how to block domain in MikroTik router and how to block social media websites on MikroTik, like Youtube, Facebook, Twitter.

Thanks to crazy-max:
https://github.com/crazy-max/WindowsSpyBlocker

Windows Update & Windows Telemetry IP address lists //

Reroute Windows Updates via VPN
/ip firewall mangle
add action=mark-connection chain=prerouting dst-address-list=windows_update new-connection-mark=\
c_windows_update passthrough=yes
add action=mark-packet chain=prerouting connection-mark=c_windows_update \
new-packet-mark=p_windows_update passthrough=yes
add action=mark-routing chain=prerouting new-routing-mark=VPN packet-mark=p_windows_update passthrough=no

 /ip route

add distance=1 gateway=<your-vpn-gateway> routing-mark=VPN

One of the best solutions so far is to force everyone on the network to use a dns resolver you control and block the dns request for this domain.

/ip firewall nat

add action=dst-nat chain=dstnat dst-address=!<dns-server> dst-port=53 \
protocol=udp to-addresses=<dns-server> to-ports=53
add action=dst-nat chain=dstnat dst-address=!<dns-server> dst-port=53 \
protocol=tcp to-addresses=<dns-server> to-ports=53

Then either create a static dns entry for download.windowsupdate.com pointing to 127.0.0.1 or use the layer7 filter to identify and drop the request.

If you still don’t have any internets after power-cycling and your modem showing everything sync’ed and online, you may be falling afoul of a weirdness in OpnSense’s default gateway configs. By default, it will mark a gateway as “down” if it doesn’t return pings… but many ISP gateway addresses (not the WAN address your router gets, the one just upstream of it) don’t return pings. So, OpnSense reports it as down and refuses to even try slinging packets through it.