BSc CSIT (TU) Science Network and System Administration (BSc CSIT, CSC412) Question Paper 2081 Nepal

System and Network Administration

System administration is the practice of installing, configuring, maintaining, and monitoring computer systems (servers, operating systems, applications) so that they remain reliable, secure, and available to users. Network administration extends this to the infrastructure that connects those systems — routers, switches, firewalls, DNS/DHCP services, and connectivity — ensuring smooth and secure communication.

Together, the system/network administrator is responsible for the day-to-day operation, health, and security of an organization's IT environment.

Goals of System Administration

1. Availability / Uptime — keep systems and services running with minimal downtime.
2. Reliability and consistency — reproducible, well-documented configurations.
3. Security — protect data and services from unauthorized access and attacks.
4. Performance — tune and scale resources (CPU, memory, disk, network) to meet demand.
5. Data integrity and recoverability — backups and disaster-recovery so data is never lost.
6. User support and satisfaction — provide accounts, access, and help to users.
7. Cost-effectiveness / automation — use scripting and tools to reduce manual effort.
8. Compliance and documentation — meet policies/standards and keep records.

Typical Tasks of an Administrator

• User and account management — creating/removing users and groups, setting passwords and permissions.
• Installation and configuration — installing the OS, software, patches, and services.
• Monitoring — watching CPU, memory, disk, logs, and network for problems (e.g. Nagios, Zabbix).
• Backup and recovery — scheduling backups and testing restores.
• Security management — firewalls, antivirus, patching, intrusion detection, hardening.
• Network configuration — IP addressing, DNS, DHCP, routing, troubleshooting connectivity.
• Performance tuning and capacity planning — adding resources before they run out.
• Automation and scripting — shell scripts, cron jobs, configuration management (Ansible, Puppet).
• Documentation — keeping records of configurations and procedures.
• Troubleshooting and support — diagnosing and resolving incidents.

DNS and DHCP

DNS (Domain Name System)

DNS is a hierarchical, distributed naming system that resolves human-readable domain names into IP addresses (and vice versa). When a host needs to reach www.example.com, its resolver queries DNS servers (root → TLD → authoritative) to obtain the corresponding IP (e.g. 93.184.216.34). It uses UDP/TCP port 53.

Configuration (Linux/BIND example): zone files declare records such as A, AAAA, CNAME, MX, NS, PTR.

; example.com zone file
@      IN  SOA  ns1.example.com. admin.example.com. ( 2024010101 3600 900 604800 86400 )
@      IN  NS   ns1.example.com.
www    IN  A    192.168.1.10
mail   IN  MX 10 mail.example.com.

Clients point to a resolver via /etc/resolv.conf (nameserver 8.8.8.8).

DHCP (Dynamic Host Configuration Protocol)

DHCP automatically assigns IP configuration to clients — IP address, subnet mask, default gateway, and DNS server addresses — eliminating manual setup. It uses UDP ports 67 (server) and 68 (client) and works through the DORA exchange: Discover → Offer → Request → Acknowledge.

Configuration (ISC dhcpd example):

subnet 192.168.1.0 netmask 255.255.255.0 {
  range 192.168.1.100 192.168.1.200;
  option routers 192.168.1.1;
  option domain-name-servers 192.168.1.10;
  default-lease-time 600;
}

Comparison of Roles

How They Work Together

When a host joins a network, DHCP first leases it an IP address, subnet mask, gateway, and the address of the DNS server to use. The client then uses that DNS server to resolve names into IP addresses for actual communication. Modern setups also use Dynamic DNS (DDNS): the DHCP server updates DNS records automatically when it hands out a lease, so a client's hostname always maps to its current IP. Thus DHCP handles who am I / how do I connect, and DNS handles where is the host I want to reach.

Network Security

Network security is the set of policies, practices, and technologies used to protect the confidentiality, integrity, and availability (CIA) of data and resources on a network against unauthorized access, misuse, and attacks (e.g. malware, DoS, spoofing, man-in-the-middle).

1. Firewalls

A firewall filters traffic between networks based on rules, enforcing a boundary between trusted and untrusted zones.

• Packet-filtering — allow/deny by IP, port, protocol.
• Stateful inspection — tracks connection state.
• Application-layer / proxy / next-gen (NGFW) — inspect content, do IDS/IPS, app control.

# iptables example: allow SSH and HTTP, drop the rest
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -P INPUT DROP

2. VPN (Virtual Private Network)

A VPN creates an encrypted tunnel over a public network so remote users/sites can communicate securely as if on a private LAN. Protocols include IPsec, OpenVPN, WireGuard, L2TP/SSL-TLS. It provides confidentiality, authentication, and integrity for traffic in transit.

3. Encryption

Encryption converts plaintext into ciphertext so only authorized parties can read it.

• Symmetric (AES) — same key for encrypt/decrypt; fast, for bulk data.
• Asymmetric (RSA, ECC) — public/private key pair; used for key exchange and digital signatures.
• In transit: TLS/SSL (HTTPS), SSH. At rest: disk/file encryption (LUKS).

4. Best Practices for Securing Servers and Services

• Least privilege — give users/services only the access they need.
• Patch and update regularly to fix vulnerabilities.
• Strong authentication — key-based SSH, MFA, strong password policy; disable root login.
• Disable unused services and close unused ports (reduce attack surface).
• Use firewalls and IDS/IPS to filter and detect threats.
• Encrypt data in transit (TLS) and at rest.
• Logging and monitoring — central logs, audit, alerting on anomalies.
• Regular backups and tested recovery.
• Hardening — SELinux/AppArmor, secure configurations, fail2ban.
• Security policy and user awareness.

A switch and a router are both networking devices but operate at different OSI layers and serve different purposes.

In short: a switch moves data between devices on the same network using MAC addresses, while a router forwards data between networks (and to the Internet) using IP addresses, choosing the best path.

Linux User Authentication Process

Authentication verifies that a user is who they claim to be before granting access. The typical password-based flow is:

1. Login prompt — the user enters a username and password (via login, SSH, or display manager).
2. Lookup of account — the system checks /etc/passwd for the username, which stores UID, GID, home directory, and login shell (but not the password).
3. Password verification — the entered password is hashed and compared against the stored hash in /etc/shadow (readable only by root). Modern systems use salted hashes such as SHA-512 ($6$...).
4. PAM — most distributions use Pluggable Authentication Modules (PAM) (/etc/pam.d/) to perform the actual checks. PAM can enforce password policy, account expiry, MFA, and account locking, and can authenticate against local files, LDAP, Kerberos, etc.
5. Session setup — on success the system assigns the user's UID/GID, sets environment variables, changes to the home directory, and starts the login shell. Failures are logged (e.g. /var/log/auth.log or /var/log/secure).

Key files: /etc/passwd (account info), /etc/shadow (hashed passwords), /etc/group (group membership), and PAM configuration under /etc/pam.d/.

Purpose of the umask Command

umask (user file-creation mask) sets the default permissions that are removed from files and directories when they are created. It defines which permission bits are masked off by default, so it controls the security of newly created files.

• Default base permissions: files = 666 (rw-rw-rw-), directories = 777 (rwxrwxrwx).
• Effective permission = base − umask (bitwise: base AND NOT umask).

Example: with umask 022:

• New file → 666 − 022 = 644 (rw-r--r--)
• New directory → 777 − 022 = 755 (rwxr-xr-x)

A more restrictive umask 077 gives files 600 and directories 700, so only the owner has access. The mask can be viewed/set with the umask command and is usually set in shell startup files (e.g. /etc/profile, ~/.bashrc).

Purpose: it lets administrators enforce safe default permissions and prevent newly created files from being world-readable or world-writable.

Disk Partitioning

Disk partitioning is the process of dividing a physical hard disk into one or more logical sections called partitions, each of which can be managed and formatted independently with its own file system.

Purpose / Benefits

• Separation of operating system, applications, and user data.
• Ability to run multiple operating systems (dual-boot) on one disk.
• Easier backup, recovery, and management; a problem in one partition need not affect others.
• Dedicated partitions (e.g. /home, swap, /var) improve organization and prevent one area from filling the whole disk.

Types / Schemes

• MBR (Master Boot Record): older scheme, supports up to 4 primary partitions (or 3 primary + 1 extended containing logical partitions); limited to 2 TB.
• GPT (GUID Partition Table): modern scheme, supports 128+ partitions and very large disks (> 2 TB); used with UEFI.
• Primary / Extended / Logical partitions (MBR terminology).

In Linux

Partitions appear as device files such as /dev/sda1, /dev/sda2. Tools like fdisk, parted, or gparted create them, then mkfs formats them (e.g. ext4) and mount attaches them to the directory tree. A typical setup includes a root /, a swap, and sometimes separate /home and /boot partitions.

Reverse Proxy

A reverse proxy is a server that sits in front of one or more back-end servers and forwards client requests to them, then returns the servers' responses to the clients. To the client it appears to be the actual server — the real back-end servers are hidden. (This is the opposite of a forward proxy, which sits in front of clients.)

Functions / Benefits

• Load balancing — distributes incoming requests across multiple back-end servers.
• Security / anonymity — hides the identity and IP addresses of back-end servers; acts as a single controlled entry point.
• SSL/TLS termination — handles HTTPS encryption/decryption centrally, offloading back-end servers.
• Caching and compression — caches static content to improve performance.
• Single entry point — can route requests to different services based on URL/host.

Examples: Nginx, HAProxy, and Apache (mod_proxy) are commonly used as reverse proxies in front of web/application servers.

Full Backup vs Incremental Backup

Full backup: a complete copy of all the chosen files/data taken at a point in time. It is simple to restore but consumes the most time and storage.

Incremental backup: backs up only the files that changed since the previous backup of any type. It is fast and space-efficient, but restoring requires the most recent full backup followed by every incremental taken after it, applied in sequence.

Typical strategy: a weekly full backup plus daily incrementals balances speed, storage, and recoverability.

SELinux (Security-Enhanced Linux)

SELinux is a Mandatory Access Control (MAC) security mechanism built into the Linux kernel (originally developed by the NSA). It enforces fine-grained security policies that go beyond the traditional Discretionary Access Control (DAC) model of user/group file permissions.

Key Points

• Every process (subject) and resource (object — files, ports, sockets) is labeled with a security context (user:role:type:level), e.g. system_u:object_r:httpd_sys_content_t:s0.
• Access is granted only if an explicit policy rule allows the subject's type to act on the object's type — type enforcement. Even the root user is constrained by policy, limiting the damage a compromised process can do.
• It implements the principle of least privilege and contains exploited services within their allowed boundaries.

Modes

1. Enforcing — policy is applied and violations are blocked.
2. Permissive — violations are only logged (not blocked), useful for testing.
3. Disabled — SELinux is off.

Managed with commands like getenforce, setenforce, sestatus, and semanage; it is enabled by default on RHEL/CentOS/Fedora.

Role of the crontab File

The crontab (cron table) file stores the schedule of commands or scripts that the cron daemon (crond) runs automatically at specified times, enabling task automation such as backups, log rotation, and system maintenance.

Format

Each line specifies five time fields followed by the command:

*  *  *  *  *  command_to_run
|  |  |  |  |
|  |  |  |  +-- day of week (0-7, Sun=0/7)
|  |  |  +----- month (1-12)
|  |  +-------- day of month (1-31)
|  +----------- hour (0-23)
+-------------- minute (0-59)

Examples

0 2 * * *      /home/user/backup.sh      # every day at 02:00
*/15 * * * *   /usr/bin/check.sh          # every 15 minutes
0 0 * * 0      /usr/bin/weekly.sh         # every Sunday midnight

Key Points

• Each user can have a personal crontab, edited with crontab -e and listed with crontab -l.
• System-wide jobs live in /etc/crontab and /etc/cron.d/, with helper directories cron.hourly/daily/weekly/monthly.
• It lets administrators schedule recurring jobs without manual intervention.

Short Notes: Containerization (Docker)

Containerization is a lightweight form of OS-level virtualization in which an application and all its dependencies (libraries, binaries, config) are packaged together into a single, portable unit called a container that runs consistently across any environment.

Docker is the most popular platform for building, shipping, and running containers.

Key Concepts

• Image — a read-only template/blueprint containing the app and its dependencies; built from a Dockerfile.
• Container — a running instance of an image; isolated but shares the host OS kernel (unlike a VM, it has no full guest OS).
• Dockerfile — text file with instructions to build an image.
• Docker Hub / Registry — repository for storing and sharing images.

Containers vs Virtual Machines

• Containers share the host kernel → lightweight, fast to start, less overhead.
• VMs run a full guest OS via a hypervisor → heavier and slower.

Benefits

• Portability — "build once, run anywhere."
• Consistency — same environment in dev, test, and production.
• Efficiency / density — many containers per host.
• Fast deployment and scaling; works well with microservices and CI/CD.

FROM python:3.11
COPY app.py /app/
WORKDIR /app
CMD ["python", "app.py"]