On 06/15/2013 03:09 AM, Brian Burch wrote: > On 14/06/13 22:25, Tom Eastep wrote: > > Hi, Tom, > > I expect to be stuck with an ever-increasing list of malicious unwanted > hosts as time goes by.
Then you should be considering using ipsets for blacklisting rather than an increasingly long gauntlet of rules for accepted connections to run. > That is my motive for getting the design and > stylistic details optimal at the beginning. I don't want to be > re-engineering my definitions when I have hundreds of existing entries. All the more reason to use ipsets. >> Which entries? In your rules file or in the Macros? > > My current "entries" (i.e. many DROP lines like the one shown above) are > in my blrules file. > > Having spent most of my life coding in dozens of different languages, my > thinking is a bit fossilised. I was thinking along the lines that a > "macro" is used to create a kind of minimalist pseudo-instruction that > hides the details of the implementation, including any constants. > > That approach led me to think I should write my own "macro" (e.g. > KillHost) that only contained constants and placeholders for the > variable arguments. Following that reasoning, I wanted to exchange the > current "hard-coded" DROP lines in my blrules file with much simpler > KillHost macro calls (i.e. still in the blrules file). So you want to put 'all' in every line of macro.KillHost rather than in a single line in blrules? > >>> I am running shorewall 4.5.5.3, so I tried to use the format1 style in >>> my macro.KillHost as follows: >>> >>> #ACTION SOURCE DEST >>> DROP net:PARAM all >>> >>> ... but that was rejected "unknown destination zone (all)". Although >>> this message does not really describe my syntax error, I take it to mean >>> that I can only associate PARAM with the first field (ACTION). Is that >>> correct? >> >> No -- it means that 'all' can't be used within the body of a macro. >> Actually, it is very unusual to even use zone names within a macro as >> most people inherit the zones from the macro invocation (in the rules file). > > Oh, I think I see what you mean. I was thinking more generally, where > "/all/ will apply to every single DROP blrule, so why not hide it as a > constant within the macro?" I was trying to avoid coding /any/ argument > hundreds of times when it could be coded once inside a macro. > You have it backwards; you are going to have to code it 100s of times inside the macro with the approach you are going to take. >>> I read the section titled "Shorewall 4.4.16 and Later". I found the >>> description of multiple parameters and default values confusing. I tried >>> several permutations, although I am unsure what features would be >>> acceptable (because I don't have 4.5.10), e.g. >>> >>> #ACTION SOURCE DEST >>> DEFAULT 1 DROP >>> $1 net:$2 all >> >> You are now mixing Macros and Actions. Actions support multiple >> parameters; macro's do not. The section you refer to is explaining that >> a macro name can appear in the policy file as a default action for a >> given policy. > > Criticism accepted! I hope I don't offend you by saying that perl is one > of the most frustrating languages I have ever encountered. When I saw > your Actions were written in perl, I turned my back on Actions and hoped > I could achieve my objective with a simple Macro! > Actions don't have to be written in Perl. But Perl inside of actions is a powerful way to extend Shorewall > However, the web page says "Also beginning with Shorewall 4.5.10, you > may pass multiple parameters in a macro invocation. Within the macro > body, $1 expands to the value of the first parameter, $2 expands to the > value of the second and so on." Is the page wrong? Yes -- I've expunged that incorrect statement from that article. Thanks for pointing it out. Note, however, that 'inline' actions (introduced in Shorewall 4.5.10) are very similar to macros and do support multiple parameters. > >>> Could you help me with the correct syntax? If you are confident that >>> something like this should work, I will try upgrading to a newer version. >>> >> >> Your entry in /etc/shorewall/rules would look something like: >> >> KillHost net all >> >> and entries in macro.KillHost then give the details of the blacklisting >> that you want, including source and destination IP addresses, protocols >> and ports. >> >> e.g.: >> >> DROP 1.2.3.4 #Drop all requests from net:1.2.3.4 >> DROP - - tcp 25 #Drop SMTP >> ... >> >> HTH,Do this: /etc/shorewall/actions KillHost /etc/shorewall/blrules KillHost 1.2.3.4 KillHost > > You are always helpful! I'm sorry if I'm a bit slow to understand. > > I (mostly) understand your suggestion, but it feels "back to front" to > my fossilised thinking. One simple entry in rules is good, although it > feels wrong to push the ongoing maintenance effort for the list of > blacklisted hosts into a macro. If you simply take my suggestion to use ipsets, host and network blacklisting takes exactly two entries in blrules: DROP net:+blacklisthosts all DROP net:+blacklistnets all When you want to blacklist a single host, you add it to the blacklisthosts ipset; when you want to blacklist an entire network, you add it to blacklistnets. Two entries are required because the ipset facility doesn't support a set type that can record both networks and single hosts. If you don't want to use ipsets for some reason, then try this: /etc/shorewall/actions: KillHosts /etc/shorewall/blrules: KillHosts net all /etc/shorewall/action.KillHosts BLACKLIST 1.2.3.4 BLACKLIST 2.3.4.5 BLACKLIST 4.5.6.7 ... You specify 'net' and 'all' exactly once. Now, in the action.KillHosts file, you only need to specify the columns that you want to match. The above examples only specify the source IP address. BLACKLIST is a macro that applies your specified BLACKLIST_DISPOSITION and BLACKLIST_LOG_LEVEL. Again, however, if you take this approach then each accepted connection from the 'net' zone must traverse each of the rules in action.KillHosts. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
