How to Set Up a Personal Threat Detection System with Open-Source Tools

All Notes

Technology

As developers, we often build and deploy, but how much thought do we put into detecting when things go wrong, or when someone’s trying to mess with our systems? A “personal” threat detection system isn’t about building a full SOC in your living room. It’s about gaining visibility, understanding what’s normal, and being alerted to anomalies or outright attacks on your individual machines or small home network.

This post will walk you through setting up a pragmatic, open-source threat detection system focusing on common Linux environments. We’ll leverage powerful, battle-tested tools to monitor network traffic, file changes, and system activities, then tie it together with a simple alerting mechanism.

Why Bother with a Personal System?

You might think, “I’m not a target.” But every internet-connected device is a target for automated scans, botnet recruitment, or opportunistic attacks. Even a small system can detect:

Unauthorized access attempts: SSH brute-force, web server exploits.
Malware activity: Outbound connections to C2 servers, unusual process behavior.
Configuration tampering: Changes to critical system files or web directories.
Network reconnaissance: Port scans against your public IP.

The goal isn’t to become a cybersecurity expert overnight, but to empower yourself with tools to understand and react to potential threats.

Core Components of Our System

We’ll focus on three main pillars:

Network Intrusion Detection (NIDS): Monitoring network traffic for suspicious patterns.
Host-based Intrusion Detection (HIDS): Monitoring the system itself for unauthorized changes, processes, or activities.
Alerting: Notifying you when something suspicious is detected.

For this guide, we’ll assume a Linux environment (Ubuntu/Debian or similar for package management).

1. Network Intrusion Detection with Suricata

Suricata is a high-performance, open-source Network IDS/IPS/NSM engine. It can inspect network traffic using rules to identify known threats, policy violations, and anomalous activity.

Installation:

sudo apt update
sudo apt install suricata

Basic Configuration & Rule Management:

Suricata uses a suricata.yaml configuration file (usually in /etc/suricata/) and relies on rule sets. The easiest way to get started with rules is by using suricata-update, which fetches and manages rules from various sources like Proofpoint Emerging Threats (ET) Open rules.

First, enable the ET Open rules source:

sudo suricata-update enable-source et/open

Then, update your rule sets:

sudo suricata-update

2023-10-27 10:00:00 - <Info> -- Loading /etc/suricata/suricata.yaml
2023-10-27 10:00:00 - <Info> -- No such file or directory for /etc/suricata/etpro.yaml, skipping
2023-10-27 10:00:00 - <Info> -- Fetching https://rules.emergingthreats.net/open/suricata-6.0.0/emerging.rules.tar.gz
2023-10-27 10:00:00 - <Info> -- Done.
2023-10-27 10:00:00 - <Info> -- Writing /var/lib/suricata/rules/suricata.rules
2023-10-27 10:00:00 - <Info> -- All rules successfully compiled.
2023-10-27 10:00:00 - <Info> -- Suricata-Update done.

Running Suricata in IDS Mode:

For a personal setup, running Suricata as an IDS (monitoring only) is generally safer than IPS (inline blocking), which can accidentally block legitimate traffic. We’ll monitor a specific network interface (e.g., eth0 or enp0s3).

Find your network interface name:

ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.100/24 brd 192.168.1.255 scope global dynamic enp0s3
       valid_lft 85600sec preferred_lft 85600sec
    inet6 fe80::a00:27ff:fexx:xx:xx/64 scope link
       valid_lft forever preferred_lft forever

In this example, enp0s3 is our interface.

Now, run Suricata. For a personal system, you might run it in the foreground for testing, or as a service for continuous monitoring.

Testing in Foreground (IDS mode):

sudo suricata -i enp0s3 -c /etc/suricata/suricata.yaml --runmode autofp --set default-log-dir=/var/log/suricata/

This command starts Suricata on enp0s3 using the default config, optimizes for auto-flow processing, and ensures logs go to /var/log/suricata/.

Generating an Alert (Test):

Let’s try to trigger a simple alert. Suricata comes with rules to detect things like basic P2P traffic or well-known malware beaconing. A common test is to visit a known EICAR test file URL, though that might be blocked by your browser or AV.

A simpler test is to craft a custom rule to detect unique traffic. Or, if you’re feeling adventurous, try to nmap scan your own machine from another device on the network (Suricata might detect port scanning activity if the rules are enabled).

Let’s create a custom Suricata rule to detect a simple ICMP echo request (ping) with a specific payload, just for demonstration. Create a file, e.g., /etc/suricata/rules/local.rules, and add:

alert icmp any any -> any any (msg:"LOCAL_RULE: ICMP Echo Request detected!"; content:"HelloSuricata"; nocase; sid:1000001; rev:1;)

Then, add local.rules to your suricata.yaml in the rule-files section (search for rule-files: and add - local.rules there). Make sure it’s uncommented.

Reload Suricata rules:

sudo suricata-update

Now, restart Suricata (or run it in the foreground again). From another machine on your network, try to ping your Suricata machine with a custom data payload:

ping -p "48656c6c6f5375726963617461" 192.168.1.100 # Replace with your IP

(Note: The payload 48656c6c6f5375726963617461 is the hex representation of HelloSuricata).

Checking Suricata Logs:

Suricata typically logs alerts to eve.json in /var/log/suricata/. You can tail this file.

tail -f /var/log/suricata/eve.json | grep LOCAL_RULE

{"timestamp":"2023-10-27T10:05:30.123456+0000","flow_id":123456789,"in_iface":"enp0s3","event_type":"alert","src_ip":"192.168.1.101","dest_ip":"192.168.1.100","proto":"ICMP","icmp_type":8,"icmp_code":0,"alert":{"action":"allowed","gid":1,"signature_id":1000001,"rev":1,"signature":"LOCAL_RULE: ICMP Echo Request detected!","category":"Custom Local Rule","severity":3},"icmp":{"type":8,"code":0,"checksum":1234},"app_proto":"icmp","pkt_src":"wire","tx_id":0}

You’ll see your custom alert, confirming Suricata is working. This JSON output is machine-readable and can be parsed by log management tools.

Running as a Service:

For continuous monitoring, enable and start the Suricata service:

sudo systemctl enable suricata
sudo systemctl start suricata
sudo systemctl status suricata

● suricata.service - LSB: Next Generation Intrusion Detection and Prevention Engine.
     Loaded: loaded (/etc/init.d/suricata; generated)
     Active: active (running) since Fri 2023-10-27 10:10:00 UTC; 10s ago
       Docs: man:systemd-sysv-generator(8)
      Tasks: 8 (limit: 4579)
     Memory: 50.0M
        CPU: 1.250s
     CGroup: /system.slice/suricata.service
             └─12345 /usr/bin/suricata -D -q 0 -c /etc/suricata/suricata.yaml --pidfile /run/suricata.pid

Note: Suricata can be resource-intensive on busy networks. For a personal workstation or home server, its impact is usually manageable. Regularly update rules using sudo suricata-update and consider running it via a cron job.

2. Host-Based Monitoring

Host-based detection focuses on what’s happening on your machine itself.

2.1 File Integrity Monitoring (FIM) with `inotifywait`

Detecting changes to critical system files or configuration files is vital. While robust FIM solutions like AIDE exist, inotifywait (part of inotify-tools) offers a simple, scriptable way to monitor specific paths in real-time.

Installation:

sudo apt install inotify-tools

Basic Usage:

To watch /etc/passwd for any write, attribute change, or delete operations:

inotifywait -m -e modify,attrib,create,delete,move /etc/passwd

Setting up watches.
Watches established.

Now, open another terminal and modify /etc/passwd (e.g., add a comment, then remove it).

sudo nano /etc/passwd # Make a change, save, exit.

In the inotifywait terminal, you’ll see:

/etc/passwd MODIFY
/etc/passwd ATTRIB

Scripting a Simple FIM:

We can wrap inotifywait in a script to continuously monitor critical directories and log changes.

Create a script monitor_files.sh:

#!/bin/bash

# Directories to monitor
WATCH_DIRS="/etc /var/www /root /home/$USER/.ssh"
LOG_FILE="/var/log/fim_events.log"
ALERT_EMAIL="your_email@example.com" # Replace with your email

echo "$(date): Starting FIM monitor..." | tee -a "$LOG_FILE"

# Use inotifywait to monitor directories recursively
# -m: monitor indefinitely
# -r: recursive
# -e: events to watch for (create, delete, modify, attribute change, move)
# --format: custom output format
inotifywait -m -r -e create,delete,modify,attrib,move --format "%T %w%f %e" --timefmt "%Y-%m-%d %H:%M:%S" $WATCH_DIRS | \
while read DATE_TIME FILE_PATH EVENT; do
    LOG_ENTRY="File changed: $DATE_TIME - $FILE_PATH - Event: $EVENT"
    echo "$LOG_ENTRY" | tee -a "$LOG_FILE"

    # Simple Alerting (can be extended with ntfy.sh later)
    # Note: For production, avoid emailing on every change.
    # Implement rate-limiting or aggregate alerts.
    if [[ "$FILE_PATH" == *"/etc/sudoers"* || "$FILE_PATH" == *".ssh"* ]]; then
        echo "CRITICAL FIM ALERT: $LOG_ENTRY" | mail -s "CRITICAL FIM ALERT on $(hostname)" "$ALERT_EMAIL"
    fi
done

Make it executable:

chmod +x monitor_files.sh

Run it in the background:

./monitor_files.sh &

Now, try creating a file in /etc:

sudo touch /etc/test_file.tmp

Check fim_events.log:

tail -f /var/log/fim_events.log

2023-10-27 10:30:00: Starting FIM monitor...
File changed: 2023-10-27 10:30:30 - /etc/test_file.tmp - Event: CREATE

Note: inotifywait is powerful but basic. It doesn’t track file contents, only metadata and existence. For enterprise-grade FIM, look into solutions like AIDE (Advanced Intrusion Detection Environment) which creates a baseline database of file hashes and attributes and alerts on deviations. For a personal system, inotifywait provides quick, actionable insights.

2.2 Rootkit Detection with `chkrootkit`

Rootkits are stealthy pieces of malware designed to hide their presence on a system. chkrootkit is a classic tool that checks for signs of rootkits by scanning system binaries for known patterns.

Installation:

sudo apt install chkrootkit

Usage:

Simply run chkrootkit with sudo:

sudo chkrootkit

chkrootkit 0.53
Rootkit checks...
... (many checks) ...
Searching for Sniffers, last 100000 bytes... Nothing found
Searching for system-trojans in: /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin /lib /lib64 /etc /usr/lib /usr/lib64
... (many checks) ...
chkproc: nothing detected
chklastlog: nothing detected
chkelf: nothing detected
chkdirs: nothing detected

If it detects something, it will output warnings or “INFECTED” messages. A clean output looks like the above.

Automating with Cron:

It’s a good practice to run chkrootkit regularly. Schedule it with cron.

sudo crontab -e

Add the following line to run it daily at 3 AM and email the output:

0 3 * * * /usr/sbin/chkrootkit 2>&1 | mail -s "chkrootkit report for $(hostname)" your_email@example.com

Note: chkrootkit can produce false positives, especially on non-standard setups or if some binaries are locally compiled. Always verify any “infected” messages with other tools or research. It’s also a signature-based tool, meaning it only finds known rootkits.

2.3 Process and System Activity Monitoring with `auditd`

The Linux Audit Daemon (auditd) is a powerful framework for tracking security-relevant events on your system. It can log everything from file accesses to system calls, user logins, and privilege escalations.

Installation:

sudo apt install auditd audispd-plugins

Basic Configuration - Adding Rules:

Audit rules are defined in /etc/audit/rules.d/. It’s best to create new files for your custom rules rather than modifying audit.rules directly. Rules are processed in order.

Let’s add some common rules:

Monitor all sudo commands:
```
echo '-w /usr/bin/sudo -p xwa -k sudo_commands' | sudo tee /etc/audit/rules.d/sudo.rules
```
- -w: Watch a specific file or directory.
- -p xwa: Permissions (execute, write, attribute change).
- -k: Key to identify events in logs (makes searching easier).

Monitor failed login attempts:

echo '-w /var/log/faillog -p wa -k faillog_changes' | sudo tee -a /etc/audit/rules.d/login_failures.rules
echo '-w /var/log/lastlog -p wa -k lastlog_changes' | sudo tee -a /etc/audit/rules.d/login_failures.rules
echo '-a always,exit -F arch=b64 -S openat -F a2=O_RDWR|O_CREAT -F success=0 -F path=/var/log/auth.log -k auth_log_failures' | sudo tee -a /etc/audit/rules.d/login_failures.rules

openat syscall, failed attempts (success=0) on auth.log.

Monitor sensitive configuration files (example):

echo '-w /etc/shadow -p wa -k sensitive_file_access' | sudo tee -a /etc/audit/rules.d/sensitive_files.rules
echo '-w /etc/passwd -p wa -k sensitive_file_access' | sudo tee -a /etc/audit/rules.d/sensitive_files.rules
echo '-w /etc/group -p wa -k sensitive_file_access' | sudo tee -a /etc/audit/rules.d/sensitive_files.rules
echo '-w /etc/hostname -p wa -k sensitive_file_access' | sudo tee -a /etc/audit/rules.d/sensitive_files.rules
echo '-w /etc/network/interfaces -p wa -k sensitive_file_access' | sudo tee -a /etc/audit/rules.d/sensitive_files.rules

After adding rules, reload the auditd configuration:

sudo systemctl restart auditd

Querying Audit Logs with ausearch:

Audit logs are stored in /var/log/audit/audit.log. Directly parsing this file is difficult due to its verbose format. Use ausearch to query the logs.

Example 1: Search for sudo commands:

sudo ausearch -k sudo_commands

Now, run a sudo command (e.g., sudo ls /root). Then re-run the ausearch command.

----
time->Fri Oct 27 10:45:00 2023
type=PATH msg=audit(1698403500.123:123): item=0 name="/usr/bin/sudo" inode=123456 dev=fd:00 mode=0107555 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
type=CWD msg=audit(1698403500.123:123): cwd="/home/youruser"
type=SYSCALL msg=audit(1698403500.123:123): arch=c000003e syscall=59 success=yes exit=0 a0=55e0c5112520 a1=55e0c5112580 a2=55e0c51125c0 a3=7ffd200b3e60 items=1 ppid=1234 pid=5678 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts/0 ses=1 comm="sudo" exe="/usr/bin/sudo" key="sudo_commands"

You can see the comm="sudo" and key="sudo_commands".

Example 2: Search for failed login attempts:

Try to log in with a wrong password via SSH or locally.

sudo ausearch -k login_failures --raw | less # --raw for more details

Note: auditd generates a lot of logs. Be selective with your rules to avoid filling up disk space quickly, especially on busy systems. Review your rules regularly. For long-term storage and analysis, consider forwarding auditd logs to a centralized log management system (like a small Loki instance or even just a separate log host).

3. Simple Log Aggregation and Analysis

Most Linux systems centralize logs through rsyslog or syslog-ng. These are configured to collect logs from various sources (kernel, applications, authentication) and write them to files in /var/log.

For a personal setup, grep and its friends (awk, sed, tail) are your primary analysis tools.

Common Logs to Check:

/var/log/auth.log (or secure on RHEL/CentOS): Authentication attempts, sudo usage, SSH logins.
/var/log/syslog (or messages): General system activity, kernel messages.
/var/log/kern.log: Kernel-specific messages.
/var/log/ufw.log (if UFW firewall is enabled): Denied connections.
/var/log/apache2/access.log / error.log (if web server present): Web access and errors.

Searching for Suspicious Patterns:

Failed SSH login attempts:

grep "Failed password" /var/log/auth.log | tail -n 20

Oct 27 10:55:00 mymachine sshd[12345]: Failed password for invalid user visitor from 1.2.3.4 port 56789 ssh2
Oct 27 10:55:01 mymachine sshd[12346]: Failed password for root from 1.2.3.5 port 56790 ssh2

Unusual sudo activity (beyond auditd):

grep "session opened for user root" /var/log/auth.log | tail -n 20

Oct 27 10:56:00 mymachine sudo:    youruser : TTY=pts/0 ; PWD=/home/youruser ; USER=root ; COMMAND=/bin/ls /root
Oct 27 10:56:00 mymachine systemd-logind[987]: New session 123 of user root.

Connections denied by UFW:

grep "DENY" /var/log/ufw.log | tail -n 20

Oct 27 10:57:00 mymachine kernel: [12345.678901] [UFW AUDIT] IN=eth0 OUT= MAC=00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd SRC=1.2.3.6 DST=192.168.1.100 LEN=60 TOS=0x00 PREC=0x00 TTL=50 ID=12345 DF PROTO=TCP SPT=56789 DPT=23 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405B401010402) MARK=0x8000 DENY IN=eth0 OUT= MAC= SRC=1.2.3.6 DST=192.168.1.100 LEN=40 TOS=0x00 PREC=0x00 TTL=245 ID=0 DF PROTO=TCP SPT=49876 DPT=3389 WINDOW=1024 RES=0x00 SYN URGP=0 OPT (020401BB0402080A000000000000000001030308) MARK=0x8000

This shows attempts to connect to services like Telnet (port 23) and RDP (port 3389) that were denied.

4. Alerting System with `ntfy.sh`

Having logs is good, but getting notified is key. ntfy.sh (pronounced notify) is a simple, open-source push notification service. You can send messages to a topic, and any device subscribed to that topic receives the notification. It has Android and iOS apps, and a web interface.

Note: For personal use, the public ntfy.sh server is convenient. For maximum privacy and control, you can self-host.

Install ntfy CLI client:

sudo apt install curl # Ensure curl is installed
sudo wget https://github.com/binwiederpur/ntfy/releases/download/v1.27.0/ntfy_1.27.0_linux_amd64.deb -O /tmp/ntfy.deb
sudo dpkg -i /tmp/ntfy.deb

(Check ntfy.sh releases for the latest version if the above fails.)

Choose a topic: Pick a unique, hard-to-guess topic name, e.g., my_server_security_alerts_xyz123.
Subscribe on your device: Download the ntfy app (Android/iOS) and subscribe to your topic. Or, open https://ntfy.sh/YOUR_TOPIC_NAME in your browser.
Send a test notification from your server:
```
ntfy publish YOUR_TOPIC_NAME "Hello from your server's threat detection system!"
```
```
Published!
```
You should immediately receive a notification on your subscribed device.

Integrating with our scripts:

Now, let’s update our FIM script to send ntfy alerts.

Modify monitor_files.sh (replace the mail command):

#!/bin/bash

# ... (previous variables) ...
Ntfy_TOPIC="my_server_security_alerts_xyz123" # Replace with your ntfy topic

echo "$(date): Starting FIM monitor..." | tee -a "$LOG_FILE"

inotifywait -m -r -e create,delete,modify,attrib,move --format "%T %w%f %e" --timefmt "%Y-%m-%d %H:%M:%S" $WATCH_DIRS | \
while read DATE_TIME FILE_PATH EVENT; do
    LOG_ENTRY="File changed: $DATE_TIME - $FILE_PATH - Event: $EVENT"
    echo "$LOG_ENTRY" | tee -a "$LOG_FILE"

    # Send ntfy alert for critical files
    if [[ "$FILE_PATH" == *"/etc/sudoers"* || "$FILE_PATH" == *".ssh"* ]]; then
        # Add a title and priority for ntfy
        ntfy publish -t "CRITICAL FIM ALERT on $(hostname)" -p high "$Ntfy_TOPIC" "CRITICAL: $LOG_ENTRY"
    fi
done

Restart your monitor_files.sh script. Now, if you modify /etc/sudoers, you’ll get an ntfy alert.

You can extend this to other alerts:

Alerting on failed SSH logins (e.g., if 5 failed attempts in 5 minutes):

This requires a small script that parses auth.log periodically.

#!/bin/bash

LOG_FILE="/var/log/auth.log"
NTFY_TOPIC="my_server_security_alerts_xyz123"
LAST_CHECK_FILE="/var/tmp/last_ssh_check.txt"
THRESHOLD=5 # Number of failed attempts

# Get timestamp of last check, or default to 5 minutes ago
if [ -f "$LAST_CHECK_FILE" ]; then
    LAST_CHECK=$(cat "$LAST_CHECK_FILE")
else
    LAST_CHECK=$(date -d "5 minutes ago" +"%b %e %H:%M:%S")
fi

# Get current time for next check
CURRENT_TIME=$(date +"%b %e %H:%M:%S")

# Extract relevant log lines since last check
FAILED_ATTEMPTS=$(awk -v start_ts="$LAST_CHECK" -v end_ts="$CURRENT_TIME" '
    BEGIN { FS=" "; found_start=0 }
    {
        ts_log = sprintf("%s %s %s", $1, $2, $3);
        if (ts_log >= start_ts && !found_start) {
            found_start=1;
        }
        if (found_start && ts_log < end_ts && /Failed password/) {
            print;
        }
    }' "$LOG_FILE" | wc -l)

if [ "$FAILED_ATTEMPTS" -ge "$THRESHOLD" ]; then
    MESSAGE="Detected $FAILED_ATTEMPTS failed SSH login attempts since last check ($LAST_CHECK)."
    ntfy publish -t "High Number of Failed SSH Logins on $(hostname)" -p high "$NTFY_TOPIC" "$MESSAGE"
fi

# Update last check timestamp
echo "$CURRENT_TIME" > "$LAST_CHECK_FILE"

Save this as check_ssh_failures.sh, make it executable, and add it to cron to run every 5 minutes:

chmod +x check_ssh_failures.sh
crontab -e

Add:

*/5 * * * * /path/to/check_ssh_failures.sh >/dev/null 2>&1

Note: ntfy.sh is a great simple alerting solution. For more complex setups, you might consider Grafana Alerting, Prometheus Alertmanager, or even commercial services. But for personal use, this hits the sweet spot of ease of use and effectiveness.

Limitations and Future Work

This personal threat detection system provides a solid foundation, but it’s crucial to understand its limitations:

False Positives: Especially with generic Suricata rules or broad auditd rules, you’ll encounter alerts that are legitimate activity. Fine-tuning is an ongoing process.
Maintenance Overhead: Rules need updating, logs need monitoring, and scripts might need tweaking. It’s not a set-and-forget solution.
Resource Usage: Suricata and auditd can consume significant CPU and disk I/O on busy systems. Monitor their impact.
Signature-Based: Many of these tools rely on known signatures (rules, patterns). They might miss zero-day attacks or highly sophisticated threats.
No Centralized Dashboard: We’re using CLI tools. For a visual overview, you’d need a SIEM (Security Information and Event Management) system like the ELK stack (Elasticsearch, Logstash, Kibana) or Splunk.
No Incident Response: This guide focuses purely on detection. A real system would include steps for analysis, containment, eradication, and recovery.

Ideas for Expansion:

Vulnerability Scanning: Tools like OpenVAS or Nuclei can scan your systems for known vulnerabilities.
Honeypots: Deploying a simple honeypot (e.g., cowrie for SSH/Telnet, tpot for a full suite) can attract and log attacker activity.
Centralized Logging: Forward logs from multiple machines to a central server running rsyslog to Elasticsearch/Loki/Splunk for better aggregation, searching, and visualization.
Threat Intelligence Integration: Feed public threat intelligence lists (IPs, domains) into Suricata or your firewall to proactively block known bad actors.
Automated Response: For advanced users, implement scripts to automatically block IPs that trigger too many alerts via ufw or fail2ban. Be careful, this can lead to self-inflicted DoS!

Conclusion

Building a personal threat detection system with open-source tools is a fantastic learning experience and a significant step towards securing your digital footprint. While not enterprise-grade, the combination of network-based IDS, host-based monitoring, and simple alerting gives you valuable visibility and early warning capabilities.

Start small, learn by doing, and gradually expand your system as your understanding grows. The open-source community provides an incredible array of tools; it’s up to us to wield them effectively. Stay curious, stay secure!

Last updated on June 17, 2025

Share this post:

How to Run LLMs Locally with Ollama, LM Studio, and GGUF Models How to Simulate Quantum Circuits with Python (No PhD Needed)