On Wed, 2003-12-31 at 10:55, Jason Dixon wrote: > On Wed, 2003-12-31 at 11:12, Rigler, Steve wrote: > > > I'd be curious to see how you get that to work. > > > > I just tested on a machine only allowing access by destination port and > > it couldn't even do a wins query (err message about wins_srv_died). If > > I open the rules to allow according to source port it works. To accommodate SMB you must allow connections to destination ports TCP 139 & 445 and UDP 137 & 138. You also need to allow connections to destination ports UDP 137 & 138 on the broadcast address of your subnet (*.*.*.255) for browser packets. I don't normally use messaging but I tried "smbclient -M <client>" and was able to send a pop-up message to a windows box with no problem. The client addresses are defined in the lmhost file. > > Think about what you initially proposed for a second. You were > suggesting that the way to allow smb traffic is to allow all traffic > originating from ports 137:139 on the source host. > > Now, imagine the following scenario... you install Bind from source, but > decide to give up on it. Realizing that it's no longer useful, you > decide to block traffic to port 53 with iptables, but you forget and > leave named running. At some point, an exploit is released for Bind > (yeah, I know, that's a stretch ;-). Thinking that you have it blocked, > you disregard the patch. > > Someone of questionable moral fabric realizes what you've done. Knowing > you run a Samba fileserver, they try a special scan based on a hunch... > sourcing their attack from low ports (137:139), so it looks like normal > SMB/CIFS traffic. Lo and behold, you've got your iptables misconfigured > so that even though traffic to port 53 is blocked/dropped, traffic with > a source port of 137:139 is allowed. Boom-shaka-laka. > > Now that we see why your config is a bad idea, let's figure out why it's > not working for you. I don't use wins queries, so you'll need to review > your firewall logs to see what traffic isn't making it through. Mine > works fine. > > -- > Jason Dixon, RHCE > DixonGroup Consulting > http://www.dixongroup.net -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
