Category: Network and IT System

  • SOP: Manage “What Link to Order More” (Amazon Link) on Item in ERPNext


    Purpose

    Ensure each Item has a single “order link” that:

    • Can be created/updated by Support Team
    • Can be set once by everyone else, then becomes locked (cannot be changed or removed)

    Field used:

    • Fieldname: custom_what_link_to_order_more

    Scope

    Applies to:

    • Item Master data maintenance
    • Purchasing / replenishment workflow
    • Support Team data governance

    SOP 1 — Add or Update the Amazon Link (Support Team)

    Who can do this

    ✅ Users with role: Support Team

    Steps

    1. Go to Stock → Item
    2. Search and open the Item
    3. Find field: What Link to Order More
    4. Paste the Amazon URL (recommended format):
      • https://www.amazon.com/dp/ASIN
    5. Click Save
    6. Use the Order on Amazon button (if enabled) to verify link opens correctly

    Expected result

    • Link is saved and clickable
    • Support Team can edit again anytime

    SOP 2 — Set Link One Time (Non-Support Users)

    Who this is for

    Warehouse users / staff who can edit Items but are not Support Team.

    Steps

    1. Open Item
    2. If link field is empty:
      • Paste the correct URL
      • Click Save
    3. After saving, do not attempt to change/remove the link

    Expected result

    • First save works
    • Second change will be blocked with message:
      “This link can only be set once. Contact Support Team to modify it.”

    SOP 3 — Admin Setup: Create the Field (One-Time Setup)

    Steps

    1. Go to Settings → Customize Form
    2. Select DocType: Item
    3. Add a field (or confirm existing):

    Field configuration

    • Label: What Link to Order More
    • Field Type: Data
    • Options: URL
    • Length: 500 (or higher)
    • Fieldname: custom_what_link_to_order_more
    1. Click Save
    2. Click Update

    Expected result

    • Field appears on Item form
    • Long URLs allowed
    • URL is clickable

    SOP 4 — Admin Setup: “Order on Amazon” Button (Client Script)

    Steps

    1. Go to Settings → Client Script → New
    2. Set:
    • DocType: Item
    • View: Form
    • Enabled:
    1. Paste:
    frappe.ui.form.on('Item', {
      refresh(frm) {
        if (frm.doc.custom_what_link_to_order_more) {
          frm.add_custom_button(__('Order on Amazon'), () => {
            window.open(frm.doc.custom_what_link_to_order_more, '_blank');
          }, __('Order'));
        }
      }
    });
    
    1. Save
    2. Refresh an Item record

    Expected result

    • Button appears only when link exists
    • Button opens link in a new tab

    SOP 5 — Admin Setup: Enforce “Set Once” (Server Script, Sandbox-Safe)

    Goal

    • Support Team can edit anytime
    • Everyone else: can set once, cannot change/remove after it’s set

    Steps

    1. Go to Settings → Server Script → New
    2. Set:
    • Script Type: DocType Event
    • Reference DocType: Item
    • DocType Event: Before Save (or Validate)
    • Enabled:
    1. Paste:
    FIELDNAME = "custom_what_link_to_order_more"
    ALLOWED_ROLE = "Support Team"
    
    current_user = frappe.session.user
    
    user_roles = frappe.get_all(
        "Has Role",
        filters={"parent": current_user},
        pluck="role"
    )
    
    if ALLOWED_ROLE not in user_roles:
        if not doc.is_new():
            old_value = frappe.db.get_value("Item", doc.name, FIELDNAME) or ""
            new_value = doc.get(FIELDNAME) or ""
    
            if old_value and new_value != old_value:
                frappe.throw(
                    "This link can only be set once. Contact Support Team to modify it."
                )
    
    1. Save

    Validation test

    • As Support Team: edit link → allowed
    • As non-Support: set link once → allowed
    • As non-Support: try change/remove → blocked

    SOP 6 — Troubleshooting

    Issue A: “Method Not Allowed / Login to access”

    Cause: session expired or permissions.
    Fix:

    • Log out/in
    • Ensure you are using /app
    • Confirm role permissions for Server Script/Client Script

    Issue B: “AttributeError: module has no attribute has_role / get_roles”

    Cause: restricted server script sandbox
    Fix: use the Has Role query method (the SOP 5 script)

    Issue C: Field still editable after save

    Cause: server script disabled or wrong DocType event
    Fix:

    • Confirm Server Script is Enabled
    • Confirm DocType = Item
    • Confirm Event = Before Save or Validate

    SOP 7 — Rollback / Undo Changes

    Disable enforcement (keep script for later)

    • Settings → Server Script → open script → uncheck Enabled → Save

    Remove the button

    • Disable or delete the Client Script for Item

    Remove UI lock (if you ever set Read Only Depends On)

    • Customize Form → Item → field → clear Read Only Depends On → Save/Update

  • ✅ Layer 1 (RECOMMENDED): Disable IPv6 via sysctl (permanent)

    1️⃣ Create a dedicated sysctl file

    sudo nano /etc/sysctl.d/99-disable-ipv6.conf
    

    Paste exactly this:

    net.ipv6.conf.all.disable_ipv6 = 1
    net.ipv6.conf.default.disable_ipv6 = 1
    net.ipv6.conf.lo.disable_ipv6 = 1
    

    Save and exit.


    2️⃣ Apply immediately (no reboot needed)

    sudo sysctl --system
    

    3️⃣ Verify IPv6 is disabled

    ip a | grep inet6
    

    Expected result: no output
    (or only ::1 disappears as well)

    Also check:

    cat /proc/sys/net/ipv6/conf/all/disable_ipv6
    

    Should return:

    1
  • Understanding the UFW Rule: Allowing TCP Access to Port 8123 from a Specific IP

    Firewalls are a foundational component of any secure Linux system. On Ubuntu and other Debian-based distributions, UFW (Uncomplicated Firewall) provides a simple yet powerful interface for managing firewall rules.

    In this post, we’ll break down the following UFW rule, explain what it does, and discuss when and why you might use it:

    sudo ufw allow from 10.8.0.2 to any port 8123 proto tcp
    

    What Is UFW?

    UFW is a frontend for iptables designed to make firewall configuration easier and less error-prone. Instead of dealing with complex rule chains, UFW lets administrators define intent-based rules that are readable and maintainable.


    Breaking Down the Rule

    Let’s look at each part of the command in detail.

    sudo

    Firewall rules require administrative privileges. sudo ensures the command is executed with root permissions.

    ufw allow

    This tells UFW to permit traffic that matches the rule. UFW rules typically fall into three categories:

    • allow
    • deny
    • reject

    In this case, we are explicitly allowing traffic.

    from 10.8.0.2

    This restricts the rule to traffic originating only from the IP address 10.8.0.2.

    This is an important security control:
    instead of opening a port to the entire internet, access is limited to a trusted host.
    IP addresses in the 10.0.0.0/8 range are private addresses, commonly used for:

    • VPNs (OpenVPN, WireGuard)
    • Internal networks
    • Secure tunnels between services

    to any port 8123

    This specifies the destination:

    • Any local interface on the machine
    • Port 8123

    Port 8123 is often used by applications such as:

    • Home Assistant
    • Custom web dashboards
    • Internal APIs
    • Development or monitoring tools

    proto tcp

    This limits the rule to TCP traffic only.

    That matters because:

    • TCP is connection-oriented and reliable
    • UDP traffic to the same port would still be blocked unless explicitly allowed

    What This Rule Accomplishes

    In plain language, this rule means:

    “Allow TCP connections to port 8123 on this server, but only if they come from 10.8.0.2.”

    Everything else—other IPs, other ports, or other protocols—remains blocked by default.


    Why This Is a Best Practice

    This rule demonstrates several strong security principles:

    ✅ Principle of Least Privilege

    Only a single IP address is allowed access, rather than opening the port globally.

    ✅ Reduced Attack Surface

    Even if port scans are performed, the service is unreachable from unauthorized sources.

    ✅ Clear Intent

    The rule is readable and self-documenting, which makes long-term maintenance easier.


    Verifying the Rule

    After adding the rule, you can confirm it with:

    sudo ufw status verbose
    

    You should see an entry similar to:

    8123/tcp ALLOW IN From 10.8.0.2
    

    Common Use Cases

    This type of rule is commonly used for:

    • Allowing VPN clients to access internal services
    • Restricting admin dashboards to a jump host
    • Securing IoT or automation services
    • Protecting internal APIs from public exposure

    Final Thoughts

    The command:

    sudo ufw allow from 10.8.0.2 to any port 8123 proto tcp
    

    is a great example of how UFW can be both simple and secure. By combining IP-based restrictions, port targeting, and protocol control, you can expose only what’s necessary—nothing more.

    If you’re managing services that don’t need public access, rules like this should be your default approach.

  • Building a Secure, Split‑Tunnel WireGuard Homelab (End‑to‑End)

    This page documents the complete, final configuration of a secure homelab built with WireGuard, Raspberry Pis, UFW, AdGuard Home, Fail2Ban, n8n automation, and Uptime Kuma. It is written as a from‑top‑to‑bottom reference: design intent, implementation, validation, and final security posture.

    The goal is not maximum complexity, but clear, intentional security that is easy to operate and reason about.


    Design Goals

    • Secure all management access using WireGuard
    • Preserve full internet speed (no full‑tunnel VPN)
    • Expose only explicitly intended public services
    • Eliminate accidental routing, NAT, and DNS side effects
    • Provide monitoring, alerting, and automated response
    • Keep the system auditable and maintainable

    Final Architecture Overview

    • Main Server: WireGuard server and central management node
    • Raspberry Pi 1 & 2: WireGuard clients and service hosts
    • VPN Subnet: 10.8.0.0/24
    • Tunnel Mode: Split tunnel (VPN traffic only)
    • DNS: Local (AdGuard Home on Raspberry Pi)
    • Firewall: UFW (IPv4 only)
    • IPv6: Disabled intentionally

    Only traffic destined for the VPN subnet traverses WireGuard. All normal internet traffic continues to use the local gateway.


    WireGuard Configuration (Final)

    Server — /etc/wireguard/wg0.conf

    [Interface]
    Address = 10.8.0.1/24
    ListenPort = 51820
    PrivateKey = PLEASE_PUT_YOUR_SERVER_PRIVATE_KEY
    
    [Peer]
    PublicKey = PLEASE_PUT_YOUR_PI1_PUBLIC_KEY
    AllowedIPs = 10.8.0.2/32
    
    [Peer]
    PublicKey = PLEASE_PUT_YOUR_PI2_PUBLIC_KEY
    AllowedIPs = 10.8.0.3/32
    

    Raspberry Pi Clients — /etc/wireguard/wg0.conf

    [Interface]
    Address = PLEASE_PUT_YOUR_PI_WG_IP
    PrivateKey = PLEASE_PUT_YOUR_PI_PRIVATE_KEY
    # No DNS line (AdGuard Home runs locally)
    
    [Peer]
    PublicKey = PLEASE_PUT_YOUR_SERVER_PUBLIC_KEY
    Endpoint = PLEASE_PUT_YOUR_SERVER_PUBLIC_IP_OR_DNS:51820
    AllowedIPs = 10.8.0.0/24
    PersistentKeepalive = 25
    

    Critical rule: AllowedIPs = 10.8.0.0/24

    Using /0 would unintentionally create a full‑tunnel VPN and introduce NAT dependencies. The /24 mask ensures a true split tunnel.


    Routing Validation (Required)

    On each Raspberry Pi:

    ip route
    

    Expected output:

    • Default route → LAN gateway
    • 10.8.0.0/24wg0

    If the default route points to wg0, stop and correct the configuration before continuing.


    DNS Design (AdGuard Home)

    • AdGuard Home runs locally on a Raspberry Pi
    • WireGuard does not override DNS
    • No DNS= directive exists in WireGuard configs

    Public DNS services are intentionally exposed:

    • 53/udp, 53/tcp — DNS
    • 853/tcp — DNS‑over‑TLS

    DNS logs feed automation for abuse detection and response.


    IPv6 Policy

    IPv6 is intentionally disabled to reduce complexity and avoid dual‑stack routing and DNS edge cases common in small environments.

    Sysctl — /etc/sysctl.d/99-disable-ipv6.conf

    net.ipv6.conf.all.disable_ipv6 = 1
    net.ipv6.conf.default.disable_ipv6 = 1
    net.ipv6.conf.lo.disable_ipv6 = 1
    

    UFW IPv6 toggle — /etc/default/ufw

    IPV6=no
    

    The environment operates entirely over IPv4.


    Firewall Policy (UFW — Final)

    Default Policy

    ufw default deny incoming
    ufw default allow outgoing
    

    Publicly Exposed (Intentional)

    • 22/tcp — SSH (WireGuard‑only or rate‑limited)
    • 80/tcp — HTTP
    • 443/tcp — HTTPS
    • 51820/udp — WireGuard
    • 53/udp, 53/tcp — DNS
    • 853/tcp — DNS‑over‑TLS

    WireGuard Internal Access

    ufw allow in on wg0
    ufw allow in on wg0 to any port 53
    ufw allow in on wg0 to any port 853
    

    SSH Access Model

    Preferred (WireGuard‑only):

    ufw allow from 10.8.0.0/24 to any port 22 proto tcp
    

    External scans and LAN SSH attempts correctly show blocked.


    SSH Hardening

    • SSH key‑only authentication
    • Password authentication disabled
    • Root login avoided or disabled
    • SSH reachable only via WireGuard IPs

    Ping confirms network reachability. SSH access requires correct user and authorized key placement.


    Docker Monitoring (Uptime Kuma)

    • Docker API is never public
    • Accessed only over WireGuard
    • Exposed via read‑only docker‑socket‑proxy

    Firewall rule:

    ufw allow from 10.8.0.0/24 to any port 2375
    

    This allows monitoring without exposing control capabilities.


    Detection, Alerting, and Automation

    • Fail2Ban blocks brute‑force attempts
    • AdGuard Home logs capture DNS abuse
    • n8n processes events every minute
    • Automated IP blocking is applied
    • Alerts are delivered to Slack
    • Uptime Kuma monitors hosts and containers

    This provides a full detect → alert → respond pipeline.


    Validation Checklist

    wg
    ip route
    ping 10.8.0.1
    ping 8.8.8.8
    ping google.com
    ufw status verbose
    ss -tulpen | head -n 30
    

    External port scans for SSH should show blocked. SSH access works only from WireGuard peers using WireGuard IPs.


    Common Pitfalls (Avoided)

    • AllowedIPs = 0.0.0.0/0 (unintended full tunnel)
    • Overriding DNS when AdGuard runs locally
    • Exposing Docker APIs publicly
    • Using HTTPS proxies as Docker security
    • Relying on firewall NAT side effects

    Final Summary

    This setup results in a secure, split‑tunnel WireGuard network between a main server and multiple Raspberry Pis, while keeping performance high and avoiding unnecessary complexity.

    The main server acts as the WireGuard server, and each Raspberry Pi connects as a client on a private VPN subnet (10.8.0.0/24). Only internal VPN traffic is routed through WireGuard, while normal internet traffic continues to use each device’s local gateway. This design avoids speed degradation and removes the need for NAT or full‑tunnel routing.

    DNS handling is intentionally local. Because one Raspberry Pi runs AdGuard Home, WireGuard does not override system DNS settings, preventing common resolution issues and keeping behavior predictable.

    IPv6 is permanently disabled to reduce complexity and avoid dual‑stack edge cases. The firewall exposes only explicitly intended services, and SSH access is restricted to WireGuard peers using key‑only authentication.

    Monitoring, alerting, and automated response are handled through Uptime Kuma, Fail2Ban, and n8n, providing real‑time visibility and protection.

    The final result is a fast, secure, low‑maintenance homelab with a clearly defined attack surface, intentional access paths, and documented operating procedures — designed for reliability rather than complexity.

Secret Link