[comp.protocols.tcp-ip] Reducing the risks when connecting to an Internet

damian@SRLVX0.SRL.FORD.COM ("Jerry Damian") (11/26/90)

In article <3768@stl.stc.co.uk> neil@stc.co.uk is looking for a way to
filter on specific IP services such as TELNET, SMTP, FTP, etc. 

You can use Cisco routers to do this quite effectively. You can use their
extended access controls to filter on source and destination address as
well as port number. However, be aware that the Cisco ability to process
packets without dropping any is proportional to the size of the access
list. You can minimize the size of the lists by permitting/denying packets
by subnet rather than by IP address. Better to put this burden on a router
than a host that is probably used for something else...

Jerry Damian
Ford Motor Co.
damian@srlvx0.srl.ford.com

ji@close.columbia.edu (John Ioannidis) (11/26/90)

In article <9011260544.AA01255@ucbvax.Berkeley.EDU> damian@SRLVX0.SRL.FORD.COM ("Jerry Damian") writes:
>In article <3768@stl.stc.co.uk> neil@stc.co.uk is looking for a way to
>filter on specific IP services such as TELNET, SMTP, FTP, etc. 
>
>You can use Cisco routers to do this quite effectively. You can use their
>extended access controls to filter on source and destination address as
>well as port number. However, be aware that the Cisco ability to process

And remember that this should only be a temporary measure, while you
plug holes in your individual hosts. Do not get lulled into a false
sense of security. Protections and security should be enforced at the
host level. If you suspect that your networking daemons are buggy, get
your vendors (or your systems programmer) to fix them. 

/ji

PS: Hi Phil!

In-Real-Life: John "Heldenprogrammer" Ioannidis
E-Mail-To: ji@cs.columbia.edu
V-Mail-To: +1 212 854 8120
P-Mail-To: 450 Computer Science \n Columbia University \n New York, NY 10027

pmoore@hemel.bull.co.uk (Paul Moore) (11/26/90)

ji@close.columbia.edu (John Ioannidis) writes:
>And remember that this should only be a temporary measure, while you
>plug holes in your individual hosts. Do not get lulled into a false
>sense of security. Protections and security should be enforced at the
>host level. If you suspect that your networking daemons are buggy, get
>your vendors (or your systems programmer) to fix them. 

Gosh, I am glad to see somebody making that point, ("security is a host
problem not a net problem"). There is an almost Pavlovian response to
networks.

damian@SRLVX0.SRL.FORD.COM ("Jerry Damian") (11/27/90)

Referencing <1990Nov26.151017.2023@hemel.bull.co.uk>. I agree completely
with all comments regarding host based security rather than network
imposed security. However, that is often not possible due to the internal
politics of an enterprise network and who administers its hosts. The majority
of hosts on my internet are administered by engineers NOT network managers
or systems programmers. The reality of my situation is that I cannot dictate
how individual hosts are to be configured because I do not own them. Yes,
this does lead to MANY problems... Limiting the visibility of an internet via
router/bridge filtering will buy time until you can get the job done right.

philip@beeblebrox.dle.dg.com (Philip Gladstone) (11/27/90)

In article <1990Nov26.151017.2023@hemel.bull.co.uk> pmoore@hemel.bull.co.uk (Paul Moore) writes:

pmoore> Gosh, I am glad to see somebody making that point, ("security is a host
pmoore> problem not a net problem").

Security is both a network and a host problem. The more defences you
have, the better protected you are. 

Compare with a military base (a network). Even though they think that
the safe (the host) holding the codebooks is secure, they still don't
let you anywhere near it!

Similarly, even though the Bank of England beleives that their vaults
are secure, they still don't hand out the plans.

The other key advantage of network security is that (if the network is
organised correctly), all traffic passes through a small number of
points. These points can be carefully controlled. Again: I would
prefer that the Bank of England control the people entering the Bank,
rather than relying solely on the security of the vault.



--
Philip Gladstone         Dev Lab Europe, Data General, Cambridge, UK

    Listen three eyes, don't you try and outweird me, I get
    stranger things that you free with my breakfast cereal.

pcg@cs.aber.ac.uk (Piercarlo Grandi) (12/02/90)

On 26 Nov 90 17:32:00 GMT, damian@SRLVX0.SRL.FORD.COM ("Jerry Damian") said:

damian> Referencing <1990Nov26.151017.2023@hemel.bull.co.uk>. I agree
damian> completely with all comments regarding host based security
damian> rather than network imposed security. However, that is often not
damian> possible due to the internal politics of an enterprise network
damian> and who administers its hosts.

Well, if you are given goals and responsibility for them and not the
ability to reach them, you are in a grave situation. You may be able to
come up with a temporary patch up job, that will make people think that
you have solved the problem, until disaster strikes, and *you* are the
scapegoat.

damian> The majority of hosts on my internet are administered by
damian> engineers NOT network managers or systems programmers. The
damian> reality of my situation is that I cannot dictate how individual
damian> hosts are to be configured because I do not own them.

This sums up to saying that these machines have ZERO (repeat ZERO)
security. Does it really make a difference whether anybody within the
company or anybody within the Internet can access them? How do you know
that one of these guys does not already have an Internet connection?
This is a deadly serious problem. You cannot take responsibility for the
security of machines you do not own. Monitoring or controlling internet
traffic is just not a viable substitute (monitoring however is an
important aid). I would not bet my job and reputation on it.

damian> Yes, this does lead to MANY problems...  Limiting the visibility
damian> of an internet via router/bridge filtering will buy time until
damian> you can get the job done right.

But as somebody else has said the solution is not to filter packets.  It
is to establish a gateway under administrative control, and allow
internet access only from the gateway machine(s).

Otherwise you (I mean here "you, the generic sysadmin") are going to
have the unsustainable problem of being *responsible* for internet
traffic while you have no control over the security of *neither* of the
machines involved. This is a joke.  The time it buys you is not the time
to build the right solution; it just gives the illusion that the problem
has been solved, and this will mean that the right solution will be no
longer urgent.

Note that I do not advocate you having control over all the machines at
your site -- this would be a nightmare for your site and you (unless you
are one of the many mad and insecure sysadmins with world-domination
plans :->). What I am saying is that you should take responsibility only
for what you can reliably devote your attention to, which usually is
very little, and making your management accept the situation. If they
don't accept the situation and tell you not to cause problems, you are
risking your job and reputation (by all means put into writing your
comments, cover your ass, find another job, ...).

I wish people studied more closely the environment of project Athena (or
Andrew). Only a few core machines are well protected and secured, and
any other is just not trusted. Security, even at minimal levels, is
terribly difficult and expensive, and rarely needed...

Finally, my favourite quote (I don't know whom from): the greatest
security hazard is a false sense of security.
--
Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk