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

20030902: allowing ports for ldm through a firewall (cont.)



------- Forwarded Message

>To: Jerrold Robaidek <address@hidden>
>cc: Unidata Support <address@hidden>,
>cc: Pete Pokrandt <address@hidden>,
>cc: Datacenter Staff <address@hidden>,
>cc: address@hidden,
>cc: address@hidden
>From: Scott Nolin <address@hidden>
>Subject: Re: 20030902: allowing ports for ldm through a firewall.
>Organization: UCAR/Unidata
>Keywords: 200309022129.h82LTOLd028503


>>We started losing a lot of data,
>>    
>>
>
>A _lot_ of data, not _all_?
>  
>
>>------------------
>>    
>>
>
>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?
>

I can't say for sure about anything else to f5, as I'm not sure what 
services are available, but in general other hosts and services behave 
as expected.

My best guess is that maybe we have a timeout problem?  We have it left 
to the default of 30 minutes.  If sessions take longer - then this issue 
of getting some of the data ok, and then none would make sense.  The 
session information is dropped, so what should be a continuation of the 
inital tcp connection now looks like a new session to our firewall and 
is dropped by the deny rule.

I've added logging to the original ldm policy and the 'catchall' for 
f5.  So we should be able to compare those two - if a session is 
accepted by the first, and then later is picked up as what looks like a 
new one by the second, and timestamps are half an hour or so - well 
that's the problem.

I just need to know next time we get data from f5 so I'll have something 
to look at.

Scott


>From address@hidden Tue Sep  2 15:25:31 2003

All,

SSH will not currently work to f5 from any ssec machines, since it's
tcp-wrapper protected.

I've added dcarchive.ssec.wisc.edu to my ssh allow'd list to try
that.

Pete

In a previous message to me, you wrote: 

 >
 >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" duratio
  >n=
 >> 0 
 >>policy_id=1 service=tcp/port:56751 proto=6 src zone=V1-Untrust dst zone=V1-T
  >ru
 >> 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/networkSecur
  >ityAndSetup.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
 >**************************************************************************** 
  ><
 >Unidata User Support                                    UCAR Unidata Program 
  ><
 >(303)497-8643                                                  P.O. Box 3000 
  ><
 >address@hidden                                   Boulder, CO 80307 
  ><
 >---------------------------------------------------------------------------- 
  ><
 >Unidata WWW Service              http://my.unidata.ucar.edu/content/support  
  ><
 >**************************************************************************** 
  ><


--
+>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<+
^ Pete Pokrandt                    V 1447  AOSS Bldg  1225 W Dayton St^
^ Systems Programmer               V Madison,         WI     53706    ^
^                                  V      address@hidden       ^
^ Dept of Atmos & Oceanic Sciences V (608) 262-3086 (Phone/voicemail) ^
^ University of Wisconsin-Madison  V       262-0166 (Fax)             ^
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<+>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+

------- End of Forwarded Message