Laura,
Here are my thoughts as to some concerns about your proposed architecture.
1) Allowing unrestricted inbound connections directly to unhardened
machines could allow flood-type attacks (like SYN or ACK floods) to the
machine, or even to your entire network (amplification attacks like SNORK
or FRAGGLE). Possible solution: use a proxy or flood-protection feature in
your firewall, coupled with inbound perimeter authentication (see next).
2) Allowing inbound telnet and ftp means userIDs and passwords are sent in
the clear and can be easily snooped. Possible solution: use strong
authentication (like SecureID or S/KEY) at either the login prompt of the
host system itself, or preferrably at the firewall for inbound connections.
3) Even if the connections are authenticated, the individual packets sent
aren't, so a telnet or FTP control session could be hijacked by a
Man-in-the-middle (MITM). Possible solution: use IPSec to authenticate
every packet.
4) The fact that you're translating the address to a private one doesn't
really affect the security concerns at all. A one-to-one translation works
just as well for the "bad guys" as for everyone else.
5) Once compromised (and it _will_ be compromised, if left unprotected),
the machine will act as a jumping-off point for any intruders to compromise
your entire network. University networks usually act as excellent
repositories for stolen software. You probably won't even notice the
intrusion -- since is to their advantage if you don't. (If you were a big,
juicy corporation, you might get some IP stolen, or just have your public
web site smeared.)
6) Having a modem connected to the machine just makes things worse: not
only can intruders go anywhere on _your_ network, now they can go _anywhere
in the world_ with a telephone line and a modem on the other side. Your
machine now becomes a convenient jumping-off point for outbound attacks --
a favorite of attackers since it's difficult to trace from the packet
network to the PSTN and back. You get the benefit of their telephone bills
and (perhaps) their lawsuits....
Sorry. I get caught up in the moment sometimes.
If you can, require that all endpoints connecting to that machine use a VPN
tunnel that terminates on your firewall. The VPN should at least
authenticate every packet, as well as the session, if not provide
encryption for confidentiality as well.
If that is not feasible, AT LEAST provide perimeter authentication at the
firewall. This will serve as a choke-point and limit possible intrusions to
those who can observe and spoof sequence numbers to act as a MITM -- a much
more limited risk.
Also, make sure floods stop at the firewall, when authentication fails.
Both client-to-LAN VPN and perimeter authentication for telnet and FTP are
provided by several major firewall vendors, including Checkpoint Firewall-1
and the Lucent Managed Firewall.
HTH.
Regards,
-david
At 10:22 AM 4/4/00 -0400, Laura Usakowski wrote:
>Attention Firewalls Group.
>
>Proposal:
>
>The need is to provide access to an internal campus Unix server
>from the Internet. The required access would be telnet and ftp.
>
>This access would be provided through the firewall. We would
>assign an IP address on the external network. Our firewall would
>provide a virtual connection to the internal Unix server (private class
>A) address. The Unix server has a dial-out only modem/phone line
>installed.
>
>What are the _specific_ security concerns with this proposal? Are
>there any risks to other servers on the internal network? Are there
>any recommendations or alternatives on how to implement this
>type of access while minimizing the security risks. Does it matter
>on the firewall vendor we have? Does it matter that we have a
>modem installed in the server?
>
-------------------------
David J. Cavuto, Systems Engineer
Lucent Security Products - http://www.lucent.com/security
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
