CurrentC – So far, I haven’t found official details, but as I understand it, they require your name, social security number, drivers license number, and linked bank account details. They keep a history of your purchases, including medical (though offer a way to opt-out of that). It works by scanning a QR code with your phone, then allowing the merchant to scan your payment QR code. At some point, you enter your 4 digit PIN code. I’m not sure if the payment code is dynamic or static. The merchant can then perform a withdrawal directly from your linked bank account. Your data is stored securely in the cloud, not on your phone. (If the SSN, etc. requirements are wrong, please someone let me know)
ApplePay – Take a photo of your credit card to add it. It recognizes your card number, expiration date, etc. Once registered, your card number (and photo) isn’t even stored on your phone. A unique device account number is assigned, which is encrypted and stored in a dedicated chip in your phone. When you make a purchase, you validate the purchase with your fingerprint. The merchant gets your device account number along with a transaction specific dynamic security code. They don’t get your card number. In fact, they don’t even get your name. The charge goes against your credit card, just like if you paid via the mag-stripe card. You get the same protections afford using your card.
Perhaps it is secure, but CurrentC seems like a huge data breach disaster waiting to happen. Imagine all that data falling into the hands of the wrong person. Further, with your bank account details, a bad actor could conceivably drain your account, forcing you to fight your bank to get your own money back. If a data breach happened with ApplePay and your data was compromised, you still have the protection of the credit card in place.
Lastly, there are a log of big name retailers behind CurrentC. I can’t help but notice that one of those big names is Target. With the size of the data breach that happened at Target one year ago, I’m certain I don’t want them having direct access to my bank accounts.
A few days ago, Palo Alo released version 6.1.0 of their firewall software. This evening, I loaded it onto my PA-200 and did a bit of looking around. There are a lot of small changes, and apparently, some bug fixes. I had a decryption issue with 6.0.5-h3, but it’s disappeared with this update. I still can’t get dropbox to work while decrypting traffic, though (so it’s in my Decrypt-exclude policy).
While I’m not the most familiar person with PA firewalls, having only just started using them recently, I could still pick out some things that were different from the version I have been running for a week.
It appears that there is a little more info exposed in the logs. Perhaps these columns were there before, but I don’t recall seeing Session End Reason or Byte counts for each log entry.
App Scope seems to have new graphs that look very snazzy.
On the Security Policy screen, there are now two new rules that are Read Only. One is intrazone-default and the other is interzone-default. When adding new rules, there is a new Rule Type dropdown that lets you select Universal (default), intrazone, or interzone. Haven’t read up on this, but it appears that you’ll be able to add rules to affect behavior between members in the same zone… Not really sure what interzone buys you, as I’d think that would be the old behavior.
Under DHCP, there’s now an “Ippool Subnet” field… I think that’s new also. If it’s not new, mine were blank….
Under GlobalProtect Portals, they have adopted a slightly different view that lets you expand a Plus sign to see more info. The Gateway screen doesn’t adopt this new change, oddly enough.
I’m sure there are many more differences… Hopefully, good ones!
I have a PA-200 hooked up to a cable modem, getting a DHCP address for the WAN. I’ve been trying to get GlobalProtect configured so that I can VPN into this network from the outside. Unfortunately, I couldn’t find a document walking me through how to do this. I experimented, taking clues from multiple documents, and then kept at it until I got it working. First, I got IPsec working from an iPhone. Now that I’ve got the SSL VPN also working from a Windows 7 machine, I wanted to write up what I did, so I can do it again if needed. I also thought that writing it up would help my understanding of how the GlobalProtect Portal and Gateway work together. As with all things computers, this method is probably not the only way to do this, but it works.
Much of the official Palo Alto documentation works off of the assumption that you have a static IP. In order to get around that issue, you need to have a machine on your internal network performing dynamic DNS. If you aren’t familiar with that, a dynamic DNS service keeps a domain name pointing to the same device, despite the fact that the IP address of the device changes. Before you do anything else, get that working, so when you ping your public DNS name you have, it always returns your current WAN address. Below, you’ll create an Address object in the Palo Alto that points to your public DNS name. The PA periodically resolves that name (every 30 minutes I believe) and if it changes, all the rules, etc using that IP get changed.
Also, before continuing, go to Device > GlobalProtect Client and download the latest one, then activate it.
1. Create Loopback Interfaces: You need two interfaces, one for the portal (192.168.99.1) and one for the gateway (192.168.99.2). Make sure you have HTTPS available in the management profile of these. They should be in your main Virtual Router, untrusted zone. You can use any unused private IPs you want here, but I’ll be referring to the ones listed above later in this document.
2. Create a tunnel interface, using the next available number (like tunnel.1). Use the same Virtual Router as above, but place this in the trusted zone. Alternatively, you could create a new zone and place it there, but then you’d need to add a security policy to allow traffic from people VPN’ed in to specific internal resources.
3. On Objects > Services, add services for UDP 500 (ike), UDP 4501 (esp), TCP 7000 (for GP Portal) and TCP 7001 (for GP Gateway). You can use whatever ports you want for the last two, just keep them straight.
5. On Objects > Addresses, add a new object named after your dynamic DNS name, of type FQDN, with the dynamic name as the address. Periodically, the PA will check external sources to see what public IP you have and all your rules will be around it.
6. On Device > Certificates, generate a new cert, making it a Certificate Authority. The Subject name should be your dynamic DNS name. After generating the cert, edit it and check the Trusted CA Root checkbox. The names here should reflect the real dynamic DNS name you have.
7. On Policies > NAT, add a new NAT rule for access to your portal. The source AND destination zone should be untrusted, destination interface should be your external interface, destination address should be your dynamic dns object. Destination service, port 7000. On the Translated tab, you want Destination, then put the IP address of your portal loopback address, and port 443. This will translate external requests for port 7000 to the internal loopback on port 443. See the screenshot at step 13.
8. On Policies > Security, add a new security policy for access to your portal. Source and Dest zones are untrusted. Services are port 7000 and HTTPS. Not 100% sure you need both. See the screenshot at step 14.
9. On Device > Authentication Profile, add a new one. For simplicity sake, I used Local authentication (in the dropdown under the allow list window). My profile is “Local-Auth”. If you have an AD server, or some other LDAP source, you’ll probably want to get that configured here once everything else is working. If you use a Local Auth policy, be sure to go to Device > Users and add a user.
10. On Network > Portals, add your portal. On the Portal Configuration section, set your interface as your portal loopback. Set the IP Address (in my case, 192.168.99.1), and select the cert you just made for Server Certificate. Select your Authentication Profile.
On the Client Configuration tab, add your cert under Trusted Root CA, then add a new Client Config.
11. On Network > Gateways, add your Gateway. On the General tab, name it, put it on the 2nd loopback, set the IP address (192.168.99.2 in my case), and select your new cert for the Server Certificate. Select your Authentication Profile.
Go to Client Config. On the tunnel settings tab, check the Tunnel mode checkbox, select your tunnel interface, check Enable IPSec and Enable X-Auth Support, fill in a group name and group password. This is needed for IOS IPSec clients.
On the Network Settings tab, configure it as you wish. In my case, my inheritance source is my WAN interface, also for DNS. Add an IP Pool with an unused subnet. For Access Route, you may want to think about it a bit. You could put 0.0.0.0/0 here, which would route ALL of your end-user traffic through the VPN, or you could use specific routes here. So, you could use 10.0.0.0/8, etc. if you wanted to only have certain traffic go across the tunnel.
12. On Policies, NAT, add a new policy for your Gateway. This is for IPsec specifically. Set it the same as #7 above, except the service should be your IPsec service group, and your destination address is your Gateway loopback (192.168.99.2 in my case). See the screenshot on step 13.
13. On Policies, NAT, add a new policy for Windows and Mac clients. Set it the same as above, except for port 7001, with the translated destination address being your gateway loopback (again 192.168.99.2 for me), and your destination port as 443.
To connect with an IOS device, make sure you aren’t on your local Wifi, go to Settings > General > VPN, and Add a Configuration. Select IPSec at the top. Enter your Dynamic DNS name as the server (with no port numbers), set your username and password, and set the group name and Secret.
To connect with a Mac / Windows machine, connect to a different public network segment (friend’s wifi, Starbucks, whatever), then in your browser, visit http://yourdynamic.dns:7000/. You should be able to log in from there. Next, download and install the client (from the resulting page, after you logged in). When you start the client, configure it to talk to the same address as above (:7000).
Good luck and happy VPN’ing!
I was very happy to get a lab licensed PA-200 in the mail early this week. If you don’t know, it’s the lowest-end model firewall from Palo Alto Networks. According to the Gartner report, Palo Alto and CheckPoint are locked in an epic battle for #1 in the enterprise firewall space. I’ve got a good bit of experience with CheckPoint, so I was eager to see what this competitor brought to the party.
The Palo Alto is not without a learning curve. Coming from a CheckPoint background, I had plenty of experience with firewalls, but the way things are done is just different in the Palo Alto world. First, the concept of Zones is something that Palo Alto embraces. This lets you group interfaces together, put them in the same zone, and traffic between those interfaces is routed without any firewall in the path.
With the large CheckPoint firewalls, we manage them using Smart Dashboard. To manage a PA firewall? It’s all in the WebGUI. Everything from configuration to looking at logs, it’s all right there. This is nice, as I once connected via my iPhone and was able to make a firewall change, though I don’t recommend doing that often! But you absolutely can’t do that on the large CheckPoint firewalls. Don’t get me wrong, there are tradeoffs with a Web interface, but I really do like the fact that there is no need to load a client to manage it.
One thing that is a little difficult to get used to with the PA series is that they are all the same! I’m used to having CheckPoints for small business, and for Enterprise having completely different feature sets. Then you have to worry about what blades to get. With Palo Alto, the highest end firewall has the same user interface as the low end. So, if you get the smallest firewall for your lab, you’ll be able to see how the high-end units will operate (the higher-end units are much faster at committing config changes, of course). Palo Alto does have a few subscription features, but it includes quite a bit of functionality in the base price.
So far, I’ve enabled decryption for a few devices on my lab network. This involved creating certificates and distributing them to the devices that will have their traffic be decrypted. For most sites, this seems to work very well, but I have ran across a few that it balks on. I think the issue may be that the root cert those sites use isn’t trusted by the Palo Alto, but I’ve not checked too deep into it yet. For the most part, the PA-200 effectively does a man-in-the-middle with your SSL traffic. Having this enabled didn’t seem to actually slow things down much, if at all. I don’t know if any malware is using SSL today (my guess is that it is), so being able to see inside the traffic and spot the bad actors is a good thing. I’m also running with Vulnerability Protection, Anti-Spyware, URL Filtering, and WildFire enabled. I did have AntiVirus scanning enabled, but did see a noticeable decrease in performance with that turned on, so it was disabled. On their higher end firewalls, you can probably safely run AV without a significant drop in performance, but it did not appear to be the case for the PA-200.
I have a number of devices including a NAS attached to the trusted network segment. Many of these devices are running static DHCP addresses. Setting them up was easy, but one thing that struck me was you could only put the MAC and an IP into the configuration. There was no way to mark which IP address was which device. If I had my way, this would be built into an Address object, so there would be a name associated with the DHCP reservation. Ideally, you’d simply add an object with the MAC address, and it would add the static reservation for you. Even better would be if they could figure out some way to tie it into their DNS proxy, so these objects are automatically in DNS. These are features that are mainly useful for a small office environment, probably not the market PA is gunning for, but they would make nice additions.
I do like the flexibility of the DNS Proxy. You configure it to forward everything to a pair of DNS servers. There are options to add your own static FQDN entries for individual names, plus the ability to have entire zones forwarded to specific DNS servers. You can also have multiple DNS proxies, listening on different interfaces, if you desire.
I have the PA-200 attached to a Cable Modem, pulling a DHCP address., something that complicates things if you wish to use GlobalProtect to run an SSL VPN. Late last night, I spent about 2 hours putting together documentation from several sources to come up with a configuration that works for SSL-VPN on a DHCP address. So far I’ve only tested it with the iPhones built-in VPN client (IPsec), but it worked great. I plan to test it with Windows and Mac clients in the next few days.
I found it refreshing that the PA SSL VPN solution is not based on Java. This means they have to have three individual clients (32 bit Windows, 64 bit Windows, and a combined 32/64 bit Mac OS X client). The CheckPoint SSL VPN product is based on Java. When I first installed it on my Mac, it worked well, but it has been giving me problems as Java or OS X has upgraded. CheckPoint doesn’t seem to put much energy in keeping that client up-to-date, but PA seems to.
There is a QOS feature built-in. I added a single QOS rule, placing traffic from a VoIP device into Queue 1, which is the “Real Time” priority queue. I talked on it for almost an hour as a test, and it worked beautifully the entire time. The caller on the other end reported that it sounded like I was right there with her.
Anyhow, that’s about all I have to report at this point.
The Apple SIM (shipping in every LTE enabled iPad Air 2) sounded like a great idea. Pick the carrier you want for a month or two, then switch to another one, depending on your needs.
Today, however, I found out that AT&T is LOCKING the Apple SIM when you choose to use them!
This doesn’t lock your iPad, but it makes it more difficult to switch to another carrier. You can do it, but it’s a hassle of having to get another Apple SIM (or a SIM from the desired carrier). That sort of defeats the purpose of this generic SIM that Apple introduced.
According to the linked article above:
AT&T did not explain why it opted to lock the SIM card to its network, however, with the spokesperson saying “it’s just simply the way we’ve chosen to do it.”
Wow. That seems to indicate that they didn’t have any technical reason to do it this way. It’s just how they have chosen to do it.
Basically, they are saying “We didn’t HAVE to make it a hassle to switch service to a competitor. We just wanted to.”
AT&T will probably get a few people to keep using them month after month with this tactic, but I imagine many more will simply choose to use one of their competitors that doesn’t use this anti-consumer practice.
That is the key, right there. One of the most successful methods of budgeting is the envelope method. It involves taking all of your money and dividing it among envelopes, one for each category of spending. When you run out of money in that category, you are done spending from it. By having your money right there in front of you, you can count it, and see exactly how much you have. Thinking ahead just a little will let you plan for how much to spend, assuming you know when you’ll get paid again.
This method compartmentalizes your money. Instead of having a single balance of $2000, you could have an envelope for these sample categories:
Car Payment $300
Car Insurance $100
Cell Phone $50
Cable TV & Internet $100
Breaking your money down into these compartments helps you to see exactly what each pile of money is for. Instead of feeling like you have $2000, you’ll see that, in truth, most of that money is spoken for. Placing it in these compartments lets you see how scarce a resource your money is, so that you can make more informed decisions.
Before I started budgeting, I suffered from not knowing where all my money went. Now that I’m budgeting to the penny every month, I can tell you exactly how much money I have available to spend on just about anything I need.
Now, I don’t actually suggest that anyone carry around all their money in envelopes. Instead, I’ve been using YNAB (YouNeedABudget) for about a year and a half. With it, you place your income into virtual envelopes called budget categories. YNAB is an amazing piece of software that runs on your Windows or Mac computer, and syncs to your iPhone or Android smart phone. That means at any time you can pull out your phone and see exactly how much you have available to spend in any of your budget categories. Sharing a budget with your spouse? No problem! It will sync between multiple phones, so you’ll know within minutes of your spouse entering new transactions. It even uses GPS to make data entry easy for places you’ve visited before. It lets you track your budget and your spending, in one place. Read more about it here: YouNeedABudget
Recently there have been a number of high profile security issues. Heartbleed, ShellShock, and POODLE have all hit in 2014.
I must say that I like the fact that these significant security vulnerabilities are getting these hip nick-names in the media. That means that more and more people who are less technical are going to hear about the issues.
It also means there is going to be bad journalism. Get everyone up in arms about the latest threat, real or imagined.
Today, I ran across this really bad article:
Here’s the sub-title:
We took a hacker to a café and, in 20 minutes, he knew where everyone else was born, what schools they attended, and the last five things they googled.
Exaggerate much? This is complete hyperbole.
How can I be sure? Because just about every major site has gone to SSL by default. Don’t believe me? Go to google.com in another tab. You’ll see that you’re redirected to an SSL page, and you’ll have the familiar lock icon visible somewhere in your browser bar. Even social sites like facebook have gone to SSL by default.
What does that prove?
Well, if this hacker really did have a way to get by SSL encryption so easily, without giving the victims any warning at all, then any reporter worth their salt would publish the details, as that would be a HUGE story. On-line shopping wouldn’t be secure. Stock trading, or any other financial transactions would be completely open to prying eyes. And it would matter if it were at a cafe, or from the comfort of your home, you could still be victimized.
But, conveniently, this author included almost no details at all.
How is this hacker able to overcome SSL encryption? I’d guess the answer is via a man-in-the-middle attack, whereby it presents it’s own SSL certificate and proxies the requests to the real website. If that is the case, the end-user’s browser would warn the user that security may be compromised. If the journalist clicked through that warning it was not mentioned in the article. That’s a detail that should not have been glossed over, as it makes things seem far worse than reality.
I can see the possibility that random people would click through an SSL warning without thought, but the fact that there was a warning is not something that should have been skipped. If there was no warning, that would be a story.
I suspect that the journalist who wrote this is not terribly technical. I’ll not assume that he understands exactly what is happening and has chosen to leave out key details to get more page clicks. For that matter, perhaps the original author had those details included, but some editor cut them out to “add more sizzle”.
Publications who wish to have any authority on matters of Internet security should get someone who is technically competent to do their reporting. That doesn’t mean that they need to be a programmer or networking expert, but someone who understands cryptography and is aware of how security works. Chances are good that the typical journalist is no more equipped to report on security than the people who blindly click through those SSL warning messages.
This article makes it sound like the hacker had to do nothing more than sit in the path of the traffic and he could get everything, encrypted or not. If SSL is so easy to bypass, we should all be very worried about the people who work at ISPs, as they could easily do the same thing, but not with the 10–20 people at a cafe, but to tens of thousands of people. ISPs generally have several large circuits that connect to their provider. All it would take is a laptop running wireshark plugged into a mirrored port, and all that data could be captured, to be later decrypted with the magic “decryption software” the author mentions at the end of paragraph 1 under the Session 3 heading.