Re: IPTables limits?
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
Karl Pearson wrote:
On Tue, October 21, 2008 12:12 pm, Rick Stevens wrote:Karl Pearson wrote:On Tue, October 21, 2008 11:16 am, Rick Stevens wrote:Karl Pearson wrote:I'm curious if there's a limit on how many iptables entries it takes to hammer a system. Okay, a better question: When am I running the risk of messing up my IP traffic if I add DROP entries in the INPUT rule of iptables?You do ask the damndest questions, Karl! :-) I've never seen a document that describes any rule limits. It is a kernel module, so one must assume there is some limit. It may be that a spelunking sesion through the source might answer that. I've got lots of drop entries on my rules and haven't had any issues, but I'm always guided by the concept that the more rules a packet must traverse, the slower the connection will be at startup. Therefore I order my rules carefully putting the more generic rules at the top of the list and the more specific ones at the bottom. That may not work for you...every network is a little different (for example, we blacklist entire /8 networks in some cases because of DOS or hack attacks from those countries).I'd love a list of those IPs and how you inserted the rule.Oh, man, I'd have to go through our firewall configs to dig up the addresses involved. As far as the rule insertion, it's pretty much a standard iptables insert, but we add a "--syn" for TCP and just simply block UDP. These are interim...eventually we migrate these rules out to our Foundry or Cisco routers and remove them from the individual servers.I also wonder about DROP vs REJECT. I know the difference, but what's the theory behind using one over the other? I have thought it is about them knowing the IP is there vs just a hang. But, I'm wondering if the DROP (hang) causes me any headaches in IP traffic limiting? I know, another annoying question.We use DROP. If we're under attack or someone's probing, why let them know they found a machine? If anything, a DROP is easier on the system than a REJECT since all the system does is drop the connection...it doesn't send anything back. And if the prober/attacker's connection hangs at his end, good! Screw them in the first place. Attackers and probers deserve absolutely no consideration in any way and should be prosecuted in the same manner as someone trying to break into my home or office.All my DROPs are in the first rule, so they are immediately acted on, or in this case, DROPped. I used to use sshblack, but the way the logfiles are written now make it ineffective for inbound, however I wrote my own blacklist scripts which I use with it, so it does do aging checks, which for DDNS is okay, I think.For SSH issues, I have a standard ruleset. Here it is from the /etc/sysconfig/iptables file: # This rejects ssh attempts more than twice in 180 seconds... # First, mark attempts as part of the "sshattack" group... -A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --set # Optional: Include this line if you want to log these attacks... #-A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --rcheck --seconds 180 --hitcount 2 -j LOG --log-prefix "SSH REJECT: " # Finally, reject the connection if more than one attempt is made in 180 seconds... -A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --rcheck --seconds 180 --hitcount 2 -j REJECT --reject-with tcp-resetThe iptables file doesn't exist, so is it checked only if it's there? I have /etc/sysconfig/iptables-config which doesn't look like I ought to mess with.
/etc/sysconfig/iptables is the normal spot for rules to go in. The /etc/sysconfig/iptables-config specifies what happens on startup and shutdown. I did change the following parameters: IPTABLES_SAVE_ON_STOP="yes" IPTABLES_SAVE_ON_RESTART="yes"The defaults are "no". Now, with those set up, I put my rules in /etc/sysconfig/iptables and they're loaded with iptables starts up.
Consequently, if I do any iptables commands, the config changes I made above will make the system save what is NOW in iptables into that file so they'll be restored on the next boot or "service iptables restart" command. The format of the /etc/sysconfig/iptables file is different from thenormal command, as it's actually the input (or output) of the iptables-save (or iptables-restore) command. Essentially, you introduce
a table (such as "nat" or "filter") with an "*" and the filter name. For example, *filter introduces rules for the filter table. From this point in the file until the next "*" or end of file, all rules affect the "filter" table. To set the default policy for a chain, you use ":" followed by the chain name, then the default policy. You can also use square brackets to set the input and output counters ("[input-ctr:output-ctr]"). Example, to set a default policy of DROP for the INPUT chain in the filter table and clear its input counter to 12 and its output to 0: *filter :INPUT DROP [12:0] To add rules to it, use the normal iptables command syntax, but without the actual iptables command and without the "-t tablename" stuff (since you're in the section of the file for that table): *filter -A INPUT (insert regular rule here) -A INPUT (insert regular rule here) and so on. Blank lines and anything following a "#" are considered comments.
I like your rule better than using sshblack or fail2ban. it's simple and doesn't require a daemon to be running all the time, other than the already running iptables.
It does have that charm as well. :-) ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks@xxxxxxxx - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - When all else fails, try reading the instructions. - ---------------------------------------------------------------------- _______________________________________________ Redhat-install-list mailing list Redhat-install-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/redhat-install-list To Unsubscribe Go To ABOVE URL or send a message to: redhat-install-list-request@xxxxxxxxxx Subject: unsubscribe