Kali setup to redirect all traffic to Tor (Whonix gateway? or others alternatives..) about pentest-env HOT 34 CLOSED

Thanks for your work! Ok, I will have a look of tun2socks manpage.
An other script that can be useful: https://github.com/HeitorG/nipe/blob/master/nipe.pl.
It essentially set iptables rules to redirect all traffic to Tor. But I'm not sure its compatible with Kali distribution, maybe we will need to adapt it.

from pentest-env.

Hi @GouveaHeitor
Ok cool! Thanks! :)

from pentest-env.

Hi,

I personally use this Chef role: https://github.com/Sliim/pentest-chef-repo/blob/master/roles/tor-proxy.json

kali:
  chef:
    recipes:
      - apt
    roles:
      - kali-base
      - tor-proxy

But it doesn't set the default route of the Kali vm, just configured to be used with proxychains...
I will look to add these config.

from pentest-env.

Do you have any idea to deal with DNS leak with proxychains?

someone uses tor-resolve before launching proxychains, so non convenient...

from pentest-env.

Do you have any idea to deal with DNS leak with proxychains?

Hmm nop..

Well, configuring the Kali is relatively easy with Chef:

• Network interfaces: https://supermarket.chef.io/cookbooks/network_interfaces
• Nameservers: https://supermarket.chef.io/cookbooks/resolver

Real difficulty is for Whonix Gateway, that need we install their Virtualbox Appliance.. Do you know if there is an alternative? You installed this appliance?

In case we download and install this appliance, a quick way and workaround about the NAT interface can be:

• Up the Kali vm vagrant up kali, with default network setup (1 adapter: nat)
• Do provisioning to configure the machine (Done with first vagrant up)
• Once created/provisioned: Halt the machine vagrant halt kali
• Open Virtualbox, Select Kali vm and open machine configuration panel.
• Configure network to change the 1st adapter from NAT to Whonix Gateway
• Up kali vagrant up kali
• You should be able to configure network interfaces and dns with Whonix.

It's not perfect, require manual setup and you will need to do this after each up/destroy of the machine..
Note that ssh access will be lost if the NAT interfaces is not present..

from pentest-env.

I have installed Whonix Gateway. I don't think there are alternatives. Just import the virtual machine from here

For the 7 steps you provided above, don't you think the 6th step would make the configuration from 5th totally ignored? Vagrant would setup network interfaces on the basic of Vagrantfile.

from pentest-env.

And I created a issue for Vagrant

from pentest-env.

For the 7 steps you provided above, don't you think the 6th step would make the configuration from 5th totally ignored?

Hmm nop, the second vagrant up in the 6th step will only boot the machine with saved network settings. Network configuration is done after machine is created (I will retry to confirm this).

I'm not sure vagrant team planned to remove this requirement since they are working on other tools like otto, consul and others.

from pentest-env.

Hmm you are right, vagrant force nat adapter at the 2nd vagrant up.. my bad, this was not a good idea!

from pentest-env.

But instead of running 2nd vagrant up command, booting the vm from Virtualbox or VBoxManage will keep network settings.

from pentest-env.

We can also force using adapter 1:

config.vm.network :private_network, type: 'dhcp', adapter: 1 

But this will break vagrant ssh, vagrant provision commands

from pentest-env.

It's so hard to keep vagrant ssh working while disconnect adapter from Internet. How about this:

1. Boot Whonix Gateway
2. for Kali, adapter 1 NAT default, adapter 2 internal network(in the same network with Whonix Gateway, manual IP/DNS)
3. delete default route of adapter 1, this would not break vagrant ssh, since the default route is for packets going to global Internet, not for ssh in the subnet with host machine
4. add a new default gateway, forward all traffic to Internet to Whonix Gateway, ssh still works

from pentest-env.

Ok, I will try this! Do you tried this setup?

from pentest-env.

Yes, I tried this before. But failed. It looks like Vagrant does something when you alter the default route. Maybe you could confirm the problem.

from pentest-env.

Sorry I have some projects in parallels, I will try as soon as possible.
If you have an error message can you past it here, I will have a look!

from pentest-env.

Well. I gave some time to several alternatives(tun2socks, redsocks, etc.). I think the most easiest implemented one is: (1) configure adapter 2 as host-only (2) boot the box, delete all default route (3) set DNS server to e.g. Tor on host (4) configure proxychains to use a proxy on host machine (5) use proxychains all the time

Noted that you could still hit the Internet after default route deleted, because at least one none default route is configured by Vagrant to use NAT. This won't break ssh.

If for example redsocks comes into play, you have to deal with iptable rules, so much headache.
This kind of fixes possible DNS leak of proxychains, I think. proxychains uses LD_PRELOAD to inject hook into program that compiled to use shared lib. So if a program(invoked by proxychains) forks to exec a static compiled program, proxychains would fail. But since the static one doesn't not know which route leads to the Internet, it will just also fail. No leak.

from pentest-env.

You may have interest to read the manpage of tun2socks

from pentest-env.

Pls tell me later which alternative you prefer.

from pentest-env.

any progress?

from pentest-env.

Not yet!

from pentest-env.

Well, I played with the Whonix gateway. The concept is not bad it provides an easy way to manage tor setup outside the Kali vm.

So, with this pentestrc, we will have a Kali linux configured for the Whonix gateway:

instances:
  - kali
kali:
  networks:
    - private_network:
        adapter: 2
        virtualbox__intnet: Whonix
        auto_config: false
  chef:
    recipes:
      - pentestenv::whonix
      - resolver
    json:
      pentestenv:
        whonix:
          interface: eth1
          gateway: 10.152.152.10
          address: 10.152.152.11
          netmask: 255.255.192.0
      resolver:
        nameservers:
          - 10.152.152.10

It configures the second adapter with the Whonix internal network and disable auto-configuration vagrant feature. The interface eth1 and nameservers are configured with Chef.

Once vm is provisioned, browsing the url https://check.torproject.org will confirm that we are connected to Tor.

/etc/resolv.conf

#
# This file is generated by Chef
# Do not edit, changes will be overwritten
#
nameserver 10.152.152.10

/etc/network/interfaces.d/eth1

auto eth1
iface eth1 inet static
  address 10.152.152.11
  netmask 255.255.192.0
  gateway 10.152.152.10

root@kali:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         gateway         0.0.0.0         UG    0      0        0 eth1
10.0.2.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.152.128.0    0.0.0.0         255.255.192.0   U     0      0        0 eth1

I will add a documentation page and a pentestrc example.

from pentest-env.

Thx for your work. I will give some time to test your config in several days. Besides I am working on integrating grimd with rotating-proxy. After integration I think it provides better privacy than Whonix. You may want to provide alternative config to pentestenv.

from pentest-env.

Ok, Cool! Feel free to share your setup, I will look to integrate it in pentest-env ;)

from pentest-env.

Hey.
I tested your configuration. It does not work for me. Here is what I did.

1. Download Whonix Gateway and import it into Virtualbox.
2. Start Whonix Gateway.
3. PENTESTRC=examples/whonix.pentestrc vagrant up

Bringing machine 'kali' up with 'virtualbox' provider...
==> kali: Clearing any previously set forwarded ports...
==> kali: Clearing any previously set network interfaces...
==> kali: Preparing network interfaces based on configuration...
    kali: Adapter 1: nat
    kali: Adapter 2: intnet
==> kali: Forwarding ports...
    kali: 22 (guest) => 2222 (host) (adapter 1)
==> kali: Running 'pre-boot' VM customizations...
==> kali: Booting VM...
==> kali: Waiting for machine to boot. This may take a few minutes...
    kali: SSH address: 127.0.0.1:2222
    kali: SSH username: root
    kali: SSH auth method: private key
    kali: Warning: Remote connection disconnect. Retrying...
    kali: Warning: Remote connection disconnect. Retrying...
==> kali: Machine booted and ready!
==> kali: Checking for guest additions in VM...
    kali: The guest additions on this VM do not match the installed version of
    kali: VirtualBox! In most cases this is fine, but in rare cases it can
    kali: prevent things such as shared folders from working properly. If you see
    kali: shared folder errors, please make sure the guest additions within the
    kali: virtual machine match the version of VirtualBox you have installed on
    kali: your host and reload your VM.
    kali:
    kali: Guest Additions Version: 4.3.30
    kali: VirtualBox Version: 5.0
==> kali: Mounting shared folders...
    kali: /vagrant => /Users/jack/Workspace/vagrantboxs/pentest-env
==> kali: Machine already provisioned. Run `vagrant provision` or use the `--provision`
==> kali: flag to force provisioning. Provisioners marked to run always will still run.

root@kali:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.0.2.2        0.0.0.0         UG    1024   0        0 eth0
10.0.2.0        *               255.255.255.0   U     0      0        0 eth0
root@kali:~# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 08:00:27:13:5b:41
          inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe13:5b41/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:280 errors:0 dropped:0 overruns:0 frame:0
          TX packets:202 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:31827 (31.0 KiB)  TX bytes:26663 (26.0 KiB)

eth1      Link encap:Ethernet  HWaddr 08:00:27:0f:60:c7
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

It looks like the VM is not provisioned. After vagrant provision it still didn't work.

from pentest-env.

Your Kali vm was already created before using this setup ?
Yeah vagrant tell you that the machine is already provisioned, can you past output of vagrant provision command please? Hmm also I not specified but Chef is required for provisioning.

from pentest-env.

Yes, the VM is already there before using your config. vagrant provision gives no output. Do I need to install chef separately? I am not familiar with chef.

from pentest-env.

Ok, to use Chef you need ruby installed on your system (it is also embedded with Vagrant).

Install rake and berkshelf gems:

gem install rake berkshelf --no-ri --no-rdoc

And install cookbook dependencies:

rake

You will also need to fetch submodules, used for chef roles:

git submodule init
git submodule update

More infos : https://github.com/Sliim/pentest-env/blob/master/docs/Installation.md

Once you have updated submodules, vagrant provision command should provision Kali vm with Chef provisioning (because it enter here)

from pentest-env.

Thx for your kindly explain. Your config now works for me after destroying the box and up a new one.

I have a minor optimization:

$ ip ro
default via 10.152.152.10 dev eth1
default via 10.0.2.2 dev eth0  proto static  metric 1024
10.0.2.0/24 dev eth0  proto kernel  scope link  src 10.0.2.15
10.152.128.0/18 dev eth1  proto kernel  scope link  src 10.152.152.11

This is the route table immediately after the box is up. explain to the table

SO network 10.152.128.0/18 is reachable through eth1. 10.0.2.0/24 is reachable through eth0. If the packet dest does not match the two above, it goes to 10.0.2.2(it's the first default gateway). Otherwise it goes to 10.152.152.10, which is the Whonix Gateway.

I think the first default route could be deleted. SO I did it:

root@kali:~# ip route del default via 10.0.2.2 dev eth0
root@kali:~# ip ro
default via 10.152.152.10 dev eth1
10.0.2.0/24 dev eth0  proto kernel  scope link  src 10.0.2.15
10.152.128.0/18 dev eth1  proto kernel  scope link  src 10.152.152.11

It didn't affect vagrant ssh. And we have less chance to leak info via 10.0.2.2, which connects to Internet directly.

from pentest-env.

We already have a working config. Problem solved.

from pentest-env.

Hmm strange, normally your default route should be removed and replaced here. Something happen when executing route del default..

Thanks for your help!

from pentest-env.

You should use ip route del default via 10.0.2.2 dev eth0, the ip command to delete default route, since route command is deprecated in Debian

from pentest-env.

👍 Thanks!

from pentest-env.

Hi, i'm the developer of Nipe, mentioned in: #19 (comment).
If you need support I'm willing to help.
Thanks! =D

from pentest-env.

Would you guys be so kind to explain step by step, command after command, all the above mentioned setup to a complete newbie, looking to reach the highest anonymity level for covert pentest through Kali Linux 2.0 pentest environment? I would really appreciate that!!=)
Hope to hear from you very soon!!=)

from pentest-env.