>> Not really! blacklist/whitelist entries are usually the first and >> precede anything else in a given chain - its their most valuable asset >> and is the reason I'd like these new features implemented in them. >> > > Yes -- and they come before traffic is broken out by zone. > Currently, they are inserted for each branch of the zone in which the "whitelist" option is used (I am assuming the "worse" case scenario where both src and dst options are used).
>> I know I could place a bunch of rules in the "rules" file, but they will >> be useless, because: 1) the blacklist/whitelist will already have been >> checked; >> > > So, only place entries that are zone-neutral in the blacklist file. > I simply can't. I think its better to illustrate this with a simple example: say I have 3 interfaces: eth0, eth1 and tun0. eth0 and tun0 have the whitelist option defined for them and I have a hefty ipsets containing subnets I don't want traffic appearing on either interfaces - in both directions, so src and dst are also specified. I want, however, to have access to specific set of iface:subnet:proto tripples also based on userid/owner on tun0 for traffic going out to be allowed on tun0. I can define the iface:subnet:proto tripples as a specific ipset called, say, vpn-out-whitelist[dst,dst], which, if placed properly in the blackout chain of the tun0 interface will punch a hole through that defined blacklist for this particular interface (tun0). This is what I currently do with the "start" shorewall script - a hacking job. Ideally, what I'd like to have is this in the blacklist file: +whitelist - - - src,dst,whitelist # whitelist applicable to all interfaces, including tun0 +vpn-out-whitelist[dst,dst] - - root dst,vpn,whitelist # this to indicate that this ipset will punch a hole in the fw2vpn's blackout chain, allowing the defined ip:proto pair to pass through for user id=0 (root) - the value of the 3rd column +blacklist - - - src,dst ... If I define vpn-out-whitelist[dst,dst] in my rules file that won't do because 1) the blacklist will be checked first and traffic going out to the addresses:ports specified in the vpn-out-whitelist will be blocked; and 2) any other macros which are put even before the rules file is processed might - and will - also block such traffic (I also have BLACKLISTNEW=No, so that everything is checked regardless of the connection state - the blacklist chain comes first and that is how it should be really). >> and 2) These rules will be after anything that usually gets >> processed in a given chain - related/established connection rules, >> dropInvalid and various other macros as well. >> > > That depends on which SECTION you put them in and what you put in front of > them. Remember that, by default, ESTABLISHED,RELATED packets don't go through > the blacklist at all. > Yes, I am aware of that, but in my case they do as I check everything regardless of the connection state (I know that it slows traffic, but the machine is powerful enough to process it and since it is in my dmz zone I don't wish anything to slip through, regardless of the connection state, hence why BLACKLISTNEW=No in my case). ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Shorewall-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-devel
