All of lore.kernel.org
 help / color / mirror / Atom feed
* block broadcast traffic
@ 2005-03-03 15:19 George Liu
  2005-03-04 15:24 ` Jason Opperisano
  0 siblings, 1 reply; 2+ messages in thread
From: George Liu @ 2005-03-03 15:19 UTC (permalink / raw)
  To: netfilter

I tried to use iptables to block inbound and outbound netbios broadcast 
announcement traffic of a system with IP 10.1.1.76. It seems iptables 
doesn't work. Is this a limitation or rule wrong? Thanks.



*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT

-A RH-Firewall-1-INPUT -s 10.1.1.0/22 -p udp -m multiport --ports 
135,136,237,138,139,445 -j REJECT
-A RH-Firewall-1-INPUT -d 10.1.1.0/22 -p udp -m multiport --ports 
135,136,237,138,139,445 -j REJECT
-A RH-Firewall-1-INPUT -p udp -m multiport --ports 
135,136,237,138,139,445 -j REJECT



^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: block broadcast traffic
  2005-03-03 15:19 block broadcast traffic George Liu
@ 2005-03-04 15:24 ` Jason Opperisano
  0 siblings, 0 replies; 2+ messages in thread
From: Jason Opperisano @ 2005-03-04 15:24 UTC (permalink / raw)
  To: netfilter

On Thu, 2005-03-03 at 10:19, George Liu wrote:
> I tried to use iptables to block inbound and outbound netbios broadcast 
> announcement traffic of a system with IP 10.1.1.76. It seems iptables 
> doesn't work. 

i'm pretty sure iptables works...maybe just for me though.

are you applying these rules *on* 10.1.1.76 in an attempt to keep it
from sending/receiving netbios packets; or is 10.1.1.76 remote to this
machine with the firewall rules?

if it's the first case--you need to be modifying INPUT and OUTPUT, not
INPUT and FORWARD...(in any case--broadcast packets are not normally
forwarded through routing gateways anyways...)

> Is this a limitation or rule wrong? Thanks.
> 
> *filter
> :INPUT ACCEPT [0:0]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [0:0]
> :RH-Firewall-1-INPUT - [0:0]
> -A INPUT -j RH-Firewall-1-INPUT
> -A FORWARD -j RH-Firewall-1-INPUT
> 
> -A RH-Firewall-1-INPUT -s 10.1.1.0/22 -p udp -m multiport --ports 
> 135,136,237,138,139,445 -j REJECT
> -A RH-Firewall-1-INPUT -d 10.1.1.0/22 -p udp -m multiport --ports 
> 135,136,237,138,139,445 -j REJECT
> -A RH-Firewall-1-INPUT -p udp -m multiport --ports 
> 135,136,237,138,139,445 -j REJECT

ports 135, 139, and 445 in the context of a microsoft network use TCP,
not UDP; and are unicast, not broadcast based.

the UDP ports used for name and service broadcasts are UDP 137 and 138,
not 237 and 138...

-j

--
"Call this an unfair generalization if you must, but old people are
 no good at everything."
	--The Simpsons



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2005-03-04 15:24 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-03-03 15:19 block broadcast traffic George Liu
2005-03-04 15:24 ` Jason Opperisano

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.