Friday, November 23, 2012

Test open ports by chatting from the command line

 
Today I needed to test whether or not a specific TCP/IP port on a firewall/server was open and whether or not traffic could successfully flow via that port without firewall interference. I needed to do this independent of the normal server application that handles this for testing purposes. I just needed to make sure the firewall aspect was all set to go.

Well, why not solve this problem with netcat? Here's how I did it...

First, I put a box booted into Knoppix at Site A and a Mac with Mountain Lion at Site B. (Netcat also exists for Windows.) I then disabled the Mountain Lion firewall temporarily and started up the netcat server at Site B:

nc -vl 666

The v is for verbose of course and the l tells it to be the listener/server. The 666 is the port it will listen on, lol. (All IP addresses and ports have been changed to protect the innocent.)

At Site A, I then had someone run this command on the Knoppix rig:

nc -v 172.31.31.31 666

This caused netcat to connect to the remote server via its IP address on port 666. At that point, I started chatting over the command line back and forth with the person at Site A like as if we were instant messaging. Who knew this could be so fun?! When I typed something on my screen and pressed enter, it appeared on their command line terminal and vice versa. Interestingly, until I solved a firewall issue, the netcat client would connect but when you typed text, you couldn't see it on the other end.

This utility is very useful and this post only shows one of many things netcat can do. By default, netcat uses TCP. For checking UDP, you can simply add the u switch to the command from both the server and the client. The 4 switch can also force netcat to use IPv4 which will help avoid problems.

This was a very lightweight, portable and easy way to test connectivity on a specific port and required no installation or configuration at all. This also allowed me to test completely independent of any normal server applications, etc. to rule out the possibility of any firewall filtering. [does happy little geek dance]




Sunday, November 18, 2012

Forward your Android SMS to email

 
There are apps out there that forward your SMS to your email but in my experience they all either don't work, or cost money. Being the cheapskate that I am, definitely wasn't going to pay money for something like that, so I started brainstorming.

I needed something to be running on my Android phone that would grab my texts and email them to me. That way if I get an SMS and my phone is in the other room charging or something I could see it on my iPad, etc. Using Google Voice for this kind of stuff is not a perfect solution because they only forward SMS that was sent to your Google number, not to your actual cell phone number.

I played around with a couple of apps and never could get the email feature to work. But I did get the feature to forward the SMS to another phone number to work, however. So I setup the free Android app "SMS Forwarding" to forward to my email via my IFTTT phone number and problem solved! Here's how to do it:

1. Setup a free ifttt.com acccount

2. Setup my shared IFTTT recipe which you can find here: https://ifttt.com/recipes/66951. You'll have to confirm your phone number and email address with IFTTT and what not but it's pretty self-explanatory.

3. Install free Android app "SMS Forwarding" on your Android phone. I believe the version I am using is 1.4.3.
 

4. Setup the "SMS Forwarding" app to forward all your SMS messages to your IFTTT phone number. To do this, you will open the app, check "Enable Forwarding" and check "Forward with SMS". Then select "Destination Number" and enter your IFTTT phone number. You can find your IFTTT phone number by viewing your IFTTT recipe or your IFTTT SMS channel. Here's a screenshot of the app before configuration has taken place. (Don't copy these settings.)


5. Test it out. It should be good to go now!! Mine's working great! You can also setup "SMS Forwarding" to notify you of missed calls and low battery but I haven't tried those yet. Be sure to comment if you try them!

BTW, ifttt.com is awesome! There are a zillion different things you can do with this free service...






Thursday, November 15, 2012

Stop your ISP from intercepting your DNS queries

My ISP hacked me.

Dude, by default they intercept all customers' DNS queries and redirect them to their DNS servers. Then, they answer the DNS queries with their servers and spoof the originating server within the DNS response to make it look like they didn't intercept it. They're a regular man-in-the-middle! Total lameness.

Now, normally this wouldn't bother me too much because I would prefer to use an ISP's DNS servers. They will typically be your fastest resource for a DNS response. But spoofing responses to me? That's over the top. What if I wanna use OpenDNS to filter my internet? Or what if I just simply wanna troubleshoot a DNS issue by querying another ISP's DNS server? No go.

I know why they do this. They are trying to control bandwidth on their end. But this is a little extreme.

There's another side to this: My ISP's DNS servers stink!! They go down for 10 minutes at a time without warning. During these periodic outages I can ping by IP address but not by name and the internet is effectively dead. Total lameness.

So…We have DNS servers that aren't reliable and we have an ISP that forces you to use the bad DNS servers. Great situation!

After fighting with my ISP's customer service and getting nowhere, I decided it was time to take matters into my own hands and solve this problem myself.

First, I proved this was indeed the problem by setting my WZR-HP-G300NH2/Gargoyle (see previous post) router to use Google's DNS servers and then checking the logs. The logs showed that I was actually talking to my ISP's DNS servers even when I made queries to Google!

I started thinking…They've got to be intercepting this based on port number…What if there was a DNS server out there somewhere that actually listened on an alternate port? Lo, and behold there is! OpenDNS' servers listen on both 53 and 5353! Now all I needed to do was make make Gargoyle/OpenWRT talk to their servers on the alternate port, thus circumventing my ISP's DNS servers!

Using a wiki designed for setting up DNSCrypt on OpenWRT (which maybe I will setup sometime), I SSHed to the router and backed up /etc/config/dhcp and then edited it using vi (I also backed up my config from the web interface):

cp /etc/config/dhcp /etc/config/dhcp.bak
vi /etc/config/dhcp

If you don't know how to use vi, check here. As shown below, under the "config dnsmasq" section I then commented the "option resolvfile" line and added 3 more lines under that line:



EDIT: Just to clarify, here are the three lines I added below the commented line:

option noresolv '1'
list server '208.67.222.222#5353'
list server '208.67.220.220#5353'

(Make sure you match the formatting/spacing shown in the image.)

As you can see, the last 2 lines tell the router to use OpenDNS' servers and talk to them on alternate port 5353. Then I created an OpenDNS account (not necessary) and restarted the router's DNS daemon:

/etc/init.d/dnsmasq restart

...Now OpenDNS has a page at http://internetbadguys.com that they block just for testing purposes...so I went to a computer to see if I was successfully blocked (I cleared the DNS cache on the computer first):


Good! Here's what would have showed had I not been successfully blocked by OpenDNS' filtering:




I also checked my router logs and found lots of entries with 208.67.222.222:5353:




Very good!! I searched my logs further for any queries to my ISP's DNS server and found none! I then backed up my router config, flushed the DNS cache on my boxes and laughed all the way home:

Windows: ipconfig/flushdns
Mac OS X ML: sudo killall -HUP mDNSResponder

Recap:
My ISP = fail
My ISP = pwned
Me = Happy!




Wednesday, November 14, 2012

Determine your home router's IP address remotely

Today I needed to determine the public IP address that my home network was using but I was not physically located at home and didn't have a means of remote access into my network without the IP address. (I'm working on getting dynamic DNS and remote access and all that but it isn't up yet.)

So, I thought really hard about what I could do and it came to me...

I happened to know that there was a computer on my home network with a browser window opened to Gmail...So I logged into Gmail from my remote location and scrolled all the way down. In the bottom right hand corner, this was displayed:




I clicked "Details" and there was my home IP! This saved my bacon!







Monday, November 12, 2012

Use Gargoyle to control bandwidth



Well I bricked my brand new router! How thrilling!

Of course, I also unbricked it which was fun, too, I guess.

I bought a Buffalo WZR-HP-G300NH router from newegg.com because I wanted to put a free custom firmware called Gargoyle on it. Gargoyle is a front end for OpenWRT and specializes in simplifying the process of configuring bandwidth limitations. You can throttle down those bandwidth hoggers that are killing your internet, etc.  So basically you hack your router to do more things than it was designed to do. Fun. This is my first time to venture into custom firmware and here's my brick story:

When my router arrived in the mail it turned out to be a WZR-HP-G300NH2 instead of a WZR-HP-G300NH and I was distracted and kinda just didn't care/notice too much I guess. (dur...) I logged into the router via telnet and HTTP and was very impressed by the ridiculous amount of features. The router comes with a Buffalo branded (weird!) version of DD-WRT which is sort of a cousin to OpenWRT and it was pretty cool stuff!






Of course, I wanted Gargoyle instead so after browsing around on the firmware a bit for fun, I used this (warning: do not use) method to update the firmware. However, I used the wrong firmware image because the wiki I was going by was designed for the router that was supposed to have been shipped to me by newegg.com and not the one that actually came. The commands I ran while telneted into the router were as follows (DO NOT RUN THESE COMMANDS):

cd /tmp

wget http://www.gargoyle-router.com/downloads/images/ar71xx/gargoyle_1.4.4-ar71xx-wzr-hp-g300nh-squashfs-sysupgrade.bin

mtd -e linux -r write gargoyle_1.4.4-ar71xx-wzr-hp-g300nh-squashfs-sysupgrade.bin linux

DO NOT USE THESE COMMANDS for this router, however. Unless you wanna brick it, of course. I'll show you the right way in a bit here. (If I would have just used the correct file, I probably would have been okay.) After this, the router came up with a solid red light and would not ping at either its old IP of 192.168.11.1 or the default Gargoyle IP of 192.168.1.1. Oopsy........

After a lot of research, forum advice, blood, sweat and tears, I successfully unbricked it using TFTP. I learned that there is a short 4 second window about 10 seconds or so into boot in which the router will accept a TFTP PUT from a specific IP address only. There also must be a static ARP entry on your computer for a generic MAC address that the router has during boot.

Below are the details on how I unbricked it using my Macbook Pro, though this can be done with Windows or Linux as well. To prepare for the unbricking, I downloaded gargoyle_1.5.8-ar71xx-generic-wzr-hp-g300nh2-squashfs-tftp.bin (experimental) and put it in my Downloads folder. So...

1. I turned off WiFi, just to make sure my computer wouldn't try to talk to the router through the wireless connection

2. Then I gave my wired Ethernet connection en0 the IP address of 192.168.11.2 and the subnet mask of 255.255.255.0. This can be done through System preferences>Network>Configure IPv4 = Manually. Just leave the router space blank.

3. Next, I went to a Terminal and confirmed that the IP for interface en0 took by running: ifconfig en0

4. Then it was time to create a static ARP entry for the router and change to the Downloads folder:
sudo arp -da (clears ARP cache)
sudo arp -s 192.168.11.1 02:aa:bb:cc:dd:1a (create a static ARP entry for the generic MAC address that the router defaults to)
arp -a (make sure that the static entry took)
cd Downloads (This is case-sensitive and changes us to the directory where I downloaded the firmware to.)

5. I then unplugged everything from the router and plugged a network cable from my Mac to the LAN port that is right next to the blue WAN port on the router -- but left the power to the router unplugged.

6. This next part was the most tricky. You have to boot up the router and then start barraging it with PUT commands via TFTP until it connects. The router will only listen on 192.168.11.1 and will only listen to your computer if your computer has the address 192.168.11.2. Fussy! It starts listening at about 10 seconds into boot and only listens for about 4 seconds. It can be tricky to catch it at just the right time. I first tried it with a couple of Mac TFTP applications but that didn't work. I then tried it from the command line, as shown below. However, it still wouldn't work after many, many attempts. I must admit that I became very frustrated at this point. Hacking was no longer feeling quite as fun, especially knowing that I may have permanently bricked my brand new router! Finally, I replaced my network cable and tried again and again some more until I got it. Still can't believe that my network cable was apparently bad. Crazy. I had even tried putting a switch between them earlier. (I read somewhere that sometimes there can be an issue with Windows taking a long time to bring up the NIC and ruining the timing for this and I thought it might apply to Mac. The way to get around this is to put a switch between the router and the computer and let the computer successfully negotiate its switchport connection before powering the router on. A low-grade dumb switch will likely do better at quick negotiation, as opposed to a super-duper switch with too many features, fyi.) So here are the Mac TFTP commands I ran from the terminal and their results...Right after the first PUT command is where I plugged the router's power in immediately and then kept hitting up arrow and then enter over and over again on my Mac until it finally took:

tftp 192.168.11.1
tftp> binary
tftp> rexmt 1
tftp> timeout 30
tftp> trace
Packet tracing on.
tftp> put gargoyle_1.5.8-ar71xx-generic-wzr-hp-g300nh2-squashfs-tftp.bin (Plug the router in immediately after this command! Then keep hitting up-arrow and enter over and over again to repeat the command!!)
sent WRQ <file=openwrt-ar71xx-generic-wzr-hp-g300nh2-squashfs-tftp.bin, mode=octet>
tftp: sendto: Can't assign requested address
tftp> put gargoyle_1.5.8-ar71xx-generic-wzr-hp-g300nh2-squashfs-tftp.bin
sent WRQ <file=openwrt-ar71xx-generic-wzr-hp-g300nh2-squashfs-tftp.bin, mode=octet>
tftp: sendto: Can't assign requested address
tftp> put gargoyle_1.5.8-ar71xx-generic-wzr-hp-g300nh2-squashfs-tftp.bin
sent WRQ <file=openwrt-ar71xx-generic-wzr-hp-g300nh2-squashfs-tftp.bin, mode=octet>
tftp: sendto: Can't assign requested address
tftp> put gargoyle_1.5.8-ar71xx-generic-wzr-hp-g300nh2-squashfs-tftp.bin
sent WRQ <file=openwrt-ar71xx-generic-wzr-hp-g300nh2-squashfs-tftp.bin, mode=octet>
tftp: sendto: Can't assign requested address
tftp> put gargoyle_1.5.8-ar71xx-generic-wzr-hp-g300nh2-squashfs-tftp.bin
sent WRQ <file=openwrt-ar71xx-generic-wzr-hp-g300nh2-squashfs-tftp.bin, mode=octet>
tftp: sendto: Can't assign requested address
tftp> put gargoyle_1.5.8-ar71xx-generic-wzr-hp-g300nh2-squashfs-tftp.bin
sent WRQ <file=openwrt-ar71xx-generic-wzr-hp-g300nh2-squashfs-tftp.bin, mode=octet>
tftp: sendto: Can't assign requested address
tftp> put gargoyle_1.5.8-ar71xx-generic-wzr-hp-g300nh2-squashfs-tftp.bin
sent WRQ <file=openwrt-ar71xx-generic-wzr-hp-g300nh2-squashfs-tftp.bin, mode=octet>
tftp: sendto: Can't assign requested address
tftp> put gargoyle_1.5.8-ar71xx-generic-wzr-hp-g300nh2-squashfs-tftp.bin
sent WRQ <file=openwrt-ar71xx-generic-wzr-hp-g300nh2-squashfs-tftp.bin, mode=octet>
tftp: sendto: Can't assign requested address
tftp> put gargoyle_1.5.8-ar71xx-generic-wzr-hp-g300nh2-squashfs-tftp.bin
sent WRQ <file=openwrt-ar71xx-generic-wzr-hp-g300nh2-squashfs-tftp.bin, mode=octet>
^[[A
^[[A
sent WRQ <file=openwrt-ar71xx-generic-wzr-hp-g300nh2-squashfs-tftp.bin, mode=octet>
^[[A
^[[A
sent WRQ <file=openwrt-ar71xx-generic-wzr-hp-g300nh2-squashfs-tftp.bin, mode=octet>
^[[A
^[[Asent WRQ <file=openwrt-ar71xx-generic-wzr-hp-g300nh2-squashfs-tftp.bin, mode=octet>
sent WRQ <file=openwrt-ar71xx-generic-wzr-hp-g300nh2-squashfs-tftp.bin, mode=octet>
sent WRQ <file=openwrt-ar71xx-generic-wzr-hp-g300nh2-squashfs-tftp.bin, mode=octet>
sent WRQ <file=openwrt-ar71xx-generic-wzr-hp-g300nh2-squashfs-tftp.bin, mode=octet>
sent WRQ <file=openwrt-ar71xx-generic-wzr-hp-g300nh2-squashfs-tftp.bin, mode=octet>
received ACK <block=0> (Here it started working so I quit repeating the command.)
sent DATA <block=1, 512 bytes>
received ACK <block=1>
sent DATA <block=2, 512 bytes>
received ACK <block=2>

etc., etc.….

sent DATA <block=5120, 512 bytes>
received ACK <block=5120>
sent DATA <block=5121, 36 bytes>
received ACK <block=5121>
Sent 2621476 bytes in 8.1 seconds


6. Once the TFTP was complete, I deleted the static ARP entry on my Mac:

$ sudo arp -da
192.168.11.1 (192.168.11.1) deleted 
192.168.11.255 (192.168.11.255) deleted
224.0.0.251 (224.0.0.251) deleted
255.255.255.255 (255.255.255.255) deleted

7. ...And changed my IP from Manual to DHCP again (reverse of step 2)

8. I then set ping to sound an alert when the router came up:
ping -a 192.168.1.1

9. When the router came up I logged in via HTTP and SSH at 192.168.1.1!







I have to say, after trying Gargoyle for a few days now, it's awesome. It may not be super pretty looking, but the bandwidth control features, etc. are out of this world. And now I've been initiated into the world of custom firmware! (And bricking...!)



Denied! ;)


If you want to try it before committing, there's a really awesome online read-only version of the webUI you can try!:

http://router-firmware-test.gamma.nu/Gargoyle/

Gargoyle isn't for everybody, but free custom firmware is! Or at least it's for everybody who wants to get super-duper business-grade features on a home router!!








Thursday, November 1, 2012

Reset the domain admin password on Windows Server 2008


Easy peasy. Even easier than it was with Server 2003. Thanks Microsoft! My stolen and modified method of resetting the domain admin password (NOT local admin!!!) is thus:

1. Boot into Trinity Rescue Kit live OS (google it).
2. Choose the option to mount all filesystems. (Do NOT choose the menu option to reset the password. It's only for local user accounts, not domain admin.)
3. If it fails, try the option to recognize more hard disk controllers and then try mounting again. I've had this save me before.
4. Choose the go to shell option
5. You'll have to know some basic Linux navigation to do it my way, so see google if you prefer the method of using a Windows install disc: Navigate to the Windows folder and then the System32 folder
6. Rename Utilman.exe to Utilman.exe.bak
7. Rename cmd.exe to Utilman.exe
8. Reboot into Windows
9. At the login screen, press Windows-key+U
10. Type: net user administrator password (replace password with your new one)
11. Close the CLI
12. Login
13. Rename the above files back like they were. This may require you taking ownership/granting Full Control to yourself (you can google that, too)
14. Exhale...

Hope you enjoyed that as much as I did!