FTPS/Implicit SSL connections filter

Question

BorderManager 3.8 on NetWare 5.1 - I have plenty of successful
ftp-port-pasv-st exceptions that I use, but now I need one for an
FTPS/Implicit SSL connection, which *should* user port 990. But when I
define an exception (creating a new packet type, TCP, All source ports to
990, stateful) I'm able to connect, but I cannot browse folders or transfer
files. For grins I even tried making an exception for ALL TCP ports from my
FTP PC to their server - oddly, that wouldn't allow me to connect at ALL.
Drop filters, and I can get it to work just fine. I would do a TCPIP DEBUG =
0, but when I do that, BorderManager usually crashes now, and last time it
crashed, it would immediately abend on reboot, and it took me 4 hours to
crawl out of this hole.
I just recently got brave enough to make new filters again (it was making
them all disappear every time I made a change for the longest time).
Anyone have any experience with this form of FTP? I've done FTP of course,
SFTP, and other secure FTP transfers, but this is the first vendor who want
FTPS/Implicit SSL, which I understand is not nearly as prevalent as Explicit
SSL.
Thanks,
Bruce

Answer 1

On Feb 26, 3:19 pm, "Bruce Lautenschlager" <[email protected]>
wrote:
> Reference the crashes - NDS came up clean after a few passes - and I still
> had the issues.
>
> I ended up running TCPVIEW on the workstation running WS_FTP Pro, and could
> see that the little ******* was opening up various ports from 1700 up.
> Different with every file. That blows. SFTP works on the same ports every
> time - but apparently this wasn't. Whatever. Maybe someday we'll have a realsecurestandard. Right now I transfer about every way known to man,
> including PGP and VPN. (But WS_FTP can't script PGP, hence I do a lot of
> SFTP and now this FTPS).
>
> I ended up making two non stateful exceptions on all ports from myFTPPC to
> theirFTPserver. Not the best solution....but - here's why I just needed
> something to hold me over for a week or two -
>
> After many years of BorderManager (and NetWare servers in general), I'm
> finally getting to do what they hired me for some years back - migrating to
> complete AD environment, including dual ISA 2006 Enterprise servers to
> replace BorderManager. I already did the NWSAA to HIS conversions. ZFD is
> about to give way to Desktop Authority. By next year, only GroupWise will
> remain (and probably not on NetWare OS), and since I only provide the web
> portion of that, what happens to that is of little concern to me.
>
> I appreciate all the help you've doled out over the years - especially Craig
> (and the very helpful book I finally bought a couple of years ago). No
> Novell bashing here...just going in a different direction.
>
> Thanks for your help,
> Bruce
>
> "Craig Johnson" <[email protected]> wrote in message
>
> news:[email protected]...
>
> > In article <[email protected]>, Bruce
> > Lautenschlager wrote:
> >> I just recently got brave enough to make new filters again (it was making
> >> them all disappear every time I made a change for the longest time).
>
> > Sounds like you have some NDS issues there that should be looked at.
>
> >> Anyone have any experience with this form ofFTP? I've doneFTPof
> >> course,
> >> SFTP, and othersecureFTPtransfers, but this is the first vendor who
> >> want
> >> FTPS/Implicit SSL, which I understand is not nearly as prevalent as
> >> Explicit
> >> SSL.
>
> > It seems to me that there are two flavors ofsecureFTP. One uses SSH,
> > and
> > just tunnelsFTPthrough an SSH connection. This is easy since you only
> > need
> > to allow port 22 through. The other seems to be like what you are seeing,
> > and
> > is using different ports than standardFTP, but still working likeFTPin
> > terms
> > of using more than one port (for control versus data). This second type
> > can be
> > very hard to work with since there is no statefulFTPexception to work
> > with
> > it.
>
> > I would solve the TCP debug issue first, and just grab the filtered ports
> > and
> > add exceptions accordingly. If your exception of all TCP to the target
> >server
> > failed, it may be because you also need one for traffic FROM the target
> >server.
> > (And your interface selections may have been done incorrectly in the
> > exception
> > you tried).
>
> > Craig Johnson
> > Novell Support Connection SysOp
> > *** For a current patch list, tips, handy files and books on
> > BorderManager, go tohttp://www.craigjconsulting.com***
The problem here is that each time you do a directory listing or try
to upload/download a file in FTP protocol you are using a passive
client connection. With each passive connection the server assigns a
port that the client should connect to for initiating the transfer.
Unless you specify a port range to use within the FTP server software,
this is generally a random open port on the server > 1024. Naturally,
this can make configuring your firewall a bit more difficult :( The
solution to this is to configure your server to use a fixed port range
for passive FTP connections e.g. 1200-1300. Then in your firewall you
can configure it to allow inbound connections on these ports. Most
servers support passive port range configuration. see your server
docs for details on how to do this. One such platform-independent
server that supports this is jscape secure ftp server ...
http://www.jscape.com/secureftpserver/
Hope this helps.
Rich