Hardening a Default Ubuntu Installation for Security
A fresh Ubuntu installation is a sound starting point, not a finished security plan. Ubuntu normally keeps the user’s day-to-day account unprivileged, locks the root account by default, and obtains software through signed package repositories. On the 2006-era desktop, those choices reduce obvious paths to compromise. They do not remove unnecessary network services, unpatched programs, or carelessly forwarded router ports. Nor does the NAT built into an Australian ADSL or cable modem protect a machine once traffic is deliberately sent to it.
Hardening should start with a short inventory: who uses the computer, what data it holds, and which connections are genuinely required. A home box in Brisbane has a different profile from a design studio machine in Melbourne or a records workstation in Canberra. The goal is not mysterious obscurity. It is a small, documented set of privileges, listening ports, and recovery paths that an intruder cannot quietly turn into normal system access.
Establish what must be reachable
Begin with network flows rather than a list of fashionable tools. Note wired and wireless connections, router port-forwarding rules, file sharing, printing, remote support, and any server exposed to customers. Everything absent from that list should have no route inward. This is especially important on home connections from providers such as Optus or Telstra, where a dynamic address and a router full of old forwarding rules can outlive the device that needed them. Disable UPnP port mapping unless a current, identified device requires it.
Turn the inventory into three simple categories: desktop, internal server, and deliberately external host. A desktop should normally reject unsolicited inbound traffic. An internal server may need narrowly described connections from the local network. Only an external host should accept traffic from the wider internet, and even then its required ports should be few and justified. In Australian office and home support slang, the machine is often simply “the box”; for a bastion or gateway, that casual label can hide a very different duty.
Keep packages and services current
On Ubuntu 6.06, security maintenance is an operator responsibility rather than a background service. Run signed repository updates regularly with apt-get update, inspect the proposed changes, and apply them with apt-get upgrade; do not bypass a broken or untrusted repository merely to make installation easier. A weekly rhythm, plus an update before a long period away, fits Australian home and small-office schedules better than an occasional emergency clean-up.
After updating, review services and listening sockets. Tools such as netstat and the system’s service configuration show what is actually waiting; package names in an old tutorial do not. Disable printing, file sharing, FTP, or other daemons that the machine does not use. Telnet should not be installed or enabled in the first place. Keep a few rollback notes, because a security update can also expose an old local assumption, and test the critical services after each service change.
Control accounts and remote access
Leave root locked and reserve sudo for specific administrative commands. Give the ordinary user a long, unique passphrase, prohibit shared logins, and remove accounts when people leave a studio or office. The GNOME screen lock matters as much as the password: an unattended session can otherwise expose mail, browser sessions, and documents without any remote attack. Root-level shells and blanket sudo privileges discard the protection created by Ubuntu’s account model.
Do not forward SSH from an ADSL router merely because remote help seems convenient. Where remote administration is unavoidable, use a private network or VPN, key authentication, restricted user accounts, and a deliberate recovery method. In sshd_config, set PermitRootLogin no and, after testing key-based access, set PasswordAuthentication no. Dynamic addresses, time differences, and support calls across Australian cities make silent lockouts a real operational risk; retain console or provider access before changing daemon rules.
Filter traffic at the workstation
The router is the first filter, but the Ubuntu machine needs its own stateful firewall. Netfilter and iptables were the relevant tools in this period, whether configured directly or through an installed management interface. A useful policy drops unsolicited inbound packets, permits loopback traffic, permits established and related flows, and allows only the inbound services justified by the inventory. Outbound access can remain permitted unless a policy demands more.
Build the rules in the active session, keep a console open, test them, and then save them. Account for DHCP before dropping traffic and permit only the ICMP needed for network diagnostics and path MTU behaviour. Blocking every ping is not meaningful protection and can make support harder. Rate limits may reduce noisy scans, but they do not justify a broad ACCEPT rule hidden in the middle of the chain.
Review the rules whenever the network changes, including a move from a private office LAN to broadband, a new wireless network, or a temporary event connection. Keep firewall ownership clear for teams that maintain older Ubuntu systems, then tighten policy from observed behaviour rather than guesswork. A host firewall complements router NAT; either one can fail through configuration, so neither should be treated as the whole boundary.
Secure routine desktop work
Firefox, mail clients, document readers, and download tools are part of the attack surface even when no server is exposed. Install updates from Ubuntu or verified upstream sources, avoid obsolete browser plug-ins, and treat unexpected attachments, archives, and executable files as untrusted input. Running the desktop as an ordinary user limits damage, but it remains a poor substitute for opening files cautiously. Shared Windows documents should be scanned where a workstation bridges to Microsoft systems; ClamAV can help, but it does not make unknown attachments safe.
Physical and account-level protections are cheap. Lock the screen whenever the room is unattended, enable the strongest wireless encryption the access point supports, and keep sensitive files out of broadly shared and indexed directories. A shared WEP key provides limited protection. Automatic locking was not especially capable on the 2006 desktop, so a deliberate Ctrl+Alt+L shortcut or session setting can outperform a neglected screensaver. A support conversation that begins, “Does this box need internet-facing login?” is often more secure than an improvised remote-access setup.
Preserve logs, baselines, and recovery
Keep system time accurate with NTP and retain /var/log/auth.log, system logs, and relevant firewall messages. Review them for repeated failed logins, unfamiliar accounts, new listeners, unexpected reboots, and disabled update jobs. Record which packages and services are approved, then compare the running system with that record after maintenance. In Australia, shared administration across states and remote support from another city are common enough that timestamps and clear ownership prevent avoidable mistakes.
Encryption needs an honest scope. Ubuntu 6.06 did not make whole-disk encryption a straightforward default installation feature, so do not claim that LUKS, encrypted containers, or an external encrypted volume protects every file. Use available disk encryption deliberately, protect keys, and include swap, temporary files, and backups in the decision. Back up configuration and irreplaceable data separately, test a restore, and keep the recovery key somewhere authorised and secure. For a serious incident, isolate the machine, preserve evidence, and seek qualified assistance through CERT-AUS, then Australia’s national computer emergency response team, rather than wiping the only useful record.
Fit the controls to Australian use
Australian conditions affect priorities more often than they change technical rules. Commonwealth agencies and private organisations may hold Canberra records covered by the federal Privacy Act 1988; covered private-sector handling of personal information follows the National Privacy Principles in the period described here. Health and service-provider records can also trigger state or territory duties. Old desktops, backup media, and casual shared drives may therefore create a records problem even when the network is quiet.
The practical differences can be expressed directly:
| Control | Common default assumption | Hardened position | Most relevant setting | Evidence to keep |
|---|---|---|---|---|
| Package updates | Packages install themselves | Scheduled operator-managed updates with verified signatures | Routers, servers, travel workstations | Changed package list and operator log |
| Router forwarding | No forwarding means safe | Remove stale rules and disable automatic port mapping | Homes and small offices | Written forwarding-rule inventory |
| SSH | A hidden dynamic address is protection | VPN or key-only access, no root login and no public port | Multi-city administration | Daemon config, key inventory and access logs |
| Account privileges | One experienced user can hold all power | Root locked, scoped sudo and named accounts | Studios and Canberra offices | Account list, sudo decisions and personnel changes |
| Encryption and backups | Files are protected once the disk is mounted | Encrypt selected volumes, secure swap and keys, and test restoration | Records-bearing laptops | Restore test, key custody and backup inventory |
No single control carries the whole design. A desktop used for ordinary office work should be patched, minimally privileged, firewalled and able to recover; a server may justify SSH or file services that would be reckless on a laptop. Document exceptions for Australian broadband routers, shared administration and sensitive records, then revisit them after every network or staffing change. The result is an Ubuntu installation whose security rests on visible decisions and tested recovery rather than assumptions about an unseen router.