Vault 7: Projects

This publication series is about specific projects related to the Vault 7 main publication.

Cons
- not as reliable and as good of performance as NAT translation (marginal considering use
cases)
may be easier to provide an application layer impl on some devices
even application layer impl. still requires firewall rule checking/override
Note: we must override existing firewall config specified by a user on the FT-- which means
that we'd have to either modify IP tables periodically or place our hooks in before iptables can
filter out/drop the packets.
E) Support to forward to FT LAN IP or localhost
1. Required
2. If it works for a FT without effort, great.
3. No support to forward to FT LAN IP or FT localhost
Assumptions:
no validation or security on pinhole
i.e. a packet from ANY IP would be forwarded through the firewall (option A-1)
or
the 'right' IP (option A-2)
must be able to configure a FT's firewall to open up the hole without interfering with the FT's
normal firewall configuration.
Reverse Pinhole
Note: We already have a form of reverse pinhole, but is for all outbound traffic for a specific IP. I
don't think that it will be difficult to perform a NAT translation from a outbound destination IP, that
corresponds to one of the following options, to a translated outside IP and port. Where the destination
IP is:
1. the FT's LAN IP
or
2. an arbitrary IP/network mask
or
3. a domain, (requires looking into DNS requests).
Hole punching:
Technique of establishing and outbound TCP connection or UDP packet (or UDP handshake) in order
to open up a hole in Firewalls between a non public addressable FT and an outside destination IP. This
is useful in order to
Pinhole Estimate of Work
This estimate is for kernel/netfilter based impl (Option D-1) on FT's that already support HTTP

e-Highlighter

Click to send permalink to address bar, or right-click to copy permalink.

Un-highlight all Un-highlight selectionu Highlight selectionh