EzDevInfo.com

How to Unban an IP properly with Fail2Ban

I'm using Fail2Ban on a server and I'm wondering how to unban an IP properly.

I know I can work with IPTables directly: iptables -D fail2ban-ssh <number>

But is there not a way to do it with the fail2ban-client?

In the manuals it states something like: fail2ban-client get ssh actionunban <IP>. But that doesn't work.

Also, I don't want to /etc/init.d/fail2ban restart as that would lose all the bans in the list.

How can I port forward with iptables?

I want connections coming in on ppp0 on port 8001 to be routed to 192.168.1.200 on eth0 on port 8080.

I've got these two rules

-A PREROUTING  -p tcp -m tcp --dport 8001 -j DNAT --to-destination 192.168.1.200:8080

-A FORWARD -m state -p tcp -d 192.168.1.200 --dport 8080 --state NEW,ESTABLISHED,RELATED -j ACCEPT

and it doesn't work. What am I missing?

How can I block all traffic *except* Tor?

On a Linux system, is there a way to block all in and outbound traffic unless it passes through the Tor network. This includes any form of IP communication, not just TCP connections. For example I want UDP to be completely blocked since it cannot pass through Tor. I want this systems Internet usage to be entirely anonymous, and I don't want any applications leaking.

I realize this might be complicated because Tor itself needs to communicate with relay nodes somehow.

Windows equivalent of iptables?

Dumb question:

Is there an equivalent of iptables on Windows? Could I install one via cygwin?

The real question: how can I accomplish on Windows what I can accomplish via iptables? Just looking for basic firewall functionality (e.g. blocking certain IP addresses)

Iptables, what's the difference between -m state and -m conntrack?

What's the practical difference between:

iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

and

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Which one is best to use?

Thank you.

IPTABLES - Limit rate of a specific incoming IP

I do not wish to limit the rate of a specific service. My goals is to limit rate based solely on the incoming IP address. For example using a pseudo-rule:

john.domain.local (192.168.1.100) can only download from our httpd/ftp servers at "10KB/s" (instead of 1MB/s)

How could I rate limit using IPTables based on incoming IP addresses?

Why not block ICMP?

I think I almost have my iptables setup complete on my CentOS 5.3 system. Here is my script...

# Establish a clean slate
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -F # Flush all rules
iptables -X # Delete all chains

# Disable routing. Drop packets if they reach the end of the chain.
iptables -P FORWARD DROP

# Drop all packets with a bad state
iptables -A INPUT -m state --state INVALID -j DROP
# Accept any packets that have something to do with ones we've sent on outbound
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# Accept any packets coming or going on localhost (this can be very important)
iptables -A INPUT -i lo -j ACCEPT
# Accept ICMP
iptables -A INPUT -p icmp -j ACCEPT

# Allow ssh
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# Allow httpd
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
# Allow SSL
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Block all other traffic 
iptables -A INPUT -j DROP

For context, this machine is a Virtual Private Server Web app host.

In a previous question, Lee B said that I should "lock down ICMP a bit more." Why not just block it altogether? What would happen if I did that (what bad thing would happen)?

If I need to not block ICMP, how could I go about locking it down more?

REJECT vs DROP when using iptables

Is there any reason why I would want to have

iptables -A INPUT -j REJECT

instead of

iptables -A INPUT -j DROP

iptables Tips & Tricks

I'm sure Linux sysadmins are quite familiar with iptables, the userland interface to the netfilter packet-filtering framework.

Now, this "Question" is meant to be a Community Wiki for collecting together various bits-n-pieces of iptables wisdom. Nothing is too common or too obscure. Post anything you know that would help others make the most of iptables.

How do you PREPEND an iptables rather than APPEND?

Pretty basic question.. How do you PREPEND an iptables rather than APPEND?

I have DROP statements at the bottom of my rules. I have software to add new rules but adding rules after DROP statements isn't good. Every time I want to add a new rule I have to flush the table which is inefficient. Is there a way to prepend a rule i.e. add a rule to the top of the table rather than the bottom?

Many thanks.

Use IPtables or null route for blacklisting about 1 million IP addresses?

I've come across a situation where a client needs to blacklist a set of just under 1 million individual IP addresses (no subnets), and network performance is a concern. While I would conjecture that IPTables rules would have less of a performance impact than routes, that's just conjecture.

Does anyone have any solid evidence or other justification for favoring either IPTables or null routing as solution for blacklisting long lists of IP addresses? In this case everything is automated, so ease-of-use isn't really a concern.

EDIT 26-Nov-11

After some testing and development, it appears that none of these options are workable. It appears that both route lookups and iptables do linear searches through the ruleset, and take simply too long to process this many rules. On modern hardware, putting 1M items in an iptables blacklist slows the server down to about 2 dozen packets per second. So IPTables and null routes are out.

ipset, as recommended by Jimmy Hedman, would be great, except that it doesn't allow you to track more than 65536 addresses in a set, so I can't even try to use it unless someone has any ideas.

Apparently the only solution for blocking this many IPs is doing an indexed lookup in the application layer. Is that not so?

More Information:

The usage case in this instance is blocking a "known offenders" list of IP addresses from accessing static content on a web server. FWIW, doing blocking through Apache's Deny from is equally slow (if not more so) as it also does a linear scan.

FYI: Final working solution was to use apache's mod_rewrite in conjunction with a berkeley DB map to do lookups against the blacklist. The indexed nature of berkeley DBs allowed the list to scale with O(log N) performance.

How to do the port forwarding from one ip to another ip in same network?

I would like do some NAT in iptables. So that, all the packets coming to 192.168.12.87 and port 80 will be forwarded to 192.168.12.77 port 80.

How to do this with iptables?

Or

Any other ways to achieve the same?

Iptables: How to allow only one ip through specific port?

How can I on my ubuntu server, in Iptables only allow one IP adress on a specific port?

Thanks

What is the correct way to open a range of ports in iptables

I have come across articles advising for the following:

iptables -A INPUT -p tcp 1000:2000 -j ACCEPT

And others stating that the above will not work and iptables only supports multiple port declarations with the --multiport option.

Is there a correct way to open many ports with iptables?

What is the point of the docker-proxy process? Why is a userspace tcp proxy needed?

I have noticed that there is docker-proxy process running for each published port. What is the purpose of this process? Why is a user space tcp proxy needed for this?

$ ps -Af | grep proxy
root      4776  1987  0 01:25 ?        00:00:00 docker-proxy -proto tcp -host-ip 127.0.0.1 -host-port 22222 -container-ip 172.17.0.2 -container-port 22
root      4829  1987  0 01:25 ?        00:00:00 docker-proxy -proto tcp -host-ip 127.0.0.1 -host-port 5555 -container-ip 172.17.0.3 -container-port 5555

and some related iptable rules created by docker:

$ sudo iptables -t nat -L -n -v
Chain PREROUTING (policy ACCEPT 1 packets, 263 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DOCKER     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type LOCAL

Chain INPUT (policy ACCEPT 1 packets, 263 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 1748 packets, 139K bytes)
 pkts bytes target     prot opt in     out     source               destination         
   32  7200 DOCKER     all  --  *      *       0.0.0.0/0           !127.0.0.0/8          ADDRTYPE match dst-type LOCAL

Chain POSTROUTING (policy ACCEPT 1719 packets, 132K bytes)
 pkts bytes target     prot opt in     out     source               destination         
   32  7200 MASQUERADE  all  --  *      !docker0  172.17.0.0/16        0.0.0.0/0           

Chain DOCKER (2 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DNAT       tcp  --  !docker0 *       0.0.0.0/0            127.0.0.1            tcp dpt:22222 to:172.17.0.2:22
    0     0 DNAT       tcp  --  !docker0 *       0.0.0.0/0            127.0.0.1            tcp dpt:5555 to:172.17.0.3:5555