WirelessPhreak.com

I like to travel, f*ck with technology, and partake in the occasional tropical drink.
I am also a co-host on The NBD Show podcast.
Follow Me
Showing posts with label network engineer. Show all posts
Showing posts with label network engineer. Show all posts
Captive portals have become synonymous with guest Wi-Fi in enterprise environments. From Starbucks to your doctor's office people expect free and easy to use Wi-Fi,  but what was once easy to do is getting more difficult. Browser security is always improving which has made the goal of HTTPS redirects even more difficult. Captive portal redirection for users going to HTTPS websites has always created SSL related errors -- this has helped create a cry wolf scenario when it comes to HTTPS redirection errors. This error rich environment has helped HSTS errors fly under the radar.

At a high level HSTS (HTTP Strict Transport Security) is a policy that, when enabled, forces a browser to use an HTTPS connection over a HTTP and allows for the SSL certificate to be cached on the browser for a predetermined length of time. With HSTS enabled, clients are protected from protocol downgrading, man in the middle attacks, and cookie hijacking. Most modern browsers (Google Chrome, Mozilla Firefox, Microsoft Edge) come preloaded with a list of sites supporting STS (Strict Transport Security).  Along with the pre-configured list built into browsers, developers can take it upon themselves to enable this policy on their sites. Once enabled a timeout will be sent with the HTTPS header that contains a HSTS TTL Strict-Transport-Security: max-age=31536000”. The certificate received from the site will be honored until the timeout expires. Future attempts to access the site will reference the certificate and,  if the certificate does not match, the browser will not allow the connection to site to be established.

For a more in depth HSTS description check out Troy Hunt's post Understanding HSTS.

So how does HSTS break captive portals?  HSTS enforces the use of HTTPS. It enforces this using two methods that where mentioned earlier the HSTS header or STS preload lists in the browser. When a user connects to a captive portal and launches their browser, normally the wireless controller would intercept their Internet request and a redirect is sent back to the client. This redirect to the captive portal will obviously be a different CN than their original request so, many times, this creates an SSL error. Many users have become numb; accepting the error and continuing to the portal. But HSTS is a little different.


Because HSTS already knows the website should be using HTTPS the browser issues an internal HTTP 307 redirect redirecting the traffic to HTTPS even before it attempts to connect to the server. Once it connects to the server it attempts to validate the HSTS valid certificate. In the case of a redirection the captive portal would not be insuring the same HTTPS HSTS validated certificates. When this happens the browser will assume something nefarious is going on and not allow the redirection to occur. I know one vendor has a bug report filed for this issue - even though its not really a bug - and I don't know if its a fix the wireless vendors can provide.

Bottom line for users connected to a captive portal today:
  • If the user visits an HTTP site, they are immediately redirected to the captive portal. This works regardless of what browser they are using
  • If the user visits an HTTPS site that does not use HSTS, they receive a warning. If they click "Continue" they are redirected to the captive portal. This works regardless of browser
  • If the user visits an HTTPS site that does use HSTS and they are using the browser that supports HSTS they are dead-ended. The only way to get redirected to the captive portal is to visit a different site. Many people have https://www.google.com or Facebook set as their homepage. Both of these sites use HSTS so this might confuse some users.

This issue of not being redirected to a captive portal affects every wireless vendor. As more and more sites use HSTS, getting a proper redirect becomes harder. Hopefully the wireless vendors are sitting on the working group for this new standard and are pushing hard to get it ratified. 

In the long run, if something is not done, enterprises will quit using captive portals if it becomes really tough to get a proper redirect. But for now, being forced to use captive portals, I have not seen a sure fire technical way of getting around the issue.  But you can get around the HSTS errors through communication and policy. 

For example:
I am considering turning off HTTPS redirection all together. What this does is create a predictable environment for the users and the system admins. By not redirecting HTTPS you take the confusion of redirection issues based on SSL certificates, HSTS, or any new security the browsers builds in and level the playing field. Then in the case of using a sponsored portal, the email notification that is sent to visitor and/or person being visited can include the verbiage, "If you are not redirected to the guest portal please type a non secured HTTP website into your browser".  



***UPDATE***
I tested the process below on Mac OS Mojave and it still works.

Original post was created by Bryan at wrmem.net 

Network engineers on Windows have been using the lightweight and open source TFTPD32, for years But for those of us who have evolved and moved to the Mac we have found a couple short comings due to the increased security and sandboxing requirements set by apple. Luckily there’s a built in tftp daemon that you can use in a pinch if you know a couple little tricks.
Here is a link to another post for apple OS Sierra Sky579x.bligspot.com

By default tftpd uses the following folder:
/private/tftpboot
which is hidden in finder, but can be accessed by using “go to folder” or hitting Command+Shift+G and entering /private/tftpboot


To launch the daemon run the following commands:
sudo launchctl load -F /System/Library/LaunchDaemons/tftp.plist
sudo launchctl start com.apple.tftpd
Be sure Read/Write/eXecute permissions are set on the tftpboot folder and any files you wish to transfer:
sudo chmod 777 /private/tftpboot
sudo chmod 777 /private/tftpboot/*
If you’ll be transferring a file TO your TFTP server, the file will technically need to exist on the server beforehand so create it with touch. For example:
sudo touch /private/tftpboot/running-config
sudo chmod 777 /private/tftpboot/running-config
To unload and shutdown your tftp daemon you can run the following command.
sudo launchctl unload -F /System/Library/LaunchDaemons/tftp.plist
If you’d like a graphical front end for launching tftp then check out the great TftpServer. I have found this application not as reliable so I have fallen back to using the built in TFTP server. 
Now you can start transferring your files.


Happy TFTP'ng

Recently we have been moving services to the Cloud (AKA other people's computers.) Amazon Web Services (AWS) offers two different types of cloud service: Gov cloud and Commercial cloud. Gov cloud is marketed to federal, state, and local government entities and offers hosting within the Untied States. The biggest issue I have found with Gov cloud is that only a fraction of the functionality offered in Commercial AWS is offered in Gov cloud. Gov cloud is pretty much a stripped down version of the Commercial AWS.

The cloud in my opinion serves a purpose, first and foremost to host stand-alone public facing applications. This is not a place to host heavy web applications that depend on data or content you are not wiling to host in the cloud. But there is still a need to connect to your corporate network for monitoring, auditing, or publishing content.

That being said, we have recently built out AWS infrastructure and wanted to share the design we came up with. Our first hurdle is the amount Amazon charges for VPN connectivity to a VPC. And if you want connectivity to a VPC it must have its own VPN connection. This was a limitation that drove us crazy. So we asked ourselves, if we are hosting truly stand-alone websites, why do we need direct connectivity to those servers? So with that question in mind we came up with the idea of creating a management VPC that is connected to or corporate network. Then as we create new applications we could add application specific VPCs that where connected to that management VPC. This not only provides a single VPN connection to our corporate network but also isolates each application in its own VPC giving us segmentation at a network and billing level.

Here are the steps we went though:
  1. Assigned a /16 network to the AWS infrastructure and set a static route to our AWS IPSec device. (This is not mandatory since you will only be routing the management VPC network, but I did it to tag those networks for AWS)
  2. Build out the management VPC with a /24. (This will be where we build our management servers such as Bastion hosts, patch server, LDAP, etc.) This VPC does not need to have internet access.
  3. Per application build out of new VPC networks using /22 this gives you 4 /24 networks to use between a web, app, and DB tier across two availability zones. (Remember Elastic Load Balancers are going to burn up a number of IP addresses.)
Pros and Cons of this design:

Pros
  • You only need one VPN connection
  • Complete segmentation between applications
  • Easy to track application billing
  • Super scalable 
  • Added security since the application VPC servers can not route directly to your corporate network
Cons
  • You can not route through the management VPC to connect directly to a server in the application VPC, or the reverse. You will need to use an SSH proxy server in the management VPC
  • Web applications that are dependent on corporate resources will not work
  • You will need to build all your management tools in the management VPC to connect and monitor application VPC servers








I have searched high and low for a decent low-priced alternative for Visio on the Mac, and I think I have finally found one.

yEd Graph Editor is a powerful desktop application that can be used to quickly and effectively generate high-quality diagrams. Create diagrams manually, or import your external data for analysis. Thier automatic layout algorithms arrange even large data sets with just the press of a button.


The install is strait forward and works great, but us network guys want cisco icons.  The network icons that come with are a little weak.  So I found a German website that had the Cisco default icons as .svg files.  Here is the link to the download cisco_svg_icons.

Next how to install the icons.

  1. Open yEd Editor Go to Edit --> Pallte Manager
  2. Create a new Click New Section (name it)
  3. Highlight newly created Section and click import symbols
  4. Select .svg symbols and import them.
That's it... You should have a diagram tool that will let you make professional looking network diagrams.

Let me know if you have any better alternatives.


Bluetooth Serial Adapter (set up)

Working in a data center allot of the time you are bouncing from one pice of equipment to another. Plugged into a console-port buried in a cabinet or behind cabling impossible to get to. So I thought I would share my wireless serial setup.

Most new laptops do not have the DB-9 serial ports of yesteryear,  and managing network equipment often times requires that old school 9600 Baud serial connection. So here are the components I used to set up my own bluetooth serial rig.

If you are weary as I was don't worry. I have been using mine for almost a year now and it works great. In fact it has worked on devices that my USB serial adapter wouldn't , i.e. Cisco CSS. I have used it with a MacBook Pro running OSX 10.6 & 10.7, as well as Windows 7 with no problems. I have found it to be a little bit more stable in OSX, I think because Windows 7 Bluetooth can be kind of finicky. Let me know if you have a different Bluetooth serial setup and I will add a link.






Serial Bluetooth Adapter UCBT232B












Energizer Mini-USB Portable Charger for BlackBerry - Black










C2G / Cables to Go - 02782 - DB9 M/M Mini Gender Changer








With the popularity of the iPhones and iPads, the Mac has become practically viral among technology professionals. Even without official company support many of these users have banded together to create user-support communities within their companies.  I was recently at a large network hardware company and they threw out some statistics about Mac adoption.  Only 4 years ago they began to allow staff to purchase Apple devices, and since then almost 45% of their employees run a Mac. This is with no official technical support.  So how do they make the Mac Network engineer friendly?

There are several things a Network engineer needs.
  1. Serial Terminal App - The Mac has several options including the built in terminal app.  But many of us like to have something more.  Secure CRT $99.00 - Great app kinda expensive though. There is also CoolTerm, it's free and so far so good, really clean interface and easy to use.
  2. SSH Client - Once again the built in Mac SSH app is great and some cleaver developer out there created an app to manage multiple telnet and SSH connections.  JellyfiSSH $3.99, in the Apple app store, is a really easy and intuitive way of bookmarking all those connections.
  3. TFTP Server - I haven't really explored TFTP on the mac, but I found TFTP Client $1.99, in the Apple app store.  I haven't had a chance to use it and I have to admit I love tftp32 for windows, but let me know what you find.
  4. Serial Port - Steve Job's obsession with sleek industrial design killed off the com port a long time ago. Without a com port a network engineer is practically dead in the water.  There have been some really good USB serial adapters like the Keyspan by Tripp Light USA-19H, but recently I have been on the hunt for a Bluetooth serial adapter.  After looking online, Bluetooth serial adapters range from $40 to $250 dollars.  I am not looking to spend a ton of money so, luckily, I found a great post by Chris Marget on fragmentationneeded.net. In his post he highlights the UConnect BT232B from US Converters.  He says it's a slam dunk for Mac or PC and it seems very reasonably priced at $45.00.  I can't wait to give it a try and update once I get a look at it.
  5. Text Editor -   The text editor in the Mac is as good as notepad but you may want more.  Syntax highlighting is kinda like crack for those who are look at code or configs all day.  I wanted to list a couple text editor I have found invaluable. The first is Ultra Edit a robust text editor with a ton of extras and at $59 bucks well worth it. They also provide a ton of free extras such as the Cisco IOS language pack found here.  There is also a pretty good free alternative called Text Wrangler, it is the freeware version of BBEdit which i have not used, but it to also has a Cisco IOS language pack that can be downloaded from here.
Lastly, I welcome your ideas so feel free to list any apps hardware tor tricks you have found to make the Mac the network engineers friend.