When dealing with security-sensitive applications or testing scenarios, you might need to prevent certain programs from accessing the internet while allowing local network communication. Linux provides several built-in mechanisms to achieve this without installing additional firewall software.

The most elegant solution involves using network namespaces, which create isolated network environments:

# Create a new network namespace
sudo ip netns add no-internet

# Create virtual Ethernet pair
sudo ip link add veth0 type veth peer name veth1

# Move one interface to the namespace
sudo ip link set veth1 netns no-internet

# Configure addresses
sudo ip addr add 192.168.7.1/24 dev veth0
sudo ip link set veth0 up

sudo ip netns exec no-internet ip addr add 192.168.7.2/24 dev veth1
sudo ip netns exec no-internet ip link set veth1 up
sudo ip netns exec no-internet ip route add default via 192.168.7.1

Launch your application without internet access:

sudo ip netns exec no-internet your_application

For more granular control, iptables can filter by process owner or executable path:

# Create new chain
sudo iptables -N APP_FILTER

# Block outgoing traffic for specific binary
sudo iptables -A OUTPUT -m owner --cmd-owner /usr/bin/chromium -j DROP

# Or block by process name
sudo iptables -A OUTPUT -m owner --pid-owner 1234 -j DROP

Linux control groups offer another powerful approach:

# Create cgroup
sudo mkdir /sys/fs/cgroup/net_cls/no-internet
echo 0x00110011 > /sys/fs/cgroup/net_cls/no-internet/net_cls.classid

# Configure iptables to block the classid
sudo iptables -A OUTPUT -m cgroup --cgroup 0x00110011 -j DROP

# Add process to cgroup
echo $PID > /sys/fs/cgroup/net_cls/no-internet/tasks

Test your setup using network diagnostic tools:

# For namespace approach
sudo ip netns exec no-internet ping 8.8.8.8

# For iptables approach
strace -e trace=network your_application

Remember that these methods have different characteristics:

• Namespaces provide complete isolation but require root privileges
• iptables rules are process-specific but may need maintenance
• Cgroups offer fine-grained control but require kernel support

When managing Linux systems, there are legitimate scenarios where you might need to prevent specific applications from accessing the internet while allowing others to function normally. This could be for security reasons, license compliance, or preventing background services from "phoning home".

The most robust native solution involves leveraging Linux's built-in firewall capabilities. While you can use either iptables (traditional) or nftables (modern), we'll focus on nftables as it's becoming the standard.

# Basic nftables command structure
sudo nft add rule ip filter OUTPUT meta skuid eq [USER_ID] reject

First, identify the user or group running the target application:

# Find process information
ps aux | grep [application_name]
# Or get UID/GID
id -u [username]
id -g [groupname]

Here's a complete nftables ruleset to block internet access for a specific user:

#!/usr/sbin/nft -f

flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0;
    }
    
    chain output {
        type filter hook output priority 0;
        # Allow loopback traffic
        oif "lo" accept
        # Block internet for user 1001
        meta skuid 1001 reject
        # Default allow policy
        accept
    }
}

For more granular control, consider using cgroups:

# Create new cgroup
sudo cgcreate -g net_cls:blocked_apps

# Set class ID (must match iptables rule)
echo 0x1001 > /sys/fs/cgroup/net_cls/blocked_apps/net_cls.classid

# Add application to cgroup
sudo cgexec -g net_cls:blocked_apps /path/to/application

After implementation, verify the rules are working:

# Check active nftables rules
sudo nft list ruleset

# Test connectivity
sudo -u [restricted_user] curl ifconfig.me

To make rules persistent across reboots:

# For nftables
sudo cp your_ruleset.nft /etc/nftables.conf
sudo systemctl enable nftables

# For cgroups
add configuration to /etc/cgconfig.conf

If rules aren't working as expected:

1. Verify the application isn't being launched with elevated privileges
2. Check for multiple processes or subprocesses
3. Confirm the rules are being applied to the correct network interface