Network security is vital. Many applications (IBM 3270 telnet emulation, Telnet, ftp...) send unencrypted passwords across the network. Although a network cannot be completely secured, the weakest links should be protected. It is not realistic to expect the Network to be ever 100% secure. The are two principal tendencies in network security today:
- New applications being developed are often designed so that they can transfer data securely across insecure networks. i.e. some type of authentication / encryption is built-in.
- IP level encryption (for TCP/IP networks) offers a secure channel between two machines, even over insecure networks. One example is SKIP (see the "Mechanisms" chapter).
Network security could easily be enhanced if Vendors replaced relics such as ftp, telnet and rlogin with more secure alternatives such as ssh (see the "Mechanisms" chapter), if NIS+ and/or Kerberos clients were bundled with all major OSs and a secure email system such as pgp were fully integrated into vendors email clients. But history shows that this is unlikely to happen.....
Centralised network management is important for maintaining network security. The Network (meaning both LAN and WAN) is analysed here in terms of:
- Protocols: Netbios, TCP/IP, SNA, IPX, Decnet...
- Physical network types: leased lines, ISDN, X25, FDDI, Ethernet, ATM, radio, infra red, Microwave, GSM, satellite.
- Pure Network devices: routers, bridges, encryption units and modems. Firewalls are discussed in the next chapter.
11.1 Network Model (OSI)
The Open Systems Interconnect model is the standard for describing the transmission of data across networks. The seven layer model is particularly useful in comparing different architectures. The following diagram should help to understand the relationships between OSI, TCP/IP and communications layers used by Lan Manager.
11.2 Network Protocols
11.2.1 Lan Manager / Microsoft Network / NT Domains
- NetBEUI: Use only on local subnets.
- WINS (Windows Internet Naming Service) allows Netbios name to IP address resolution via a highly automated dynamic database. It reduces the need for LMHOSTS files. See the "Windows NT" chapter.
- RAS (Remote Access Service), see the "Windows NT" chapter.
11.2.2 TCP/IP
11.2.2.1 Weaknesses
TCP/IP was not designed for high security:
- Protection through the use of privileged ports (0-1000) has little value since PCs have become TCP/IP clients.
- No traffic priority (easy to flood the network).
- Traffic can be injected, packets can be stolen or hijacked.
- UDP (datagram based) offers no authentication.
- TCP (connection based) offers weak authentication.
- No confidentiality (no encryption).
- IP spoofing is easy (weak authentication), machines can lie about IP addresses. Routers can be tricked. Header checksums are not sufficient.
- Checksums are easy to cheat (weak algorithm).
However, TCP/IP is reliable, robust and the de-facto standard.
See the Mechanisms chapter for a discussion of new IP level encryption products designed to address many of the above problems.
11.2.2.2 Routing Protocols
TBD: Helo, Router discovery (rdisc), Gated, EGP, BGP, RIP, OSPF.
11.2.2.3 PPP (Point to Point Protocol)
TBD)
11.2.2.4 DNS (Domain Name Service)
- The DNS which is used on the internal network should not be visible to the outside world (Internet). Firewalls which provide DNS information to the Internet should only resolve firewall addresses/names (i.e. for email, an MX record which points to the firewall itself) and not provide any information about hosts on the internal network.
- The internal DNS server can be set up to send unresolved queries to the external DNS server (using "fowarders" in /etc/resolv.conf), which will then search the Internet.
- Internal clients should point to the internal DNS server(s).
- Clients with very few, designated connections do not need to use DNS.
- DNS servers should be configured as class
.
- Use replica (secondary) servers to increase availability.
- Up the lastest version of the Public Domain BIND for the internet exposed DNS servers, the public versions evolves more quickly and bug are fixed more rapidly than most vendors.
11.2.2.5 NIS, NIS + (Network Information Service)
See the chapter "Securing UNIX".
11.2.2.6 DHCP (Dynamic Host Configuration Protocol)
DHCP is very practical, especially for Laptops and in environments where reorganisations are constant. However, dynamic DHCP makes it difficult to uniquely identify machines, so for class networks, avoid the use of dynamic IP addressing. Static DHCP may be useful for centralising the management of IP addresses.
- An IP address should uniquely identify a machine (to prevent host spoofing and allow use of IP address access control i.e. inetd tcp_wrappers on UNIX machines).
- If DHCP is to be used (for large laptop populations for example), class servers should have static IP address and not be configured via DHCP.
- Ethernet MAC addresses can also be used to uniquely identify a hosts's traffic, if the MAC addresses are recorded and a database kept up to date and relevant network monitoring software exists.
11.2.2.7 NFS (Network File System)
See the "Securing UNIX" chapter for a discussion of NFS.
11.3 Physical network types
TBD: Cabling recommendations to protect against:
* Electromagnetic interference.
* Eavesdropping (clip-on, inductive, electromagnetic).
11.3.1 Ethernet
- Use hubs instead of Thin Ethernet (Star formation).
- no "unused" lived connections.
- Do not daisy chain.
- Disconnect unused sockets.
- Networks could be physically secured by using conduit.
11.3.2 Leased lines
11.3.3 FDDI
Because FDDI is a fibre optic ring, it is impossible to "listen" by detection of magnetic fields and if someone tries to connect to the ring, they need specialist equipment and the ring would be disturbed - it should not go unnoticed.
11.3.4 ATM
ATM (Asynchronous transfer mode) is a complex suite of protocols with many interesting features, such as bandwidth allocation, virtual networks, high speed... They are useful primarily by telecom providers. The complexity of ATM makes it difficult for hackers to crack, but also difficult to configure correctly.
TBD: detailed analysis.
11.4 Network Devices
Most attacks come from the inside, so:
- No "sniffer" or "network analyser" software is to be allowed on any PC unless it has been authorised by the Network manager, the Security manager and the user is fully aware of his responsibilities and the PC is logged on a list of dangerous machines. The status of these machines should be reviewed yearly.
- On systems (such as SunOS, Solaris) which include such software as standard, should either
1. Delete the utility or
2. Change permissions on the utility so that it can only be used by root. Of course the user must NOT have access to the root account in this case. - Class
systems should not be allowed on the same subnet as .
- Install a packet filter/firewall between internal networks and class systems.
- Network interface cards in PCs: some cards cannot be switched into promiscuous mode e.g. those based on the TROPIC chipset (HP Ethertwist). Buy Ethernet cards which do not allow promiscuous mode.
- Hubs, bridges and routers are getting very intelligent, they have more and more configuration options and are increasingly complex. This is useful for additional features, but the added complexing increases the security risk.
On critical subnets, it's important correctly configure network devices: only enable needed services, restrict access to configuration services by port/interface/IP address, disable broadcasts, source routing, choose strong (non default) passwords, enable logging, choose carefully who has user/enable/admin access, etc.
11.4.1 Hubs
- Repeater hubs broadcast incoming traffic. However, active (or switching) hubs send only packets addressed for a host to that host. i.e. sniffer software is rendered harmless. Performance is also improved. Recommended!
- Some hubs can be configured to protect at MAC level (so that only known MAC addresses can be connected to certain ports). Other hubs remember Ethernet address seen at certain ports and can be configured to stop access for new Ethernet addresses.
- Newer hubs also have built in http servers, if possible restrict access to certain IP addresses/ports, and avoid using this service from public or potentially hostile networks.
- Newer hubs can also create VLANS (virtual LANs) that group together certain ports into a virtual network, that other ports cannot see. Can be useful.
- Critical subnets: unused ports should be disabled (prevent attackers from using open ports).
11.4.2 Bridges
- Useful for breaking up subnets into small segments, making it easier to localise errors.
- Restricts traffic local to machines to that segment, by sensing what ethernet addresses are where. This improves both network performance and privacy (makes sniffing more difficult).
- Newer bridges also have built in http servers, if possible restrict access to certain IP addresses/interfaces, and avoid using this service from public or potentially hostile networks.
11.4.3 Routers
Routers have become complex and can have almost as many configuration options as a UNIX host...
- Routers should not pass NetBEUI packets or TCP/IP broadcast packets, to save bandwidth and increase availability. Where NIS is used, allowing IP broadcast across subnets also decreases security.
- A router may be used as a filter to protect subnets, e.g. for firewalls or connections to class
networks: See the "Firewalls" chapter for details.
- Routers have a configuration port, often accessible via telnet. Use a strong password, change it regularly! If possible restrict access to certain IP addresses/interfaces, or even the console.
- Newer routers also have built in http servers, if possible restrict access to certain IP addresses/interfaces, and avoid using this service from public or potentially hostile networks.
- A useful checklist for router auditing (in particular cisco) can be found at security portal.
- Avoid SNMP write community strings, if write is really necessary use difficult to guess strings.
- Consider enabling logging (of access violation, admin access errors), to a centralised syslog server.
11.4.4 Modems
A sweep of all Internal telephone lines should be made once a month (during the night) to see how many modems are attached and at what numbers. This can then be checked against a list of registered modems. TBD: example of a product which can do this!
- Modems which are only needed for outgoing calls should be configured to ignore incoming calls.
- A simple (10.- CHF) timer on the 220V modem supply can be used to deactivate the modem when it is not needed (for example during the night).
11.4.5 Gateways
11.4.5.1 Internet Email Gateway
A special firewall should exist to securely send and receive email from the Internet. See also the section on UNIX sendmail in the UNIX chapter and the Firewalls chapter. This machine will be subject to numerous attacks, so it must be very carefully configured.
11.5 External connections to WANs
11.5.1 Permission for external connections
For external access (via modem for example) to internal systems or from internal systems to the outside (Internet for example), a user should have the written permission. The user should prove that such an external access is absolutely necessary.
These external connections can be classed as incoming and outgoing:
11.5.2 Example Incoming connections
- Dialup access for company partners.
- Dialup access for IT staff and directors.
- Access from universities (co-ordination on research projects).
- Internet Email.
- Enterprise WWW Server.
- EDI
11.5.3 Example Outgoing Connections
- Access to Vendor Bulletin boards (for getting information, drivers).
- Customer connections: providing special services to clients (examples?).
- Internet Email.
- Normal Internet access: Netscape via proxy server.
- Special Internet Access: WWW, archie, ftp, news, telnet, gopher, wais.
- EDI (see above).
11.5.4 Simple Internet or Bulletin board access
If Internet access is required for information browsing (e.g. ftp or Web) on a sensitive zone, one solution is to use a simple PC with modem but with absolutely no (internal) network connection.
It is important that these connections be registered with, and audited regularly by centralised security staff.
11.5.5 Insecure subnets
Where many external connections are required in one building, one possibility is to group together the external connections on an "Insecure Subnet" which has direct outside access, but which is separated from the internal network via a Firewall. This minimises cost (only one firewall) and maximises flexibility, but great care must be taken in the daily usage on these machines on the "Insecure Subnet", as they must be considered as dangerous, penetrated hosts.
11.6 Network Management / Monitoring
Networks are becoming more important, data speeds and volumes are increasing and networks are becoming more and more heterogeneous. Professional Network monitoring can help to analyse and predict problems (and increase availability). Such monitors can also be used to increase security by two methods:
a) "Strange" network behaviour could be an intrusion, so a monitor should be able to note "strange" (i.e. not "normal") network behaviour.
b) If security policy specifies that certain services are not to be used by certain hosts at specified times, network monitor software could be used to check this. e.g. if the security policy for a network specifies that ftp is not to be used between 00:00 and 06:00, then any ftp traffic on the network at this time should be monitored an reported as a security alert. This kind of monitoring is especially useful for local high security networks.
- The Solaris 1 utility etherfind or the Solaris 2 utility snoop or the VMS utility ethermon could be used to monitor the network for unusual behaviour, but only from qualified, trusted personnel!
- Utilities such as satan can be used to identify devices on an IP network, as well as report on TCP/IP security problems.
- Such utilities should be removed from all other machines.