On 06/17/2014 01:46 AM, Bret Taylor wrote:
Get rid of fail2ban, it's not needed. Just write a proper firewall.
Are you series?? There are applications that fail2ban offers them things which others just can't..
If you can email me the ip for your servers and also the root password and allow me in your INPUT all over the place I will leave you a message in the server.(hope you understand jokes)
All The Bests, Eliezer
[previous article hasn't appeared on gmane yet]
On 2014-06-16, Eliezer Croitoru eliezer@ngtech.co.il wrote:
On 06/17/2014 01:46 AM, Bret Taylor wrote:
Get rid of fail2ban, it's not needed. Just write a proper firewall.
Are you series?? There are applications that fail2ban offers them things which others just can't..
Indeed, fail2ban and their ilk (e.g. my new favorite, sshguard) modify iptables rules in response to excessive failed login attempts. A ''proper firewall'' with just static iptables rules can't do that. And with so many pwn3d hosts out there being used to bounce attacks off of, it is foolish to rely on static rules alone to fend off these attacks.
Much better of course are static firewall rules that blocks off all but a few whitelisted hosts. But that is much less flexible for users.
--keith
All of the suggestions are graciously accepted, however, I was actually asking what I was doing wrong with iptables, and why, with the rules I put in place, someone was still able to connect to my machine.
I understand there might be better ways, but if I don't understand what I did wrong last time, how am I going to figure out how to deny all, then allow selected, ehrn I can't seem to allow all and deny selected.
There must be a misunderstanding on my part about how iptables are supposed to work.
-chuck
On Mon, 2014-06-16 at 21:42 -0500, Chuck Campbell wrote:
All of the suggestions are graciously accepted, however, I was actually asking what I was doing wrong with iptables, and why, with the rules I put in place, someone was still able to connect to my machine.
I understand there might be better ways, but if I don't understand what I did wrong last time, how am I going to figure out how to deny all, then allow selected, ehrn I can't seem to allow all and deny selected.
There must be a misunderstanding on my part about how iptables are supposed to work.
-chuck
As John R Pierce mentioned one of your first rule in the chain is "RH-Firewall-1-INPUT all -- anywhere anywhere", this simply mean everything with "DROP" after it will be ignored. iptables will work its way down the chain, therefore you have to options 1. remove that line or 2. move it at the bottom of the chain.
On 6/16/2014 9:44 PM, Earl Ramirez wrote:
On Mon, 2014-06-16 at 21:42 -0500, Chuck Campbell wrote:
All of the suggestions are graciously accepted, however, I was actually asking what I was doing wrong with iptables, and why, with the rules I put in place, someone was still able to connect to my machine.
I understand there might be better ways, but if I don't understand what I did wrong last time, how am I going to figure out how to deny all, then allow selected, ehrn I can't seem to allow all and deny selected.
There must be a misunderstanding on my part about how iptables are supposed to work.
-chuck
As John R Pierce mentioned one of your first rule in the chain is "RH-Firewall-1-INPUT all -- anywhere anywhere", this simply mean everything with "DROP" after it will be ignored. iptables will work its way down the chain, therefore you have to options
- remove that line or
- move it at the bottom of the chain.
I am clearly missing some emails, because I didn't see a reply from John R Pierce. My apologies. I appreciate you restating this. I'll try to go make sense of iptables, given the insight,
thanks, -chuck
As John R Pierce mentioned one of your first rule in the chain is "RH-Firewall-1-INPUT all -- anywhere anywhere", this simply mean everything with "DROP" after it will be ignored. iptables will work its way down the chain, therefore you have to options
- remove that line or
- move it at the bottom of the chain.
I am clearly missing some emails, because I didn't see a reply from John R Pierce. My apologies. I appreciate you restating this. I'll try to go make sense of iptables, given the insight,
thanks, -chuck
OK, I went to the list archive and found the email in question. Also, one after it that asked how I added these rules.
I ran a script after fail2ban was started. It looks like this: #!/bin/sh iptables -A INPUT -s 116.10.191.0/24 -j DROP iptables -A INPUT -s 183.136.220.0/24 -j DROP iptables -A INPUT -s 183.136.221.0/24 -j DROP iptables -A INPUT -s 183.136.222.0/24 -j DROP iptables -A INPUT -s 183.136.223.0/24 -j DROP iptables -A INPUT -s 122.224.11.0/24 -j DROP iptables -A INPUT -s 219.138.0.0/16 -j DROP
so, how do I get them in front of the RH-Firewall-1-INPUT, or do I add them to that chain?
-chuck
On 6/16/2014 8:52 PM, Chuck Campbell wrote:
I ran a script after fail2ban was started. It looks like this: #!/bin/sh iptables -A INPUT -s 116.10.191.0/24 -j DROP iptables -A INPUT -s 183.136.220.0/24 -j DROP iptables -A INPUT -s 183.136.221.0/24 -j DROP iptables -A INPUT -s 183.136.222.0/24 -j DROP iptables -A INPUT -s 183.136.223.0/24 -j DROP iptables -A INPUT -s 122.224.11.0/24 -j DROP iptables -A INPUT -s 219.138.0.0/16 -j DROP
so, how do I get them in front of the RH-Firewall-1-INPUT, or do I add them to that chain?
use -I (insert) rather than -A (append).
OR
specify chain RH-Firewall-1-INPUT rather than INPUT
OR, better
use system-config-firewall rather than running your own iptables commands. this manages the rules used by the RH firewall scripts invoked by the iptables service which is run at boot time.
also, if you do manually add iptables rules, you can use `service iptables save` to remember these changes, instead of running them from your own scripts. these changes get saved to /etc/sysconfig/iptables
On 6/16/2014 11:08 PM, John R Pierce wrote:
On 6/16/2014 8:52 PM, Chuck Campbell wrote:
I ran a script after fail2ban was started. It looks like this: #!/bin/sh iptables -A INPUT -s 116.10.191.0/24 -j DROP iptables -A INPUT -s 183.136.220.0/24 -j DROP iptables -A INPUT -s 183.136.221.0/24 -j DROP iptables -A INPUT -s 183.136.222.0/24 -j DROP iptables -A INPUT -s 183.136.223.0/24 -j DROP iptables -A INPUT -s 122.224.11.0/24 -j DROP iptables -A INPUT -s 219.138.0.0/16 -j DROP
so, how do I get them in front of the RH-Firewall-1-INPUT, or do I add them to that chain?
use -I (insert) rather than -A (append).
OR
specify chain RH-Firewall-1-INPUT rather than INPUT
I used the RH-Firewall-1-INPUT chain, and -I, defaulting to position 1, and all is working as I had anticipated.
It is working as expected, killing all of those rolling ip attempts. I was loathe to use system-config-firewall, because I wasn't sure it wouldn't drop something I needed, or forgot to include, and it would have wiped out the existong ruleset. I'll experiment with that when I am physically in front of the server, instead of remote from it. I would have had no quick remedy if I messed it up.
Thanks you for the clear concise explanation.
-chuck
On 6/17/2014 2:14 PM, Chuck Campbell wrote:
I'll experiment with that when I am physically in front of the server, instead of remote from it. I would have had no quick remedy if I messed it up.
thats why all my servers have remote consoles :)
-
Chuck Campbell -
Earl Ramirez -
Eliezer Croitoru -
John R Pierce -
Keith Keller