SciCOs “security workshop”

George Ross 1.5/June 23, 1999 1. Introductory waffle

2. External network precautions: wrappers, filters, firewalls, ...

3. Specific services: ssh & telnet, web, mail, ...

4. Internal issues: trusting hosts, self-managed machines & root access, protocols, password practice, ...

5. The way forward

\overline{Threats 2}

“Know your enemy”...

Internal: your own local users may want to get at information or resources that they’re really not supposed to.

External: there are lots of people out there who apparently think it’s fun to break into other people’s machines

In between: sites which share users but not system management.

Of course, not all sites have the same exposure or requirements.

Meta-problems:

• Do your users understand the problem? Do they care?

• Will they kick up a fuss? Will they accept what you give them?

• Is it more acceptable to change things gradually? What if something else is being changed anyway?

• Can you get it agreed in black and white??

External precautions in general, and particular:

1. Host-based precautions — me

2. “Real firewalls” — Rob

3. What the core can offer — Sam

4. Discussion?

5. ssh and telnet — me and Craig

6. Mail — Ross

7. Discussion

\overline{Nasties 5}

Nasty things that people out there might try to exploit include but are certainly not limited to:

• Buffer overflows

• Unquoted shell-script variables

• Address spoofing

• BackOrifice et al

• Smurfs and fraggles

• SNMP

• Protocol-stack bugs

• ...

dns.dcs.ed.ac.uk and dns2.dcs are probed

several times every day. The entire dcs.ed address space is scanned three or four times a month on average.

General advice: make sure you don’t run anything that isn’t needed. If it’s not there it can’t be exploited.

What is “buffer overrun”?

Input (from a user or a network client) overruns a program’s internal buffer, writing over following variables or saved registers.

Why is it a problem?

Because one of those scribbled-over things could be a saved return-address. If you overwrite that with the “right” value you can make program execute arbitrary code of your own!

Seems unlikely! Real-life examples?

Plenty from the BUGTRAQ list!

– Command-line parameters

– Environment variables

– Any kind of network protocol

– setuid programs can give a root shell

– Network daemon overflows (MTAs, POP and IMAP servers, web servers, FTP servers, ...) can give a shell to remote exploiters.

Why are unquoted shell-script variables a problem?

Because when they’re substituted in they can introduce shell meta-characters, and hence make the script execute arbitrary commands.

What’s vulnerable?

Any script that acts on user input:

– cgi-bin scripts can be persuaded to run arbitrary commands as the daemon (or the user).

– metamail would silently execute commands contained in mail and news messages.

– (Not just shell scripts — PostScript, Adobe PDF, ActiveX, embedded editor commands and word-processor macros, ...)

\overline{Spoofing 8}

What’s address spoofing?

Someone out there creates packets with someone else’s address in the “source” field. As far as the network is concerned, that’s where they came from.

Why is it a problem?

What if the purported source address really belongs to a machine that you trust...?

But surely the replies won’t get back to the sender...?

That probably doesn’t matter. The damage may be done by the initial packet. And it’s often possible to predict what the the responses in a longer exchange would be well enough that it’s not actually necessary to see them!

How can this be prevented?

Don’t trust any machines outside your own wires.

Address filtering at your border routers.

What’s a smurf? What’s a fraggle?

A smurf is a proxy denial-of-service attack. Send an ICMP echo request with a spoofed source address to someone’s broadcast address. Some or all of the machines which receive the broadcast may respond to the spoofed source, swamping it or its network connection.

What’s a fraggle?

The same thing, only using one of the “standard” services (echo, chargen, ...).

How can it be prevented?

You can’t do anything about people attacking you unless you’re prepared to filter out some possibly-legitimate traffic too.

You can avoid being the proxy by not responding to broadcast echo requests and by turning off unwanted “standard” services.

– On Solaris use ndd to set

  ip respond to echo broadcast to zero.

– Filter the requests out before they reach your machines.

– Highly system-dependent.

Remember to block all-zeros as well as all-ones broadcasts. Some machines (Macs?) respond to both.

TCP wrappers — commonly used tool. Interpose between inetd and specific service daemons. Configure through /etc/hosts.allow and

/etc/hosts.deny files.

Advantages:

• Called once only when a service starts up.

• Require minimal changes to existing configuration and none to code.

• Very flexible rules.

• Easy to call user-level code, and even to run something completely different in some cases.

• Wrapper library can be linked in to non-inetd daemons.

Disadvantages:

• Only things started from inetd can be protected (i.e. not mountd, NFS, portmapper, YP, ...).

• Must have a completely separate service daemon instance for each host handled.

Alternative: filter packets in the protocol stack. A couple of widely-used options: ipfilter for Solaris, SunOS, *BSD and IRIX; and ipchains for Linux 2.2 kernels.

Advantages:

• Everything can be protected, including traffic for the machine and traffic it routes for others.

• No changes to existing configurations.

• NAT and some redirection for those who need it.

Disadvantages:

• Adds an extra overhead for all packets.

• Kernel-space code.

• Can be quite complicated to set up adequately.

Wrappers vs. filters:

• Wrappers can protect only some of the services run on a machine; filtering can protect all services on the machine itself and anything it’s a router for.

• Wrapper overhead is present only when a service starts up; filtering overhead is present for all packets.

• Wrappers can invoke user-space actions; filters generally can’t.

• Wrappers are much easier to set up.

IPfilter vs. ipchains:

• Different non-overlapping platforms.

• Both have pretty comprehensive filtering.

• Essentially the same functionality, except:

– ipfilter has slightly more powerful TCP flags rules.

– ipchains won’t RST a TCP connection because it’s the Wrong Thing To Do.

– ipfilter has “keep state” mechanism; ipchains relies on other user-space packages.

• Both send logs to syslog for archive and further analysis.

• We’ve been using ipfilter in DCS since June 1997 on Solaris 2.4, 2.5.1 and 2.6. We run it on all our routers and anything which has an interface on an external wire. We currently have 86 rules in our default filter set.

• We’ve not noticed a performance hit for 10Mb ether. There does seem to be a noticeable but unquantified effect with 100Mb ether.

• Sun’s hotline can be unhelpful if you run anything non-standard. OTOH we can’t really run without filtering.

• Code went through an unstable patch, but seems solid again now.

• We’re going to install a dedicated PC filtering router. We’ve not yet decided whether to use Solaris x86 and ipfilter, Linux and ipchains, or something completely different.

Some external services are of course required. Remote terminal access is one of these.

rsh and rlogin shouldn’t be allowed. Trust can’t be extended to remote clients (spoofing), so there’s no advantage over telnet. The way the protocol works makes them hard to filter.

telnet is ubiquitous, but everything (including passwords) is transmitted in the clear and so is snoopable.

Two possibilties:

– encrypt the link

– one-time passwords

\overline{ssh 17}

ssh gives:

• Secure encrypted remote terminal access

• Forwarding of X traffic with one-time cookies • Forwarding of other arbitrary TCP ports —

rsync, POP, ...

• Choice of authentication mechanisms: password, public-key

Problems:

• Key distribution

• US politics

• Usual licence and patent restrictions

• Not everywhere has it installed

Nevertheless it’s DCS’s preferred remote-access mechanism for both internal and external traffic.

Internal issues include:

• Snooping

• Trust; NFS in particular; Kerberos

• Self-managed machines, root access

• Problem protocols: routing, YP

• SKIP?? IPsec??

• Passwords

• Encryption

• ...