> For the complete documentation index, see [llms.txt](https://blog.rootkid.in/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://blog.rootkid.in/exam-prep-notes/klcp-exam-pen-103-notes/8.-securing-and-monitoring-kali-linux.md).
# 8. Securing and Monitoring Kali Linux
## 8.1. Defining a Security Policy
**1. Importance of Goal-Driven Security**
* Security encompasses a vast range of concepts, tools, and procedures; no universal approach applies to all scenarios.
* Begin with clear goals to avoid focusing on the wrong aspects of security.
* **Key Questions to Define Goals:**
1. **What to Protect?** Distinguish between securing systems (e.g., computers) and data (identify specific data).
2. **What to Protect Against?** Define risks such as:
* Data leakage
* Accidental loss
* Service disruption
3. **Who to Protect Against?** Risks vary based on:
* Internal errors (e.g., typos by regular users)
* External threats (e.g., attacker groups)
**2. Risk Modeling**
* **Risk Factors:** Combine answers to the above questions to model risks.
* Use this model to create a security policy with actionable steps.
* A good security policy evolves over time in response to changing risks.
***
**3. Security is a Continuous Process**
* As Bruce Schneier states: **"Security is a process, not a product."**
* Assets, threats, and attacker tools evolve, requiring constant re-evaluation.
* Consider external constraints:
* Monetary costs
* User convenience
* System performance
***
**4. Tailoring Security to Context**
* **Low-Value Systems:** Minimal security might suffice (e.g., a second-hand computer used for basic calculations).
* **High-Value Systems:** For maximum confidentiality, extreme measures might be justified:
* Securely erase or destroy data.
* Store critical data on highly durable mediums in secure locations.
* **Key Insight:** Any well-reasoned security policy, tailored to risks and constraints, is valid.
***
**5. Segmenting Systems for Security**
* Break an information system into **independent subsystems** for tailored risk assessment and security design.
* **Key Principle:** Minimize the attack surface for easier defense.
* Concentrate sensitive services on fewer machines.
* Use minimal, well-secured routes for access.
* **Network Organization Tips:**
* Implement network filtering to restrict access points.
* Use firewalls (hardware or software) to secure entry points effectively.
## 8.2. Possible Security Measures
### 8.2.1. On a Server
When running **Kali Linux** on a server accessible to the public, it's crucial to implement strong security measures. Here's a guide:
* **Securing Network Services**:
* Change any **default passwords** configured on the system.
* Use a **firewall** to restrict access to services (refer to "Firewall or Packet Filtering").
* **User Accounts**:
* Ensure **strong passwords** that can resist **brute-force attacks**.
* Install **fail2ban** to block IP addresses after multiple failed login attempts:
* Commands:
* `apt update`
* `apt install fail2ban`
* **Web Services**:
* Host services over **HTTPS** to protect against traffic sniffing and safeguard **authentication cookies**.
### 8.2.2. On a Laptop
* **Risks and Context**:
* Laptops are less likely to face **random scans** from **script kiddies** due to minimal network services.
* Real risks include **theft**, **seizure by customs**, and exposing **confidential data** while traveling.
* **Data Protection**:
* Use **full disk encryption** (refer to "Installation on a Fully Encrypted File System").
* Enable the **nuke feature** to securely erase data if necessary (see "Adding a Nuke Password for Extra Safety").
* **Firewall Rules**:
* Restrict **outbound traffic** to only **VPN-generated traffic**:
* Purpose: Ensures you notice when the VPN is down and prevents falling back to local network access.
* Prevents exposing **customer IP addresses** during online activities.
* **Engagement Activity**:
* For local internal engagements:
* Maintain **control of activity** to minimize **network noise**.
* Avoid triggering **customer defense systems**.
## 8.3. Securing Network Services
* **General Guidelines**:
* **Disable unused services** to minimize security risks.
* **Kali Linux default**: Network services are disabled by default and pose no threat unless enabled.
* **Risks of Enabling Services**:
* **No firewall by default**: Services listening on all network interfaces become publicly available.
* Some services have **no authentication** or use **default credentials**:
* Always **(re)set passwords** to unique and secure values.
* Many services run as **root**, increasing the impact of unauthorized access.
* **Default Credentials**:
* Refer to:
* **README.Debian** for specific packages.
* **kali.org/docs/** and **tools.kali.org** for securing services.
* Review for any **special care** required by a service.
* **SSH Service**:
* **Live Mode**: The default `kali` account password is `kali`.
* Do not enable SSH without:
* Changing the **kali account password**.
* Configuring SSH to disallow **password-based logins**.
* For **pre-generated images**: Generate **new SSH host keys** (see "Generating New SSH Host Keys").
## 8.4. Firewall or Packet Filtering
A **firewall** is a system (hardware, software, or both) that examines **network packets** (incoming or outgoing) and allows or blocks them based on predefined rules.
***
**Types of Firewalls:**
1. **Filtering Network Gateway**:
* Protects an **entire network**.
* Installed on a **dedicated machine** configured as a gateway.
* Monitors and parses all **inbound and outbound traffic**.
2. **Local Firewall**:
* Runs on a **single machine**.
* Functions:
* Filters or limits access to local services.
* Prevents **rogue software** from initiating outgoing connections.
***
**Linux Firewall Implementation:**
* **Netfilter**: Embedded in the **Linux kernel** for packet filtering.
* Controlled via:
* **iptables**: For **IPv4** networks.
* **ip6tables**: For **IPv6** networks.
* Both tools must often be used together to handle dual-stack networks (IPv4 and IPv6).
* **fwbuilder**: GUI-based tool for creating and managing filtering rules.
***
**Considerations:**
* No **turn-key configuration**:
* Firewall settings depend on **network requirements** and **user needs**.
* Netfilter serves as the **core firewall** implementation in Linux, requiring careful setup for security.
### 8.4.1. Netfilter Behavior
**Netfilter Tables:**
Netfilter uses **four tables** to manage packet operations:
1. **filter**: Handles **filtering rules** (accept, refuse, or ignore packets).
2. **nat (Network Address Translation)**: Modifies **source/destination addresses or ports**.
3. **mangle**: Alters other packet fields (e.g., **Type of Service (ToS)**).
4. **raw**: Allows manual modifications **before connection tracking**.
***
**Chains and Rules:**
* Each table has **chains**, which are lists of **rules**.
* **Standard chains** handle packets based on predefined conditions:
* Administrator-created chains are invoked by standard chains.
***
**Standard Chains:**
1. **filter table**:
* **INPUT**: Packets destined for the firewall itself.
* **OUTPUT**: Packets emitted by the firewall.
* **FORWARD**: Packets passing through the firewall (not source or destination).
2. **nat table**:
* **PREROUTING**: Modifies packets **on arrival**.
* **POSTROUTING**: Modifies packets **before departure**.
* **OUTPUT**: Modifies packets generated by the firewall.
***
**Rule Actions:**
* Each rule contains **conditions** and a corresponding **action**:
* **Actions** interrupt chain processing unless otherwise specified.
**Standard Actions**:
* **ACCEPT**: Allow the packet.
* **REJECT**: Deny the packet and send an **ICMP error packet**.
* **DROP**: Ignore the packet.
* **LOG**: Record packet details to **syslogd**.
* Parameters:
* `--log-level` (default: `warning`), `--log-prefix`, `--log-tcp-sequence`, `--log-tcp-options`, `--log-ip-options`.
* **ULOG**: Log messages using **ulogd**, suitable for heavy logging.
**Chain Actions**:
* **chain\_name**: Jump to a custom chain for further rule evaluation.
* **RETURN**: Exit the current chain and resume at the calling chain (or use default action if no calling chain).
**nat Table Actions**:
* **SNAT**: Apply **Source NAT** (e.g., `--to-source address:port`).
* **DNAT**: Apply **Destination NAT** (e.g., `--to-destination address:port`).
* **MASQUERADE**: Special case of **Source NAT**.
* **REDIRECT**: Redirect packets to a specific port of the firewall (e.g., for transparent web proxies).
***
**ICMP (Internet Control Message Protocol):**
* A protocol for transmitting **network communication details**.
* Functions:
* Tests connectivity (e.g., **ping** sends ICMP echo requests and receives echo replies).
* Signals rejected packets, buffer overflows, or better routes for packets.
* Defined in:
* **IPv4**: RFC777, RFC792.
* **IPv6**: RFC4443 (required for IPv6 networks).
* **Buffer Overflow Handling**:\
ICMP adjusts transfer rates when a **receive buffer** (temporary memory for network data) is full.
**IPv6 Note**: ICMPv6 integrates features of IPv4 ICMP, IGMP, and ARP, making it essential for IPv6 operations.
### 8.4.2. Syntax of iptables and ip6tables
The `iptables` and `ip6tables` commands are used to manipulate tables, chains, and rules. Their `-t table` option indicates which table to operate on (by default, `filter`).
Used to manipulate **tables**, **chains**, and **rules** for packet filtering.
**Basic Commands:**
* **-t table**: Specifies the table (default: `filter`).
* **-L chain**: Lists rules in the chain (use `-n` to disable name resolution).
* **-N chain**: Creates a new chain.
* **-X chain**: Deletes an empty, unused chain.
* **-A chain rule**: Adds a rule to the end of the chain.
* **-I chain rule\_num rule**: Inserts a rule before a specific rule number.
* **-D chain rule\_num**: Deletes a rule by its number (use `--line-numbers` for rule numbers).
* **-F chain**: Flushes (deletes all) rules in a chain.
* **-P chain action**: Defines the default action (policy) for a chain.
**Common Rule Actions:**
* **-p protocol**: Matches the protocol (e.g., `tcp`, `udp`, `icmp`, `icmpv6`).
* Can be combined with **--source-port** and **--destination-port**.
* **-s address/network**: Matches the source address.
* **-d address/network**: Matches the destination address.
* **-i interface**: Selects packets coming from a specific network interface.
* **-o interface**: Selects packets going out through a specific interface.
* **--state state**: Matches the state of a packet (e.g., `NEW`, `ESTABLISHED`, `RELATED`).
**Negating Conditions:**
* Prefix conditions with an exclamation mark (`!`) to negate them.
**Examples of Common Commands:**
1. **Block incoming traffic from specific IP**:
```bash
$> iptables -A INPUT -s 10.0.1.5 -j DROP
$> iptables -A INPUT -s 31.13.74.0/24 -j DROP
$> iptables -n -L INPUT
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP all -- 10.0.1.5 0.0.0.0/0
DROP all -- 31.13.74.0/24 0.0.0.0/0
```
2. **Allow specific services (e.g., SSH, HTTP, IMAP)**:
```bash
$> iptables -A INPUT -m state --state NEW -p tcp --dport 22 -j ACCEPT
$> iptables -A INPUT -m state --state NEW -p tcp --dport 80 -j ACCEPT
$> iptables -A INPUT -m state --state NEW -p tcp --dport 143 -j ACCEPT
$> iptables -n -L INPUT
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP all -- 10.0.1.5 0.0.0.0/0
DROP all -- 31.13.74.0/24 0.0.0.0/0
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:143
```
**Cleaning up Rules:**
* Use **`--line-numbers`** to view the rule numbers in a chain and delete by number.
$> iptables -n -L INPUT --line-numbers
Chain INPUT (policy ACCEPT)
num target prot opt source destination
1 DROP all -- 10.0.1.5 0.0.0.0/0
2 DROP all -- 31.13.74.0/24 0.0.0.0/0
3 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
4 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80
5 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:143
$> iptables -D INPUT 2
$> iptables -D INPUT 1
$> iptables -n -L INPUT --line-numbers
Chain INPUT (policy ACCEPT)
num target prot opt source destination
1 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
2 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80
3 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:143
**Additional Notes:**
* Mastery of **iptables** and **ip6tables** requires experience with **conditions** and **actions** for handling network traffic.
* For more details, refer to the manual pages: `man iptables` and `man ip6tables`.
### 8.4.3. Creating Rules
**Fwbuilder Overview**
Fwbuilder is a high-level tool designed to simplify the creation of firewall rules by generating scripts for different systems, including **iptables** (Linux), **ipf** (FreeBSD), and **pf** (OpenBSD). It helps automate firewall configuration, which otherwise requires tedious manual input.
***
#### **Steps to Create Firewall Rules with Fwbuilder:**
1. **Install Fwbuilder:**
* Run the command: `apt install fwbuilder`
2. **Describe Key Elements for Rules:**
* **Firewall:**
* Define the network interfaces.
* **Networks:**
* Specify corresponding IP ranges.
* **Servers:**
* Add the relevant servers involved in your firewall rules.
* **Ports and Services:**
* Define the ports associated with the services hosted on the servers.
3. **Creating the Rules:**
* Use **drag-and-drop** actions to assign objects to the rules.
* Utilize **contextual menus** to modify conditions (e.g., negation).
* Select and configure the **action** for each rule.
Fwbuilder's Main Window
***
#### **IPv6 Configuration:**
* You can either:
* Create **separate rulesets** for **IPv4** and **IPv6**.
* Or, create a **single ruleset**, letting fwbuilder automatically adapt it based on the assigned addresses.
***
#### **Modular Architecture:**
* Fwbuilder generates firewall scripts that are compatible with various systems, such as:
* **iptables** (Linux)
* **ipf** (FreeBSD)
* **pf** (OpenBSD)
***
This structured approach allows for both simplicity and flexibility in managing complex firewall configurations.
### 8.4.4. Installing the Rules at Each Boot
To ensure that firewall rules are applied each time the system boots, you need to register the firewall configuration script in the **up** directive of the **/etc/network/interfaces** file. This will run the script once the network interface is brought up.
***
#### **Steps to Register the Firewall Script:**
1. **Edit the `/etc/network/interfaces` File:**
* Locate the interface configuration (e.g., `eth0`).
* Add the **up** directive to specify the path to the firewall script.
**Example configuration for interface `eth0`:**
```bash
auto eth0
iface eth0 inet static
address 192.168.0.1
network 192.168.0.0
netmask 255.255.255.0
broadcast 192.168.0.255
up /usr/local/etc/arrakis.fw
```
* **Explanation**: This example assumes the script is located at **/usr/local/etc/arrakis.fw** and the hostname of the machine is **arrakis**.
2. **Network Interface Management:**
* This approach assumes you're using **ifupdown** to configure network interfaces.
* For alternative tools like **NetworkManager** or **systemd-networkd**, refer to their respective documentation to find the correct way to execute a script after the interface is brought up.
***
By including the script in the `up` directive, the firewall configuration will be applied automatically each time the system boots. This helps maintain consistent firewall settings without manual intervention.
## 8.5. Monitoring and Logging
**Monitoring Logs with Logcheck**
Logcheck is a tool that monitors log files regularly and sends emails to the system administrator if unusual log messages are detected. By default, it checks logs every hour.
***
#### **Logcheck Key Features:**
1. **Monitoring Log Files:**
* Logcheck monitors the log files listed in **/etc/logcheck/logcheck.logfiles**.
* It works well with default settings if **/etc/rsyslog.conf** hasn’t been heavily modified.
2. **Report Levels:**
* Logcheck can be configured to report at three levels of verbosity:
* **Paranoid**: Very detailed; best for specific servers like firewalls.
* **Server**: Default mode; recommended for most servers.
* **Workstation**: Minimal output; suited for workstations, filtering out more messages.
3. **Customizing Logcheck:**
* Logcheck needs customization to exclude irrelevant messages, depending on installed services, to avoid receiving excessive emails.
* The configuration is complex, and it’s advised to read the file **/usr/share/doc/logcheck-database/README.logcheck-database.gz** for better understanding.
***
#### **Types of Rules in Logcheck:**
1. **Cracking Attempt Rules:**
* Stored in **/etc/logcheck/cracking.d/**.
* Classifies log messages as potential security breaches or cracking attempts.
2. **Ignored Cracking Attempts:**
* Found in **/etc/logcheck/cracking.ignore.d/**.
* Allows ignoring specific cracking attempts based on predefined rules.
3. **Security Alert Rules:**
* Stored in **/etc/logcheck/violations.d/**.
* Used to classify messages as security alerts.
4. **Ignored Security Alerts:**
* Found in **/etc/logcheck/violations.ignore.d/**.
* Allows ignoring specific security alerts.
5. **System Event Rules:**
* Messages not related to cracking attempts or security alerts are treated as system events.
* System events are reported unless explicitly ignored.
***
#### **Exclusion of Messages:**
* **ignore.d files** are used to ignore certain messages.
* Example: A cracking attempt or security alert can be ignored using rules in **/etc/logcheck/violations.ignore.d/** or corresponding files.
* **System events** are always reported unless excluded by a rule in **/etc/logcheck/ignore.d.{paranoid,server,workstation}** files.
* The rules applied depend on the selected verbosity level (paranoid, server, or workstation).
***
#### **Bash Command with Curly Brackets `{}`:**
* **Curly Braces** in bash are used for shorthand in commands, allowing multiple items to be created or specified without repeating the command structure.
**Example:**
* Command:
```bash
touch /home/kali/file1.txt /home/kali/file2.txt /home/kali/file3.txt
```
* Equivalent command using curly braces:
```bash
touch /home/kali/file{1,2,3}.txt
```
* Both commands create three files in the **/home/kali/** directory, but the second command is more concise.
### 8.5.2. Monitoring Activity in Real Time
**Monitoring Activity in Real Time**
To monitor system activity and resource usage in real time, **top** is an interactive command-line tool that provides insights into the processes currently running on a system. It's useful for checking CPU usage, memory consumption, and identifying resource-intensive processes.
***
#### **Key Features of the `top` Command:**
1. **Sorting Process Information:**
* By default, processes are sorted by **CPU usage**.
* You can change the sorting order with the following keys:
* **P**: Sort by **processor usage** (default).
* **M**: Sort by **memory usage**.
* **T**: Sort by **total processor time**.
* **N**: Sort by **process identifier (PID)**.
2. **Managing Processes:**
* **k**: Kill a process by entering its **PID**.
* **r**: Change the **priority** of a process (nice value).
3. **Identifying System Issues:**
* **top** helps identify which processes are using excessive CPU or memory resources.
* It’s important to compare the processes with expected services to detect any anomalies.
* A process running as **www-data** (typically used for web services) could be suspicious if it's unknown, as it may indicate a vulnerability or unauthorized software.
4. **Customization:**
* **top** is highly flexible and can be customized to display the data in a way that suits your needs.
* The **manual page** for **top** provides detailed instructions on customizing its display and functionality.
***
#### **Graphical Alternatives to `top`:**
* **xfce4-taskmanager**: A graphical tool similar to **top** for users of the **XFCE** desktop environment.
* **gnome-system-monitor**: A graphical tool for **GNOME** desktop users, providing similar features to **top**.
* **ksysguard**: The graphical process monitor for **KDE** users, offering similar functionality.
### 8.5.3. Detecting Changes
**Detecting Changes in System Files**
Once a system is installed and configured, most system files should remain unchanged unless there’s an upgrade or intentional modification. Monitoring changes to these files is critical, as unexpected changes could signal an attack. This section introduces tools commonly used to detect changes in system files.
***
#### **1. Auditing Packages with `dpkg --verify`:**
* **`dpkg --verify`** (or **`dpkg -V`**) checks for file modifications in installed packages.
* It compares system files against checksums stored in the **dpkg** database.
* **Limitations**: If an attacker modifies files and updates the checksum database, **dpkg** might not detect the changes.
* To protect against such attacks, use **APT’s digital signature verification** to verify package authenticity.
* **Example Output:**
```bash
??5?????? /lib/systemd/system/ssh.service
??5?????? c /etc/libvirt/qemu/networks/default.xml
??5?????? c /etc/lvm/lvm.conf
??5?????? c /etc/salt/roster
```
* The **5** in the third position indicates a failed checksum.
* The **c** indicates the file is a configuration file that was modified legitimately.
***
#### **2. What Is a File Fingerprint?**
* A **fingerprint** is a value that uniquely identifies the contents of a file.
* Calculated using algorithms like **MD5**, **SHA1**, or **SHA256**.
* Even the smallest change in the file alters the fingerprint (known as the **avalanche effect**).
* Fingerprints are non-reversible, so knowing the fingerprint doesn't allow retrieving the original contents.
***
#### **3. Monitoring Files with AIDE:**
* **AIDE (Advanced Intrusion Detection Environment)** checks file integrity and detects changes by comparing the current file state to a previously recorded image (stored in **/var/lib/aide/aide.db**).
* **Installation**:
```bash
apt update
apt install aide
```
* **Initialization**: Run **`aideinit`** to create the initial database.
* **Daily Checks**: AIDE runs daily via the **/etc/cron.daily/aide** script to check for changes.
* Changes are logged in **/var/log/aide/\*.log** and can be emailed to the system administrator.
* **Protecting the Database**:
* Since AIDE uses a local database to compare file states, an attacker with root access could replace the database to hide their actions.
* Store the AIDE database on **read-only storage media** to prevent this.
* **Configuration**:
* AIDE's configuration files are located in **/etc/aide/aide.conf** and **/etc/aide/aide.conf.d/**.
* The configuration specifies which files and properties need to be checked, such as content, permissions, and timestamps.
* A new database version is generated daily in **/var/lib/aide/aide.db.new**. If changes are legitimate, the new version replaces the reference database.
***
#### **4. Alternative Tools:**
* **Tripwire**:
* Similar to AIDE but adds **signatures** to the configuration file to prevent tampering by attackers.
* **Samhain**:
* Similar to AIDE and Tripwire but also includes **rootkit detection** features.
* Can be deployed across a network to monitor multiple systems and send results to a central server.
***
#### **5. Other Security Tools:**
* **checksecurity**:
* A set of scripts that perform basic checks like searching for empty passwords or new **setuid** files.
* It’s not comprehensive and should be used in conjunction with other tools.
* **chkrootkit** and **rkhunter**:
* These tools detect rootkits, which are malicious software designed to hide a system’s compromise.
* While not 100% reliable, they can alert you to potential rootkit infections.
***
By using tools like **dpkg --verify**, **AIDE**, and **Tripwire**, administrators can efficiently monitor system files for unauthorized changes. Additionally, **checksecurity**, **chkrootkit**, and **rkhunter** provide extra layers of protection by detecting rootkits and other security vulnerabilities.
Reference:
***
***
***
**`Hacker's Mantra:`**` ``The best hackers are the ones who don’t leave a trace. -- Kevin Mitnick`
