dear all,
We really like csf, but in my humble opinion i do miss the definition of interfaces in csf.
as a hoster we also use internal network link with a 10.0.0.0/8 range for internal backups so we need to disable bogon network completely enabling this on the public facing interfaces is preferred. (i also read iod's question here for the same issue)
also i really miss the definition of the interfaces in the csf.allow, you can define ip ranges and open ports for them, but i would really would like to define the interface so that packet crafting on the public interfaces is not possible at that moment.
Thanks in advance.
seperate interface naming and bogon exlusion
-
- Junior Member
- Posts: 11
- Joined: 24 Jan 2012, 08:55
Re: seperate interface naming and bogon exlusion
You cannot selectively disable features per NIC. The only option in csf would be to add the local NIC to ETH_DEVICE_SKIP if you want to ignore traffic on it.
-
- Junior Member
- Posts: 11
- Joined: 24 Jan 2012, 08:55
Re: seperate interface naming and bogon exlusion
but to disable a feature per nic is really needed if you have multiple interfaces
for instance in the csf.allow when i allow IN for a certain protocol then it is allowed on all interfaces in many situation this is not desirable, i want to enable a service on 1 interface. in the readme we saw you can even supply a GID and UID !!! and to supply an interface name here is what would more be used then a gid or uid
using the eth+ is to broad, because i would like to have rules on eth0 and different on eth2 while eth1 has total other ports.
now all eth+ devices are given the ports from the csf.config this is my view the default. but on other interfaces i would not like to define the same ports. most of the time i would like to supply on eth1 or eth2 completely other ports or services. this is in my book default firewall usage.
further using ETH_DEVICE_SKIP could work, but then you don't have fire walling on this interface, in some cases desirable
- csf would be ideal if you could supply a comma separated interface list in the config on what you want to have the "default" rule configs from csf.config on
when i look at them manpage of iptables i can see were this comes from:
--
Name of an interface via which a packet was received (only for
packets entering the INPUT, FORWARD and PREROUTING chains).
When the "!" argument is used before the interface name, the
sense is inverted. If the interface name ends in a "+", then
any interface which begins with this name will match. If this
option is omitted, any interface name will match.
---
so in a sense to facilitate this there must be a "loop" on this config value that then will identify multiple values and translates this to multiple iptable rules.
right?
i would see the ports in csf.config as default but if you really would like to specify it then the csf.allow change to allow interfaces would be the most flexible. in code it would be reusing the gid/uid syntax and simlpy assume if the value is not supplied then its for the config value from the csf.allow using the seperated interface list and the eth+ value. but if the value is supplied it would use the interface name and based on the out/in you could then also set in iptables the -o or -i with it
in my opinion then csf would be usable in every situation.
any feed back on this would be highly appreciated.
Thanks in advance.
soulshepard
for instance in the csf.allow when i allow IN for a certain protocol then it is allowed on all interfaces in many situation this is not desirable, i want to enable a service on 1 interface. in the readme we saw you can even supply a GID and UID !!! and to supply an interface name here is what would more be used then a gid or uid
![Smile :)](./images/smilies/smile.gif)
using the eth+ is to broad, because i would like to have rules on eth0 and different on eth2 while eth1 has total other ports.
now all eth+ devices are given the ports from the csf.config this is my view the default. but on other interfaces i would not like to define the same ports. most of the time i would like to supply on eth1 or eth2 completely other ports or services. this is in my book default firewall usage.
further using ETH_DEVICE_SKIP could work, but then you don't have fire walling on this interface, in some cases desirable
- csf would be ideal if you could supply a comma separated interface list in the config on what you want to have the "default" rule configs from csf.config on
when i look at them manpage of iptables i can see were this comes from:
--
Name of an interface via which a packet was received (only for
packets entering the INPUT, FORWARD and PREROUTING chains).
When the "!" argument is used before the interface name, the
sense is inverted. If the interface name ends in a "+", then
any interface which begins with this name will match. If this
option is omitted, any interface name will match.
---
so in a sense to facilitate this there must be a "loop" on this config value that then will identify multiple values and translates this to multiple iptable rules.
right?
i would see the ports in csf.config as default but if you really would like to specify it then the csf.allow change to allow interfaces would be the most flexible. in code it would be reusing the gid/uid syntax and simlpy assume if the value is not supplied then its for the config value from the csf.allow using the seperated interface list and the eth+ value. but if the value is supplied it would use the interface name and based on the out/in you could then also set in iptables the -o or -i with it
in my opinion then csf would be usable in every situation.
any feed back on this would be highly appreciated.
Thanks in advance.
soulshepard
-
- Moderator
- Posts: 1523
- Joined: 01 Oct 2008, 09:24
Re: seperate interface naming and bogon exlusion
We'll look at adding an option to exclude specific NICs from the BOGON list option as this does make sense. However, we're not looking at having separate csf configurations for different NICs at this time.
-
- Junior Member
- Posts: 11
- Joined: 24 Jan 2012, 08:55
Re: seperate interface naming and bogon exlusion
Thank you for considering.ForumAdmin wrote:We'll look at adding an option to exclude specific NICs from the BOGON list option as this does make sense.
as extra suggestion: If the normal config would be used together with its interface list, then this is the default.ForumAdmin wrote: However, we're not looking at having separate csf configurations for different NICs at this time.
and use the csf.allow to add extra rules for interfaces in the same syntax as done now, then with an extra column as interface name
the this will truely empower csf in my opinion. as now you need to work arround it with source adresses otherwise all the open ports will be open on all interfaces, i cant imagine this is desireble, especially if one would use internal networks or extra nets.
Thanks in advance
Re: seperate interface naming and bogon exlusion
We've added the LF_BOGON_SKIP option to cater for the bogon issue.
-
- Junior Member
- Posts: 11
- Joined: 24 Jan 2012, 08:55
Re: seperate interface naming and bogon exlusion
Thanks, really appriciated, we will incorporate it in the default configschirpy wrote:We've added the LF_BOGON_SKIP option to cater for the bogon issue.
Soul!
ps: other people plese vote for the interface naming option in the csf.allow
![Wink ;)](./images/smilies/wink.gif)
<3
![Smile :)](./images/smilies/smile.gif)
-
- Junior Member
- Posts: 1
- Joined: 27 Nov 2012, 15:07
Re: seperate interface naming and bogon exlusion
This would be a welcome feature indeed. I've just installed CSF\LFD on a rackspace box with their managed backup service and they require access for 10.0.0.0/8 via the lo adapter.
unfortunately this does not seem possible from the CSF configuration and i needed to add my own rules into iptables.
It would be great to keep everything within CSF's control.
Great product btw, settings per adapter would make it even better!!
unfortunately this does not seem possible from the CSF configuration and i needed to add my own rules into iptables.
It would be great to keep everything within CSF's control.
Great product btw, settings per adapter would make it even better!!