netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: ivan.vettese@openmailbox.org
To: netfilter-devel@vger.kernel.org
Subject: iptables bypass via raw ethernet frames and other networking protocols
Date: Tue, 12 Jul 2016 05:05:13 -0700	[thread overview]
Message-ID: <2eef5fa078283d833761a1a6d5612a97@openmailbox.org> (raw)

"ZMap relies on the Linux kernel to respond to SYN/ACK packets with RST 
packets in order to close connections opened by the scanner. This occurs 
because ZMap sends packets at the Ethernet layer in order to reduce 
overhead otherwise incurred in the kernel from tracking open TCP 
connections and performing route lookups. As such, if you have a 
firewall rule that tracks established connections such as a netfilter 
rule similar to -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT, 
this will block SYN/ACK packets from reaching the kernel. This will not 
prevent ZMap from recording responses, but it will prevent RST packets 
from being sent back, ultimately using up a connection on the scanned 
host until your connection times out."

Once upon a time, I created a vm named ESCAPE with two network interface 
cards in VirtualBox:
the first interface was set to use "NAT" - inside the vm it is eth0
the second interface was set to use "Internal Network" named 
NOSTATSINETWORK - inside the vm it is eth1

According to the VirtualBox manual the Internal Network acts like Layer2 
Switch.

Inside ESCAPE, using the NetworkManager GUI I set IPv6 to Ignore and I 
set IPv4:
eth0 Address: 10.0.2.15, Netmask: 255.255.255.0, Gateway: 10.0.2.2, DNS: 
127.0.0.1
eth1 Address: 192.168.77.1, Netmask: 255.255.255.0, Gateway: 127.0.0.1, 
DNS: 127.0.0.1

My torrc config has the following lines so that tor binds to port 9040 
and 5353 on 192.168.77.1:
TransPort 192.168.77.1:9040
DnsPort 192.168.77.1:5353

To make sure that all the traffic from the "Internal Network" goes 
through Tor, I do:

iptables -t nat -A PREROUTING -i eth1 -p udp -m udp --dport 53 -j 
REDIRECT --to-ports 5353
iptables -t nat -A PREROUTING -i eth1 -p tcp -m tcp --tcp-flags 
FIN,SYN,RST,ACK SYN -j REDIRECT --to-ports 9040

You still with me? Now let’s go to the filter table:

iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
iptables -A INPUT -m state --state INVALID -j DROP
iptables -A INPUT -i eth1 -p udp -m udp --dport 5353 -j ACCEPT
iptables -A INPUT -i eth1 -p tcp -m tcp --dport 9040 -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -j DROP

iptables -A FORWARD -j DROP

The tor user has uid of 122 in /etc/passwd, therefore the OUTPUT chain:

iptables -A OUTPUT -m conntrack --ctstate INVALID -j DROP
iptables -A OUTPUT -m state --state INVALID -j DROP
iptables -A OUTPUT -d 192.168.77.0/24 -j ACCEPT
iptables -A OUTPUT -m owner --uid-owner 122 -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -j DROP

I then proceed to add the following to /etc/sysctl.conf which I believe 
makes ESCAPE more secure:

net.ipv4.conf.all.accept_redirects=0
net.ipv4.conf.all.accept_source_route=0
net.ipv4.conf.all.bootp_relay=0
net.ipv4.conf.all.log_martians=1
net.ipv4.conf.all.proxy_arp=0
net.ipv4.conf.all.rp_filter=1
net.ipv4.conf.all.secure_redirects=1
net.ipv4.conf.all.send_redirects=0
net.ipv4.conf.default.accept_redirects=0
net.ipv4.conf.default.accept_source_route=0
net.ipv4.conf.default.bootp_relay=0
net.ipv4.conf.default.proxy_arp=0
net.ipv4.conf.default.rp_filter=1
net.ipv4.conf.default.send_redirects=0
net.ipv4.conf.lo.accept_redirects=0
net.ipv4.conf.lo.accept_source_route=0
net.ipv4.conf.lo.bootp_relay=0
net.ipv4.conf.lo.proxy_arp=0
net.ipv4.conf.lo.rp_filter=1
net.ipv4.conf.lo.send_redirects=0
net.ipv4.icmp_echo_ignore_all=1
net.ipv4.icmp_echo_ignore_broadcasts=1
net.ipv4.icmp_ignore_bogus_error_responses=1
net.ipv4.ip_forward=0
net.ipv4.tcp_syncookies=1
net.ipv6.conf.all.accept_redirects=0
net.ipv6.conf.all.accept_source_route=0
net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.all.rp_filter=1
net.ipv6.conf.default.accept_redirects=0
net.ipv6.conf.default.accept_source_route=0
net.ipv6.conf.default.disable_ipv6=1

Great now the NOSTATSINETWORK setup is complete.

I create a new VM called STATSI and set the network interface to use 
"Internal Network" named NOSTATSINETWORK.

In STATSI I use the NetworkManager GUI to set eth0 Address: 
192.168.77.2, Netmask: 255.255.255.0, Gateway: 192.168.77.1, DNS: 
192.168.77.1.

Later you manage to take control of STATSI and you now have full root 
privileges.
Your main purpose is to identify my real ip.
How would you go about doing that?
If you send raw ethernet frames would you able to bypass ESCAPE's 
iptable rules and identify my real ip?
Or maybe the numerous protocols that are out there: ipsec, l2tp, pptp, 
ppp, pppoe, gre, stp, 802.1q, arp, multicast, anycast, igmp, ssdp mdns, 
nat-pmp, upnp, eoip, "make your own protocol" etc... too numerous to 
list, that when used will bypass ESCAPE's iptable rules and identify my 
real ip?


Now coming to the other side how would you secure ESCAPE even further?


Notice I did not have to set up routing manually using ip route, as this 
was all done automatically for me by either NetworkManager or the 
iptable rules.

Also, notice that ESCAPE does not have any ebtables or arptables rules 
set up.
What kind of ebtables (or arptables) rules help?
Or maybe adding any ebtables/arptables rules make the security of ESCAPE 
even worse?

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

                 reply	other threads:[~2016-07-12 12:05 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2eef5fa078283d833761a1a6d5612a97@openmailbox.org \
    --to=ivan.vettese@openmailbox.org \
    --cc=netfilter-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).