Topic: Block IP list

[Stefano]

Just a FYI but be aware I discovered that XT_Geoip seems to insert itself higher up the chain than deny RiffRaff.

So I had IPs apparently blocked by RiffRaff, but still saw them hitting Geoip.

The answer is in the geoip template code.

everything seems ok here

Code: [Select]

[root@sme9 ~]# rpm -qa | grep -i xt_geo
smeserver-xt_geoip-1.3.1-20.el7.sme.noarch
[root@sme9 ~]# iptables -L INPUT -v --line-numbers
Chain INPUT (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1     265K   14M DROP       all  --  any    any     anywhere             anywhere             match-set blacklist src
2      11M 3886M XTGeoIP    all  --  any    any     anywhere             anywhere
3      11M 3885M state_chk  all  --  any    any     anywhere             anywhere
4    1132K   77M Fail2Ban   all  --  any    any     anywhere             anywhere
5    1132K   77M local_chk  all  --  any    any     anywhere             anywhere
6        0     0 denylog    all  --  any    any     base-address.mcast.net/4  anywhere
7        0     0 denylog    all  --  any    any     anywhere             base-address.mcast.net/4
8    86661 6781K InboundICMP  icmp --  any    any     anywhere             anywhere
9        0     0 denylog    icmp --  any    any     anywhere             anywhere
10    313K   16M InboundTCP  tcp  --  any    any     anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN
11       0     0 denylog    tcp  --  any    any     anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN
12   98523 9182K InboundUDP  udp  --  eth0   any     anywhere             anywhere
13       0     0 denylog    udp  --  eth0   any     anywhere             anywhere
14       0     0 ACCEPT     udp  --  dummy0 any     anywhere             anywhere             udp spts:bootps:bootpc
15   79176 4684K denylog    all  --  any    any     anywhere             anywhere


am I missing anything?

TIA

[ReetP]

everything seems ok here
am I missing anything?

Yes.

/etc/e-smith/templates/etc/rc.d/init.d/masq/40Xt_Geoip

Code: [Select]

{
  $OUT .=<<'EOF';
   # A blacklist chain for xtables-addons GEOIP
    /sbin/iptables --new-chain XTGeoIP
    /sbin/iptables --new-chain XTGeoIP_1
    /sbin/iptables --append XTGeoIP -j XTGeoIP_1
    /sbin/iptables --insert INPUT 1 \
       -j XTGeoIP
EOF
}


I think that this:

Code: [Select]

    /sbin/iptables --insert INPUT 1 \
Inserts the rule above every other rule - including RiffRaff.

So you only get to the Riffraff block AFTER GeoIP no matter where you add the RiffRaff template.

So effectively a RiffRaff block will be checked AFTER it is checked for GeoIP and will then ONLY block IPs that are permitted by GeoIP.

Try blocking a IP that you see blocked by GeoIP. You would think that GeoIP would never see it, but it is still there.

Took me ages to realise what was going on!

You could of course add say

Code: [Select]

--INSERT 1

to your RiffRaff rule to put it above GeoIP.

(all based on observation and my limited knoweledge of IPTables !!)

Proof if required.

Code: [Select]

[root@esmith masq]# iptables -L INPUT -v --line-numbers
Chain INPUT (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1     413M  164G XTGeoIP    all  --  any    any     anywhere             anywhere           
2     412M  164G Fail2Ban   all  --  any    any     anywhere             anywhere           
3     412M  164G state_chk  all  --  any    any     anywhere             anywhere           
4    4647K  313M local_chk  all  --  any    any     anywhere             anywhere           
5        0     0 denylog    all  --  any    any     base-address.mcast.net/4  anywhere           
6        0     0 denylog    all  --  any    any     anywhere             base-address.mcast.net/4
7        0     0 DROP       all  --  any    any     193.47.61.13         anywhere                           <<<< See this?
8    88733 3869K InboundICMP  icmp --  any    any     anywhere             anywhere           
9        0     0 denylog    icmp --  any    any     anywhere             anywhere
I have a config entry for my RiffRaff:

Code: [Select]

ipblock=configuration
    DenyHosts=193.47.61.13/32
So that DROP is after GeoIP.

[Stefano]

well, I have the same file but everything is working fine since more than 2 years

Code: [Select]

Chain INPUT (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1     279K   14M DROP       all  --  any    any     anywhere             anywhere             match-set blacklist src
2      12M 4168M XTGeoIP    all  --  any    any     anywhere             anywhere
3      12M 4167M state_chk  all  --  any    any     anywhere             anywhere
4    1195K   82M Fail2Ban   all  --  any    any     anywhere             anywhere
5    1195K   82M local_chk  all  --  any    any     anywhere             anywhere
6        0     0 denylog    all  --  any    any     base-address.mcast.net/4  anywhere
7        0     0 denylog    all  --  any    any     anywhere             base-address.mcast.net/4
8    91804 7186K InboundICMP  icmp --  any    any     anywhere             anywhere
9        0     0 denylog    icmp --  any    any     anywhere             anywhere
10    323K   16M InboundTCP  tcp  --  any    any     anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN
11       0     0 denylog    tcp  --  any    any     anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN
12    108K   10M InboundUDP  udp  --  eth0   any     anywhere             anywhere
13       0     0 denylog    udp  --  eth0   any     anywhere             anywhere
14       0     0 ACCEPT     udp  --  dummy0 any     anywhere             anywhere             udp spts:bootps:bootpc
15   84130 4982K denylog    all  --  any    any     anywhere             anywhere


[ReetP]

well, I have the same file but everything is working fine since more than 2 years

My point was your IP block only operates AFTER processing by GeoIP.

I had imagined it would be first thereby saving GeoIP the overhead.

[Stefano]

My point was your IP block only operates AFTER processing by GeoIP.

I had imagined it would be first thereby saving GeoIP the overhead.

no, as you can see, the chain order is correct

Code: [Select]

[root@sme9 ~]# iptables -L INPUT -v --line-numbers
Chain INPUT (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1     292K   15M DROP       all  --  any    any     anywhere             anywhere             match-set blacklist src
2      12M 4308M XTGeoIP    all  --  any    any     anywhere             anywhere
3      12M 4307M state_chk  all  --  any    any     anywhere             anywhere
4    1243K   85M Fail2Ban   all  --  any    any     anywhere             anywhere
5    1243K   85M local_chk  all  --  any    any     anywhere             anywhere
6        0     0 denylog    all  --  any    any     base-address.mcast.net/4  anywhere
7        0     0 denylog    all  --  any    any     anywhere             base-address.mcast.net/4
8    94934 7442K InboundICMP  icmp --  any    any     anywhere             anywhere
9        0     0 denylog    icmp --  any    any     anywhere             anywhere
10    332K   17M InboundTCP  tcp  --  any    any     anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN
11       0     0 denylog    tcp  --  any    any     anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN
12    114K   11M InboundUDP  udp  --  eth0   any     anywhere             anywhere
13       0     0 denylog    udp  --  eth0   any     anywhere             anywhere
14       0     0 ACCEPT     udp  --  dummy0 any     anywhere             anywhere             udp spts:bootps:bootpc
15   87915 5217K denylog    all  --  any    any     anywhere             anywhere

so that my blocklist is evaluated before XTGeoIP

[ReetP]

Damn I just saw:

Code: [Select]

let IPTABLES_IPSET_RULE_NUMBER=1 # if FORCE is yes, the number at which place insert the ipset-match rule (default to 1)
That'll do it

Ok thanks Stefano. Nice job.

[Stefano]

Damn I just saw:

Code: [Select]

let IPTABLES_IPSET_RULE_NUMBER=1 # if FORCE is yes, the number at which place insert the ipset-match rule (default to 1)
That'll do it

Ok thanks Stefano. Nice job.

you're more than welcome