Is there a good (easy) way to find out what port above 1023 are
actually being used?

on my pix firewall I have a statment such as

access-list storein permit tcp host 1.1.1.1 host 10.1.1.1 gt 1023

my security auditors tell me I have to list the actual ports.

bboett

On 2006-10-02 03:37, bboett@hickorytech.net wrote:
> Is there a good (easy) way to find out what port above 1023 are
> actually being used?

Can You be more precise? What do You mean by "being used"?


-- 
Michał Iwaszko
(Rot13 my address)

Well you could
access-list storein permit tcp host YOURIP  host 10.1.1.1 ANY

All you need to do is a run a port scanner on host YOURIP to 10.1.1.1 and 
see what pops up.


<bboett@hickorytech.net> wrote in message 
news:1159753029.151454.204740@h48g2000cwc.googlegroups.com...
> Is there a good (easy) way to find out what port above 1023 are
> actually being used?
>
> on my pix firewall I have a statment such as
>
> access-list storein permit tcp host 1.1.1.1 host 10.1.1.1 gt 1023
>
> my security auditors tell me I have to list the actual ports.
>
> bboett
> 

In article <1159753029.151454.204740@h48g2000cwc.googlegroups.com>,
 <bboett@hickorytech.net> wrote:
>Is there a good (easy) way to find out what port above 1023 are
>actually being used?

>on my pix firewall I have a statment such as

>access-list storein permit tcp host 1.1.1.1 host 10.1.1.1 gt 1023

>my security auditors tell me I have to list the actual ports.

Is this Microsoft Windows systems involved? If so, then gt 1023 is
as often as specific as you are going to be able to get. Windows
-tends- to allocate the lowest unused port number from 1024 upwards,
but it can get into the 60000+ range too.

The key to resolving this to the satisifaction of the security
auditors is to note that dynamic port numbers as destinations
do not occur in isolation in normal operations: when they occur,
they occur as a result of a negotiation process that the PIX can
often track and automatically open -just- the particular port.
Particularily for tcp, since "permit tcp" is for opening new
connections (whereas "permit udp" can sometimes be for getting
around too-low timeouts on connections that have been opened from
outside into the PIX, since udp is "stateless".)

You need to track down the process which is allocating the connection
numbers dynamically, and ensuring that the PIX opens the appropriate
ports automatically by way of an appropriate "fixup".

If you have PIX 4, PIX 5, or PIX 6, there are some circumstances
under which the PIX cannot do this properly when using NETBIOS,
Windows NT Authentication, Windows RPC, or plain "Sun RPC".

In particular, if you have Windows Exchange clients on your end,
and the remote end of the link has Windows NT authentication and
Windows Exchange 2000 Server, then you will never get this right,
not unless you have experts running the Exchange systems that can
nail down the ports very very precisely and tell you what they
configured them as. (This is, for example, beyond the capacities
of the five-person full-time Exchange team at my organization;
there is a poster to comp.security.firewalls who goes by Leythos
who -claims- that his company routinely does this.) In the
scenario I describe, remote NT authentication and remove Exchange 2000
server, unless you find an expert lock-downer, you *will* encounter
problems unless you static NAT all your internal addresses individually
to public IP addresses and you permit all tcp ports > 1023 in both
directions between your desktops and the remote servers.

In -theory-, going for Exchange 2003 and LDAP solves those problems.
Well, I shouldn't say "in theory": I should say that "The Exchange
team assured me that [...]". In practice when we switched over to
Exchange 2003, we still had inexplicables :(