[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20030902: allowing ports for ldm through a firewall.

>From: Jerrold Robaidek <address@hidden>
>Organization: SSEC
>Keywords: 200309021841.h82IflLd018009 LDM port 388 firewall

Jerry, Scott, and Tom,

Jerry asked:

>Our IT group recently implemented a firewall here at SSEC.  However
>while trying to pull the CONDUIT Feed data from f5.aos.wisc.edu, we ran
>into some problems.

>We started losing a lot of data,

A _lot_ of data, not _all_?

>and we began
>seeing the following errors in our firewall log.
>
>-----------------
>Sep  2 10:32:33 screen.ssec.wisc.edu screen: NetScreen device_id=screen 
>system-notification-00257(traffic): start_time="2003-09-02 10:32:33" duration=
> 0 
>policy_id=1 service=tcp/port:56751 proto=6 src zone=V1-Untrust dst zone=V1-Tru
> st 
>action=Deny sent=0 rcvd=0 src=144.92.131.244 dst=128.104.110.92 src_port=388 d
> st_port=56751
>------------------

The above behavior is as if the SSEC firewall is not picking up the
port number for the other half of the TCP connection in which
dcarchive.ssec is attempting to establish to port 388 on f5.aos.
A TCP connection is bidirectional with the initiating system specifying
the inbound port number to use.  Such behavior should break everything!

Do ssh and/or telnet on dcarchive to f5 work at all?

>The "help" for ldm says that we only need to allow port 388?

The upstream LDM will always receive requests on port 388.  The
firewall should pick this up and cache the information in a state table
so that it will allow packets destined for the downstream port to
pass.  The port to which data is being sent is set by the downstream
TCP layer; it can be any port number above 32000.

>see: 
>http://my.unidata.ucar.edu/content/software/ldm/ldm-6.0.10/networkSecurityAndSetup.html

>Where it says:
>
>"Access Control and Access to Port 388
>
>When the LDM was designed it was decided that it would perform its own
>access control.  This is implemented in the form of allow lines in the
>configuration file ldmd.conf. In that file allow lines specify hosts
>that may connect to the localhost to receive data.  Subnets may be used
>as host names. The LDM will deny a connection from any host that is not
>allowed to connect.
>
>Use of the LDM requires that any host listed in its access control list
>be allowed a TCP connection to port 388 on the localhost. If the
>localhost is behind a firewall, the firewall must allow access to port
>388. "
>
>Is there any information how to handle the problem we are seeing?

This is hard to answer since it seems like your firewall is broken.

>We have temprorarily remedied the problem, by allowing all ports on out
>machine access from f5.aos.wisc.edu, but I was wondering if there are
>some ports need to be left open (other than 388 which is already open.)

This is not the way to fix your problem.  The answer to the question
about whether ssh and/or telnet from dcarchvie to f5 works will help
us to further understand your situation.

>Thanks!

No worries.

>From address@hidden Tue Sep  2 13:04:32 2003

>Looking a little closer - I see the source port on f5.aos is 388, the 
>expected LDM *destination* port, according to our currently written rule.

The port on the upstream LDM (f5.aos) is 388.  The port on the
downstream machine (dcarchive.ssec) is arbitrary and is selected by the
TCP layer when the downstream LDM establishes the connection.

Perhaps the confusion is centered around who is initiating the
connection.  The downstream LDM initiates the connection by connecting
to port 388 on the upstream machine and then requesting data.

>Basically for us it now says:

>Allow any non-ssec src port to connect to ssec destination port 388.

>Traffic is not blocked on outbound sessions.  However if the server you 
>are contacting then establishes a separate inbound session - then maybe 
>that's the problem.

The downstream LDM establishes the connection by issuing a request to
the upstream LDM. The upstream LDM uses the port number that the
downstream TCP layer selected when the connection was initiated to send
data back.

>Scott Nolin

Steve Emmerson
Tom Yoksas
Mike Schmidt