I am trying to set up SSLSplit on OSX Mavericks according to this tutorial.
I got it working on a Ubuntu Machine, so I know SSLSplit works just fine and the issue is only with packets not being forwarded to the port on which SSLSplit is listening on Mavericks. On the SSLSplit homepage it says :
SSLsplit currently supports the following operating systems and NAT engines:
Mac OS X: ipfw fwd
so I try to set up port forwarding using the following two commands, but I read somewhere that ipfw has been dropped in OSX 10.9 Mavericks.
sudo sysctl -w net.inet.ip.forwarding=1
sudo ipfw add fwd 127.0.0.1,8080 tcp from 192.168.2.2 to any 443 in via bridge100
I even tried this in OSX 10.8.5, the commands don't give any error on either operating systems but traffic is not being forwarded.
I also tried the pfctl approach as mentioned here. But with this method, I don't think SSLSplit is too happy, since I think the packet loops around, I get too many files open error and SSLSplit crashes. Can SSLSplit work with pfctl? Does it really care how traffic is forwarded to the port on which it is listening? Or does the error occur because of some misconfiguration on my part?
Has someone been able to use SSLSplit on OSX Mavericks? Can you guide me with the port forwarding part? It would be better if you could explain the entire process.
I am not using tools such as mitmproxy since I have to decrypt the SSL Layer over non-HTTP Traffic.
Can SSLSplit work with pfctl? Does it really care how traffic is forwarded to the port on which it is listening? Or does the error occur because of some misconfiguration on my part?
When receiving a connection on a socket, SSLsplit needs to determine where the connection was originally destined to, before it got intercepted and redirected by ipfw, pf or some other NAT mechanism. Each NAT mechanism requires that SSLsplit uses a different way of figuring out what the original destination address was. When using pf rdr, that mechanism is the DIOCNATLOOK ioctl interface. For ipfw fwd, that mechanism is a standard getsockname() call. If you call getsockname() on a connected socket redirected by pf rdr, you will receive the local socket endpoint which is the IP address and port that sslsplit is listening on, therefore creating and endless packet loop. If you do that on a ipfw fwd divert socket, you get the original destination.
Has someone been able to use SSLSplit on OSX Mavericks? Can you guide me with the port forwarding part?
Unfortunately, there is currently no way to make SSLsplit support pf on Mac OS X since Apple does not seem to install the required header files required to use the DIOCNATLOOK ioctl interface, and the headers shipping with the source distribution differ from the OpenBSD/FreeBSD counterparts in that the ioctl interface has slightly changed and was made private. It would be possible to add support for that Apple modified private ioctl interface to SSLsplit, but nobody has written the code to do that so far.
SSLsplit is quite usable in SNI configurations though, where the destination address is taken from the SNI hostname the client asks for, but that of course only works with clients supporting SNI. Also working are configurations with static destinations.
There is also pf divert-to which would be compatible with ipfw fwd, but that feature of pf is not available on Mac OS X pf so far.
Also see this bug tracker issue: https://github.com/droe/sslsplit/issues/15
Update: SSLsplit git master now includes experimental support for pf on Mac OS X 10.7, 10.8 and 10.9 which will be part of the upcoming 0.4.8 release.
Related
I'd like to check the option to debug my kernel driver installed over remote physical machine (since I don't have firewire cables). Reading the relevant documentation, I haven't seen any limitation about remote physical debugging medium, so I deduced both firewire cables and ip over wireless network should work.
I thought that lldb remote connection using kdp-remote <machine-ip> would do the trick, but I don't get any response.
From remote VM however, it succeed even though the VM can be located on remote physical machine.
My boot-args configuration are keepsyms=1 debug=0x144 -v
We figured out the problem in the comments (item 2 below), but for posterity, here's a list of things to check if xnu kernel debugging isn't working:
The target machine must have a physical ethernet port which is connected via PCIe or Thunderbolt, or you must use a direct firewire connection (optionally via Thunderbolt). USB to ethernet adapters will not work on the target end. The client machine is less fussy, you can use wifi or USB-ethernet there.
The protocol uses UDP, not TCP. Have you got a firewall running on your lldb machine which might be blocking UDP packets? (You could try sending udp packets from target to client with the nc (netcat) tool while the machine is not crashed.)
Is the ARP entry correct on the client machine? arp <target ip> should yield the target interface's MAC address.
The crashed Mac will NOT respond to pings, only to KDP packets via UDP. So not getting pings back doesn't mean anything.
As far as I'm aware the machine won't request a new DHCP lease when it crashes, so that shouldn't be the problem, but you can always try setting a static IP address just to be sure.
Did you reboot after setting the boot-args? They only take effect on a fresh boot.
If SIP is active, you can only set nvram variables from the recovery environment from OS X/macOS 10.11 onwards. You can run nvram boot-args to verify that the settings stuck.
My personal recommendation is to use FireWire for kernel debugging if possible, it seems to be the fastest and most reliable in my experience.
im trying to setup a redirection towards an app that im writing in Java. This app opens a port 8443 on my laptop (which is a MacOS 10.10 Yosemite) and offers a HTTPS service.
The big plan is to have another device connecting to an access point that im setting up on my laptop and when it connects to any ip/domain on 443 this traffic is redirected to my local machine on port 8443.
I need to redirect traffic that im getting on 443 to 8443. I kinda might have gotten a solution for this using the following guide: http://www.abetobing.com/node/81, and changed the rule to rdr pass on lo0 inet proto tcp from any to any port 443 -> 127.0.0.1 port 8443
But this rule only works locally if im right about that. So only traffic coming from my own laptop is redirected. if im trying to open https://192.168.178.25/ on another machine it doesn't work, but https://192.168.178.25:8443/ does.
Additionally i also was able to change a domain via the /etc/hosts file. That only works for local connections and for single domains if im right. So the second step would be to redirect ALL possible domain names to my ip. I think this should be possible with kinda of a proxy service, but since i am new to this topic I haven't found a solution that is working for me.
At the moment I am using 2 Wifi devices and the MacOS Internet share. My USB wifi card is connected to a router and internet. My internal wifi card opens an access point (it says hotspot) and offers the internet connection of the other device. This is annoying, since the USB wifi connection always has to work, otherwise MacOS will shut down the access point. The best solution would be a software opening a reliable access point with the internal wifi card (haven't had any success with the Mac OS ad-hoc network)
I would be so glad if someone would be able to help me out with any of the 3 single parts. Thank you already :)
I want to set the dns servers that my router will hand out to all clients from a program running on osx. Is there any native way to do this. Does osx provide any uPNP wrapper apis. I have seen some 3rd party apis for uPNP like minipnp etc, but would prefer to use the OS if available.
It seems from people I have talked to that "DNSServiceNATPortMappingCreate" will do uPNP nat port forwards. So should I assume DNSServiceAddRecord would do the same?
You've no chance.
Many routers don't even support overriding the DHCP DNS settings from their own GUI, let alone from uPNP. See Section 5 of RFC 5625 for the gory details on how DHCP and DNS interact on routers.
The only practical solution is to run your own DHCP server, and turn off the one on the router. If your OSX machine is your network server you can easily install ISC DHCPD from the MacPorts project.
Well it turns out the best and only option is router screen scraping, yucky, but works.
How do I know visitor's MAC address on linux hosting (nginx)?
From ethernet user.
Thanks.
You cannot get that through PHP.
Networks protocol are used in a stack. When doing HTTP communications, your web server uses the HTTP protocol, responsible for the high-level communications. This protocol is implemented on the top of the TCP protocol (which brings stream-like connections and port numbers), which in turn is implemented on the top of the IP protocol (v4 or v6, which bring IP addresses for identification), which in turn is implemented on the top of the Ethernet protocol.
The Ethernet protocol is the one you would need to work with. It has both the source MAC address and the destination MAC address. However, most unfortunately, there are a lot of problems with it.
First, the data it conveys is probably hard to access: I say "probably" because I never stumbled upon how to do it.
Second, much like you get your client's router address when they access your site, you get your client's router MAC address at the Ethernet level. Unless they don't traverse any router (which would only happen if your server was directly wired to your client machine without any router interfering, because there are a whole lot of routers out there that relay data to other parts of the Internet), there is no chance that the MAC address you'll receive will be your client's.
Third, Apache will never try to access that data. And since PHP is "sandboxed" into the network environment Apache gives it, there is no way you can wind back to the Ethernet protocol.
So accessing the MAC address of a visitor from a website, from PHP, is not possible.
EDIT Seems you've taken out the PHP part from your question. So obviously, the last point won't stand anymore.
You can't get that with php it's not included in http
The more general question is this one. Since all PHP has to work with (I'm assuming this is PHP running on your webserver, here) is the HTTP request, you won't be able to get the MAC address. That requires something running on the visitor's side.
This may, or may not work. I know it will work on LAN clients, however for external clients it may be incorrect. I don't overly know my networking, but it's worth a shot right?
If you execute the arp -a command on either windows or linux, it will print out your arp records, which you can then parse for the mac.
Other than that, as far as I know, apache (and therefor php) doesn't just give out mac addresses in its env vars.
*Edited: Sorry, that won't work... The better utility is arping however that will just give you the mac of your router.
If you want to do this, clients will need to be directly connected to your server, with no router in between...
However if that is the case, then arping will work... I don't know of a better tool, but it seems a bit wasteful to do a ping (in root) for just a mac address.
The mac address is only visible on for the network provider if i'm correct (your internet host can see the mac address of your router for example), don't think you can get it with php.
Is there a Mac/Unix commands that lets you see the local network in terms of machines/IP addresses? If there's something on the Mac that is gui-based that would be great too.
ping the broadcast address (the broadcast address is printed as part of the output to ifconfig en0)
The hosts answering are on your local network. (You may also try arp -a but that only keeps track of recently contacted hosts so you may want to run it after the broadcast.)
There is a program called Bonjour Browser that will list well known services that have registered on your local network. I believe that most Macs have one or more registered protocols by default.
The only way to reliably do this is to scan the network using ping sweeps and similar techniques looking for open ports etc on various addresses. You can do that with nmap which is available for OS X. See http://www.netadmintools.com/art406.html for an example.
EDIT: Just to clarify, as diciu pointed out, you can usually ping the broadcast address and/or use your arp cache as well. This will probably work for most home networks where directed broadcast is allowed.
If not, then you would need to run a ping sweep with a tool like nmap to individually check each address for an available host. Many network discovery/scanning tools can check for more than just ping, looking for listening ports, SNMP, etc. as well.
in the days of tiger (10.4) every mac broadcast a 'presence' service on bonjour, which made finding macintoshes on the network a snap. alas, no more...
You can use netdiscover on Mac OS, which is based on ARP packets. It will send ARP requests and scan the response.
For example, run netdiscover command sudo netdiscover -i en0 -r 10.106.0.0/16 in my local network would bring the following result:
Try IP Scanner 2.5 for OS X. http://10base-t.com/ Looking for others, but that's the only real one I've found for OS X.
You can use Nmap but that seems to be a bit much for your stated goals.
OS X ships with netstat, or open Up /Applications/Utilities/Network Utility.app, perhaps this will work for you?
EDIT: oops. netstat doesn't do what I thought.
angry IP scanner for a no mus - no fuss IP scanner with basic port scanning.
NMap and Zenmap for the big power scans.
I actually use both together, as nmap can get easily sidetracked by certain reverse proxy boxes.