To IPSec Packet Filter OR Not To IPSec Packet Filter - that is the question

[Bill Tomlinson]

These questions are intended for those Microsoft Certified Professionals
that monitor this 'managed' news group:

How do you configure a W2k server IPSec Packet Filter for your LAN to handle
an anti-virus software application where the clients send "ping-packs" to
the server on ANY port above 1025 without unblocking ALL the ports above
1025?

Is it practicle to put an IPSec Packet Filter on a W2k server in your LAN,
as described in the TechNet Security section: "Hardening Specific Server
Roles - ch7," when many applications use "RANDOM" ports via RPC?

Thanks

Bill

 

[Dieter Duwe]

Have you tried to create another Ipsec filter accepting ICMP packets? I
don´t know wich one will take precedence, but you can try.

 

[Steven L Umbach]

That is exactly what you would have to do. A rule could be created to accept
that particualr traffic from the lan subnet to any destination port with a permit
filter action. Specific ipsec rules override a general rule such as "block all". --
Steve

 

[Bill Tomlinson]

Steven,

Thanks for your response.

I am still confused about the "random" nature of port assignment that this
anti-virus and other applications utilize in their programming.

If an application calls the Remote Procedure Call and asks for any available
port above 1025, then how can I create an IPSec filter that blocks all
traffic to ports that are not specifically configured, (such as those above
port 1025), and also allows these kinds of applications to function? The
assumption here is that if you don't block all traffic to ports that are not
specifically configured to allow traffic to pass, that the filter is not a
filter at all.

I would like to re-state that this question concerns my Local Area Network,
and using IPSec to create a packet filter for the LAN. What I have heard is
that IPSec packet filtering in a LAN is not recommended because applications
such as my anti-virus product are designed to depend on "random" ports being
available on request, and this is in direct conflict with blocking all ports
that are not specifically configured ahead of time.

The question could be restated as: "Are IPSec packet filters only practical
on the WAN side of your router?" OR "Is it recommended by Microsoft to
secure your LAN using the IPSec rules/filters that are configured to request
or require negotiated secure connections without using IPSec packet
filtering?"

I have read about the "dynamic" block policy for a specific Protocol and
Port, but this also appears to be a CATCH-22. If the port is assigned
randomly, and there could be multiple applications requesting a random port
via RPC, then how do you know which specific ports to configure statically
or dynamically for these applications?

I have read the white paper: "Instant Message Polling and Fixed Port
Callback Delivery," in this paper the method of configuring Fixed Port
Callback Delivery appears to be specifically programmed into SP1 of Exchange
2000 and clients, does this imply that other software vendors could also
design these features into their products to allow for Fixed Port Callback
Delivery, or is this a generic technique that can be applied to any
application that needs random port assignments?

What I am looking for is a IPSec rule that could allow a known application
to request a random port, that could then be 'dynamically' "allowed" for
that connection's lifetime only, and then blocked again after the connection
is no longer in use (sounds a bit like fixed port callback to me).

In my test network, I currently have no IPSec rules/filters 'assigned' and I
am concerned that using the IPSec Filtering (which by definition means that
there is no security negotiation, just blocking and allowing certain ports
to function) with the recommended ports open, and blocking all others will
cause these "randomly" assigned ports to be blocked, causing the
applications to fail.

I must be missing the point somewhere, is there any way you could explain
how to determine a packet filter for ports that are assigned randomly for me
in more basic terminology?

Thanks

Bill

 

[Bill Tomlinson]

Cherry,

Thank you for your response.

I am still confused about the "random" nature of port assignment that this
anti-virus and other applications utilize in their programming.

If an application calls the Remote Procedure Call and asks for any available
port above 1025, then how can I create an IPSec filter that blocks all
traffic to ports that are not specifically configured, (such as those above
port 1025), and also allows these kinds of applications to function? The
assumption here is that if you don't block all traffic to ports that are not
specifically configured to allow traffic to pass, that the filter is not a
filter at all.

I would like to re-state that this question concerns my Local Area Network,
and using IPSec to create a packet filter for the LAN. What I have heard is
that IPSec packet filtering in a LAN is not recommended because applications
such as my anti-virus product are designed to depend on "random" ports being
available on request, and this is in direct conflict with blocking all ports
that are not specifically configured ahead of time.

The question could be restated as: "Are IPSec packet filters only practical
on the WAN side of your router?" OR "Is it recommended by Microsoft to
secure your LAN using the IPSec rules/filters that are configured to request
or require negotiated secure connections without using IPSec packet
filtering?"

I have read about the "dynamic" block policy for a specific Protocol and
Port, but this also appears to be a CATCH-22. If the port is assigned
randomly, and there could be multiple applications requesting a random port
via RPC, then how do you know which specific ports to configure statically
or dynamically for these applications?

I have read the white paper: "Instant Message Polling and Fixed Port
Callback Delivery," in this paper the method of configuring Fixed Port
Callback Delivery appears to be specifically programmed into SP1 of Exchange
2000 and clients, does this imply that other software vendors could also
design these features into their products to allow for Fixed Port Callback
Delivery, or is this a generic technique that can be applied to any
application that needs random port assignments?

What I am looking for is a IPSec rule that could allow a known application
to request a random port, that could then be 'dynamically' "allowed" for
that connection's lifetime only, and then blocked again after the connection
is no longer in use (sounds a bit like fixed port callback to me).

In my test network, I currently have no IPSec rules/filters 'assigned' and I
am concerned that using the IPSec Filtering (which by definition means that
there is no security negotiation, just blocking and allowing certain ports
to function) with the recommended ports open, and blocking all others will
cause these "randomly" assigned ports to be blocked, causing the
applications to fail.

I must be missing the point somewhere, is there any way you could explain
how to determine a packet filter for ports that are assigned randomly for me
in more basic terminology?

Thanks

Bill

 

[Steven L Umbach]

For network applications/services the random unpriviliged ports above
1024 are used by the client computer to set up a session with the server
computer on one of the "well known" ports available on the server. You can
view that using netstat -an where you will see a list of connected and
listening ports. Another computer/application trying to establish a session
would have to attempt to connect to a "listening port" and would not have a
choice of ports to connect to. When a client computer attempts the
connection it tells the server computer what random port it has selected to
listen for return responses, and that port stays open only for as long as
the connection lasts. There is also a set of squence numbers exchanged with
the packets during the connection between the two computers that drastically
reduces the risk of another computer to try to connect to the open random
port on the client.

Apparently the anti virus application you use scans the above 1024 ports
to see if any unusual ones are listening because that is where the trojans
would be listening [just my guess]. So yes, you would not want to block
those ports from the computers running that application or it could not do
its job. You could however create a rule in your ipsec policy that would
exempt just that icmp traffic. Find out what port the application uses
[fport will tell you - free download], and create a permit rule for that
icmp traffic for: source - lan, destination - my address, source port -
whatever the application uses, destination port - any, protocol - whatever
icmp the application uses. I think such a rule would cause very minimal risk
on a lan even though it can not be of the dynamic nature that you desire.

Using ipsec filtering on a lan to protect from the lan may have some
merit as far as reducing the spread of trojans and keeping malicious users
from from trying to hack vulnerable services that they would not otherwise
need to access, however by design a lot of ports need to still be open to
conduct business with netbios/smb being the most vulnerable. It could be
used as part of an overall hardening strategy that incorporates effective
password policy, physically securing sensitive computers/equipment, keeping
up with critical updates, diabling uneeded services, assigning users minimum
needed rights and permissions, guarding the administrator accounts, enabling
an audit policy, etc. -- Steve

http://securityadmin.info/faq.asp#harden ---FAQ.
https://www.unc.edu/security/fport.html -- Fport.

 

[Bill Tomlinson]

Mark,

Thanks for your response.

I think I understand what you are saying here.

I am still confused about a particular situation that I have with my
Anti-Virus Software (AVS).

My AVS has built in to it a Central Administration Console (CAC), which is
very effective in reducing trips to individual workstations and servers for
configurations, virus scans etc.. As part of this CAC it uses an executable
that is a service that is initiated during machine boot/startup and is
assigned a random port from Winsock that it uses until the machine is
re-booted again. This service is used to communicate with the other servers
in the network, and as such uses the concept of "discovery" to allow the
console to manage other servers. Without this central console I will not be
able to manage other servers, and clients in a central fashion.

Now I can see how you could allow for ANY client port or address in an IPSec
filter, to come into a specific server port, but in this case I do not know
the port that is being assigned to the service on the server until the
Winsock has assigned it a port, and that port could change each time the
server is re-booted.

The engineers at the anti virus company have suggested to me that the IPSec
needs to be able to allow or block traffic to a service rather than a
specific port in order to work in a practical manner.

Do you know if the W2k Server's IPSec can be configured to allow or block
services?

Without this capability I don't see how you could effectively create an
IPSec packet filter that would work without extensive effort to determine
the port for each of these types of services each time you re-boot your
server.

It would appear that the concept of random port assignment is one born from
necessity, there are a finite number of ports 65,500 or so, and a
potentially infinite amount of services or applications that need ports to
communicate through.

Thanks

Bill

 

[Bill Tomlinson]

Steven,

Thanks for your response.

I think I understand what you are saying here.

I am still confused about a particular situation that I have with my
Anti-Virus Software (AVS).

My AVS has built in to it a Central Administration Console (CAC), which is
very effective in reducing trips to individual workstations and servers for
configurations, virus scans etc.. As part of this CAC it uses an executable
that is a service that is initiated during machine boot/startup and is
assigned a random port from Winsock that it uses until the machine is
re-booted again. This service is used to communicate with the other servers
in the network, and as such uses the concept of "discovery" to allow the
console to manage other servers. Without this central console I will not be
able to manage other servers, and clients in a central fashion.

Now I can see how you could allow for ANY client port or address in an IPSec
filter, to come into a specific server port, but in this case I do not know
the port that is being assigned to the service on the server until the
Winsock has assigned it a port, and that port could change each time the
server is re-booted.

The engineers at the anti virus company have suggested to me that the IPSec
needs to be able to allow or block traffic to a service rather than a
specific port in order to work in a practical manner.

Do you know if the W2k Server's IPSec can be configured to allow or block
services?

Without this capability I don't see how you could effectively create an
IPSec packet filter that would work without extensive effort to determine
the port for each of these types of services each time you re-boot your
server.

It would appear that the concept of random port assignment is one born from
necessity, there are a finite number of ports 65,500 or so, and a
potentially infinite amount of services or applications that need ports to
communicate through.

Thanks

Bill

For network applications/services the random unpriviliged ports above
1024 are used by the client computer to set up a session with the server
computer on one of the "well known" ports available on the server. You can
view that using netstat -an where you will see a list of connected and
listening ports. Another computer/application trying to establish a session
would have to attempt to connect to a "listening port" and would not have a
choice of ports to connect to. When a client computer attempts the
connection it tells the server computer what random port it has selected to
listen for return responses, and that port stays open only for as long as
the connection lasts. There is also a set of squence numbers exchanged with
the packets during the connection between the two computers that drastically
reduces the risk of another computer to try to connect to the open random
port on the client.

Apparently the anti virus application you use scans the above 1024 ports
to see if any unusual ones are listening because that is where the trojans
would be listening [just my guess]. So yes, you would not want to block
those ports from the computers running that application or it could not do
its job. You could however create a rule in your ipsec policy that would
exempt just that icmp traffic. Find out what port the application uses
[fport will tell you - free download], and create a permit rule for that
icmp traffic for: source - lan, destination - my address, source port -
whatever the application uses, destination port - any, protocol - whatever
icmp the application uses. I think such a rule would cause very minimal risk
on a lan even though it can not be of the dynamic nature that you desire.

Using ipsec filtering on a lan to protect from the lan may have some
merit as far as reducing the spread of trojans and keeping malicious users
from from trying to hack vulnerable services that they would not otherwise
need to access, however by design a lot of ports need to still be open to
conduct business with netbios/smb being the most vulnerable. It could be
used as part of an overall hardening strategy that incorporates effective
password policy, physically securing sensitive computers/equipment, keeping
up with critical updates, diabling uneeded services, assigning users minimum
needed rights and permissions, guarding the administrator accounts, enabling
an audit policy, etc. -- Steve

http://securityadmin.info/faq.asp#harden ---FAQ.
https://www.unc.edu/security/fport.html -- Fport.

Steven,

Thanks for your response.

I am still confused about the "random" nature of port assignment that this
anti-virus and other applications utilize in their programming.

If an application calls the Remote Procedure Call and asks for any available
port above 1025, then how can I create an IPSec filter that blocks all
traffic to ports that are not specifically configured, (such as those above
port 1025), and also allows these kinds of applications to function? The
assumption here is that if you don't block all traffic to ports that are not
specifically configured to allow traffic to pass, that the filter is not a
filter at all.

I would like to re-state that this question concerns my Local Area Network,
and using IPSec to create a packet filter for the LAN. What I have

heard

is
that IPSec packet filtering in a LAN is not recommended because applications
such as my anti-virus product are designed to depend on "random" ports being
available on request, and this is in direct conflict with blocking all ports
that are not specifically configured ahead of time.

The question could be restated as: "Are IPSec packet filters only practical
on the WAN side of your router?" OR "Is it recommended by Microsoft to
secure your LAN using the IPSec rules/filters that are configured to request
or require negotiated secure connections without using IPSec packet
filtering?"

I have read about the "dynamic" block policy for a specific Protocol and
Port, but this also appears to be a CATCH-22. If the port is assigned
randomly, and there could be multiple applications requesting a random port
via RPC, then how do you know which specific ports to configure statically
or dynamically for these applications?

I have read the white paper: "Instant Message Polling and Fixed Port
Callback Delivery," in this paper the method of configuring Fixed Port
Callback Delivery appears to be specifically programmed into SP1 of Exchange
2000 and clients, does this imply that other software vendors could also
design these features into their products to allow for Fixed Port Callback
Delivery, or is this a generic technique that can be applied to any
application that needs random port assignments?

What I am looking for is a IPSec rule that could allow a known application
to request a random port, that could then be 'dynamically' "allowed" for
that connection's lifetime only, and then blocked again after the connection
is no longer in use (sounds a bit like fixed port callback to me).

In my test network, I currently have no IPSec rules/filters 'assigned'

and

I
am concerned that using the IPSec Filtering (which by definition means that
there is no security negotiation, just blocking and allowing certain ports
to function) with the recommended ports open, and blocking all others will
cause these "randomly" assigned ports to be blocked, causing the
applications to fail.

I must be missing the point somewhere, is there any way you could explain
how to determine a packet filter for ports that are assigned randomly

for

me
in more basic terminology?

Thanks

Bill

created

to

with

a "block
all". --

packets?

I "ping-packs" your

 

[Steven L Umbach]

Mark is much more qualified than I am to answer this, but from what I
know ipsec can not be configured to filter by service - just ip addresses,
ports, and protocols. I agree it would be impratical to configure a new
filter for a service that changes port number every time it is started. You
should ask them if can be configured to use a fixed port of your choosing. I
still think there is little risk on configuring a rule that would allow icmp
[assuming that is what it uses for ping packs] from any port on the lan to
any port on the server. You still would be blocking a lot of tcp and udp
traffic with those separate rules.

To be fair to MS ipsec, I believe it was not designed to be a highly
configurable firewall. It's main purpose is to provide for AH/ESP
authentication and/or encryption on the network for securing data, but the
idea of using it for filtering caught on by using only permit or block
instead of the negotiate filter action. In many situations it is very
acceptable doing that at no additional cost. --- Steve

Steven,

Thanks for your response.

I think I understand what you are saying here.

I am still confused about a particular situation that I have with my
Anti-Virus Software (AVS).

My AVS has built in to it a Central Administration Console (CAC), which is
very effective in reducing trips to individual workstations and servers for
configurations, virus scans etc.. As part of this CAC it uses an executable
that is a service that is initiated during machine boot/startup and is
assigned a random port from Winsock that it uses until the machine is
re-booted again. This service is used to communicate with the other servers
in the network, and as such uses the concept of "discovery" to allow the
console to manage other servers. Without this central console I will not be
able to manage other servers, and clients in a central fashion.

Now I can see how you could allow for ANY client port or address in an IPSec
filter, to come into a specific server port, but in this case I do not know
the port that is being assigned to the service on the server until the
Winsock has assigned it a port, and that port could change each time the
server is re-booted.

The engineers at the anti virus company have suggested to me that the IPSec
needs to be able to allow or block traffic to a service rather than a
specific port in order to work in a practical manner.

Do you know if the W2k Server's IPSec can be configured to allow or block
services?

Without this capability I don't see how you could effectively create an
IPSec packet filter that would work without extensive effort to determine
the port for each of these types of services each time you re-boot your
server.

It would appear that the concept of random port assignment is one born from
necessity, there are a finite number of ports 65,500 or so, and a
potentially infinite amount of services or applications that need ports to
communicate through.

Thanks

Bill

For network applications/services the random unpriviliged ports above
1024 are used by the client computer to set up a session with the server
computer on one of the "well known" ports available on the server. You can
view that using netstat -an where you will see a list of connected and
listening ports. Another computer/application trying to establish a session
would have to attempt to connect to a "listening port" and would not

have

a
choice of ports to connect to. When a client computer attempts the
connection it tells the server computer what random port it has selected to
listen for return responses, and that port stays open only for as long as
the connection lasts. There is also a set of squence numbers exchanged with
the packets during the connection between the two computers that drastically
reduces the risk of another computer to try to connect to the open random
port on the client.

Apparently the anti virus application you use scans the above 1024 ports
to see if any unusual ones are listening because that is where the trojans
would be listening [just my guess]. So yes, you would not want to block
those ports from the computers running that application or it could not do
its job. You could however create a rule in your ipsec policy that would
exempt just that icmp traffic. Find out what port the application uses
[fport will tell you - free download], and create a permit rule for that
icmp traffic for: source - lan, destination - my address, source port -
whatever the application uses, destination port - any, protocol - whatever
icmp the application uses. I think such a rule would cause very minimal risk
on a lan even though it can not be of the dynamic nature that you desire.

Using ipsec filtering on a lan to protect from the lan may have some
merit as far as reducing the spread of trojans and keeping malicious users
from from trying to hack vulnerable services that they would not otherwise
need to access, however by design a lot of ports need to still be open to
conduct business with netbios/smb being the most vulnerable. It could be
used as part of an overall hardening strategy that incorporates effective
password policy, physically securing sensitive computers/equipment, keeping
up with critical updates, diabling uneeded services, assigning users minimum
needed rights and permissions, guarding the administrator accounts, enabling
an audit policy, etc. -- Steve

http://securityadmin.info/faq.asp#harden ---FAQ.
https://www.unc.edu/security/fport.html -- Fport.

Steven,

Thanks for your response.

I am still confused about the "random" nature of port assignment that this
anti-virus and other applications utilize in their programming.

If an application calls the Remote Procedure Call and asks for any available
port above 1025, then how can I create an IPSec filter that blocks all
traffic to ports that are not specifically configured, (such as those above
port 1025), and also allows these kinds of applications to function? The
assumption here is that if you don't block all traffic to ports that

are
not

specifically configured to allow traffic to pass, that the filter is

not

a heard and for created with packets? LAN
to

 

[Eric Chamberlain]

Search for RPC Dynamic ports in the knowledge base. It is a configurable
setting in the registry and allows you to limit the ports dynamically used
by RPC. Microsoft recommends 20 ports, I usually set a block of 100 IANA
unassigned ports. Then setup your IPSEC filters to leave those ports open
for the IP addresses that are allowed to connect.

 

[Cherry Qian]

Hi Bill,

Thank you for the posting again.

Remote Procedure Call (RPC) dynamic port allocation is used by remote
administration applications such as Dynamic Host Configuration Protocol
(DHCP) Manager, Windows Internet Name Service (WINS) Manager, and so on.
RPC dynamic port allocation will instruct the RPC program to use a
particular random port above 1024.

Customers using firewalls may want to control which ports RPC is using so
that their firewall router can be configured to forward only these
Transmission Control Protocol (TCP) ports.

The following registry entries apply to Windows NT 4.0 and above. They do
not apply to previous versions of Windows NT. Even though you can configure
the port used by the client to communicate with the server, the client must
be able to reach the server by its actual IP address. You cannot use DCOM
through firewalls that do address translation (e.g. where a client connects
to virtual address 198.252.145.1, which the firewall maps transparently to
the server's actual address of, say, 192.100.81.101). This is because DCOM
stores raw IP addresses in the interface marshaling packets and if the
client cannot connect to the address specified in the packet, it will not
work.

As for more information and detailed step-by-step procudure to do so,
please refer to the following knowledge base article:

154596 HOWTO: Configure RPC Dynamic Port Allocation to Work with Firewall
http://support.microsoft.com/?id=154596

300083 HOWTO: Restrict TCP/IP Ports on Windows 2000 and Windows XP
http://support.microsoft.com/?id=300083

Hope the above information and suggestion helps and answres your question.
If anythign is uclear, please let me know.


Sincerely,

Cherry Qian
MCSE2000, MCSA2000, MCDBA2000
Microsoft Partner Online Support


Get Secure! - www.microsoft.com/security

====================================================
When responding to posts, please Reply to Group via your newsreader so
that others may learn and benefit from your issue.
====================================================
This posting is provided AS IS with no warranties, and confers no rights.

 

[Bill Tomlinson]

Steven,

Thank you for your responses, they have been helpful in analyzing the
capabilities of IPSec and Packet Filters.

Bill

Mark is much more qualified than I am to answer this, but from what I
know ipsec can not be configured to filter by service - just ip addresses,
ports, and protocols. I agree it would be impratical to configure a new
filter for a service that changes port number every time it is started. You
should ask them if can be configured to use a fixed port of your choosing. I
still think there is little risk on configuring a rule that would allow icmp
[assuming that is what it uses for ping packs] from any port on the lan to
any port on the server. You still would be blocking a lot of tcp and udp
traffic with those separate rules.

To be fair to MS ipsec, I believe it was not designed to be a highly
configurable firewall. It's main purpose is to provide for AH/ESP
authentication and/or encryption on the network for securing data, but the
idea of using it for filtering caught on by using only permit or block
instead of the negotiate filter action. In many situations it is very
acceptable doing that at no additional cost. --- Steve

Steven,

Thanks for your response.

I think I understand what you are saying here.

I am still confused about a particular situation that I have with my
Anti-Virus Software (AVS).

My AVS has built in to it a Central Administration Console (CAC), which is
very effective in reducing trips to individual workstations and servers for
configurations, virus scans etc.. As part of this CAC it uses an executable
that is a service that is initiated during machine boot/startup and is
assigned a random port from Winsock that it uses until the machine is
re-booted again. This service is used to communicate with the other servers
in the network, and as such uses the concept of "discovery" to allow the
console to manage other servers. Without this central console I will

not

be
able to manage other servers, and clients in a central fashion.

Now I can see how you could allow for ANY client port or address in an IPSec
filter, to come into a specific server port, but in this case I do not know
the port that is being assigned to the service on the server until the
Winsock has assigned it a port, and that port could change each time the
server is re-booted.

The engineers at the anti virus company have suggested to me that the IPSec
needs to be able to allow or block traffic to a service rather than a
specific port in order to work in a practical manner.

Do you know if the W2k Server's IPSec can be configured to allow or block
services?

Without this capability I don't see how you could effectively create an
IPSec packet filter that would work without extensive effort to determine
the port for each of these types of services each time you re-boot your
server.

It would appear that the concept of random port assignment is one born from
necessity, there are a finite number of ports 65,500 or so, and a
potentially infinite amount of services or applications that need ports to
communicate through.

Thanks

Bill

For network applications/services the random unpriviliged ports above
1024 are used by the client computer to set up a session with the server
computer on one of the "well known" ports available on the server. You can
view that using netstat -an where you will see a list of connected and
listening ports. Another computer/application trying to establish a session
would have to attempt to connect to a "listening port" and would not

have

a
choice of ports to connect to. When a client computer attempts the
connection it tells the server computer what random port it has

selected
to

listen for return responses, and that port stays open only for as long as
the connection lasts. There is also a set of squence numbers exchanged with
the packets during the connection between the two computers that drastically
reduces the risk of another computer to try to connect to the open random
port on the client.

Apparently the anti virus application you use scans the above 1024 ports
to see if any unusual ones are listening because that is where the trojans
would be listening [just my guess]. So yes, you would not want to block
those ports from the computers running that application or it could

not

do

its job. You could however create a rule in your ipsec policy that would
exempt just that icmp traffic. Find out what port the application uses
[fport will tell you - free download], and create a permit rule for that
icmp traffic for: source - lan, destination - my address, source port -
whatever the application uses, destination port - any, protocol - whatever
icmp the application uses. I think such a rule would cause very

minimal
risk

on a lan even though it can not be of the dynamic nature that you desire.

Using ipsec filtering on a lan to protect from the lan may have some
merit as far as reducing the spread of trojans and keeping malicious users
from from trying to hack vulnerable services that they would not otherwise
need to access, however by design a lot of ports need to still be open to
conduct business with netbios/smb being the most vulnerable. It could be
used as part of an overall hardening strategy that incorporates effective
password policy, physically securing sensitive computers/equipment, keeping
up with critical updates, diabling uneeded services, assigning users minimum
needed rights and permissions, guarding the administrator accounts, enabling
an audit policy, etc. -- Steve

http://securityadmin.info/faq.asp#harden ---FAQ.
https://www.unc.edu/security/fport.html -- Fport.

Steven,

Thanks for your response.

I am still confused about the "random" nature of port assignment

that
this

anti-virus and other applications utilize in their programming.

If an application calls the Remote Procedure Call and asks for any
available
port above 1025, then how can I create an IPSec filter that blocks all
traffic to ports that are not specifically configured, (such as those
above
port 1025), and also allows these kinds of applications to function? The
assumption here is that if you don't block all traffic to ports that are
not
specifically configured to allow traffic to pass, that the filter is

not

a
filter at all.

I would like to re-state that this question concerns my Local Area
Network,
and using IPSec to create a packet filter for the LAN. What I have heard
is
that IPSec packet filtering in a LAN is not recommended because
applications
such as my anti-virus product are designed to depend on "random" ports
being
available on request, and this is in direct conflict with blocking all
ports
that are not specifically configured ahead of time.

The question could be restated as: "Are IPSec packet filters only
practical
on the WAN side of your router?" OR "Is it recommended by Microsoft to
secure your LAN using the IPSec rules/filters that are configured to
request
or require negotiated secure connections without using IPSec packet
filtering?"

I have read about the "dynamic" block policy for a specific Protocol and
Port, but this also appears to be a CATCH-22. If the port is assigned
randomly, and there could be multiple applications requesting a random
port
via RPC, then how do you know which specific ports to configure statically
or dynamically for these applications?

I have read the white paper: "Instant Message Polling and Fixed Port
Callback Delivery," in this paper the method of configuring Fixed Port
Callback Delivery appears to be specifically programmed into SP1 of
Exchange
2000 and clients, does this imply that other software vendors could also
design these features into their products to allow for Fixed Port Callback
Delivery, or is this a generic technique that can be applied to any
application that needs random port assignments?

What I am looking for is a IPSec rule that could allow a known application
to request a random port, that could then be 'dynamically' "allowed" for
that connection's lifetime only, and then blocked again after the
connection
is no longer in use (sounds a bit like fixed port callback to me).

In my test network, I currently have no IPSec rules/filters

'assigned'
and

I
am concerned that using the IPSec Filtering (which by definition means
that
there is no security negotiation, just blocking and allowing certain ports
to function) with the recommended ports open, and blocking all

others
will

cause these "randomly" assigned ports to be blocked, causing the
applications to fail.

I must be missing the point somewhere, is there any way you could explain
how to determine a packet filter for ports that are assigned

randomly
for

me
in more basic terminology?

Thanks

Bill

That is exactly what you would have to do. A rule could be created
to
accept
that particualr traffic from the lan subnet to any destination

port
with

a
permit
filter action. Specific ipsec rules override a general rule such as
"block
all". --
Steve

Have you tried to create another Ipsec filter accepting ICMP packets?
I
don´t know wich one will take precedence, but you can try.

"Bill Tomlinson" <[email protected]> escreveu na mensagem
These questions are intended for those Microsoft Certified
Professionals
that monitor this 'managed' news group:

How do you configure a W2k server IPSec Packet Filter for your LAN
to
handle
an anti-virus software application where the clients send
"ping-packs"
to
the server on ANY port above 1025 without unblocking ALL the ports
above
1025?

Is it practicle to put an IPSec Packet Filter on a W2k server in
your
LAN,
as described in the TechNet Security section: "Hardening Specific
Server
Roles - ch7," when many applications use "RANDOM" ports via RPC?

Thanks

Bill

 

[Bill Tomlinson]

Cherry,

Thanks again for your response.

I think we have narrowed down the 'security surface' sufficiently with this
'range' of random ports.

I appreciate your help in understanding the capabilities of using IPSec for
Packet Filtering and the implications on applications that rely on randomly
assigned ports.

Bill

 

[Bill Tomlinson]

Eric,

Thanks for your response.

I think we have narrowed down the 'security surface' sufficiently with this
'range' of random ports.

Thank you also for your links to the scripts you wrote to configure the
registry.

Bill

 

[Cherry Qian]

Hi Bill,

Thank you for the posting again. I am glad to hear the information answers
your question. If anything is unclear or if there is anything further we
can help you with from our side, please let me know and we will try our
best to assist you.

It was my pleasure working with you. Thank you for your cooperation and
thank you for choosing Microsoft.

Sincerely,

Cherry Qian
MCSE2000, MCSA2000, MCDBA2000
Microsoft Partner Online Support


Get Secure! - www.microsoft.com/security

====================================================
When responding to posts, please Reply to Group via your newsreader so
that others may learn and benefit from your issue.
====================================================
This posting is provided AS IS with no warranties, and confers no rights.