I am contemplating this architecture:
INTERNET | CISCO PIX FW ------- DMZ FTP SERVER | | ------------------------------ | | | | NT CLIENT NETAPP
The DMZ FTP Server would have an a UDP NFS mount THROUGH THE FIREWALL into the internal network. Inbound guest FTP would be directed there via the Netapp NFS mount. The NT box would have a covering SMB mount over the same filesystem. After a guest client delivers data to the FTP server it would be moved from the in to the out directory where it would be picked up by the internal NT box.
Intent: Maintain an Internet-visible FTP server in the DMZ and yet provide easy access for inside servers.
Question: 1. Does this make sense? Does anyopne use filers this way or in related ways? 2. Are there known exploits against filers doing UDP NFS as I describe above. Could the Netapp be attacked if the FTP box were hacked? 3. Related question: Can admin access to the filer be to ONLY the console port or ONLY a single interface?
Thanks - Jim Klun
* James A. Klun Sterling Commerce 4600 Lakehurst Ct. Dublin, Oh 43016 * * jklun@stercomm.com 614-793-7183 voice 614-793-7092 fax * * ---- "very like a whale" ---- * * ---- Hamlet, Act 2, Scene 2 ---- *
Jim:
Why not just "push" your content out to the DMZ FTP, rather than having live connections through your firewall?
-marc
On Sun, 2 Apr 2000, Jim Klun 7183 wrote:
I am contemplating this architecture:
INTERNET | CISCO PIX FW ------- DMZ FTP SERVER | | ------------------------------ | | | | NT CLIENT NETAPPThe DMZ FTP Server would have an a UDP NFS mount THROUGH THE FIREWALL into the internal network. Inbound guest FTP would be directed there via the Netapp NFS mount. The NT box would have a covering SMB mount over the same filesystem. After a guest client delivers data to the FTP server it would be moved from the in to the out directory where it would be picked up by the internal NT box.
Intent: Maintain an Internet-visible FTP server in the DMZ and yet provide easy access for inside servers.
Question: 1. Does this make sense? Does anyopne use filers this way or in related ways? 2. Are there known exploits against filers doing UDP NFS as I describe above. Could the Netapp be attacked if the FTP box were hacked? 3. Related question: Can admin access to the filer be to ONLY the console port or ONLY a single interface?
Thanks - Jim Klun
- James A. Klun Sterling Commerce 4600 Lakehurst Ct. Dublin, Oh 43016 *
- jklun@stercomm.com 614-793-7183 voice 614-793-7092 fax *
---- "very like a whale" ---- *---- Hamlet, Act 2, Scene 2 ---- *
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Marc Nicholas Hippocampus OSD, Inc. "Industrial Strength Internet Solutions" 125 John Street, Suite 100, Toronto, ON M5V 2E2, CANADA 416.979.9000 x 11 fax 416.979.8223 http://www.hippocampus.net =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Host your business website for only $29/month! 1.877.GO.HIPPO
Pushing from the NT box to the FTP bastion host is what we do for outbound ( ftp put ).
I want to severely restrict inbound traffic from bastion FTP box. I was having the NT box poll the bastion FTP server and then simply pull data in with a get - but there are synchronization issues that I am worried about ( user doing a put while internal box is doing a get. )
There are other solutions that might work - but I thought the Netapp might provide a simple solution - assuming it would not be potential break-in point.
* James A. Klun Sterling Commerce 4600 Lakehurst Ct. Dublin, Oh 43016 * * jklun@stercomm.com 614-793-7183 voice 614-793-7092 fax * * ---- "very like a whale" ---- * * ---- Hamlet, Act 2, Scene 2 ---- *
On Sun, 2 Apr 2000, Marc Nicholas wrote:
Jim:
Why not just "push" your content out to the DMZ FTP, rather than having live connections through your firewall?
-marc
On Sun, 2 Apr 2000, Jim Klun 7183 wrote:
I am contemplating this architecture:
INTERNET | CISCO PIX FW ------- DMZ FTP SERVER | | ------------------------------ | | | | NT CLIENT NETAPPThe DMZ FTP Server would have an a UDP NFS mount THROUGH THE FIREWALL into the internal network. Inbound guest FTP would be directed there via the Netapp NFS mount. The NT box would have a covering SMB mount over the same filesystem. After a guest client delivers data to the FTP server it would be moved from the in to the out directory where it would be picked up by the internal NT box.
Intent: Maintain an Internet-visible FTP server in the DMZ and yet provide easy access for inside servers.
Question: 1. Does this make sense? Does anyopne use filers this way or in related ways? 2. Are there known exploits against filers doing UDP NFS as I describe above. Could the Netapp be attacked if the FTP box were hacked? 3. Related question: Can admin access to the filer be to ONLY the console port or ONLY a single interface?
Thanks - Jim Klun
- James A. Klun Sterling Commerce 4600 Lakehurst Ct. Dublin, Oh 43016 *
- jklun@stercomm.com 614-793-7183 voice 614-793-7092 fax *
---- "very like a whale" ---- *---- Hamlet, Act 2, Scene 2 ---- *-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Marc Nicholas Hippocampus OSD, Inc. "Industrial Strength Internet Solutions" 125 John Street, Suite 100, Toronto, ON M5V 2E2, CANADA 416.979.9000 x 11 fax 416.979.8223 http://www.hippocampus.net =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Host your business website for only $29/month! 1.877.GO.HIPPO
A number of years ago, I did something similar, except that I had 2nd interfaces on both my filer and the "DMZ" host. I simply connected them back to back and made the obvious access restrictions so the DMZ host could only mount what it was supposed to, couldn't telnet to the filer, ...
There were 2 main advantages for doing it this way in this client's case.
1. Exclusive access to the filer's interface made data transfers much faster.
2. Changes to their firewalls and network configurations would not change how the DMZ host could access the filer.
Eventually they simply put the filer interface on the DMZ network with appropriate changes to their firewalls to keep outside hosts from talking to the filer(s) directly. This provided them additional scalability. I still think they should have just gone from doing a back-to-back connection to putting the 2nd interfaces (filer and DMZ) onto the same switch/hub and scaled that way.
~mitch
/* Jim Klun [jklun@stercomm.com] writes: */
I am contemplating this architecture:
INTERNET | CISCO PIX FW ------- DMZ FTP SERVER | | ------------------------------ | | | | NT CLIENT NETAPPThe DMZ FTP Server would have an a UDP NFS mount THROUGH THE FIREWALL into [...]
Thanks for the info.
What type of internal "trusted network" clients were there? NT, Unix?
How did you cleanly get the internal clients to pick up inbound FTP files?
Are there legitimate concerns about an NFS based attack on the filer itself?
* James A. Klun Sterling Commerce 4600 Lakehurst Ct. Dublin, Oh 43016 * * jklun@stercomm.com 614-793-7183 voice 614-793-7092 fax * * ---- "very like a whale" ---- * * ---- Hamlet, Act 2, Scene 2 ---- *
/* Jim Klun [jklun@stercomm.com] writes: */
What type of internal "trusted network" clients were there? NT, Unix?
It was strictly UNIX, but I think this scheme would have benefited CIFS clients even more...
How did you cleanly get the internal clients to pick up inbound FTP files?
The internal clients talked to the filer on the "internal" interface.
Are there legitimate concerns about an NFS based attack on the filer itself?
Of course (and more), that is why I advocated the "back-door" network. I didn't want ANY packets from foreign hosts to touch the filer interfaces. Perhaps a drawing would help...
+---------+ 'da____|Firewall |_____ INTERNAL---------/clients/ NET | | NETWORK +----+----+ | | |e1 DMZ ------- |ep0 |filer| -------- ------- | FTP |ep1 |e2 | host |----------+ --------
ep0 and ep1 are ethernet interfaces on the FTP host e1 and e2 are ethernet interfaces on teh filer
ep1 was connected to e2 with a simple crossover cable.
Internal clients talked to the filer over e1 as expected, and the public FTP host used it's ep1 to talk to the filer's e2 interface. The packets never had to go through the firewall, and the filer was simply configured to allow only certain mount request from the FTP host. Routing on the FTP host was obviously turned off, and was "secured" (meaning only running what it required). Access was available only from the console or RSA authenticated SSH connections.
Question: 1. Does this make sense?
The goal? Yes.
Does anyopne use filers this way or in related ways?
Yes, lots of people.
2. Are there known exploits against filers doing UDP NFS as I describe above.
None that I know of, but there are probably some that are denial of service attacks or the like. However, I doubt any data could be compromised or the internal network.
Could the Netapp be attacked if the FTP box were hacked?
Sure, if they can get past the password or spoof root access from the FTP box before your monitoring can detect it. The latter is quite unlikely... you DO have monitoring set up in this scheme, right?
3. Related question: Can admin access to the filer be to ONLY the console port or ONLY a single interface?
No, although there are options to restrict what hosts can rsh/telnet in.
Personally, I favor a model similar to the one Might Wright mentioned, with the filer serving as a "firewall" of it's own, with two interfaces, one on the inside and one to the FTP host. The main security issue is making sure if they get into the filer, they can't rsh or telnet back out somehow. You'll have to sacrifice the data integrity of the filer, but that's a small price to pay.
Hmm... I wonder if it's possible to use the console to write Java code that the filer would then execute...
Netapp really should hire one of those ex-hacker security companies to take a whack at the filer sometime.
Bruce
On Sun, 2 Apr 2000, Jim Klun 7183 wrote:
Question: 1. Does this make sense?
You will have to allow RPC as well as NFS traffic in through the internal interface on the firewall. Since the FTP server is on the DMZ, you should be able to protect it fairly well from external attacks. Is the PIX capable of doing stateful packet inspection of RPC and NFS traffic? If so, that's another avenue of defense.
2. Are there known exploits against filers doing UDP NFS as I describe above. Could the Netapp be attacked if the FTP box were hacked?
It is conceivable that someone could gain privileged access to your FTP server, spoof a root filesystem mount request to the Netapp and change the contents of the filer's /etc directory. If you do not otherwise block inbound access from the DMZ, that could eventually lead to console access on the filer. From there, the attacker can sniff your internal network traffic, assuming they know about the pktt command. Granted, the chances of this hypothetical situation actually happening are pretty darned slim, if you take the necessary precautions and vigilantly maintain your DMZ security.
3. Related question: Can admin access to the filer be to ONLY the console port or ONLY a single interface?
Only with what you can do with /etc/hosts.equiv (i.e., only put in allowed IP's that will appear on one of the interfaces, or not put in any at all and turn off "options telnet.enable").
-
Brian Tao -
Bruce Sterling Woodcock -
Jim Klun 7183 -
Marc Nicholas -
Mitch Wright -
mitch＠netline.com