Thread: [Fwbuilder-discussion] debugging SAMBA/Netbios port 138 broadcasts
Brought to you by:
mikehorn
From: OpenMacNews <fwb...@sp...> - 2004-08-30 20:03:53
|
hi, i've just installed a SAMBA server on my LAN, for use/broadcast ONLY inside the LAN. despite all other internal traffic flowing along nicely, i'm seeing related port 138 traffice caught by my Global Catch-all rule: Aug 30 12:54:05 linksys kernel: [Catch: global(20) DENY] IN=br0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:00:46:d3:e2:1b:82:00 SRC=10.0.0.2 DST=10.0.0.255 LEN=234 TOS=0x00 PREC=0x00 TTL=64 ID=35443 PROTO=UDP SPT=138 DPT=138 LEN=214 where 10.0.0.2 is the SAMBA box, and 10.0.0.1 is the Firewall/Gateway as a debugging step, i setup an Internal Intfc rule: Src: LAN Dst: LAN Direction: Both Action: Accept, Log which does what i think it should be doing, i.e., ALLOW this traffic: Aug 30 12:54:05 linksys kernel: [br0(0) ACCEPT] IN=br0 OUT=br0 SRC=10.0.0.2 DST=10.0.0.255 LEN=234 TOS=0x00 PREC=0x00 TTL=64 ID=35443 PROTO=UDP SPT=138 DPT=138 LEN=214 so, question is, why is the LAN-to-LAN traffic subsequently falling through to the GlobalCatchAll rule? the MAC address and no "OUT=" makes be suspect the FW object needs to involved ... but what rule specifically? richard |
From: Vadim K. /r/ <va...@vk...> - 2004-08-30 20:57:09
|
On Aug 30, 2004, at 1:03 PM, OpenMacNews wrote: > hi, > > i've just installed a SAMBA server on my LAN, for use/broadcast ONLY > inside the LAN. > > despite all other internal traffic flowing along nicely, i'm seeing > related port 138 traffice caught by my Global Catch-all rule: > > > Aug 30 12:54:05 linksys kernel: [Catch: global(20) DENY] IN=br0 > OUT= MAC=ff:ff:ff:ff:ff:ff:00:00:46:d3:e2:1b:82:00 SRC=10.0.0.2 > DST=10.0.0.255 LEN=234 TOS=0x00 PREC=0x00 TTL=64 ID=35443 PROTO=UDP > SPT=138 DPT=138 LEN=214 > these are broadcast packets, that's why your firewall sees them. There is no harm in blocking them on the firewall; it would not be able, or need to, use them anyway. --vk > where 10.0.0.2 is the SAMBA box, and 10.0.0.1 is the Firewall/Gateway > > as a debugging step, i setup an Internal Intfc rule: > > Src: LAN > Dst: LAN > Direction: Both > Action: Accept, Log > > which does what i think it should be doing, i.e., ALLOW this traffic: > > Aug 30 12:54:05 linksys kernel: [br0(0) ACCEPT] IN=br0 OUT=br0 > SRC=10.0.0.2 DST=10.0.0.255 LEN=234 TOS=0x00 PREC=0x00 TTL=64 ID=35443 > PROTO=UDP SPT=138 DPT=138 LEN=214 > > so, question is, why is the LAN-to-LAN traffic subsequently falling > through to the GlobalCatchAll rule? the MAC address and no "OUT=" > makes be suspect the FW object needs to involved ... but what rule > specifically? > > richard > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > _______________________________________________ > Fwbuilder-discussion mailing list > Fwb...@li... > https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion |
From: OpenMacNews <fwb...@sp...> - 2004-08-30 21:06:43
|
>> hi, >> >> i've just installed a SAMBA server on my LAN, for use/broadcast ONLY >> inside the LAN. >> >> despite all other internal traffic flowing along nicely, i'm seeing >> related port 138 traffice caught by my Global Catch-all rule: >> >> >> Aug 30 12:54:05 linksys kernel: [Catch: global(20) DENY] IN=br0 >> OUT= MAC=ff:ff:ff:ff:ff:ff:00:00:46:d3:e2:1b:82:00 SRC=10.0.0.2 >> DST=10.0.0.255 LEN=234 TOS=0x00 PREC=0x00 TTL=64 ID=35443 PROTO=UDP >> SPT=138 DPT=138 LEN=214 >> > > these are broadcast packets, that's why your firewall sees them. There is no harm in blocking them on the firewall; it would not be able, or need to, use them anyway. understood. but isn't a BROADCAST considered lan-to-lan traffic? and therefore should not be 'generically' blocked under any circumstance? AFAIK, there's no specific rule *prohibiting* this traffic ... at the very least, which specific rule needs to be enable to ensure that these packets -- even tho caught -- are not logged by the global catch-all? richardf |
From: Vadim K. /r/ <va...@vk...> - 2004-08-30 21:16:13
|
On Aug 30, 2004, at 2:06 PM, OpenMacNews wrote: >>> hi, >>> >>> i've just installed a SAMBA server on my LAN, for use/broadcast ONLY >>> inside the LAN. >>> >>> despite all other internal traffic flowing along nicely, i'm seeing >>> related port 138 traffice caught by my Global Catch-all rule: >>> >>> >>> Aug 30 12:54:05 linksys kernel: [Catch: global(20) DENY] >>> IN=br0 >>> OUT= MAC=ff:ff:ff:ff:ff:ff:00:00:46:d3:e2:1b:82:00 SRC=10.0.0.2 >>> DST=10.0.0.255 LEN=234 TOS=0x00 PREC=0x00 TTL=64 ID=35443 PROTO=UDP >>> SPT=138 DPT=138 LEN=214 >>> >> >> these are broadcast packets, that's why your firewall sees them. >> There is no harm in blocking them on the firewall; it would not be >> able, or need to, use them anyway. > > > understood. > > but isn't a BROADCAST considered lan-to-lan traffic? and therefore > should not be 'generically' blocked under any circumstance? AFAIK, > there's no specific rule *prohibiting* this traffic ... > is there specific rule permitting it ? If not, then catch all rule prohibits it. > at the very least, which specific rule needs to be enable to ensure > that these packets -- even tho caught -- are not logged by the global > catch-all? > method 1: a rule somewhere above the catch-all one, with action DROP and no logging, with source and destination "any" and collection of some service objects in service. These objects should be all services you do not care about that generate broadcast packets, such as all this Microsoft stuff, DHCP, may be something else. If you put this rule in the global policy, it will drop without logging these on the outside as well Obviously you should not block DHCP in a rule like this if you use your firewall as DHCP server for the LAN. Use your judgment. method 2: a rule with action ACCEPT and no logging, with source and destination 10.0.0.0/24 and service 'any'. This will permit all sorts of things from internal LAN to broadcast as well as to the firewall itself. If you trust your LAN, it is not a problem that you permit everything from it to the firewall. This rule won't filter junk on the outside. I believe you either used to have or have now a rule per #2. --vk |