I use ipset for various bits of firewall blocking and have a script which modprobes it if it is not loaded. Ages ago I thought I'd be clever and load it from /etc/modprobe.d from a file I called ip_set.conf but it does not work (as I found when I rebooted the machine yesterday). If you try loading it from there you get a:
This suggest to me that you have to modprobe it from /etc/rc.local but then there is no guarantee of it loading before the firewall, or loading it from /etc/clearos/firewall.d/local so it loads when the firewall loads, but this seems wrong as it will try to load it every time the firewall restarts. You can test for it having loaded before trying to load it with a:
WARNING: /etc/modprobe.d/ip_set.conf line 1: ignoring bad line starting with 'install'
message in your logs. You can reproduce this by removing the module then using "modprobe ip_set -v" while the file etc/modprobe.d/ip_set.conf with a line "install ip_set" in it exists. If you remove the file you can modprobe it successfully.This suggest to me that you have to modprobe it from /etc/rc.local but then there is no guarantee of it loading before the firewall, or loading it from /etc/clearos/firewall.d/local so it loads when the firewall loads, but this seems wrong as it will try to load it every time the firewall restarts. You can test for it having loaded before trying to load it with a:
if [ "`lsmod | grep ip_set`" = "" ]; then
modprobe ip_set
fi
but it seems wrong having to do this. It works so why bother with something else, but I am a bit of a purist and also like to increase my knowledge.
In Firewall
Share this post:
Accepted Answer
Found a much more 'elegant' method to fix this that will survive rpm updates...
Create a file as shown here and make executable
This will be loaded by /etc/rc.d/rc.sysinit before iptables starts, as shown by this snippet from /var/log/messages
Now if we look at this...
What about all these other modules - do they require loading as well? loaded auto on demand? or ???
Don't use ipset - so have no idea... I am using the latest kernel for ClearOS 6.8 beta i.e. 2.6.32-642.1.1.v6.i686
Create a file as shown here and make executable
[root@madeleine ~]# cat /etc/sysconfig/modules/ipset.modules
# Load ipset module
/sbin/modprobe ip_set
This will be loaded by /etc/rc.d/rc.sysinit before iptables starts, as shown by this snippet from /var/log/messages
... snipped
Jun 25 20:06:33 madeleine kernel: Netfilter messages via NETLINK v0.30.
Jun 25 20:06:33 madeleine kernel: ip_set: protocol 6
Jun 25 20:06:33 madeleine kernel: EXT4-fs (md0): mounted filesystem with ordered data mode. Opts:
Jun 25 20:06:33 madeleine kernel: EXT4-fs (md4): mounted filesystem with ordered data mode. Opts:
Jun 25 20:06:33 madeleine kernel: EXT4-fs (md3): mounted filesystem with ordered data mode. Opts:
Jun 25 20:06:33 madeleine kernel: Adding 2095036k swap on /dev/md1. Priority:-1 extents:1 across:2095036k
Jun 25 20:06:33 madeleine kernel: NET: Registered protocol family 10
Jun 25 20:06:33 madeleine kernel: lo: Disabled Privacy Extensions
Jun 25 20:06:33 madeleine kernel: r8169 0000:01:07.0: eth1: link down
Jun 25 20:06:33 madeleine kernel: r8169 0000:01:07.0: eth1: link down
Jun 25 20:06:33 madeleine kernel: ADDRCONF(NETDEV_UP): eth1: link is not ready
Jun 25 20:06:33 madeleine kernel: r8169 0000:01:07.0: eth1: link up
Jun 25 20:06:33 madeleine kernel: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
Jun 25 20:06:33 madeleine kernel: r8169 0000:01:08.0: eth2: link down
Jun 25 20:06:33 madeleine kernel: r8169 0000:01:08.0: eth2: link down
Jun 25 20:06:33 madeleine kernel: ADDRCONF(NETDEV_UP): eth2: link is not ready
Jun 25 20:06:33 madeleine kernel: r8169 0000:01:08.0: eth2: link up
Jun 25 20:06:33 madeleine kernel: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
Jun 25 20:06:33 madeleine kernel: 802.1Q VLAN Support v1.8 Ben Greear <[email protected]>
Jun 25 20:06:33 madeleine kernel: All bugs added by David S. Miller <[email protected]>
Jun 25 20:06:33 madeleine kernel: type=1305 audit(1466849192.222:3): audit_pid=1443 old=0 auid=4294967295 ses=4294967295 res=1
Jun 25 20:06:33 madeleine kernel: ip_tables: (C) 2000-2006 Netfilter Core Team
Jun 25 20:06:33 madeleine kernel: nf_conntrack version 0.5.0 (16097 buckets, 64388 max)
... snipped
Now if we look at this...
[root@madeleine ~]# cd /lib/modules/`uname -r`/kernel/net/netfilter/ipset
[root@madeleine ipset]# ls -lad *
-rwxr--r-- 1 root root 11644 Jun 23 06:43 ip_set_bitmap_ip.ko
-rwxr--r-- 1 root root 10208 Jun 23 06:43 ip_set_bitmap_ipmac.ko
-rwxr--r-- 1 root root 10328 Jun 23 06:43 ip_set_bitmap_port.ko
-rwxr--r-- 1 root root 31012 Jun 23 06:43 ip_set_hash_ip.ko
-rwxr--r-- 1 root root 33628 Jun 23 06:43 ip_set_hash_ipportip.ko
-rwxr--r-- 1 root root 32384 Jun 23 06:43 ip_set_hash_ipport.ko
-rwxr--r-- 1 root root 37424 Jun 23 06:43 ip_set_hash_ipportnet.ko
-rwxr--r-- 1 root root 34356 Jun 23 06:43 ip_set_hash_net.ko
-rwxr--r-- 1 root root 35892 Jun 23 06:43 ip_set_hash_netport.ko
-rwxr--r-- 1 root root 40816 Jun 23 06:43 ip_set.ko
-rwxr--r-- 1 root root 10180 Jun 23 06:43 ip_set_list_set.ko
[root@madeleine ipset]#
What about all these other modules - do they require loading as well? loaded auto on demand? or ???
Don't use ipset - so have no idea... I am using the latest kernel for ClearOS 6.8 beta i.e. 2.6.32-642.1.1.v6.i686
Responses (5)
-
Accepted Answer
I like that!
About the other modules, I think they are loaded on demand. When I did my earlier test:
I could not then rmmod ip_set as it said that ip_set_list_set was needed by ip_set, but I'd never explicitly loaded ip_set_list_set. If I rmmod'd ip_set_list_set first I could then rmmod ip_set (and then nfnetlink).[root@ClearOS6_5 ~]# modprobe ip_set
[root@ClearOS6_5 ~]# service ipset status
ipset: not running
[root@ClearOS6_5 ~]# ipset create TEST hash:ip
[root@ClearOS6_5 ~]# ipset list
Name: TEST
Type: hash:ip
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 16504
References: 0
Members: -
Accepted Answer
Thanks for that, Tony.
Digging a bit more, if you install ipset, it sets itself to start automatically and the process does start successfully. You just can't do anything with it:
Modprobing it then fixes it:[root@ClearOS6_5 ~]# ps aux | grep ipset
root 4172 0.0 0.0 103304 900 pts/0 S+ 08:48 0:00 grep ipset
[root@ClearOS6_5 ~]# service ipset status
ipset v6.11: Cannot open session to kernel.
ipset: not running
[root@ClearOS6_5 ~]# ipset create TEST hash:ip
ipset v6.11: Cannot open session to kernel.
[root@ClearOS6_5 ~]# ipset list
ipset v6.11: Cannot open session to kernel.
It looks like the status being returned from "service ipset status" is wrong, and, as you effectively imply, the installation (probably the init file) is buggy. The ClearOS6 version is 6.11 but the released version is 6.29 and the changelog is massive. I'll have to have another look at it when I'm more awake.[root@ClearOS6_5 ~]# modprobe ip_set
[root@ClearOS6_5 ~]# service ipset status
ipset: not running
[root@ClearOS6_5 ~]# ipset create TEST hash:ip
[root@ClearOS6_5 ~]# ipset list
Name: TEST
Type: hash:ip
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 16504
References: 0
Members:
-
Accepted Answer
Hi Nick - sorry, no idea how it is supposed to be loaded. Played around and it seems to be reluctant to load by the "normal" means...
One way to load before the firewall that works, probably others... If you look in /etc/rc.d/rc3.d, for example, you will see S07ipset and S13firewall (at least on my system). This means that as it's a lower number, S07ipset will be loaded before S13firewall ('S' means start - 'K' kill or stop) assuming of course you are starting the ipset service at boot time (e.g. chkconfig ipset on). S07ipset is a symlink to /etc/init.d/ipset.
Now if we edit /etc/init.d/ipset and add your little script, then every time ipset is started or restarted; then a check is made that the module is loaded.
... clipped
}
start() {
# Check the module is loaded, if not load it
if [ "`lsmod | grep ip_set`" = "" ]; then
modprobe ip_set
fi
# Do not start if there is no config file.
[[ ! -f "$IPSET_DATA" ]] && {
echo $"${IPSET}: Loaded with no configuration"
return 6;
}
... clipped
This works - after a fresh reboot found this...
[root@madeleine ~]# lsmod | grep ip_set
ip_set 26143 0
nfnetlink 3180 1 ip_set
[root@madeleine ~]#
Naturally an rpm update to ipset could remove this. In these cases using chattr to set the immutable bit will result in a yum error if it tries to update that file and you are then alerted to what is happening...
Bit of a hack - but at least it loads before the firewall.... -
Accepted Answer
Please login to post a reply
You will need to be logged in to be able to post a reply. Login using the form on the right or register an account if you are new here.
Register Here »