-5

I have a redirect rule on my CSF like the below;

17.1.1.13|80|27.5.5.22|80|tcp

17.1.1.13 is my firewall(csf) and 27.5.5.22 is my web server address. So everybody access my web site through the firewall. Blocking a redirect rule on CSF (iptables)

And I've been trying to block 50.30.0.0/16 CIDR block and it has been added to my csf.deny file.

Now, if I try to visit web site using 44.5.6.7 ip address I can. Although 50.30.0.1 is blocked, I can access web site using the ip address. I want to block 50.30.0.1 in all circumstances.

Related lines of my iptables like the below. What should I do?

Chain DENYIN (1 references)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 LOGDROPIN  all  --  !lo    *       50.30.0.0/16          0.0.0.0/0           

Chain DENYOUT (1 references)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 LOGDROPOUT  all  --  *      !lo     0.0.0.0/0            50.30.0.0/16 

Chain PREROUTING (policy ACCEPT 7 packets, 336 bytes)
num   pkts bytes target     prot opt in     out     source               destination   
1        0     0 REDIRECT   tcp  --  !lo    *       50.30.0.0/16          0.0.0.0/0 
2        0     0 REDIRECT   tcp  --  !lo    *       50.30.0.0/16          0.0.0.0/0      
3        0     0 DNAT       tcp  --  !lo    *       0.0.0.0/0            17.1.1.13
4        0     0 DNAT       tcp  --  !lo    *       0.0.0.0/0            17.1.1.13

Chain POSTROUTING (policy ACCEPT 6 packets, 699 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 SNAT       tcp  --  *      !lo     0.0.0.0/0            27.5.5.22 
2        0     0 SNAT       tcp  --  *      !lo     0.0.0.0/0            27.5.5.22 
efkan
  • 203
  • 3
  • 9
  • Can you post the output of `iptables -vL` ? – eltrai May 22 '15 at 08:43
  • All of them are too long. If I wrote related lines only, is it work? – efkan May 22 '15 at 08:45
  • That for you to work out, but if you post only incomplete data, the answer might not be accurate. – eltrai May 22 '15 at 08:48
  • OK, now I will stop some features of my CSF and reduce the lines. Then I'm editing my question. Thanks. – efkan May 22 '15 at 08:50
  • 2
    Actually if you have rule like -s 0.0.0.0 -j ACCEPT and then you append a rule with DROP statement, then you drop statement wont work. In iptables rules order does matter! – Navern May 22 '15 at 08:52
  • Hello @Navern, yes I saw lines like you said. However I thought that 'CSF developer should be considered these things'. I examined several projects like TurtleFirewall, fwbuilder, shorewall. Then I decided CSF. Easy managable using webmin, and simple. – efkan May 22 '15 at 09:13
  • 1
    Your ruleset is insanely complex, and I don't think you understand it. I'm not sure I do. E.g., `INPUT` rules 28-31 inclusive are **identical**, so the last three of those are therefore completely redundant. Rules 28 and 33 between them permit just about **everything**, so no blocking statement after that will have any effect. If you want to write your own rules, you will need to write **all** of them, or at least understand why they're all there. – MadHatter May 22 '15 at 09:17
  • Hello @MadHatter, thanks. You're right. It's complex because it has been generated by CSF. And lines 28-33 I thought these are comment lines and I deleted. Then I realized these aren't comment lines. Unfortunately notepad provide just 1 level undo process. After read your comment I corrected immediately. – efkan May 22 '15 at 09:43
  • `5.254.0.0/16` covers 11 different ISP across several different countries. Whatever reason you have for thinking you need to block all of that is almost certainly a misconception. – kasperd May 22 '15 at 09:46
  • @kasperd I want to improve a DDOS disaster plan. If I encountered an attack, I want to block all countries except one. For starting, I want to block just one CIDR. I've been trying to solve this issue for 2 days. Then I wrote here. I guess, people didn't like it because of I made simple mistakes. Thanks.. – efkan May 22 '15 at 09:54
  • You cannot avoid a DDoS attack by blocking traffic. It is even possible for traffic blocking to make the problem worse. – kasperd May 22 '15 at 10:02
  • @kasperd If I wrong please correct me :) Actually I intended reduce effects of a DDOS attack. If my server in U.S and someone attack me using 9,000 zombie client. Three thousands of these computers from Europe, three thousands from Asia and three thousands from U.S. If I block the all countries except U.S. I get rid of 60% of total effects. It makesense for me https://youtu.be/OT2y3DzMEmQ?t=2566 – efkan May 22 '15 at 10:35
  • 1
    @user3765109 You cannot reduce load on a congested network link by blocking packets which have already come through that link. And if it happens to be a reflection attack, your blocking is going to suppress those ICMP errors which could provide indication of the attack to those who can do something about it. – kasperd May 22 '15 at 10:46
  • Are you sure it's INPUT (traffic to host) chain not FORWARD(traffic to hosts behind firewall) that you want to add your rule to ? – Pavel K May 22 '15 at 11:30
  • 1
    Hello @PavelK, actually I have a firewall (IP:1.1.1.1) and a webserver (IP: 2.2.2.2). Under normal circumstances, when someone try to http://1.1.1.1 he can access my web site. There are DNAT and SNAT rules. However, I want to block IP 5.5.5.5. If someone -who has 5.5.5.5 IP address- wants to access my web site he shouldn't get access to my web site. This is the main problem :) – efkan May 22 '15 at 11:48
  • @user3765109 that is FORWARD chain mate: iptables -A FORWARD -p tcp -i $PUBLIC_IFACE -s 5.5.5.5 -o $DMZ_IFACE -d $WEB_SERVER --dport 80 -m state --state NEW -j DROP – Pavel K May 22 '15 at 11:50
  • You can find entire firewall script here: https://doittherightway.wordpress.com/2013/02/11/basic-bash-iptables-dmz-firewall-script/ – Pavel K May 22 '15 at 11:53

1 Answers1

1

When you use a -A (for APPEND) iptables command, your rule is added at the end of the table.

The way rules are evaluated are from the first to the last, and any matching rule that results in a decision (ACCEPT, REJECT, DENY) stops the evaluation of any subsequent rule.

So here, what happen is that your DROP rule will never matter, since if iptables evaluates it, it would have gone to the DROP policy anyway.

You need to add your rule before any ACCEPT rule you would like the corresponding IP address to not be able to access. I would guess as first rule in your case.

Which would be something like

iptables -I INPUT -s 5.254.0.0/16 -j DROP

It will add the rule at the beginning of the table, therefore considering it before anything else and ignoring the rest of your rules for any matching IP, which packets will be dropped.

Note that if you need to be more precise into where you which your rule inserted, you can specify a pôsitional number just after the -I.

eltrai
  • 998
  • 8
  • 12
  • Thank you. I've tried to input rule using -A and then -I parameters separately. It doesn't work for me but I gave reputation because of I learned somethings from your answer. – efkan May 22 '15 at 10:15