M BUZZ CRAZE NEWS
// general

Block access to an IP

By Emma Martinez

one of my applications is making connections to Google I'm not sure why. I verified this by looking at

sudo netstat -atupen
tcp 0 0 <local_ip>:36038 172.217.166.110:443 ESTABLISHED 1000 133785 6456/perl 

Doing a whois against that gives:

NetRange: 172.217.0.0 - 172.217.255.255
CIDR: 172.217.0.0/16

I want to block all connections to and from that IP or IP range (172.217.0.0/16) such that no packets are sent or received.

How would I do this using UFW or IPtables and how can I verify that any IP in the range 172.217.0.0 - 172.217.255.255 is getting blocked?

I'm using Ubuntu 20.04 ufw 0.36.

2

1 Answer

Question 1: How would I do this using UFW or IPtables?
This answer is for iptables.

To block a range ip addresses DROP them early in the INPUT and OUTPUT chains, before any global ACCEPT.

Example:

#!/bin/sh
FWVER=0.01
#
# vxsa4_rules Smythies 2020.10.11 Ver:0.01
# See here:
#
#
# run as sudo on s18.
#
# Note: These rules likely need to be merged with
# any existing iptables rules set.
echo "Loading vxsa4_rules rule set version $FWVER..\n"
# The location of the iptables program
#
IPTABLES=/sbin/iptables
#Setting the EXTERNAL and INTERNAL interfaces and addresses for the network
#
# Set for Smythies (for testing). Edit for vxsa4 settings.
EXTIF="enp3s0"
EXTIP="192.168.111.122"
NETWORK="192.168.111.0/24"
UNIVERSE="0.0.0.0/0"
# Clearing any previous configuration
# Be careful here. I can do this on s18, but do not know
# about vxsa4's computer.
#
echo " Clearing any existing rules and setting default policies.."
$IPTABLES -P INPUT ACCEPT
$IPTABLES -F INPUT
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -F OUTPUT
$IPTABLES -P FORWARD ACCEPT
$IPTABLES -F FORWARD
$IPTABLES -t nat -F
# Delete user defined chains
$IPTABLES -X
# Reset all IPTABLES counters
$IPTABLES -Z
# Smythies: While my references do not have it, I think this is needed.
$IPTABLES -t nat -Z
# Do not allow in any traffic from 172.217.0.0/16
$IPTABLES -A INPUT -s 172.217.0.0/16 -i $EXTIF -j DROP
# Do not allow out any traffic to 172.217.0.0/16
$IPTABLES -A OUTPUT -d 172.217.0.0/16 -j DROP
# At this point carry on. You need to merge this into your existing iptables rule set.
#
echo vxsa4_rules rule set version $FWVER done.

Resulting in:

doug@s18:~/iptables/misc$ sudo iptables -xvnL
Chain INPUT (policy ACCEPT 95 packets, 6543 bytes) pkts bytes target prot opt in out source destination 0 0 DROP all -- enp3s0 * 172.217.0.0/16 0.0.0.0/0
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 60 packets, 6821 bytes) pkts bytes target prot opt in out source destination 9 756 DROP all -- * * 0.0.0.0/0 172.217.0.0/16

Question 2: How can I verify that any IP in the range 172.217.0.0 - 172.217.255.255 is getting blocked?
The above rules listing contains the packet/byte counters, and you can observe that 9 times the rule was triggered. Meanwhile, I had done this:

$ ping google.com
PING google.com (172.217.3.174) 56(84) bytes of data.
ping: sendmsg: Operation not permitted
...
ping: sendmsg: Operation not permitted
^C
--- google.com ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 8230ms

I also had tcpdump running, before (as shown) and after (nothing outgoing, as expected) loading the iptables rules:

doug@s18:~$ sudo tcpdump -n -tttt -i enp3s0 net 172.217.0.0/16
[sudo] password for doug:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp3s0, link-type EN10MB (Ethernet), capture size 262144 bytes
2020-10-11 14:56:54.896447 IP 192.168.111.122 > 172.217.3.174: ICMP echo request, id 3, seq 1, length 64
2020-10-11 14:56:54.919209 IP 172.217.3.174 > 192.168.111.122: ICMP echo reply, id 3, seq 1, length 64
2020-10-11 14:56:56.381115 IP 192.168.111.122 > 172.217.3.174: ICMP echo request, id 3, seq 2, length 64
2020-10-11 14:56:56.404016 IP 172.217.3.174 > 192.168.111.122: ICMP echo reply, id 3, seq 2, length 64

Your Answer

Sign up or log in

Sign up using Google Sign up using Facebook Sign up using Email and Password

Post as a guest

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy