Hello Shorewall users, First I would like to say I enjoy using Shorewall and wouldn''t place a box on the Net without it installed. With that being said, I do have a small issue with Shorewall. Shorewall''s logging is completely out of control in my case and for my needs. In shorewall.conf I have all logging set to "err" and I''m kind of lost on how to stop all this logging (example: SMURF_LOG_LEVEL=err). I guess if there''s an error then I might want to know, but blocked traffic doesn''t help me unless I''m trying to let someone in and they can''t get there. Then I would need to have logging in my situation. In my case I use Shorewall to block all ports except for ports 80, 443 and ssh (when I''m on the road only). Every other incoming traffic is DROPed with shorewall. Since I know this is all blocked, I really don''t care to log this information on a daily basis as millions of scans and hack attempts happen 24/7. To tell you the truth I''m more interested in seeing what shorewall lets through on any port OTHER than what I have allowed access to than logging those IP''s which were successfully blocked. Hey they were blocked right? Anyway, here are a couple of shorewall log entries for starters that I would like to stop. Of course there are all kinds of ports which are scanned continuously so this is just a quick snapshot of the last 3 entries: Oct 15 13:47:29 backup kernel: Shorewall:net2fw:DROP:IN=eth0 OUT= MAC=00:06:5b:8c:18:1f:00:06:53:10:18:01:08:00 SRC=202.107.228.35 DST=[123.456.789.012] LEN=4 04 TOS=0x00 PREC=0x20 TTL=112 ID=63441 PROTO=UDP SPT=4820 DPT=1434 LEN=384 Oct 15 13:47:30 backup kernel: Shorewall:net2fw:DROP:IN=eth0 OUT= MAC=00:06:5b:8c:18:1f:00:06:53:10:18:01:08:00 SRC=66.56.253.79 DST=[123.456.789.012] LEN=48 TOS=0x00 PREC=0x20 TTL=113 ID=41389 DF PROTO=TCP SPT=1742 DPT=2967 WINDOW=16384 RES=0x00 SYN URGP=0 Oct 15 13:47:30 backup kernel: Shorewall:net2fw:DROP:IN=eth0 OUT= MAC=00:06:5b:8c:18:1f:00:06:53:10:18:01:08:00 SRC=66.230.119.236 DST=[123.456.789.012] LEN=4 8 TOS=0x00 PREC=0x20 TTL=119 ID=11572 DF PROTO=TCP SPT=3696 DPT=2968 WINDOW=64512 RES=0x00 SYN URGP=0 Any help on how to just turn off logging would be appreciated. John _________________________________________________________________ Peek-a-boo FREE Tricks & Treats for You! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us ------------------------------------------------------------------------- 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/
J and T wrote:> > Any help on how to just turn off logging would be appreciated.As explained at http://www.shorewall.net/shorewall_logging.html#Log, there are five different ways in which packets can get logged. So the key to stopping unwanted logging is to identify in which of the five ways the log entries are being generated. In your case, it is undoubtedly the fifth way (entry in /etc/shorewall/policy). So the want to eliminate the unwanted messages is to change the LEVEL on the net->fw policy (may be expressed in the file as a net->all policy). -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/
Thanks Tom. Sorry about hotmail screwing up the reply formatting, but it''s what we have to deal with I guess. Any I already had the policy logging set to: net all DROP err all all REJECT err I thought it would only log "err"ors. Do I instead need to set this to "emerg"? I guess I just don''t get it. Sorry to be a pain, John ----------------------------------------> Date: Mon, 15 Oct 2007 14:50:17 -0700> From: teastep@shorewall.net> To: shorewall-users@lists.sourceforge.net> Subject: Re: [Shorewall-users] How to shut down logging?>> J and T wrote:>>>>> Any help on how to just turn off logging would be appreciated.>> As explained at http://www.shorewall.net/shorewall_logging.html#Log, there> are five different ways in which packets can get logged. So the key to> stopping unwanted logging is to identify in which of the five ways the log> entries are being generated. In your case, it is undoubtedly the fifth way> (entry in /etc/shorewall/policy).>> So the want to eliminate the unwanted messages is to change the LEVEL on the> net->fw policy (may be expressed in the file as a net->all policy).>> -Tom> --> Tom Easte p \ 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> _________________________________________________________________ Peek-a-boo FREE Tricks & Treats for You! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us ------------------------------------------------------------------------- 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/
J and T wrote:> Thanks Tom. Sorry about hotmail screwing up the reply formatting, but it''s what we have to deal with I guess. Any I already had the policy logging set to: > > net all DROP err > all all REJECT err > > I thought it would only log "err"ors. Do I instead need to set this to "emerg"? I guess I just don''t get it. > > Sorry to be a pain,Hopefully someone else on the list has the time and energy to try to teach you how logging on a Unix system works. I have neither. Sorry, -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 10/15/07, J and T <j_and_t@hotmail.com> wrote:> I already had the policy logging set to: > > net all DROP err > all all REJECT err > > I thought it would only log "err"ors. Do I instead need to set this to "emerg"? I guess I just don''t get it.As documented in policy(5): #SOURCE DEST POLICY LOG BURST:LIMIT net all DROP err So this line says "If it''s coming from net to all, drop it and log it at level err." Remove "err" entirely, and it should stop logging all those packets. Will ------------------------------------------------------------------------- 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/
> ... how logging on a Unix system works ...Shorewall -like many well-integrated *nix subsystems- uses the "syslog" capability of *nix (rather than rolling its own logging). So you can search Shorewall documentation high and low and not find what you''re looking for; do `man syslog` on your *nix system (or Google "man syslog"). Syslog has scads of capabilities for large complex multi systems, but you can simply ignore all that. For example there''s a way to combine _in_real_time_ messages from several different systems onto one system more or less dedicated to handling messages. But you can just treat "syslog" as single-system. Syslog pre-defines levels of messages. Applications can''t affect the names or the order (although they do have quite a bit of latitude to choose for themselves what they consider to be an "info" and what they consider to be an "emerg" etc.). The pre-defined levels (in decreasing order) are: emerg system is or will be unusable if situation is not resolved alert immediate action required crit critical situations warning recoverable errors notice unusual situation that merits investigation; a significant event that is typically part of normal day-to-day operation info informational messages debug verbose data for debugging You control this with configuration of "syslog" itself (often via the file /etc/syslog.conf). You control which messages go into which file(s) and/or onto which screen(s). Often the first 2/3 of this configuration are set "by convention" ...but the convention is different for different Linux distributions. You fill in the rest of the configuration for optional subsystems such as Shorewall. There are two slightly different ways for configuring "syslog" which are not quite fully compatible with each other, so check your own system''s documentation carefully and thoroughly. Specifying a level normally gives you that level _and_all_levels_above_it_, so for example if you specify level "crit" you''ll also get levels "alert" and "emerg". What the application documentation will usually tell you is just enough information (something called a "facility", a brief description of how the application uses "levels") for you to configure "syslog" for that application. good luck! -Chuck Kollars ____________________________________________________________________________________ Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list&sid=396545469 ------------------------------------------------------------------------- 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/
> ... how logging on a Unix system works ...Shorewall -like many well-integrated *nix subsystems- uses the "syslog" capability of *nix (rather than rolling its own logging). So you can search Shorewall documentation high and low and not find what you''re looking for; do `man syslog` on your *nix system (or Google "man syslog"). Syslog has scads of capabilities for large complex multi systems, but you can simply ignore all that. For example there''s a way to combine _in_real_time_ messages from several different systems onto one system more or less dedicated to handling messages. But you can just treat "syslog" as single-system. Syslog pre-defines levels of messages. Applications can''t affect the names or the order (although they do have quite a bit of latitude to choose for themselves what they consider to be an "info" and what they consider to be an "emerg" etc.). The pre-defined levels (in decreasing order) are: emerg system is or will be unusable if situation is not resolved alert immediate action required crit critical situations warning recoverable errors notice unusual situation that merits investigation; a significant event that is typically part of normal day-to-day operation info informational messages debug verbose data for debugging You control this with configuration of "syslog" itself (often via the file /etc/syslog.conf). You control which messages go into which file(s) and/or onto which screen(s). Often the first 2/3 of this configuration are set "by convention" ...but the convention is different for different Linux distributions. You fill in the rest of the configuration for optional subsystems such as Shorewall. There are two slightly different ways for configuring "syslog" which are not quite fully compatible with each other, so check your own system''s documentation carefully and thoroughly. Specifying a level normally gives you that level _and_all_levels_above_it_, so for example if you specify level "crit" you''ll also get levels "alert" and "emerg". What the application documentation will usually tell you is just enough information (something called a "facility", a brief description of how the application uses "levels") for you to configure "syslog" for that application. good luck! -Chuck Kollars ____________________________________________________________________________________ Need a vacation? Get great deals to amazing places on Yahoo! Travel. http://travel.yahoo.com/ ------------------------------------------------------------------------- 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/
Chuck Kollars wrote:> The pre-defined > levels (in decreasing order) are: > > emerg – system is or will be unusable if situation > is not resolved > alert – immediate action required > crit – critical situations > warning – recoverable errors > notice – unusual situation that merits > investigation; a significant event that is typically > part of normal day-to-day operation > info – informational messages > debug – verbose data for debugging > > You control this with configuration of "syslog" itself > (often via the file /etc/syslog.conf). You control > which messages go into which file(s) and/or onto which > screen(s).> Specifying a level normally > gives you that level _and_all_levels_above_it_, so for > example if you specify level "crit" you''ll also get > levels "alert" and "emerg".Note that the above list is in decreasing order of message importance. It follows that those messages with levels at the top of the list are more important than those with levels at the bottom. Hence, giving a message a level toward the bottom of the list is likely to suppress its being written to some (sometimes all) of the logs. -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:> Chuck Kollars wrote: >> The pre-defined >> levels (in decreasing order) are: >> >> emerg – system is or will be unusable if situation >> is not resolved >> alert – immediate action required >> crit – critical situations >> warning – recoverable errors >> notice – unusual situation that merits >> investigation; a significant event that is typically >> part of normal day-to-day operation >> info – informational messages >> debug – verbose data for debugging >> >> You control this with configuration of "syslog" itself >> (often via the file /etc/syslog.conf). You control >> which messages go into which file(s) and/or onto which >> screen(s). > >> Specifying a level normally >> gives you that level _and_all_levels_above_it_, so for >> example if you specify level "crit" you''ll also get >> levels "alert" and "emerg". > > Note that the above list is in decreasing order of message importance. > It follows that those messages with levels at the top of the list are > more important than those with levels at the bottom. Hence, giving a > message a level toward the bottom of the list is likely to suppress its > being written to some (sometimes all) of the logs.BTW: I was addressing my remarks to John, not to Chuck. Hope that was clear... -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/
That was simple and to the point. I guess it was a bit much for Tom, but I wasn''t asking to be taught how syslog worked. All I wanted to know was how to stop the logging from shorewall and you answered that. Thank you. ----------------------------------------> Date: Mon, 15 Oct 2007 22:46:11 +0000> From: will.murnane@gmail.com> To: shorewall-users@lists.sourceforge.net> Subject: Re: [Shorewall-users] How to shut down logging?>> On 10/15/07, J and T wrote:>> I already had the policy logging set to:>>>> net all DROP err>> all all REJECT err>>>> I thought it would only log "err"ors. Do I instead need to set this to "emerg"? I guess I just don''t get it.> As documented in policy(5):> #SOURCE DEST POLICY LOG BURST:LIMIT> net all DROP err>> So this line says "If it''s coming from net to all, drop it and log it> at level err." Remove "err" entirely, and it should stop logging all> those packets.>> Will>> -------------------------------------------------------------------------> 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 _________________________________________________________________ Help yourself to FREE treats served up daily at the Messenger Café. Stop by today. http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=TXT_TAGLM_OctWLtagline ------------------------------------------------------------------------- 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/