On 15/06/13 15:13, Tom Eastep wrote: > 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.
That sounds exactly what I wanted to do. I didn't stumble over the subject when reading the shorewall documentation and I've obviously let my iptables knowledge get out of date. I have to install the three ubuntu xtables-addons packages, and probably a newer version of shorewall because the capabilities subcommand is not recognised on my system. I'll probably go quiet for a several days! Thanks again. > 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 > > > > ------------------------------------------------------------------------------ > 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
