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:
What to Protect? Distinguish between securing systems (e.g., computers) and data (identify specific data).
What to Protect Against? Define risks such as:
Data leakage
Accidental loss
Service disruption
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 updateapt 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
kaliaccount password iskali.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:
Filtering Network Gateway:
Protects an entire network.
Installed on a dedicated machine configured as a gateway.
Monitors and parses all inbound and outbound traffic.
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:
filter: Handles filtering rules (accept, refuse, or ignore packets).
nat (Network Address Translation): Modifies source/destination addresses or ports.
mangle: Alters other packet fields (e.g., Type of Service (ToS)).
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:
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).
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
-nto 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-numbersfor 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:
Block incoming traffic from specific IP:
Allow specific services (e.g., SSH, HTTP, IMAP):
Cleaning up Rules:
Use
--line-numbersto view the rule numbers in a chain and delete by number.
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 iptablesandman 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:
Install Fwbuilder:
Run the command:
apt install fwbuilder
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.
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.
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:
Edit the
/etc/network/interfacesFile:Locate the interface configuration (e.g.,
eth0).Add the up directive to specify the path to the firewall script.
Example configuration for interface
eth0:Explanation: This example assumes the script is located at /usr/local/etc/arrakis.fw and the hostname of the machine is arrakis.
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:
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.
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.
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:
Cracking Attempt Rules:
Stored in /etc/logcheck/cracking.d/.
Classifies log messages as potential security breaches or cracking attempts.
Ignored Cracking Attempts:
Found in /etc/logcheck/cracking.ignore.d/.
Allows ignoring specific cracking attempts based on predefined rules.
Security Alert Rules:
Stored in /etc/logcheck/violations.d/.
Used to classify messages as security alerts.
Ignored Security Alerts:
Found in /etc/logcheck/violations.ignore.d/.
Allows ignoring specific security alerts.
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:
Equivalent command using curly braces:
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:
top Command: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).
Managing Processes:
k: Kill a process by entering its PID.
r: Change the priority of a process (nice value).
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.
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:
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:dpkg --verify(ordpkg -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:
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:
Initialization: Run
aideinitto 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
Last updated
Was this helpful?
