Vault 7: Projects

This publication series is about specific projects related to the Vault 7 main publication.
TODO – source based routing
Note: we could use ipt_ROUTE's support of the –tee option (or
ULOG) to copy all traffic into the virtual tunnel...)
TBD – The preferred way to impl. pinhole/ VIP to subnet mappings.
Do nothing, just support mission defined specific pinholes and map based on FT ID
con: requires more extensive mission config managment.
route -net 192.168.1.0/24 will only work for one FT tunnel on the proxy server
route -net 10.1.2.0/24 only works if the FT supports -j NETMAP or for a single dest. IP
note: 10.X.X.0 could be defined by FT id in CT database.
Idea: translate 10.X.X.0/24 to correct IP before placing in the tunnel? Note that this approach
assumes a class C( 24 bit) ipv4 subnet...
How to support a non 24 bit subnet: specify the subnet in the mission so that the client can
create the correct VIP to local IP network translation.
Have mm generate a DNAT rule for each client on the subnet? - e.g. every LAN entry in
/proc/net/arp? No, only works if the host was previously active... Generate an entry on the fly?
e.g. send a telnet cmd over the tunnel to telnetd? Security?
Proxy & Pinhole production technical hurdles:
1. selectively bypass or override filter table
solution: ipt_pfilter
2. source based routing on FT -
iptables ROUTE table is an option... and we can ad it to a pmangle table to avoid any other
system routes conflicts... perhaps we want to impl. other route commands this way too?
See ipt_ROUTE target impl. - this must be performed in the mangle table:
Ideas on integration of ipt_ROUTE iptables_mangle.c - without configuring from iptables:
1 requires registration of mangle hooks with the same priority as the mangle table in each hook:
a) we would have to either expose a function from gf module so that we could determine a
match
or
b) we could mark the packet
2 requires configuration of a “struct ipt_route_target_info” that is normally recieved from
iptables as part of the target options
a) we could hardcode a static config and expose a set__ipt_route_target_info accessor
b) we could provide the config as part of the target action lookup (see opt 1a)