TCP/IP Packet Filtering

[Guest]

Archived from groups: microsoft.public.win2000.security (More info?)

I am trying to set up a cheap firewall on my web server which is a
win2k server machine. All I need to do is use IIS on port 80 and do
basic web surfing with IE6. So I used the TCP/IP Packet filtering
feature to PERMIT ONLY ports 80 and 53 (DNS) in both TCP and UDP.
After rebooting, I can serve up web pages via IIS but I can't surf via
IE6. I've done extensive research on this and looked up common port
defs and added PERMITS on ports 139, 137, 161, and 520. And added
PERMITS on IP Protocls 1 to 5, but still no luck.

I tried the exact same thing on a whole different network that happens
to be behind a cable/DSL router. The funny thing about that is I can
use ie6 to connect to a web server behind the router, but can't surf
on the general internet.

Any suggestions?

Thanks,

Thread7

 

[Guest]

Archived from groups: microsoft.public.win2000.security (More info?)

The best way to learn what you did is to fire up a network sniffer and trace the
traffic on that machine when you go to surf. It should become fairly obvious
after a few glances at the trace.

You can use netmon from MS or go get Ethereal from www.ethereal.com.

--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net



Jim Bohan wrote:
> I am trying to set up a cheap firewall on my web server which is a
> win2k server machine. All I need to do is use IIS on port 80 and do
> basic web surfing with IE6. So I used the TCP/IP Packet filtering
> feature to PERMIT ONLY ports 80 and 53 (DNS) in both TCP and UDP.
> After rebooting, I can serve up web pages via IIS but I can't surf via
> IE6. I've done extensive research on this and looked up common port
> defs and added PERMITS on ports 139, 137, 161, and 520. And added
> PERMITS on IP Protocls 1 to 5, but still no luck.
>
> I tried the exact same thing on a whole different network that happens
> to be behind a cable/DSL router. The funny thing about that is I can
> use ie6 to connect to a web server behind the router, but can't surf
> on the general internet.
>
> Any suggestions?
>
> Thanks,
>
> Thread7

 

[Guest]

Archived from groups: microsoft.public.win2000.security (More info?)

Well I installed a network sniffer and this problem has become even
more of a mystery. I was almost sure that it had something to do with
UDP traffic because when I take off the PERMIT ONLY settings on UDP
but leave them on TCP and IP Protocol I can use IE6. But when I put
the PERMIT ONLY's back on UDP, my browsers (inclduing mozilla) don't
work again. They just time out.
So I figured the network sniffer would fine some port in UDP that I
needed to enable. But it didn't. When I successfully surf to a site,
there is absolutely no UDP traffic according to the sniffer - only TCP
traffic. (Remember I can surf on the internal network even with
PERMIT ONLY's set on UDP, but the general internet I cannot.) When I
can't connect to a site, there is absolutely no traffic whatsoever
according to the sniffer. It is like I didn't even have my browser
going. Arggh! I know there is an easy fix but I've tried it on
several different PC's/networks with the same results.

Thanks,

Thread7


"Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
> The best way to learn what you did is to fire up a network sniffer and trace the
> traffic on that machine when you go to surf. It should become fairly obvious
> after a few glances at the trace.
>
> You can use netmon from MS or go get Ethereal from www.ethereal.com.
>
> --
> Joe Richards Microsoft MVP Windows Server Directory Services
> www.joeware.net
>
>
>
> Jim Bohan wrote:
> > I am trying to set up a cheap firewall on my web server which is a
> > win2k server machine. All I need to do is use IIS on port 80 and do
> > basic web surfing with IE6. So I used the TCP/IP Packet filtering
> > feature to PERMIT ONLY ports 80 and 53 (DNS) in both TCP and UDP.
> > After rebooting, I can serve up web pages via IIS but I can't surf via
> > IE6. I've done extensive research on this and looked up common port
> > defs and added PERMITS on ports 139, 137, 161, and 520. And added
> > PERMITS on IP Protocls 1 to 5, but still no luck.
> >
> > I tried the exact same thing on a whole different network that happens
> > to be behind a cable/DSL router. The funny thing about that is I can
> > use ie6 to connect to a web server behind the router, but can't surf
> > on the general internet.
> >
> > Any suggestions?
> >
> > Thanks,
> >
> > Thread7

 

[Guest]

Archived from groups: microsoft.public.win2000.security (More info?)

Note that a network trace will show you all traffic even if the PC isn't using
it when you are using this type of filtering. It isn't like an external firewall
where the traffic will be blocked...

Another hint, look for DNS queries. Do you see responses. What does the machine
do with the response? Does it query again or does it go to that IP address?

joe

--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net



Jim Bohan wrote:
> Well I installed a network sniffer and this problem has become even
> more of a mystery. I was almost sure that it had something to do with
> UDP traffic because when I take off the PERMIT ONLY settings on UDP
> but leave them on TCP and IP Protocol I can use IE6. But when I put
> the PERMIT ONLY's back on UDP, my browsers (inclduing mozilla) don't
> work again. They just time out.
> So I figured the network sniffer would fine some port in UDP that I
> needed to enable. But it didn't. When I successfully surf to a site,
> there is absolutely no UDP traffic according to the sniffer - only TCP
> traffic. (Remember I can surf on the internal network even with
> PERMIT ONLY's set on UDP, but the general internet I cannot.) When I
> can't connect to a site, there is absolutely no traffic whatsoever
> according to the sniffer. It is like I didn't even have my browser
> going. Arggh! I know there is an easy fix but I've tried it on
> several different PC's/networks with the same results.
>
> Thanks,
>
> Thread7
>
>
> "Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
>
>>The best way to learn what you did is to fire up a network sniffer and trace the
>>traffic on that machine when you go to surf. It should become fairly obvious
>>after a few glances at the trace.
>>
>>You can use netmon from MS or go get Ethereal from www.ethereal.com.
>>
>>--
>>Joe Richards Microsoft MVP Windows Server Directory Services
>>www.joeware.net
>>
>>
>>
>>Jim Bohan wrote:
>>
>>>I am trying to set up a cheap firewall on my web server which is a
>>>win2k server machine. All I need to do is use IIS on port 80 and do
>>>basic web surfing with IE6. So I used the TCP/IP Packet filtering
>>>feature to PERMIT ONLY ports 80 and 53 (DNS) in both TCP and UDP.
>>>After rebooting, I can serve up web pages via IIS but I can't surf via
>>>IE6. I've done extensive research on this and looked up common port
>>>defs and added PERMITS on ports 139, 137, 161, and 520. And added
>>>PERMITS on IP Protocls 1 to 5, but still no luck.
>>>
>>>I tried the exact same thing on a whole different network that happens
>>>to be behind a cable/DSL router. The funny thing about that is I can
>>>use ie6 to connect to a web server behind the router, but can't surf
>>>on the general internet.
>>>
>>>Any suggestions?
>>>
>>>Thanks,
>>>
>>>Thread7

 

[Guest]

Archived from groups: microsoft.public.win2000.security (More info?)

First when you are using dns to resolve and internet name you are using port 53 udp
"outbound" - not inbound. IP udp filtering is useless for using dns as you need to
configure the policy to allow the above 1024 ports for return traffic from the
external dns server to your computer which is not practical. For whatever reason IP
filtering on tcp knows when inbound traffic is from a response you initiated but it
does NOT for udp. I suggest that you leave just port 80 in your list for tcp and then
disable udp filtering and create an ipsec filtering policy instead through Local
Security Policy. Start with a mirrored block all IP policy for udp. Then add a
mirrored rule that permits traffic from your IP to any IP from any port to port 53
udp and you should be all set. By the way, opening port 139 tcp is a HUGE risk if you
have file and print sharing enabled on any computer. Ipsec policies take affect
almost immediately after being assigned or unassigned and do not require a
reboot. --- Steve

http://www.securityfocus.com/infocus/1559 --- about ipsec policies

"Jim Bohan" <Thread7@hotmail.com> wrote in message
news:49c7cba4.0407021328.24267d96@posting.google.com...
> I am trying to set up a cheap firewall on my web server which is a
> win2k server machine. All I need to do is use IIS on port 80 and do
> basic web surfing with IE6. So I used the TCP/IP Packet filtering
> feature to PERMIT ONLY ports 80 and 53 (DNS) in both TCP and UDP.
> After rebooting, I can serve up web pages via IIS but I can't surf via
> IE6. I've done extensive research on this and looked up common port
> defs and added PERMITS on ports 139, 137, 161, and 520. And added
> PERMITS on IP Protocls 1 to 5, but still no luck.
>
> I tried the exact same thing on a whole different network that happens
> to be behind a cable/DSL router. The funny thing about that is I can
> use ie6 to connect to a web server behind the router, but can't surf
> on the general internet.
>
> Any suggestions?
>
> Thanks,
>
> Thread7

 

[Guest]

Archived from groups: microsoft.public.win2000.security (More info?)

Steve! I was walking him through the figure it out learning process man! Now you
gave him the fish.

Oh well.

joe

--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net



Steven L Umbach wrote:
> First when you are using dns to resolve and internet name you are using port 53 udp
> "outbound" - not inbound. IP udp filtering is useless for using dns as you need to
> configure the policy to allow the above 1024 ports for return traffic from the
> external dns server to your computer which is not practical. For whatever reason IP
> filtering on tcp knows when inbound traffic is from a response you initiated but it
> does NOT for udp. I suggest that you leave just port 80 in your list for tcp and then
> disable udp filtering and create an ipsec filtering policy instead through Local
> Security Policy. Start with a mirrored block all IP policy for udp. Then add a
> mirrored rule that permits traffic from your IP to any IP from any port to port 53
> udp and you should be all set. By the way, opening port 139 tcp is a HUGE risk if you
> have file and print sharing enabled on any computer. Ipsec policies take affect
> almost immediately after being assigned or unassigned and do not require a
> reboot. --- Steve
>
> http://www.securityfocus.com/infocus/1559 --- about ipsec policies
>
> "Jim Bohan" <Thread7@hotmail.com> wrote in message
> news:49c7cba4.0407021328.24267d96@posting.google.com...
>
>>I am trying to set up a cheap firewall on my web server which is a
>>win2k server machine. All I need to do is use IIS on port 80 and do
>>basic web surfing with IE6. So I used the TCP/IP Packet filtering
>>feature to PERMIT ONLY ports 80 and 53 (DNS) in both TCP and UDP.
>>After rebooting, I can serve up web pages via IIS but I can't surf via
>>IE6. I've done extensive research on this and looked up common port
>>defs and added PERMITS on ports 139, 137, 161, and 520. And added
>>PERMITS on IP Protocls 1 to 5, but still no luck.
>>
>>I tried the exact same thing on a whole different network that happens
>>to be behind a cable/DSL router. The funny thing about that is I can
>>use ie6 to connect to a web server behind the router, but can't surf
>>on the general internet.
>>
>>Any suggestions?
>>
>>Thanks,
>>
>>Thread7
>
>
>

 

[Guest]

Archived from groups: microsoft.public.win2000.security (More info?)

So sorry Joe! [Steve hangs his head in shame] I guess the Holiday spirit overcame
me. Hopefully he still has learned.--- Steve

"Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
news:%23glnm9VYEHA.3536@TK2MSFTNGP11.phx.gbl...
> Steve! I was walking him through the figure it out learning process man! Now you
> gave him the fish.
>
> Oh well.
>
> joe
>
> --
> Joe Richards Microsoft MVP Windows Server Directory Services
> www.joeware.net
>
>
>
> Steven L Umbach wrote:
> > First when you are using dns to resolve and internet name you are using port 53
udp
> > "outbound" - not inbound. IP udp filtering is useless for using dns as you need
to
> > configure the policy to allow the above 1024 ports for return traffic from the
> > external dns server to your computer which is not practical. For whatever reason
IP
> > filtering on tcp knows when inbound traffic is from a response you initiated but
it
> > does NOT for udp. I suggest that you leave just port 80 in your list for tcp and
then
> > disable udp filtering and create an ipsec filtering policy instead through Local
> > Security Policy. Start with a mirrored block all IP policy for udp. Then add a
> > mirrored rule that permits traffic from your IP to any IP from any port to port
53
> > udp and you should be all set. By the way, opening port 139 tcp is a HUGE risk if
you
> > have file and print sharing enabled on any computer. Ipsec policies take affect
> > almost immediately after being assigned or unassigned and do not require a
> > reboot. --- Steve
> >
> > http://www.securityfocus.com/infocus/1559 --- about ipsec policies
> >
> > "Jim Bohan" <Thread7@hotmail.com> wrote in message
> > news:49c7cba4.0407021328.24267d96@posting.google.com...
> >
> >>I am trying to set up a cheap firewall on my web server which is a
> >>win2k server machine. All I need to do is use IIS on port 80 and do
> >>basic web surfing with IE6. So I used the TCP/IP Packet filtering
> >>feature to PERMIT ONLY ports 80 and 53 (DNS) in both TCP and UDP.
> >>After rebooting, I can serve up web pages via IIS but I can't surf via
> >>IE6. I've done extensive research on this and looked up common port
> >>defs and added PERMITS on ports 139, 137, 161, and 520. And added
> >>PERMITS on IP Protocls 1 to 5, but still no luck.
> >>
> >>I tried the exact same thing on a whole different network that happens
> >>to be behind a cable/DSL router. The funny thing about that is I can
> >>use ie6 to connect to a web server behind the router, but can't surf
> >>on the general internet.
> >>
> >>Any suggestions?
> >>
> >>Thanks,
> >>
> >>Thread7
> >
> >
> >

 

[Guest]

Archived from groups: microsoft.public.win2000.security (More info?)

Yep, possibly this will promote learning anyway.

--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net



Steven L Umbach wrote:
> So sorry Joe! [Steve hangs his head in shame] I guess the Holiday spirit overcame
> me. Hopefully he still has learned.--- Steve
>
> "Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
> news:%23glnm9VYEHA.3536@TK2MSFTNGP11.phx.gbl...
>
>>Steve! I was walking him through the figure it out learning process man! Now you
>>gave him the fish.
>>
>>Oh well.
>>
>> joe
>>
>>--
>>Joe Richards Microsoft MVP Windows Server Directory Services
>>www.joeware.net
>>
>>
>>
>>Steven L Umbach wrote:
>>
>>>First when you are using dns to resolve and internet name you are using port 53
>
> udp
>
>>>"outbound" - not inbound. IP udp filtering is useless for using dns as you need
>
> to
>
>>>configure the policy to allow the above 1024 ports for return traffic from the
>>>external dns server to your computer which is not practical. For whatever reason
>
> IP
>
>>>filtering on tcp knows when inbound traffic is from a response you initiated but
>
> it
>
>>>does NOT for udp. I suggest that you leave just port 80 in your list for tcp and
>
> then
>
>>>disable udp filtering and create an ipsec filtering policy instead through Local
>>>Security Policy. Start with a mirrored block all IP policy for udp. Then add a
>>>mirrored rule that permits traffic from your IP to any IP from any port to port
>
> 53
>
>>>udp and you should be all set. By the way, opening port 139 tcp is a HUGE risk if
>
> you
>
>>>have file and print sharing enabled on any computer. Ipsec policies take affect
>>>almost immediately after being assigned or unassigned and do not require a
>>>reboot. --- Steve
>>>
>>>http://www.securityfocus.com/infocus/1559 --- about ipsec policies
>>>
>>>"Jim Bohan" <Thread7@hotmail.com> wrote in message
>>>news:49c7cba4.0407021328.24267d96@posting.google.com...
>>>
>>>
>>>>I am trying to set up a cheap firewall on my web server which is a
>>>>win2k server machine. All I need to do is use IIS on port 80 and do
>>>>basic web surfing with IE6. So I used the TCP/IP Packet filtering
>>>>feature to PERMIT ONLY ports 80 and 53 (DNS) in both TCP and UDP.
>>>>After rebooting, I can serve up web pages via IIS but I can't surf via
>>>>IE6. I've done extensive research on this and looked up common port
>>>>defs and added PERMITS on ports 139, 137, 161, and 520. And added
>>>>PERMITS on IP Protocls 1 to 5, but still no luck.
>>>>
>>>>I tried the exact same thing on a whole different network that happens
>>>>to be behind a cable/DSL router. The funny thing about that is I can
>>>>use ie6 to connect to a web server behind the router, but can't surf
>>>>on the general internet.
>>>>
>>>>Any suggestions?
>>>>
>>>>Thanks,
>>>>
>>>>Thread7
>>>
>>>
>>>
>
>

 

[Guest]

Archived from groups: microsoft.public.win2000.security (More info?)

Joe,

Well he gave me the fish, but I did learn. I could find no
documentation telling me Steve's statement - "IP udp filtering is
useless for using dns as you need to configure the policy to allow the
above 1024 ports for return traffic from the external dns server to
your computer which is not practical." After hours trying to figure
out why the UDP traffic wasn't coming through I was at a dead end and
finally had to ask some "experts" such as yourselves. Great response
guys.

Thread7

 

[Guest]

Archived from groups: microsoft.public.win2000.security (More info?)

Hi Jim.

FYI. I have pasted a capture from Ethereal so you can see the sequence that
caused you grief. I modified the output screen to show unresolved source and
destination ports . I am not sure how good it will look in a paste but here
goes. This is an example on a capture just before I opened my web browser
which has a home page of Foxnews.com and my internal lan IP address is
192.168.1.105. Notice my computer using a source port of 3513 to a
destination port of 53 and the response of the dns server from port 53 back
to port 3513. It would be the port 3513 udp in this example that would be
blocked by the udp port filtering. Keep in mind that W2K dns client caches
recent dns queries including failures. So if you do any testing in the
future, always use the command " ipconfig /flushdns" to clear the dns client
cache first. --- Steve


Source Destination Protocol Src port Dst
port Info
192.168.1.105 202.12.27.33 DNS 3513 53
Standard query A www.foxnews.com

202.12.27.33 192.168.1.105 DNS 53 3513
Standard query response

"Jim Bohan" <Thread7@hotmail.com> wrote in message
news:49c7cba4.0407042158.181c5059@posting.google.com...
> Joe,
>
> Well he gave me the fish, but I did learn. I could find no
> documentation telling me Steve's statement - "IP udp filtering is
> useless for using dns as you need to configure the policy to allow the
> above 1024 ports for return traffic from the external dns server to
> your computer which is not practical." After hours trying to figure
> out why the UDP traffic wasn't coming through I was at a dead end and
> finally had to ask some "experts" such as yourselves. Great response
> guys.
>
> Thread7

 

[Guest]

Archived from groups: microsoft.public.win2000.security (More info?)

First off note that UDP is connectionless. It is all fire and forget. No stream
as it were for the firewall to maintain state on.

Second... You would think everything was fine by looking at that part of the
trace unless you realized that the filter was making it so the OS didn't respond
to the 3513 inbound...

What you will notice is that even though a positive response came back, the
machine would ask a couple of more times for that address to be resolved and
depending on your configuration would start to broadcast or ask WINS for help.

Basically it would look like it was ignoring the IP address that the name was
being resolved to and that is EXACTLY what is happening.

joe

--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net



Steven L Umbach wrote:
> Hi Jim.
>
> FYI. I have pasted a capture from Ethereal so you can see the sequence that
> caused you grief. I modified the output screen to show unresolved source and
> destination ports . I am not sure how good it will look in a paste but here
> goes. This is an example on a capture just before I opened my web browser
> which has a home page of Foxnews.com and my internal lan IP address is
> 192.168.1.105. Notice my computer using a source port of 3513 to a
> destination port of 53 and the response of the dns server from port 53 back
> to port 3513. It would be the port 3513 udp in this example that would be
> blocked by the udp port filtering. Keep in mind that W2K dns client caches
> recent dns queries including failures. So if you do any testing in the
> future, always use the command " ipconfig /flushdns" to clear the dns client
> cache first. --- Steve
>
>
> Source Destination Protocol Src port Dst
> port Info
> 192.168.1.105 202.12.27.33 DNS 3513 53
> Standard query A www.foxnews.com
>
> 202.12.27.33 192.168.1.105 DNS 53 3513
> Standard query response
>
> "Jim Bohan" <Thread7@hotmail.com> wrote in message
> news:49c7cba4.0407042158.181c5059@posting.google.com...
>
>>Joe,
>>
>>Well he gave me the fish, but I did learn. I could find no
>>documentation telling me Steve's statement - "IP udp filtering is
>>useless for using dns as you need to configure the policy to allow the
>>above 1024 ports for return traffic from the external dns server to
>>your computer which is not practical." After hours trying to figure
>>out why the UDP traffic wasn't coming through I was at a dead end and
>>finally had to ask some "experts" such as yourselves. Great response
>>guys.
>>
>>Thread7
>
>
>