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. 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. > On 06/13/2013 07:32 AM, Brian Burch wrote: >> I have recently started blacklisting by accumulating lines in the >> blrules file, e.g. >> >> DROP net:200.62.170.200 all >> >> The number of lines is growing fairly quickly, so it occurred to me that >> I could improve maintenance by defining a macro to hide the fixed >> elements of these lines. >> >> >> I read http://shorewall.net/Macros.html carefully, but found it somewhat >> confusing because of the changes to macro support in recent releases. >> >> I thought I could code my entries very simply like this: >> >> KillHost 200.62.170.200 > > 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). >> 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. >> 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! 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? >> 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, 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. Also, you say put the "macro call" into rules. Stylistically, that makes sense because it won't change in the long term. However, wasn't the whole point of the blrules design to move maintenance of that kind of ever-changing "rule set" to a separate file? I hope you don't mind me trying to get these architectural issues clear in my own mind. I think Shorewall is a great product - I came to it quite recently after years of hand-crafting my own iptables, so I am grateful for all that it does! Brian > -Tom > > > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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
