This tutorial starts with an overview of Sun's Wide Area Network (SWAN), with an overview of the mostly internal threats faced behind the firewall and why they're not all that different from being outside a firewall in a large operation. We'll discuss what types of problems we face.
We'll use that as a starting point to divide the subject in several
topics. These topics are:
1) Policies Procedures
2) System configuration
3) Tools
4) Logging and Auditing
We'll conclude with examples of how we apply this on SWAN
Sun's wide area network (SWAN) is a network on which 13,000+ Sun employees working on 40,000 network nodes. Although largely behind the firewall, these machines need to be protected from network threats. As part of world wide "Enterprise Network Services", the "Network Security Group" keeps a watchful eye over the security of all systems on SWAN.
While many people may feel that there safe behind the firewall, in reality you're often not. There are a lot more connections to the outside than just the one firewall, we need to control them all.
There are a lot of questions to be asked:
1) Are all your users allowed to access all information?
2) Can you trust all users to abide by the "acceptable use policies"?
3) Should they connect modems outside our control?
4) If there's one security breach, should the entire network fall prey to
the hacker?
5) Are people allowed to connect just everything to the net?
6) What are we allowed to do when following up on an incident report?
And many more.
In this section we'll explain why policies are necessary and what kind of policies you may want to consider.
When you want to secure a network, you'll need to have some form of control. There are many items want to consider for control.
First and foremost, you will want to control all access to your network, such as where dial-ins are and how they are used.
And what OS configuration settings are acceptable and which are not.
What system administrators are allowed to do when responding to an incident. (Is reading private files, email and such permissible and under which circumstances)
When old accounts are removed
Password control (one-time password, reusable passwords and when)
In this part we'll talk about the systems services most under threat and what you can do to stand a better chance.
Sometimes you'll be forced to make a choice: do I want ease of use or do I want security, and do I want the same for all my systems?
Here's the ground rule: "Don't trust what you don't control"
We explain why keeping your software revisions current is important. Maintenance for old releases lags. Security problems in older revisions. This is not limited to OS software but also to free software, wu-ftpd various HTTP daemons, etc. It's even important when using client software, witness the security problems found recently in netscape releases.
And how best to handle systems that cannot be upgraded because they run some "turn-key" or other application that prevents the OS from being upgrade, or because they run on unsupported hardware; just strip the OS.
We'll talk about IP spoofing, the little that can be done about it. You'll need this further down.
These services are open to gross misconfiguration or abuse by users. Why you should consider limiting access to these services.
An important point here is; should I trust things beyond my control? (remote hosts, DNS, etc)
At this point it should also be clear to the audience that IP address based authentication is vulnerable to spoofing.
The trend for the early nineties in hacking is "password snooping". Why reusable passwords over uncontrolled LANs and WANs are bad and what you can do about it.
How one time passwords help you to fight IP spoofing (you don't use IP addresses for authentication) and snooping (a password is used only once).
We explain some of the options, ranging from free S/Key to for-money solutions as secure-id and Enigma DES Gold.
Those solutions are still vulnerable to session hijacking.
An alternative to the r* services and telnetd has been developed which has the easy of use of the r* commands, but much better security through the use of end-to-end encryption and publickey authentication.
For SSH, all you need is two secure endpoints, as you can't hide data from the superuser at either end.
Sun RPC suite of protocols is the most widely used set of protocols for remote procedures such as file access, name services etc.
The protocol supports a number of authentication levels, unfortunately the most widely used one, AUTH_UNIX is easily faked. We'll discuss how you can make those services more secure and what the shortcomings are.
And a peek in the future, how things will improve.
A bird's eye view of Kerberos, its advantages and its drawbacks.
Dangers lurking with anonymous ftp and the web servers.
We won't mention too many sites, but here's the main one to remember:
It a wealth of information.
1) SATAN
2) COPS
3) ISS
1) access control - based on IP address
2) logging - gives a lot of information.
How can you use syslog most effectively and why it's sensible to centralize logging on a secure server.
Syslog isn't the only mechanism used for logging. Many programs write to files.
Of course, you'll need to inspect them on a regular basis.
We'll explain where you should concentrate your efforts and why you shouldn't use Fred Cohen's headless chicken approach.
Why you should watch for the unexpected, rather than the expected you know how to defend yourself against.
Logs should be pretty verbose, yet what you log is mostly noise.
We'll explain how SWATCH allows you to be watch for interesting events. But we'll also give you a warning: the unexpected, unwatched events, may turn out to be the most interesting.
The final section sums up all most of what we've discussed using policies and implementations from SWAN as example.