Trouble setting up port forwarding for transparent proxy on Mac OS X - macos

I'm trying to set up a transparent proxy on my Mac OS X Lion (10.7.5), so I can use mitmproxy (to intercept SSL traffic from android applications). I followed the steps in the mitmproxy docs for setting up port forwarding with pf on Mac OS X, and they all went without any errors:
$ sudo sysctl -w net.inet.ip.forwarding=1
Password:
net.inet.ip.forwarding: 0 -> 1
$ sudo pfctl -f pf.conf
No ALTQ support in kernel
ALTQ related functions disabled
$ sudo pfctl -e
No ALTQ support in kernel
ALTQ related functions disabled
pf enabled
But it doesn't seem to have had any effect. When I go to websites in my browser, it makes a direct request, and doesn't go through the port I specified. Here is the pf.conf file (en1 is my wifi):
rdr on en1 inet proto tcp to any port 80 -> 127.0.0.1 port 4500
rdr on en1 inet proto tcp to any port 443 -> 127.0.0.1 port 4500

Thanks for stopping by the IRC channel today. I've tracked this down, and the basic issue is that the rdr rules apply to inbound traffic. This means that they will NOT redirect traffic coming from the box itself. If you think about it, this is inevitable: we can't distinguish between an outbound connection from a non-mitmproxy app, and an outbound connection from mitmproxy itself. We can use route-to to send the traffic to lo0 and then redirect it, but that causes an infinite loop where mitmproxy's own outbound connections are also redirected back to mitmproxy.
Because I know a bit about your use case, I would suggest exploring ways to do this with VirtualBox. A plan of attack would be to set the VirtualBox network up in bridge mode, and then use a pf rule with a match on the source address to redirect traffic to mitmproxy. That should do what you want, and not cause singularities in time and space due to infinite redirection.
Please drop by the IRC channel again if you need a further hand with this.

Did you try net.inet.ip.scopedroute=0? From http://lucumr.pocoo.org/2013/1/6/osx-wifi-proxy/:
Now currently if you finish that above setup you will notice that
nothing actually works. The cause for this is a Bug in the OS X kernel
that requires flipping the net.inet.ip.scopedroute flag to 0. I am not
entirely sure what it does, but the internet reports that it breaks
network sharing through the user preferences. In any case it fixes
ipfw based forwarding so you can flip it with sysctl:
$ sudo sysctl -w net.inet.ip.scopedroute=0
Unfortunately in OS X Lion this flag can actually not be flipped from
userspace so you need to set it as boot parameter and then restart
your computer. You can do this by editing the
/Library/Preferences/SystemConfiguration/com.apple.Boot.plist file
(continued...)

You are using the port 4500 instead the default port 8080.
Do you start mitmproxy with the port specification?: mitmproxy -T --host -p 4500
Did you follow the steps to set the certificate in the Android device? http://mitmproxy.org/doc/certinstall/android.html
Another problem could be the gateway on your android phone: Preferences - Wifi - Hold on the network you are using - Edit network - Advanced options - Set as gateway the ip of your machine with mitmproxy.
By the way I have the same warning with No ALTQ function but it works.

Related

Need to create a restricted network with UDP ports blocked in mac

I build video conferencing solutions using WebRTC. Some of the clients come from a restricted network with UDP ports blocked and the conferencing does not work well as the media server relies on UDP port 10000. I need to simulate the same network conditions in my mac so that without troubling the clients I can test out the video conference.
So how to block UDP connections to my Mac? Any help would be highly appreciated.
Regards,
Yasith
You can use pfctl in OSX.
sudo nano /etc/pf.conf
At the end of the file add the following to block UDP on port 10000
block out proto udp from any to any port 10000
Then enable the firewall with
sudo pfctl -f /etc/pf.conf && sudo pfctl -E

Laradock + PhpStorm + Xdebug Fails whereas PhpStorm Validation Succeeds

I've setup debug configuration for PhpStorm and it is successfully validated by PhpStorm:
Xdebug helper for Chrome is also installed.
The problem is that nothing happens when I start listening for debug connections and reload the required page with Xdebug helper switched on. Also tried this bookmarklets with no luck.
No errors or something, just nothing.
Also tried to set different IPs as dockerhost: from 192.168.. range (from network settings), from 172.* range (from nginx), from 10.* range (10.0.75.1 is default). Also tried docker.for.mac.internal.host which failed when containers were starting.
Docker 17.02, macOS Sierra, PhpStorm 2017.3
If you're on linux, be sure to create corresponding rules in your firewall.
But to troubleshoot this more effectively you need to gather more info.
Enable xdebug logging xdebug.remote_log=/var/www/xdebug.log in you
xdebug.ini or you can append that in the "Cli Interpreters > Configuration Options" in PHPStorm (xdebug.remote_log, /path/inside/workspace/container/xdebug.log)
Another step you could take is to monitor the incoming connections to your machine. (run this on where you installed docker). It will start listening to all incoming connection attempts on port 9000.
sudo tcpdump -i any port 9000
Now run the debugger once, check the logs inside the container (workspace by default) and see if any incoming connection attempts have gone through from the container.
If you see something like Time-out connecting to client (Waited: 200 ms). :-(, chances are that your firewall is blocking the incoming connections.
To open them up you could add a rule using ufw
sudo ufw allow in from 172.22.0.0/24 to any port 9000 (or write down a specific ip) Be sure to double check that this is the ip trying to connect
this will allow all connections on port 9000 from 172.22.0.* (which is what laradock uses for its virtual networks). Be sure to double check the logs maybe your setup uses different ip range)
My working xdebug.ini (both in php-fpm and workspace containers are the same)
xdebug.remote_host=dockerhost
xdebug.remote_connect_back=0
xdebug.remote_port=9000
xdebug.idekey=PHPSTORM
xdebug.remote_autostart=1
xdebug.remote_enable=1
xdebug.remote_log=/var/www/xdebug.log
xdebug.cli_color=1
xdebug.profiler_enable=0
xdebug.profiler_output_dir="~/path/to/profiler.log"
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
xdebug.var_display_max_children=-1
xdebug.var_display_max_data=-1
xdebug.var_display_max_depth=-1
If none of the above works, another step would be to also check if you have any containers running on port 9000 already. If so, then you'll need to use another, port, just don't forget to expose it from docker.
(Explanation: docker binds (exposes) ports to the host machine so that any incoming connections get directed to the right container, if 9000 is taken, xdebug won't be able to connect to any IDE on your machine, even if the IDE says it is running the listener)
Hope this helps.

Mac OS X 10.10.1 AMP stack offline use

before the update to Yosemite (on Mavericks) i was able to access my locally hosted sites via apache even when the wifi was completely turned off. i set up my AMP stack according to this tutorial: http://wizardmode.com/2012/06/apache-php-mysql-dev-on-os-x-lion-with-a-minimum-of-pain/
FROM THE TUTORIAL
One more thing. OS X will refuse to do DNS lookups if you’re not connected to a network (under some circumstances). There’s a simple way around that, in two steps:
First, install VirtualBox. Create a new virtual machine, and give it a Host-only network adapter. (You can use the FreeDos image, if you don’t actually need a virtual machine for anything. It’s small.) Start the virtual machine at least once.
You can do this from the commandline with this snippet (after VirtualBox is installed):
(ifconfig | grep -s vboxnet) || VBoxManage hostonlyif create ipconfig vboxnet0 --ip 192.168.56.1 --netmask 255.255.255.0
This prevents OS X from disabling normal DNS resolution when you’re not connected to a network.
Second, create a ‘dev’ domain resolver entry:
sudo mkdir -p /etc/resolver
sudo tee /etc/resolver/dev <<EOT
nameserver 127.0.0.1
domain dev
search_order 1
EOT
This tells OS X that it can always ask localhost (your dnsmasq server) for domain resolution for .dev domains when it doesn’t have other DNS servers.
Now if you type ifconfig in a terminal, one of the lines should start with vboxnet0: – if it does, great! OS X will happily do DNS lookups even if you’re on an airplane, so you can keep using your .dev domains wherever you are.
END TUTORIAL SECTION
after the update i went through hell to get all my local sites running and now they only work if i have an internet connection
I am running dnsmasq according to the tutorial and I did the whole VirtualBox trick. here is the relevant output of ifconfig:
vboxnet0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 0a:00:27:00:00:00
inet 192.168.56.1 netmask 0xffffff00 broadcast 192.168.56.255
vboxnet1: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 0a:00:27:00:00:01
I'm not really sure what's going wrong. Here is a screenshot of my wifi network settings:
you can see the opendns servers and then localhost for dns resolution purposes.
furthermore, here is scutil --dns output:
DNS configuration
resolver #1
nameserver[0] : 208.67.222.222
nameserver[1] : 208.67.220.220
nameserver[2] : 127.0.0.1
flags : Request A records, Request AAAA records
reach : Reachable
resolver #2
domain : dev
nameserver[0] : 127.0.0.1
flags : Request A records, Request AAAA records
reach : Reachable,Local Address
order : 1
DNS configuration (for scoped queries)
resolver #1
nameserver[0] : 208.67.222.222
nameserver[1] : 208.67.220.220
nameserver[2] : 127.0.0.1
if_index : 4 (en0)
flags : Scoped, Request A records, Request AAAA records
reach : Reachable
I'm really at a loss here for what's happening and going wrong. I've tried debugging some of the shell scripts from the tutorial to see if they are causing problems but I can't figure it out. This should be simple as pie IMO. Why is this such a nightmare?
Any help would be greatly, greatly appreciated as I'm wasting valuable time that could be used for building useful things on this mess. THANK YOU!!!!
As of 10.10 and discoveryd no DNS resolution can take place when you are disconnected from all networks.
you can confirm this by running scutil --dns once when connected, and again when disconnected.
Here is a video that shows the difference in behavior between 10.9 and 10.10 https://www.youtube.com/watch?v=3m9OI_AjCx8
I've tried to escalate this with Apple, the response was that it's expected behavior.
The only workaround I know of is to re-add mDNSResponder as per http://arstechnica.com/apple/2015/01/why-dns-in-os-x-10-10-is-broken-and-what-you-can-do-to-fix-it/

Transparent proxy on Mac OS X Lion with Fusion

I have a MacOS X (Lion) with VMWare Fusion installed. In Fusion I have two guests: a Linux and a MS Windows XP. The two guests networking is configured to use NAT thru vmnet8 interface. Both boxes access to the internet just fine by default.
My objective is to force all HTTP (tcp/80) traffic leaving the XP client to be redirected to the Linux client on the proxy port (tcp/8080). The XP client must not be aware of the redirection thus explicit proxy configuration in the XP browser is not an option.
I already tried this setup on a linux host running virtualbox. The iptables nat rules did the trick just fine. But I'm completely lost on how to do this in Mac which is pf based.
I've been attempting to configure a complementary pf.conf (proxy.conf) file with just one line:
rdr on vmnet8 proto tcp from 192.168.190.138 to any port 80 -> 192.168.190.134 port 8080
Concerning the IP: 192.168.190.138 is the XP guest ip and 192.168.190.134 is the linux guest.
I then run the following pfctl commands:
$sudo pfctl -vf ~/proxy.conf
No ALTQ support in kernel
ALTQ related functions disabled
rdr on vmnet8 inet proto tcp from 192.168.190.138 to any port = 80 -> 192.168.190.134 port 8080
and then:
$ sudo pfctl -e
No ALTQ support in kernel
ALTQ related functions disabled
pfctl: pf already enabled
When I attempt to open a webpage on the XP guest pf doesn't redirect the traffic to the linux box. For some reason the pf rule isn't working as expected. Probably because something is missing...

How to configure direct http access to EC2 instance?

This is a very basic Amazon EC2 question, but I'm stumped so here goes.
I want to launch an Amazon EC2 instance and allow access to HTTP on ports 80 and 8888
from anywhere. So far I can't even allow the instance to connect to on those ports using
its own IP address (but it will connect to localhost).
I configured the "default" security group for HTTP using the standard HTTP option on the management console (and also SSH).
I launched my instance in the default security group.
I connected to the instance on SSH port 22 twice and in one window launch an HTTP server
on port 80. In the other window I verify that I can connect to HTTP using the "localhost".
However when I try to access HTTP from the instance (or anywhere else) using either the public DNS or the Private IP address I het "connection refused".
What am I doing wrong, please?
Below is a console fragment showing the wget that succeeds and the two that fail run from the instance itself.
--2012-03-07 15:43:31-- http://localhost/
Resolving localhost... 127.0.0.1
Connecting to localhost|127.0.0.1|:80... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: /__whiff_directory_listing__ [following]
--2012-03-07 15:43:31-- http://localhost/__whiff_directory_listing__
Connecting to localhost|127.0.0.1|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: “__whiff_directory_listing__”
[ <=>
] 7,512 --.-K/s in 0.03s
2012-03-07 15:43:31 (263 KB/s) - “__whiff_directory_listing__” saved [7512]
[ec2-user#ip-10-195-205-30 tmp]$ wget http://ec2-50-17-2-174.compute-1.amazonaws.com/
--2012-03-07 15:44:17-- http://ec2-50-17-2-174.compute-1.amazonaws.com/
Resolving ec2-50-17-2-174.compute-1.amazonaws.com... 10.195.205.30
Connecting to ec2-50-17-2-174.compute-1.amazonaws.com|10.195.205.30|:80... failed:
Connection refused.
[ec2-user#ip-10-195-205-30 tmp]$ wget http://10.195.205.30/
--2012-03-07 15:46:08-- http://10.195.205.30/
Connecting to 10.195.205.30:80... failed: Connection refused.
[ec2-user#ip-10-195-205-30 tmp]$
The standard tcp sockets interface requires that you bind to a particular IP address when you send or listen. There are a couple of somewhat special addresses: localhost (which you're probably familiar with) which is 127.0.0.1. There's also a special address, 0.0.0.0 or INADDR_ANY (internet protocol, special shorthand for ANY ADDRESS). It's a way to listen on ANY or more commonly, ALL addresses on the host. This is a way to tell the kernel/stack that you're not interested in a particular IP address.
So, when you're setting up a server that listens to "localhost" you're telling the service that you want to use the special reserved address that can only be reached by users of this host, and while it exists on every host, making a connection to localhost will only ever reach the host you're making the request from.
When you want a service to be reachable everywhere (on a local host, on all interfaces, etc.) you can specify 0.0.0.0.
(0) It's silly but the first thing you need to do is to make sure that your web server is running.
(1) You need to edit your Security Group to let incoming HTTP packets access your website. If your website is listening on port 80, you need to edit the Security Group to open access to port 80 as mentioned above. If your website is listening on some other port, then you need to edit the Security Group to access that other port.
(2) If you are running a Linux instance, the iptables firewall may be running by default. You can check that this firewall is active by running
sudo service iptables status
on the command line. If you get output, then the iptables firewall is running. If you get a message "Firewall not running", that's pretty self-explanatory. In general, the iptables firewall is running by default.
You have two options: knock out the firewall or edit the firewall's configuration to let HTTP traffic through. I opted to knock out the firewall as the simpler option (for me).
sudo service iptables stop
There is no real security risk in shutting down iptables because iptables, if active, merely duplicates the functionality of Amazon's firewall, which is using the Security Group to generate its configuration file. We are assuming here that Amazon AWS doesn't misconfigure its firewalls - a very safe assumption.
(3) Now, you can access the URL from your browser.
(4) The Microsoft Windows Servers also run their personal firewalls by default and you'll need to fix the Windows Server's personal firewall, too.
Correction: by AWS default, AWS does not fire up server firewalls such iptables (Centos) or UAF (Ubuntu) when you are ordering the creation of new EC2 instances - That's why EC2 instances that are in the same VPC can ssh into each other and you can "see" the web server that you fired up from another EC2 instance in the same VPC.
Just make sure that your RESTful API is listening on all interfaces i.e. 0.0.0.0:portID
As you are getting connection refused (packets are being rejected) I bet it is iptables causing the problem. Try to run
iptables -I INPUT -p tcp --dport 80 -j ACCEPT
iptables -I INPUT -p tcp --dport 8888 -j ACCEPT
and test the connection.
You will also need to add those rules permanently which you can do by adding the above lines into ie. /etc/sysconfig/iptables if you are running Red Hat.
Apparently I was "binding to localhost" whereas I needed to bind to 0.0.0.0 to respond to port 80 for the all incoming TCP interfaces (?). This is a subtlety of TCP/IP that I don't fully understand yet, but it fixed the problem.
Had to do the following:
1) Enable HTTP access on the instance config, it wasn't on by default only SSH
2) Tried to do nodejs server, so port was bound to 80 -> 3000 did the following commands to fix that
iptables -F
iptables -I INPUT -p tcp --dport 80 -j ACCEPT
sudo service iptables-persistent flush
Amazon support answered it and it worked instantly:
I replicated the issue on my end on a test Ubuntu instance and was able to solve it. The issue was that in order to run Tomcat on a port below 1024 in Ubuntu/Unix, the service needs root privileges which is generally not recommended as running a process on port 80 with root privileges is an unnecessary security risk.
What we recommend is to use a port redirection via iptables :-
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080
I hope the above information helps.

Resources