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 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? 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 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. Thanks, Brian ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev
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.200Which entries? In your rules file or in the Macros?> > > 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).> > > 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 allYou 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.> > > 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, -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 \________________________________________________ ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev
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 > Shorewall-users@lists.sourceforge.net > 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
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 \________________________________________________ ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev
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 > Shorewall-users@lists.sourceforge.net > 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
On 15/06/13 18:12, Brian Burch wrote:> On 15/06/13 15:13, Tom Eastep wrote:<snip/>>> On 06/15/2013 03:09 AM, Brian Burch wrote: >> >> 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!I have not made much progress. I have ubuntu 12.10 quantal on this machine and the xtables-addons-dkms package will not install. I discovered this is a manifestation of an old problem: in my case the dkms source will not compile using the header files from the 3.5.0 kernel line. A fix has just been release for the 13.04 raring kernels, but it fails to apply against my older kernel. The various workarounds fail too. If anyone is interested, take a look at https://bugs.launchpad.net/bugs/1062256 I am not prepared to risk destabilising my production system and so I will adopt Tom''s "plan B". ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev