Attention Firewalls Group:
Original question:
>As one part of our security plan, we have implemented a firewall
>between the Internet (External network) and the campus networks.
>The campus networks include a DMZ zone (mail servers, web
>servers, etc.) and an Internal network (campus-only servers (Linux)
>and file servers (NetWare 5), Intranet web servers, etc.).
>We have a proposal up for discussion. I would like opinions on the
>security implications.
>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?
I compiled the responses I received to develop a list of discussion points
when our team got together to decide/discuss the issue. We did not
decide the issue on Tuesday. We will be continuing the discussion
which is the objective I wanted to accomplish. I wanted us to make an
informed decision aware of what risks we would be placing on our
information resources.
Thank you everyone for your input. I appreciate it. As promised, I am
posting our list of discussion points.
Discussion points:
We have followed the industry standards when we designed our
network. We have designed our network to put hosts with similar levels
of risk on networks together. This way we can determine the level of
security to provide per network. That is, we do not provide the same
level of host security on a "trusted" network that we do on an
"untrusted" network. Why are we moving away from this approach?
By configuring the firewall to allow access from the Internet to the
internal network, there will be a connection from the outside all the way
in. The other internal hosts are not protected. If anyone should manage
to compromise the internal Unix host, our entire internal network is
compromised. Once compromised (why wouldn't it be compromised in
our current environment?), the host will act as a jumping-off point for
any intruders to compromise our entire network. By providing the
external connection, the internal network can no longer considered
"trusted." We would need to review security on all internal hosts.
Assessment of request: Can the services the implemented requests
provide be duplicated by dropping a box in the DMZ? Does the vendor
"require" or just "strongly recommend" telnet capabilities for our
support contract. What are other customers doing? How have they
addressed the security issues? How have we assessed this request?
How have we addressed the security issues raised by this request?
Have we looked at other ways to meet this request other than going
through a hole in the firewall?
Providing external access to the inside of our firewall will never be
entirely safe. Has anyone done a risk analysis to determine if the risks
(total compromise of our internal network resources) outweigh the
benefits? We need to assess the information risk associated with this
change, then implement the "right" level of security for these conditions.
Assess vulnerabilities. Protect critical information systems.
Security was one of the issues evaluated when designing our IP address
space. An unpublished, unroutable IP address offers a degree of
protection for our internal networks from the Internet. The fact that we
are using NAT (translate the private IP to a public one) does not really
affect the security concerns at all. A translation works just as well for
the "bad guys" as for the authorized users.
Having a modem connected to the host raises additional security
concerns.
Not only is our internal network compromised, but now the
intruders can use the host as a convenient jumping off point for
outbound attacks. They could go anywhere in the world (if
phone calls are not restricted locally) with a telephone line and a
modem. This is a favorite method of attackers since it is difficult
to trace from the packet network to the PSTN (phone) and back.
What about telephone charges? How much of a bill can be run
up before we notice something wrong?
What about potential lawsuits? Consider what our exposure is
if some other site is attacked from this host via the dial-out
capability.
Telnet and FTP issues:
Telnet and FTP use clear text passwords. Allowing inbound Telnet
and FTP means logins and passwords are sent in the clear and can
be easily snooped. Crackers will find them (why wouldn't they?)
If Telnet will be a full shell, then they can do anything to the rest of
our network that any other user on the host can do. Many hosts
have root vulnerabilities that are only accessible once normal access
to the host has been obtained.
An FTP control connection can be used to map internal network
devices. How will we prevent this?
With inbound FTP, people could drop off cracked games and
programs for others to fetch. How will we prevent this?
Implementing SSH for Telnet connections: For which hosts? All
internal hosts?
Implementing SSH enable FTP for FTP connections: For which
hosts? All internal hosts?
Put a FTP server in front of firewall, or better yet on a DMZ zone.
Use strong authentication (like SecureID or s/Key) at either the login
prompt of the host system itself, or preferably at the firewall for
inbound connections.
Don't reuse passwords. (i.e., Consider a one-time password system
like OPIE or S/key. Or a two-factor system like a smartcard.)
How would we prevent a "man-in-the-middle" from observing and
spoofing sequence numbers to take over a session?
With authenticating connections: the individual packets sent would
not be authenticated, so a telnet or FTP control session could still
be hijacked by someone. How will we prevent this?
Perimieter authentication at the firewall.
Use IPSec to authenticate every packet.
How would we restrict inbound connections to prevent flood-type
attacks (i.e., SYN or ACK floods) to the host, or even to the entire
internal network (i.e., SNORK or FRAGGLE)?
Use a proxy or flood-protection feature in firewall, coupled w/
inbound perimeter authentication.
Make sure floods stop at the firewall, when authentication fails.
Encryption: Raptor VPN solution. ({ HYPERLINK http://www.firetower.com
}www.firetower.com) Require that all
endpoints connecting to the machine use a VPN tunnel that terminates at
the firewall. The VPN should at least authenticate every packet, as well
as the session, if not provide encryption for confidentiality as well.
What do our auditors say about this? Security issues? Confidentiality
issues? Do they have any requirements or recommendations?
------------------------------
Laura Usakowski, Network Administrator
Aquinas College, Information Technology & Services
1607 Robinson RD SE, Grand Rapids MI 49506 USA
http://www.aquinas.edu, 616-459-8281 x3729
[EMAIL PROTECTED]
Personal e-mail: [EMAIL PROTECTED]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
