Wednesday, July 31, 2019

PS4 Tunneling

While setting up a couple of PS4s at work on a guest wifi network we ran into issues getting them to play well with each online.  The play station would complain about the NAT type being 3 or restrictive.  We could join a lobby that another play had hosted but not one of our own.  If we were both in the same lobby we could not see each other's cars.

The first solution I came up with involved tunneling the traffic through a Raspberry PI and GCE instance using Wireguard, IPtables and Dnsmasq.
PS4 --> Switch --> Pi --> Wifi --> GCE --> Internet

For my personal record a few snippets of the configs.
root@wireguard:~# cat /etc/rc.local
#! /bin/sh -e
ip link add dev wg0 type wireguard
wg setconf wg0 /etc/wireguard/wg0.conf
ip link set up dev wg0
ip address add dev wg0 172.16.0.1/24
# Roue packets back
ip route add 192.168.3.0/24 dev wg0
exit 0 
root@wireguard:~# cat /etc/wireguard/wg0.conf
[Interface]
ListenPort = *****
PrivateKey = *****
[Peer]
PublicKey = *****
AllowedIPs = 0.0.0.0/0
Endpoint = ***** 
root@wireguard:~# cat /etc/iptables.up.rules
# Generated by iptables-save v1.6.0 on Wed Jul 31 01:22:23 2019
*filter
:INPUT ACCEPT [67:11564]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [45:5251]
-A FORWARD -i eth0 -p udp -m udp --dport 3478:3480 -j ACCEPT
-A FORWARD -i eth0 -p tcp -m tcp --dport 3478:3480 -j ACCEPT
-A FORWARD -i eth0 -p tcp -m tcp --dport 1935 -j ACCEPT
-A FORWARD -i eth0 -o wg0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i wg0 -o eth0 -j ACCEPT
COMMIT
# Completed on Wed Jul 31 01:22:23 2019
# Generated by iptables-save v1.6.0 on Wed Jul 31 01:22:23 2019
*nat
:PREROUTING ACCEPT [2:160]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [4:240]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -i eth0 -p udp -m udp --dport 3478:3480 -j DNAT --to-destination 192.168.3.4
-A PREROUTING -i eth0 -p tcp -m tcp --dport 3478:3480 -j DNAT --to-destination 192.168.3.4
-A PREROUTING -i eth0 -p tcp -m tcp --dport 1935 -j DNAT --to-destination 192.168.3.4
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Wed Jul 31 01:22:23 2019

And on the PI.  Note the MTU was dropped to 1432 in the DHCP config.
 pi@raspberrypi:~ $ cat /etc/rc.local
#!/bin/sh -e
_IP=$(hostname -I) || true
if [ "$_IP" ]; then
  printf "My IP address is %s\n" "$_IP"
fi
# Wireguard interface
ip link add dev wg0 type wireguard
wg setconf wg0 /etc/wireguard/wg0.conf
ip link set up dev wg0
ip address add dev wg0 172.16.0.3/24
# Default route magic
wg set wg0 fwmark 1234
ip route add default dev wg0 table 2468
ip rule add not fwmark 1234 table 2468
ip rule add table main suppress_prefixlength 0
exit 0
root@raspberrypi:~# cat /etc/wireguard/wg0.conf
[Interface]
ListenPort = ****
PrivateKey = *****
[Peer]
PublicKey = ****
AllowedIPs = 0.0.0.0/0
Endpoint = **** 
root@raspberrypi:~# grep -e '^#' -v /etc/dhcpcd.conf
....
interface eth0
static ip_address=192.168.3.3/24
root@raspberrypi:~# grep -e '^#' -e '^$' -v /etc/dnsmasq.conf | tr -s \n
interface=eth0
dhcp-range=192.168.3.50,192.168.3.150,12h
dhcp-host=,2c:cc:44:6a:ae:32,192.168.3.4,12h
dhcp-option-force=26,1432
dhcp-mac=set:client_is_a_pi,B8:27:EB:*:*:*
dhcp-reply-delay=tag:client_is_a_pi,2

The max MTU size was discovered by sending pings with increasing sizes until they no longer work.
# ping google.com -c 1 -s 1432

Useful tcpdump commands
  tcpdump -i eth0 -v port 53
  tcpdump -i wg0 host 192.168.3.129
  tcpdump host 192.168.3.129 port 53
  tcpdump -i eth0
  tcpdump -i eth0 port 53
  tcpdump -i eth0 port 53 -v
  tcpdump -i eth0 portrange 3478-3480 or port 1935 -n
  tcpdump -i eth0,wg0 portrange 3478-3480 or port 1935 -n
  tcpdump -i eth0 -i wg0 portrange 3478-3480 or port 1935 -n
We noticed once the playstations were connected that most of the link light traffic on the switch was for the PS4s and not the PI.  The latest theory is that maybe uPNP is being used to discovery each other and connect locally instead through the internet.  Had this not been the case I was playing on adding a NAT rule on the PI for the PS4 hosting the lobby.  Since the traffic is local maybe we can get away without the tunnel and have the PI NAT the guest WIFI.  I cringed as I typed that.

Tuesday, January 3, 2017

USB Ubuntu Install

Installing Ubuntu to a USB drive without a separate drive or CD.
sudo qemu-system-x86_64 -boot d -cdrom ubuntu-16.04.1-desktop-amd64.iso -m 4096 -usb -usbdevice disk:/dev/sdb

Tuesday, October 6, 2015

Quick & Dirty PXE Boot


sudo apt-get install tftpd-hpa
$ cat /etc/default/tftpd-hpa
# /etc/default/tftpd-hpa

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/var/lib/tftpboot"
TFTP_ADDRESS="[::]:69"
TFTP_OPTIONS="--secure"

sudo -i
cd /var/lib/tftpboot
wget http://archive.ubuntu.com/ubuntu/dists/trusty-updates/main/installer-amd64/current/images/netboot/netboot.tar.gz
tar xvzf netboot.tar.gz

Tuesday, January 28, 2014

Notes on HP 1020 printer setup with Google Cloud print.

Notes on HP 1020 printer setup with Google Cloud print. This is a very scattered post and long TODO item.

Installed the printer with this guide.
http://tkjacobsen.wordpress.com/2008/12/15/hp-laserjet-1020-on-fedora-10/

https://support.google.com/a/answer/2906017?hl=en
python generate_cloudprint_config.py

Confused a bit about the instructions so I added a symlink called "Service State" that points to the config.
ls /etc/google-cloud-print/ -l
total 4
-rw-r--r-- 1 root root 736 Jan 25 19:22 dj-server.conf
lrwxrwxrwx 1 root root  14 Jan 25 19:24 Service State -> dj-server.conf

I've been abusing /etc/rc.d/rc.local for a lot of my startup scripts.  This server setup has been a more get it working kind of approach.  Note the --user-data-dir flag reference the directory I created with the config not the exact config file.
vi /etc/rc.d/rc.local
su - djhedges -c '/usr/bin/screen -dmt cloud-print -S cloud-print /opt/google/chrome/chrome --type=service --enable-cloud-print-proxy --no-service-autorun --noerrdialogs --user-data-dir=/etc/google-cloud-print/  --enable-logging=stderr --v=1 --enable-logging --v=1'

From there I can share the printer from some sort of printer setting I found linked with my Google account.

Saturday, June 9, 2012

Cisco WPA


My wireless on my router quit working for a while.  I think it was power cycled and something from the config wasn't written to flash.  I spent hours trying to reconfigure it, how hard could setting up WPA be?  The examples I found online showed the following and even my old configs had something similar.

interface Dot11Radio0
 no ip address
 !
 encryption vlan 2 mode ciphers tkip
 !
 ssid dj-ap
    vlan 2
    max-associations 1
    authentication open mac-address 00:00:00:00:00:00
    authentication key-management wpa
    guest-mode
    wpa-psk ascii 7 password_hash

This for some reason was the missing piece.  If I recall correctly as soon as I added the world-mode line everything started working.  It goes under the Dot11 interface but I always overlooked it because of indentation from the ssid bit above.

 world-mode dot11d country US both
 speed basic-1.0 basic-2.0 basic-5.5 6.0 9.0 basic-11.0 12.0 18.0 24.0 36.0 48.0
 station-role root

Separate network SSID instead of bridging it with the ethernet ports like I used to.   I plan to add a guest SSID and prevent their traffic from talking to my network.

interface Dot11Radio0.2
 encapsulation dot1Q 2
 ip address 172.16.2.1 255.255.255.0
 ip nat inside
 ip virtual-reassembly

Sunday, March 27, 2011

Hiding Data in Ping Packets

Fun little idea I started playing around with. I wanted to send data using ping packets ICMP packets are seemed as harmless and it would be hard to distinguish legitimate pings and pings containing encrypted data.
  • Populate a Protocol Buffer
  • Serialize the Protocol Buffer to a String
  • Pad the data if necessary and encrypt with Blowfish
  • Create a ICMP packet with a random salt + the encrypted data.
  • Sniff for ICMP packets and reverse all the above steps.
Inspired a bit by Loki.
http://www.phrack.org/issues.html?id=6&issue=49

Some of things I learned and want to do if I find the time.
  • I learned that block ciphers need to pad data.
  • Ping replies contain the same data as the request. It makes sense now but I was initially planning to change the data in the reply.
  • I'm concerned I'm still not doing things properly. Example theres nothing to stop anybody from replaying a packet. Maybe I could add a timestamp to the protocol buffer and ignore packets that are a minute old or something. I'd liked to figure out how fwknop works.
Source

Saturday, May 2, 2009

Cracking WPA keys with GPUs

I first read the article and I thought wow thats a lot faster. Then I started doing some math and realized it's still not practical.

http://arstechnica.com/security/news/2008/10/company-puts-nvida-gpus-to-work-cracking-wireless-security.ars

They benchmarked a 8800GTX at 2,500 guesses per second. It's distributed software up to 256 GPUS.
2,500 x 256 = 640,000 a second

How many possibilities can a WPA pass phrase be? (I think my math is right)
Upper & Lower case possible characters. 26*2 = 52
Possible special characters like $@!%, at least what I counted on my laptop. 32
52+32 = 84
63 possible characters in a WPA psk.
A!/(A-N)! = 84!/(84-63)! = 6.486942682e+106
I took that really big number and divided it by (640,000 * 60 * 60 * 24 * 365)
3214056297949842159116168158203114584942029386406415805023892166920391523704839025459200000000 years to find all the possibilities
http://wiki.answers.com/Q/What_is_the_equation_to_determine_number_of_possible_lock_combinations

I did the same math and found how long it would take to generate all the possible combinations. It's amazing how much stronger a pass phrase becomes by adding another character.
1-5 characters would take 96 minutes
1-6 characters would take 5.2 days
1-7 characters would take 412 days
1-8 character would take 87 years

Site I've always used to generate keys.
http://www.kurtm.net/wpa-pskgen/

All in all I guess as long as you have a decent password your ok.