On 5/23/11 5:28 PM, Mr Dash Four wrote:
> 
>>     d)  The BLACKLIST_DISPOSITION, MACLIST_DISPOSITION and
>>         TCP_FLAGS_DISPOSITION options may be set as follows:
>>
>>      BLACKLIST_DISPOSITION         A_DROP or A_REJECT
>>      MACLIST_DISPOSITION           A_DROP 
>>                                    A_REJECT, unless
>>                                             MACLIST_TABLE=mangle
>>         TCP_FLAGS_DISPOSITION         A_DROP or A_REJECT
>>   
> I've just tested this (with the exception of MACLIST_DISPOSITION), 
> though I do not know why I can't disable the logging (to the syslog) as 
> the tcpflags chain is as follows:
> 
> Chain logflags (5 references)
>  pkts bytes target     prot opt in     out     source               
> destination        
>     0     0 LOG        all  --  *      *       0.0.0.0/0            
> 0.0.0.0/0           LOG flags 4 level 6 prefix `Shorewall:logflags:A_DROP:'
>     0     0 AUDIT      all  --  *      *       0.0.0.0/0            
> 0.0.0.0/0            AUDIT drop
>     0     0 DROP       all  --  *      *       0.0.0.0/0            
> 0.0.0.0/0          
> 
> Is there a way I could get rid of the first statement?

'man shorewall.conf' and look for TCP_FLAGS_LOG_LEVEL

> 
>>     e)  A SMURF_DISPOSITION option has been added to
>>         shorewall.conf. The default value is DROP; if the option is set
>>         to A_DROP, then dropped smurfs are audited.
>>   
> Two things:
> 
> Chain smurfs (2 references)
>  pkts bytes target     prot opt in     out     source               
> destination        
>     0     0 RETURN     all  --  *      *       0.0.0.0              
> 0.0.0.0/0          
>     0     0 smurflog   all  --  *      *       0.0.0.0/0            
> 0.0.0.0/0           [goto] ADDRTYPE match src-type BROADCAST
>     0     0 smurflog   all  --  *      *       224.0.0.0/4          
> 0.0.0.0/0           [goto]
> 
> I can't see a way in which there will ever be a jump to smurflog!

Look at the first rule again. Apparently, there is an optional interface
that is not currently up so Shorewall uses an unmatchable address
(0.0.0.0) in that case.

What is causing this? Also, the same comment as with logflags above:
> 
> Chain smurflog (2 references)
>  pkts bytes target     prot opt in     out     source               
> destination        
>     0     0 LOG        all  --  *      *       0.0.0.0/0            
> 0.0.0.0/0           LOG flags 0 level 6 prefix `Shorewall:smurfs:DROP:'
>     0     0 AUDIT      all  --  *      *       0.0.0.0/0            
> 0.0.0.0/0            AUDIT drop
>     0     0 DROP       all  --  *      *       0.0.0.0/0            
> 0.0.0.0/0          
> 
> Is there a way to get rid of the LOG statement?

man shorewall.conf and look for SMURF_LOG_LEVEL

> 
>>     f)  An 'audit' option has been added to the
>>         /etc/shorewall/blacklist file which causes the packets matching
>>         the entryto be audited. 'audit' may not be specified together
>>         with 'accept'.
>>   
> That works beautifully!

Good.

-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 \________________________________________________

Attachment: signature.asc
Description: OpenPGP digital signature

------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Shorewall-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-devel

Reply via email to