Hello: I''m getting a fair number of UDP connections to port 59695. The connections seem to come from primarily four or five IP addresses at the rate of one per minute or so. I log and drop those connections, but unfortunately my log fills up quickly. Is there a way to continue to drop all UDP connections to port 59695, but limit the logging to only one entry per IP address per hour? If so, I''ll still have an indication of the dropped connections without overloading the log file. I''ve looked through the help files and examples, but they seem to apply to ACCEPT rules, not DROP rules. Is there a way to extend log limiting to DROP also? Incidentally, a quick Google search didn''t turn up anything obvious on UDP port 59695. Does anyone have any idea what that is? Lastly, and most important, thanks for the great product! As a hobbyist, I''ve learned quite a bit by tinkering with Shorewall. Thank you. -- Brian Schang ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev
Brian Schang wrote:> I''ve looked through the help files and examples, but they seem to apply > to ACCEPT rules, not DROP rules. Is there a way to extend log limiting > to DROP also?/etc/shorewall/actions: LogLimit /etc/shorewall/action.LogLimit: #TARGET SOURCE DEST PROTO DEST SOURCE RATE USER/ # PORT PORT(S) LIMIT GROUP LOG:info - - - - - 1/hour:1 DROP /etc/shorewall/rules: LogLimit net fw udp 59695> > Incidentally, a quick Google search didn''t turn up anything obvious on > UDP port 59695. Does anyone have any idea what that is?Nope.> > Lastly, and most important, thanks for the great product! As a hobbyist, > I''ve learned quite a bit by tinkering with Shorewall. >You''re welcome. -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 \________________________________________________ ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev
Tom: On 2/14/2010 12:19 PM, Tom Eastep wrote:>> I''ve looked through the help files and examples, but they seem to apply >> to ACCEPT rules, not DROP rules. Is there a way to extend log limiting >> to DROP also? > > /etc/shorewall/actions: > > LogLimit > > /etc/shorewall/action.LogLimit: > > #TARGET SOURCE DEST PROTO DEST SOURCE RATE USER/ > # PORT PORT(S) LIMIT GROUP > LOG:info - - - - - 1/hour:1 > DROP > > /etc/shorewall/rules: > > LogLimit net fw udp 59695Worked like a charm. Thank you. But what I really wanted was to get a log message from each IP address that tried to connect to UDP port 59695, but limited to one log entry per IP per hour. So I tried the following (based on Limit): /etc/shorewall/actions: LogLimit2 /etc/shorewall/action.LogLimit2: *empty* /etc/shorewall/LogLimit2: use Shorewall::Chains; my @tag = split /,/, $tag; fatal_error ''Limit rules must include <list name>,<max connections>,<interval> as the log tag ('' . join( '':'', ''Limit'', $level eq '''' ? ''none'' : $level , $tag ) . '')'' unless @tag == 3; my $list = $tag[0]; for ( @tag[1,2] ) { fatal_error ''Max connections and interval in Limit rules must be numeric ('' . join( '':'', ''Limit'', $level eq '''' ? ''none'' : $level, $tag ) . '')'' unless /^\d+$/ } my $count = $tag[1] + 1; add_rule $chainref, "-m recent --name $list --set"; if ( $level ) { add_rule $chainref, "-m recent --name $list --update --seconds $tag[2] --hitcount $count -j DROP"; log_rule_limit $level, $chainref, $tag[0], ''DROP'', '''', '''', ''add'', ''''; } else { add_rule $chainref, "-m recent --update --name $list --seconds $tag[2] --hitcount $count -j DROP"; } add_rule $chainref, ''-j DROP''; 1; /etc/shorewall/rules: LogLimit2:info:LOG,1,3600 net fw udp 59695 It all seems to work fine. Thank you for sending me down the right track. I appreciate the help. ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev
On Sun, 2010-02-14 at 15:09 -0500, Brian Schang wrote:> Tom: > > On 2/14/2010 12:19 PM, Tom Eastep wrote: > > >> I''ve looked through the help files and examples, but they seem to apply > >> to ACCEPT rules, not DROP rules. Is there a way to extend log limiting > >> to DROP also? > > > > /etc/shorewall/actions: > > > > LogLimit > > > > /etc/shorewall/action.LogLimit: > > > > #TARGET SOURCE DEST PROTO DEST SOURCE RATE USER/ > > # PORT PORT(S) LIMIT GROUP > > LOG:info - - - - - 1/hour:1 > > DROP > > > > /etc/shorewall/rules: > > > > LogLimit net fw udp 59695 > > Worked like a charm. Thank you. But what I really wanted was to get a > log message from each IP address that tried to connect to UDP port > 59695, but limited to one log entry per IP per hour.In /etc/shorewall/action.LogLimit LOG:info - - - - - s:1/hour:1 -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 \________________________________________________ ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev
Tom: On 2/14/2010 4:00 PM, Tom Eastep wrote:>> Worked like a charm. Thank you. But what I really wanted was to get a >> log message from each IP address that tried to connect to UDP port >> 59695, but limited to one log entry per IP per hour. > > In /etc/shorewall/action.LogLimit > > LOG:info - - - - - s:1/hour:1Ah, I guess I did things the hard way... It seems to me that the iptables ''limit'' match has similarities to the ''recent'' match. For my education, other than the ''limit'' method being simpler, are there any significant differences between the two methods in this context? Thanks again! -- Brian Schang ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev
On Sun, 2010-02-14 at 18:32 -0500, Brian Schang wrote:> Tom: > > On 2/14/2010 4:00 PM, Tom Eastep wrote: > > >> Worked like a charm. Thank you. But what I really wanted was to get a > >> log message from each IP address that tried to connect to UDP port > >> 59695, but limited to one log entry per IP per hour. > > > > In /etc/shorewall/action.LogLimit > > > > LOG:info - - - - - s:1/hour:1 > > Ah, I guess I did things the hard way... > > It seems to me that the iptables ''limit'' match has similarities to the > ''recent'' match. For my education, other than the ''limit'' method being > simpler, are there any significant differences between the two methods > in this context?''hashlimit'' generally requires fewer rules. -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 \________________________________________________ ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev
Tom: On 2/14/2010 7:00 PM, Tom Eastep wrote:>> It seems to me that the iptables ''limit'' match has similarities to the >> ''recent'' match. For my education, other than the ''limit'' method being >> simpler, are there any significant differences between the two methods >> in this context? > > ''hashlimit'' generally requires fewer rules.I understand now. Thanks for all of your help! -- Brian Schang ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev
Hello: On 2/14/2010 4:00 PM, Tom Eastep wrote:> In /etc/shorewall/action.LogLimit > > LOG:info - - - - - s:1/hour:1While using the ''limit'' match worked fine, becoming IP-specific with ''hashlimit'' has not been working. More specifically there seems to be no limiting occurring. The same source IP addresses show up in the logs on essentially every connection. I have attached my ''shorewall dump'' output. I read through the file and have reviewed my configuration files and I don''t understand what could be going wrong. Any insight would be appreciated. Thank you. -- Brian Schang ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev
Brian Schang wrote:> Hello: > > On 2/14/2010 4:00 PM, Tom Eastep wrote: > >> In /etc/shorewall/action.LogLimit >> >> LOG:info - - - - - s:1/hour:1 > > While using the ''limit'' match worked fine, becoming IP-specific with > ''hashlimit'' has not been working. More specifically there seems to be no > limiting occurring. The same source IP addresses show up in the logs on > essentially every connection. > > I have attached my ''shorewall dump'' output. I read through the file and > have reviewed my configuration files and I don''t understand what could > be going wrong. Any insight would be appreciated. >I have none. Let''s wait to see if your query on the Netfilter list bears fruit. If not, I would send it to netfilter-devel; when you do that, be sure to mention your kernel version. -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 \________________________________________________ ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev
Tom Eastep wrote:> Brian Schang wrote: >> Hello: >> >> On 2/14/2010 4:00 PM, Tom Eastep wrote: >> >>> In /etc/shorewall/action.LogLimit >>> >>> LOG:info - - - - - s:1/hour:1 >> While using the ''limit'' match worked fine, becoming IP-specific with >> ''hashlimit'' has not been working. More specifically there seems to be no >> limiting occurring. The same source IP addresses show up in the logs on >> essentially every connection. >> >> I have attached my ''shorewall dump'' output. I read through the file and >> have reviewed my configuration files and I don''t understand what could >> be going wrong. Any insight would be appreciated. >> > > I have none. Let''s wait to see if your query on the Netfilter list bears > fruit. If not, I would send it to netfilter-devel; when you do that, be > sure to mention your kernel version.I think that I''ve figured this out. The default expiration time for idle entries is 10 seconds. So very infrequent packets from a given IP address will always match when the rate is low. -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 \________________________________________________ ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev
Tom: On 2/16/2010 12:30 PM, Tom Eastep wrote:>>> While using the ''limit'' match worked fine, becoming IP-specific with >>> ''hashlimit'' has not been working. More specifically there seems to be no >>> limiting occurring. The same source IP addresses show up in the logs on >>> essentially every connection. >>> >>> I have attached my ''shorewall dump'' output. I read through the file and >>> have reviewed my configuration files and I don''t understand what could >>> be going wrong. Any insight would be appreciated. >>> >> >> I have none. Let''s wait to see if your query on the Netfilter list bears >> fruit. If not, I would send it to netfilter-devel; when you do that, be >> sure to mention your kernel version. > > I think that I''ve figured this out. The default expiration time for idle > entries is 10 seconds. So very infrequent packets from a given IP > address will always match when the rate is low.Alright. So if I understand correctly, then limiting to an average rate of once per hour or once per day needs to be combined with overriding the default expiration time? Actually any time that a packet would come in at a rate of less than once every ten seconds, the expiration time should be changed from the default? Thank you for helping me figure this out. Having experts like yourself willing to help and explain makes learning a lot of fun. -- Brian Schang ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev
Brian Schang wrote:> Tom: > > On 2/16/2010 12:30 PM, Tom Eastep wrote: > >>>> While using the ''limit'' match worked fine, becoming IP-specific with >>>> ''hashlimit'' has not been working. More specifically there seems to be no >>>> limiting occurring. The same source IP addresses show up in the logs on >>>> essentially every connection. >>>> >>>> I have attached my ''shorewall dump'' output. I read through the file and >>>> have reviewed my configuration files and I don''t understand what could >>>> be going wrong. Any insight would be appreciated. >>>> >>> I have none. Let''s wait to see if your query on the Netfilter list bears >>> fruit. If not, I would send it to netfilter-devel; when you do that, be >>> sure to mention your kernel version. >> I think that I''ve figured this out. The default expiration time for idle >> entries is 10 seconds. So very infrequent packets from a given IP >> address will always match when the rate is low. > > Alright. So if I understand correctly, then limiting to an average rate > of once per hour or once per day needs to be combined with overriding > the default expiration time? Actually any time that a packet would come > in at a rate of less than once every ten seconds, the expiration time > should be changed from the default? > > Thank you for helping me figure this out. Having experts like yourself > willing to help and explain makes learning a lot of fun. >I''ve done some experiments and unfortunately, setting --hashlimit-htable-expire to 1 hour does not change anything; the hashtable entries still expire in 10 seconds :-( I don''t have much time to mess with this so if you want to play with it, feel free. -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 \________________________________________________ ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev
Tom: On 2/16/2010 9:27 PM, Tom Eastep wrote:> I''ve done some experiments and unfortunately, setting > --hashlimit-htable-expire to 1 hour does not change anything; the > hashtable entries still expire in 10 seconds :-(Are you seeing the save behavior as me? Or is it working fine for you? I''d like to go back to the Netfilter mailing list, and would like to have a sense for whether this issue is unique to me or whether it is more widespread. Thanks again. -- Brian Schang ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev
Brian Schang wrote:> Tom: > > On 2/16/2010 9:27 PM, Tom Eastep wrote: > >> I''ve done some experiments and unfortunately, setting >> --hashlimit-htable-expire to 1 hour does not change anything; the >> hashtable entries still expire in 10 seconds :-( > > Are you seeing the save behavior as me? Or is it working fine for you? > I''d like to go back to the Netfilter mailing list, and would like to > have a sense for whether this issue is unique to me or whether it is > more widespread.I have been able to make it work correctly. I will be releasing 4.4.7.5 within the week which will hopefully solve your problem. -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 \________________________________________________ ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev
Tom Eastep wrote:> Brian Schang wrote: >> Tom: >> >> On 2/16/2010 9:27 PM, Tom Eastep wrote: >> >>> I''ve done some experiments and unfortunately, setting >>> --hashlimit-htable-expire to 1 hour does not change anything; the >>> hashtable entries still expire in 10 seconds :-( >> Are you seeing the save behavior as me? Or is it working fine for you? >> I''d like to go back to the Netfilter mailing list, and would like to >> have a sense for whether this issue is unique to me or whether it is >> more widespread. > > I have been able to make it work correctly. I will be releasing 4.4.7.5 > within the week which will hopefully solve your problem.I must say, however, that the fact that iptables and Netfilter kernel code will accept a rate of 1/hour with a 10-second expiration interval is not very helpful. -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 \________________________________________________ ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev
Tom: On 2/17/2010 9:27 PM, Tom Eastep wrote:>>> I''ve done some experiments and unfortunately, setting >>> --hashlimit-htable-expire to 1 hour does not change anything; the >>> hashtable entries still expire in 10 seconds :-( >> >> Are you seeing the save behavior as me? Or is it working fine for you? >> I''d like to go back to the Netfilter mailing list, and would like to >> have a sense for whether this issue is unique to me or whether it is >> more widespread. > > I have been able to make it work correctly. I will be releasing 4.4.7.5 > within the week which will hopefully solve your problem.That''s great news! I will certainly let the group know whether it addresses my problem. I appreciate everything you have done to help me. Thank you. -- Brian Schang ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev
Tom: On 2/17/2010 10:42 PM, Brian Schang wrote:>>>> I''ve done some experiments and unfortunately, setting >>>> --hashlimit-htable-expire to 1 hour does not change anything; the >>>> hashtable entries still expire in 10 seconds :-(>> I have been able to make it work correctly. I will be releasing 4.4.7.5 >> within the week which will hopefully solve your problem.I have confirmed that your fix solves my problem. :-) Thank you very much for all of your help! I appreciate it. -- Brian Schang ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev
Brian Schang wrote:>>> within the week which will hopefully solve your problem. > > I have confirmed that your fix solves my problem. :-) > > Thank you very much for all of your help! I appreciate it. >Glad to hear that it now works for you. -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 \________________________________________________ ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev