Hi Tom!
I found one bug with parsing macro file when i want to use
'ORIGINAL DEST' parameter. When i create macro file with follow
content:
DNAT - - tcp 30022 - 192.168.5.1
command 'shorewall check' complain:
Checking /etc/shorewall/rules...
ERROR: Invalid rate (192.168.5.1) : /etc/shorewall/macro.VSRVS-SSH (line
12)
Alex
---------
Самый содержательный портал о туризме и отдыхе в Беларуси
http://belarustourism.by/
Города Беларуси http://belarustourism.by/cities/
Развлечения, архитектура, гостиницы, базы отдыха, национальные парки.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
On 10/26/07, alex <alshu@tut.by> wrote:> Hi Tom! > I found one bug with parsing macro file when i want to use > ''ORIGINAL DEST'' parameter. When i create macro file with follow > content:You may want to say what version of shorewall you are using. Prasanna. -- www.elinanetworks.com Seamless, secure delivery of applications. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
>> Hi Tom! >> I found one bug with parsing macro file when i want to use >> 'ORIGINAL DEST' parameter. When i create macro file with follow >> content:> You may want to say what version of shorewall you are using. > > Prasanna.Very much sorry. I talk about shorewall-4.0.5. Alex --------- Самый содержательный портал о туризме и отдыхе в Беларуси http://belarustourism.by/ Города Беларуси http://belarustourism.by/cities/ Развлечения, архитектура, гостиницы, базы отдыха, национальные парки. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
alex wrote:> Hi Tom! > I found one bug with parsing macro file when i want to use > ''ORIGINAL DEST'' parameter. When i create macro file with follow > content: > > DNAT - - tcp 30022 - 192.168.5.1 > > command ''shorewall check'' complain: > > Checking /etc/shorewall/rules... > ERROR: Invalid rate (192.168.5.1) : /etc/shorewall/macro.VSRVS-SSH (line > 12)Alex, I regret having to inform you that macro files don''t have an ORIGINAL DEST column. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On Fri, Oct 26, 2007 at 08:11:55AM -0700, Tom Eastep wrote:> I regret having to inform you that macro files don''t have an ORIGINAL DEST > column.Perhaps it''s time to completely rethink macros. They''re obviously designed to be convinient to process in shell; shorewall-perl should be able to do something much more flexible with very little effort. Let me just pull something out of the air, to give you some ideas. I''m making this up as I go along, so it may set fire to your cat. This is a description of one possible feature set that would make a good replacement: In the rules file, a ''function'' is any line of the form: name/args where ''args'' is a whitespace-delimited list of arguments. Example: #ACTION SOURCE DEST PROTO DEST PORT(S) SMTP/DNAT:info net 192.168.1.5 This is a call to the function ''SMTP'' with the arguments ''DNAT:info'', ''net'', and ''192.168.1.5''. Shorewall breaks the line up by whitespace but otherwise places no particular significance on the arguments; they''re passed through to the function as-is. When evaluating a function, shorewall first looks for the file ''function.name'' (function.SMTP in this example) on the usual paths; if it exists, it first evaluates this file in the perl interpreter, then calls $Shorewall::Function::functions{$name}->(@args). The result of that call is treated as a list of rules lines to be processed. Such a file might look something like this (minus the comments): package Shorewall::Function::SMTP; # By convention, this namespace is reserved # for functions to define whatever they # want; shorewall itself won''t put anything # in here. use Shorewall::Function; # @EXPORT = qw{add_function} sub process { $_[3] = ''tcp''; $_[4] = 25; return [@_], [qw{ACCEPT fw}, $_[2], qw{tcp 465}]; # Example only. This line is # nonsense. Don''t actually do # this. } add_function(SMTP => \&process); # sub add_function {$functions{$_[0]} = $_[1]} 1; But it could be any arbitrarily complicated perl code. You could fetch stuff from a database or whatever. You could also install functions from an extension script ahead of time - if there''s already a function of the right name in the hash, shorewall won''t try to load a file. You could even mess around with add_rule() and the other extension script interfaces if you were being particularly evil (ie, return nothing and insert the rules yourself, presumably because you didn''t like how Shorewall::Rules normally processed them). This feature set should be sufficient to generate anything somebody could reasonably want to do in the rules file. If no function can be located in this manner, shorewall attempts to construct one out of a macro file: macro.SMTP is loaded, and processed as usual. Macros are a subset of functions here. It should be possible to implement all of that in under a hundred lines of new code, or about an afternoon''s work. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Andrew Suffield wrote:> On Fri, Oct 26, 2007 at 08:11:55AM -0700, Tom Eastep wrote: >> I regret having to inform you that macro files don''t have an ORIGINAL DEST >> column. > > Perhaps it''s time to completely rethink macros. They''re obviously > designed to be convinient to process in shell; shorewall-perl should > be able to do something much more flexible with very little effort. > > Let me just pull something out of the air, to give you some ideas. I''m > making this up as I go along, so it may set fire to your cat. This is > a description of one possible feature set that would make a good > replacement: > > In the rules file, a ''function'' is any line of the form: > > name/args > > where ''args'' is a whitespace-delimited list of arguments. Example: > > #ACTION SOURCE DEST PROTO DEST PORT(S) > SMTP/DNAT:info net 192.168.1.5 > > This is a call to the function ''SMTP'' with the arguments ''DNAT:info'', > ''net'', and ''192.168.1.5''. Shorewall breaks the line up by whitespace > but otherwise places no particular significance on the arguments; > they''re passed through to the function as-is.I''ll have to think about this proposal. I don''t believe that I can just suddenly de-implement Macros in Shorewall-perl so I would need to add the ''function'' capability in an upwardly-compatible way. FWIW, the reason that macro''s don''t support ORIGINAL DEST is that they can be used in both the rules file and in action bodies. I chose to make macros support the least common denominator of those two. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On Fri, Oct 26, 2007 at 11:11:53AM -0700, Tom Eastep wrote:> I''ll have to think about this proposal. I don''t believe that I can just > suddenly de-implement Macros in Shorewall-perl so I would need to add the > ''function'' capability in an upwardly-compatible way.It should be fairly simple to accomplish that - but I really haven''t thought about the problem for any longer than it took to write that mail, it''s just a sketch of one possible approach. The basic goal is straightforward: there''s no good reason for the limitations of the macro system, and tossing a Turing-complete language in there pretty much eliminates them with a minimum of effort. I''d be happy with anything that I can (ab)use to implement: foreach i in x,y,z: ACCEPT fw $i tcp ssh (I get tired of endlessly pasting lines to accomplish the same thing)> FWIW, the reason that macro''s don''t support ORIGINAL DEST is that > they can be used in both the rules file and in action bodies. I > chose to make macros support the least common denominator of those > two.Any solution along these lines should completely subsume/eliminate the need for actions - it''s more of a least common multiple, combining all the capabilities of both into one coherent and simple operation. That does indicate that the syntax I sketched out is inadequete (on reflection I don''t much like it anyway). ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Andrew Suffield wrote:> On Fri, Oct 26, 2007 at 11:11:53AM -0700, Tom Eastep wrote: >> I''ll have to think about this proposal. I don''t believe that I can just >> suddenly de-implement Macros in Shorewall-perl so I would need to add the >> ''function'' capability in an upwardly-compatible way. > > It should be fairly simple to accomplish that - but I really haven''t > thought about the problem for any longer than it took to write that > mail, it''s just a sketch of one possible approach. The basic goal is > straightforward: there''s no good reason for the limitations of the > macro system, and tossing a Turing-complete language in there pretty > much eliminates them with a minimum of effort. > > I''d be happy with anything that I can (ab)use to implement: > > foreach i in x,y,z: ACCEPT fw $i tcp sshHow about something so simple as: SHELL for z in x y z; do echo ACCEPT fw $z tcp ssh; done Line continuation can be used for more complex scripts. And it took me less that 1/2 hour to get that working :-) And it''s available in any file. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Tom Eastep wrote:> Andrew Suffield wrote: >> On Fri, Oct 26, 2007 at 11:11:53AM -0700, Tom Eastep wrote: >>> I''ll have to think about this proposal. I don''t believe that I can just >>> suddenly de-implement Macros in Shorewall-perl so I would need to add the >>> ''function'' capability in an upwardly-compatible way. >> It should be fairly simple to accomplish that - but I really haven''t >> thought about the problem for any longer than it took to write that >> mail, it''s just a sketch of one possible approach. The basic goal is >> straightforward: there''s no good reason for the limitations of the >> macro system, and tossing a Turing-complete language in there pretty >> much eliminates them with a minimum of effort. >> >> I''d be happy with anything that I can (ab)use to implement: >> >> foreach i in x,y,z: ACCEPT fw $i tcp ssh > > How about something so simple as: > > SHELL for z in x y z; do echo ACCEPT fw $z tcp ssh; done > > Line continuation can be used for more complex scripts. > > And it took me less that 1/2 hour to get that working :-) And it''s available > in any file. >And just to show I''m not a language bigot: PERL for ( qw(fw dmz) ) { printf "ACCEPT net $_ tcp 25\n"; } -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On Fri, Oct 26, 2007 at 03:01:26PM -0700, Tom Eastep wrote:> > How about something so simple as: > > > > SHELL for z in x y z; do echo ACCEPT fw $z tcp ssh; done > > > > Line continuation can be used for more complex scripts. > > > > And it took me less that 1/2 hour to get that working :-) And it''s available > > in any file. > > > > And just to show I''m not a language bigot: > > PERL for ( qw(fw dmz) ) { printf "ACCEPT net $_ tcp 25\n"; }Hmm, assuming that it''s just evaled then you could probably stash a sub in one of the extension scripts that runs early in the compile process, and then: PERL SMTP qw{fw net} gives you the "smarter macro" feature. (It does depend what package you''re evaling stuff in - ideally they should all be tossed into a private namespace, so you don''t accidentally redefine parts of shorewall-perl) It is not immediately apparent how to get the same effect from the shell version. Maybe something with scripts and the search path? ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Andrew Suffield wrote:> > Hmm, assuming that it''s just evaled then you could probably stash a > sub in one of the extension scripts that runs early in the compile > process, and then: > > PERL SMTP qw{fw net} > > gives you the "smarter macro" feature. > > (It does depend what package you''re evaling stuff in - ideally they > should all be tossed into a private namespace, so you don''t > accidentally redefine parts of shorewall-perl) > > It is not immediately apparent how to get the same effect from the > shell version. Maybe something with scripts and the search path?It''s not just evaled -- it''s using a child process with piped output. The feature is built on top of the INCLUDE mechanism already in Shorewall; a PERL or SHELL directive is basically like an INCLUDE only the compiler is reading a pipe rather than a file. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Tom Eastep wrote:> The feature is built on top of the INCLUDE mechanism already in Shorewall; a > PERL or SHELL directive is basically like an INCLUDE only the compiler is > reading a pipe rather than a file.Missing comma made that hard to parse: The feature is built on top of the INCLUDE mechanism already in Shorewall; a PERL or SHELL directive is basically like an INCLUDE, only the compiler is reading a pipe rather than a file. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On Fri, Oct 26, 2007 at 03:19:40PM -0700, Tom Eastep wrote:> Andrew Suffield wrote: > > > > > Hmm, assuming that it''s just evaled then you could probably stash a > > sub in one of the extension scripts that runs early in the compile > > process, and then: > > > > PERL SMTP qw{fw net} > > > > gives you the "smarter macro" feature. > > > > (It does depend what package you''re evaling stuff in - ideally they > > should all be tossed into a private namespace, so you don''t > > accidentally redefine parts of shorewall-perl) > > > > It is not immediately apparent how to get the same effect from the > > shell version. Maybe something with scripts and the search path? > > It''s not just evaled -- it''s using a child process with piped output.If it''s spawning a new interpreter, that''s inconvinient. Can that be avoided? A fork of the parent interpreter would suffice, since that''ll still have any state that was set up by the earlier extension scripts. It''d also be faster (the perl interpreter takes a *long* time to start up, compared to the already kinda slow fork() syscall). ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Andrew Suffield wrote:> On Fri, Oct 26, 2007 at 03:19:40PM -0700, Tom Eastep wrote: >> Andrew Suffield wrote: >> >>> Hmm, assuming that it''s just evaled then you could probably stash a >>> sub in one of the extension scripts that runs early in the compile >>> process, and then: >>> >>> PERL SMTP qw{fw net} >>> >>> gives you the "smarter macro" feature. >>> >>> (It does depend what package you''re evaling stuff in - ideally they >>> should all be tossed into a private namespace, so you don''t >>> accidentally redefine parts of shorewall-perl) >>> >>> It is not immediately apparent how to get the same effect from the >>> shell version. Maybe something with scripts and the search path? >> It''s not just evaled -- it''s using a child process with piped output. > > If it''s spawning a new interpreter, that''s inconvinient. Can that be > avoided? A fork of the parent interpreter would suffice, since that''ll > still have any state that was set up by the earlier extension > scripts. It''d also be faster (the perl interpreter takes a *long* time > to start up, compared to the already kinda slow fork() syscall).PERL is now forking. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Tom Eastep wrote:> Andrew Suffield wrote: >> On Fri, Oct 26, 2007 at 03:19:40PM -0700, Tom Eastep wrote:> > PERL is now forking. >I realized last night that running Perl scripts in a child is unsatisfactory unless the child is persistent. And even if the child were persistent, the script couldn''t do things like add rules that use matches which Shorewall doesn''t support directly (by directly calling Shorewall::Chains::add_rule()). I also disliked having to use line continuation for multi-line scripts. So: a) Multi-line scripts are introduced by "BEGIN PERL" and terminated by "END PERL" (''PERL'' may be omitted from the ending line). Both the beginning and ending markers can be optionally followed with '';'' so that a Perl-aware editor doesn''t get confused. b) Single-line scripts (or multi-line scripts using line continuation) are still introduced by ''PERL''. c) Both script types are evaluated in the compiler process. d) Rather than using print statements to generate input to Shorewall, the script calls Shorewall::Config::shorewall(). The script includes an implicit "use Shorewall::Config qw/shorewall/;" so the function name does not need to be qualified. e) The script includes an implicit "package Shorewall::User;". f) Perl syntax errors are reported against the actual filename and line number. Example script: BEGIN PERL; for ( qw(fw dmz) ) { shorewall "ACCEPT net $_ tcp 25\n"; } 1; END PERL; Note that the script must evaluate to a ''true'' value. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On Sat, Oct 27, 2007 at 09:57:00AM -0700, Tom Eastep wrote:> I realized last night that running Perl scripts in a child is unsatisfactory > unless the child is persistent. And even if the child were persistent, the > script couldn''t do things like add rules that use matches which Shorewall > doesn''t support directly (by directly calling Shorewall::Chains::add_rule()).Oh yeah. At least one of us is paying attention.> e) The script includes an implicit "package Shorewall::User;".Can you do that to the regular extension scripts too? I anticipate that the "normal" way to use this will be to write all your code in the initdone(?) script (or suck it in there via ''use'') and just call functions using the single-line variant, so you''d want them all to be in the same package. Also, while we''re on the subject, please stick: unshift @INC, @config_dirs; somewhere early in the compiler, so that ''use'' searches them. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Andrew Suffield wrote:> On Sat, Oct 27, 2007 at 09:57:00AM -0700, Tom Eastep wrote: > >> e) The script includes an implicit "package Shorewall::User;". > > Can you do that to the regular extension scripts too?Done.> I anticipate > that the "normal" way to use this will be to write all your code in > the initdone(?) script (or suck it in there via ''use'') and just call > functions using the single-line variant, so you''d want them all to be > in the same package.I''ve added a ''compile'' compile-time user exit. It gets invoked early in the compilation process.> > > Also, while we''re on the subject, please stick: > > unshift @INC, @config_dirs; > > somewhere early in the compiler, so that ''use'' searches them.Done. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Tom Eastep wrote:> Andrew Suffield wrote: >> On Sat, Oct 27, 2007 at 09:57:00AM -0700, Tom Eastep wrote: >> >>> e) The script includes an implicit "package Shorewall::User;". >> Can you do that to the regular extension scripts too? > > Done. > >> I anticipate >> that the "normal" way to use this will be to write all your code in >> the initdone(?) script (or suck it in there via ''use'') and just call >> functions using the single-line variant, so you''d want them all to be >> in the same package. > > I''ve added a ''compile'' compile-time user exit. It gets invoked early in > the compilation process. > >> >> Also, while we''re on the subject, please stick: >> >> unshift @INC, @config_dirs; >> >> somewhere early in the compiler, so that ''use'' searches them. > > Done.I would really appreciate it if people would play with this facility and offer feedback. The code is available at: http://www1.shorewall.net/pub/shorewall/development/staging/4.0/shorewall-4.0.6-RC1/ Thanks! -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On Sat, Oct 27, 2007 at 04:13:09PM -0700, Tom Eastep wrote:> I would really appreciate it if people would play with this facility and > offer feedback. The code is available at: > > http://www1.shorewall.net/pub/shorewall/development/staging/4.0/shorewall-4.0.6-RC1/I''ve been playing with it, in an attempt to generate similar-but-more-flexible behaviour for the SSHKnock action described in http://www.shorewall.net/PortKnocking.html (since that''s a familiar example that should showcase how this feature can be used). The goal is something like: PERL Knock ''net'', ''loc:192.168.1.5'', {port => 22, knocker => 1600, trap => [1599, 1601]}; where the ''net'' and ''loc:192.168.1.5'' arguments are handed off to shorewall for normal processing, while the perl function takes care of the rest. I find myself having to perpetrate an ugly hack in order to get shorewall''s normal behaviour for ''source'' and ''dest'' fields. It''s straightforward to create new rules with add_rule(), but what chain should I add them to, and what should I do with any address restrictions? Reimplementing shorewall''s own processing of those fields is possible but silly. I seem to get more or less the right behaviour by fudging shorewall''s internal variables to trick it into thinking that I''m using the external-action mechanism, so I think that I want an interface of the form: my $name = ''knock'' . ++$i; my $chainref = new_manual_chain($name); shorewall "$name $src $dest"; add_rule($chainref, ...); which tells shorewall "I''m going to populate this chain myself; please create it and insert a rule that jumps to it, like for an action, but otherwise leave it alone". If I understand the code correctly, this should be a simple variation on the theme of the ($actiontype & ACTION) bits of process_rule1, that just avoids triggering Shorewall::Action. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Andrew Suffield wrote:> I want an interface of the form: > > my $name = ''knock'' . ++$i; > my $chainref = new_manual_chain($name); > shorewall "$name $src $dest"; > add_rule($chainref, ...); > > which tells shorewall "I''m going to populate this chain myself; please > create it and insert a rule that jumps to it, like for an action, but > otherwise leave it alone". If I understand the code correctly, this > should be a simple variation on the theme of the ($actiontype & > ACTION) bits of process_rule1, that just avoids triggering > Shorewall::Action.Patch attached. Thanks, Andrew. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Tom Eastep wrote:> > Patch attached. >And here''a a patch that allows manual chains to appear as a target in Action bodies. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Andrew Suffield wrote:> I''ve been playing with it, in an attempt to generate > similar-but-more-flexible behaviour for the SSHKnock action described > in http://www.shorewall.net/PortKnocking.html (since that''s a familiar > example that should showcase how this feature can be used). > > The goal is something like: > > PERL Knock ''net'', ''loc:192.168.1.5'', {port => 22, knocker => 1600, trap => [1599, 1601]}; > > where the ''net'' and ''loc:192.168.1.5'' arguments are handed off to > shorewall for normal processing, while the perl function takes care of > the rest.Andrew, With the patches that I''ve posted, this should now be possible. When you get it working, please post it here and I''ll include it in a new article that describes "Manual Chains". -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
ERROR: Couldn''t do /home/asuffield/tmp/knock-test/compile: Shorewall/Config.pm line 1499, $! is not necessarily set when eval returns undef. Should have been ''unless defined $return and $!''. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On Sun, Oct 28, 2007 at 09:23:43AM -0700, Tom Eastep wrote:> Andrew Suffield wrote: > > > I''ve been playing with it, in an attempt to generate > > similar-but-more-flexible behaviour for the SSHKnock action described > > in http://www.shorewall.net/PortKnocking.html (since that''s a familiar > > example that should showcase how this feature can be used). > > > > The goal is something like: > > > > PERL Knock ''net'', ''loc:192.168.1.5'', {port => 22, knocker => 1600, trap => [1599, 1601]}; > > > > where the ''net'' and ''loc:192.168.1.5'' arguments are handed off to > > shorewall for normal processing, while the perl function takes care of > > the rest. > > With the patches that I''ve posted, this should now be possible. When you get > it working, please post it here and I''ll include it in a new article that > describes "Manual Chains".Here''s a first cut - I haven''t yet tested this on a real firewall, and it''ll be a few days before I get a chance to do that. A diff of the compiled output against that given by the example in the ''Port Knocking'' article shows no significant difference, so I think it''s at least as correct as that article. Would be nice if somebody who actually uses the method in that article could try it, and see how it matches their expectations. Knock.pm is attached, and contains the main code; it should be placed in the firewall config directory (/etc/shorewall or whatever). You also have to create a ''compile'' file, containing the following two lines: use Knock; 1; Then, for the example rules lines in http://www.shorewall.net/PortKnocking.html, here are translations: #ACTION SOURCE DEST PROTO DEST PORT(S) SSHKnock net $FW tcp 22,1599,1600,1601 becomes: PERL Knock ''net'', ''loc:192.168.1.5'', {target => 22, knocker => 1600, trap => [1599, 1601]}; and: #ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL # PORT(S) DEST DNAT- net loc:192.168.1.5 tcp 22 - 206.124.146.178 SSHKnock net $FW tcp 1599,1600,1601 SSHKnock net loc:192.168.1.5 tcp 22 - 206.124.146.178 becomes: DNAT- net loc:192.168.1.5 tcp 22 - 206.124.146.178 PERL Knock ''net'', ''$FW'', {name => ''SSH'', knocker => 1600, trap => [1599, 1601]}; PERL Knock ''net'', ''loc:192.168.1.5'', {name => ''SSH'', target => 22, original_dest => ''206.124.136.178''}; The ''name'' argument is used to tie together related target/knocker/trap sets that appear in different rules - unlike the original, you can just add more rules with different names to create different sets. Also there''s the obvious benefit that all the configuration is now in the ''rules'' file, rather than having half of it hardcoded into the action script, so if you change the port numbers in the rule then it actually works. Might be worth rewriting the ''Port Knocking'' article to use this method. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Andrew Suffield wrote:> ... > Then, for the example rules lines in > http://www.shorewall.net/PortKnocking.html, here are translations: > > > #ACTION SOURCE DEST PROTO DEST PORT(S) > SSHKnock net $FW tcp 22,1599,1600,1601 > > becomes: > > PERL Knock ''net'', ''loc:192.168.1.5'', {target => 22, knocker => 1600, trap => [1599, 1601]}; > > and: > > #ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL > # PORT(S) DEST > DNAT- net loc:192.168.1.5 tcp 22 - 206.124.146.178 > SSHKnock net $FW tcp 1599,1600,1601 > SSHKnock net loc:192.168.1.5 tcp 22 - 206.124.146.178 > > becomes: > > DNAT- net loc:192.168.1.5 tcp 22 - 206.124.146.178 > PERL Knock ''net'', ''$FW'', {name => ''SSH'', knocker => 1600, trap => [1599, 1601]}; > PERL Knock ''net'', ''loc:192.168.1.5'', {name => ''SSH'', target => 22, original_dest => ''206.124.136.178''};My question is: how many people would actually prefer and use the newer syntax? The cleanness of rules is one of Shorewall''s major draws. I would personally rather maintain the clean-looking rules file and wear the fact that some of the config is in the action. The number of port knocking rules on any given firewall is likely to be 0 or 1, so it doesn''t seem like a big win for me. Perhaps another example of its use might be more convincing... ;-) -- Paul <http://paul.gear.dyndns.org/> -- Are you tired of the major political parties? Do you want to make a difference with your vote? Please support the Family First Party in your local electorate, and Jeff Buchanan and the Queensland Senate team. See <http://www.familyfirstqld.org.au/> for more details, or ask me about how you can help in the electorate of Bowman. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On Mon, Oct 29, 2007 at 10:45:35AM +1000, Paul Gear wrote:> My question is: how many people would actually prefer and use the newer > syntax? The cleanness of rules is one of Shorewall''s major draws. I > would personally rather maintain the clean-looking rules file and wear > the fact that some of the config is in the action. The number of port > knocking rules on any given firewall is likely to be 0 or 1, so it > doesn''t seem like a big win for me. Perhaps another example of its use > might be more convincing... ;-)I used the port knocking one because it''s an example that people will recognise, and because I could do it by making minor adjustments to the sample code in the article - it''s not the most amazing improvement, but it does neatly demonstrate all of the new features. It''s something of a corner case - but then, the whole point of this feature set is corner cases. It''s not something that you would frequently use, it''s something that you use when shorewall''s normal behaviour doesn''t cut it, most likely because you''re doing something new that nobody''s thought of before. It''s always difficult to dream up good examples of stuff you haven''t thought of yet. As far as pure syntax goes, I can do better, but it wouldn''t be a very nice example. I''d have to do some creatively evil preprocessing, either by overriding eval or with something from the Filter:: namespace. It would certainly be possible to extend shorewall in this way, but that''s not really the intended purpose of this feature. If you want to add something new to shorewall with really neat syntax, that''s why you have the source. This one is in the domain of "tools to create crude but workable solutions to problems that otherwise would be painful or impossible to solve". It''s also a workaround for awkward limitations like the one that sparked this thread. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
>> Hi Tom! >> I found one bug with parsing macro file when i want to use >> 'ORIGINAL DEST' parameter. When i create macro file with follow >> content: >> >> DNAT - - tcp 30022 - 192.168.5.1 >> >> command 'shorewall check' complain: >> >> Checking /etc/shorewall/rules... >> ERROR: Invalid rate (192.168.5.1) : /etc/shorewall/macro.VSRVS-SSH >>(line >> 12) > > Alex, > > I regret having to inform you that macro files don't have an ORIGINAL DEST > column. > > -TomSorry Tom, but i don't understand exactly. These are misprints in Shorewall's distribution files or you don't understand my question? As i can see in all '/usr/share/shorewall/macro.*' files is seventh column with such name. For example, content of DNS macro file: # # Shorewall version 4 - DNS Macro # # /usr/share/shorewall/macro.DNS # # This macro handles DNS traffic. # ############################################################################### #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ # PORT PORT(S) DEST LIMIT GROUP PARAM - - udp 53 PARAM - - tcp 53 #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE Alex --------- Новые условия и возможности для участия в Лотерее Грин кард. Воспользуйтесь нашим предложением - лучшим по ценам, качеству и надежности исполнения. Поэтому нас не любят конкуренты. http://greencard.nvs.by/ ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
alex wrote:> Tom Eastep wrote: >> >> I regret having to inform you that macro files don''t have an ORIGINAL DEST >> column.> > Sorry Tom, but i don''t understand exactly. These are misprints in > Shorewall''s distribution files or you don''t understand my question? > As i can see in all ''/usr/share/shorewall/macro.*'' files is seventh > column with such name. For example, content of DNS macro file:It is regrettable that the original macro (whichever one it was) had incorrect column headings and that all other macros were copied from it. The patch at http://www1.shorewall.net/pub/shorewall/misc/alex.diff corrects that problem. The facts remain: a) The Macro Documentation (http://www.shorewall.net/Macros.html) does not mention an ORIGINAL DEST column b) The Macro Template (/usr/share/shorewall/macro.template) does not contain an ORIGINAL DEST column c) No version of the Shorewall code has ever supported an ORIGINAL DEST column in macro files. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/