Web Admin Blog

Real Web Admins. Real World Experience.

Completing the LASCON 2017 Badge Game

For those who don’t know, every year I put together a game that starts on the back of the LASCON badge.  It’s typically some combination of crypto challenges alongside application security vulnerabilities with the goal of having it take somewhere around 1-3 hours, depending on experience, to complete.  Those who complete the game are rewarded with one of these awesome challenge coins:

LASCON 2017 Challenge Coin

Now, I know that there are people out there who look at one of these things and don’t even know where to start so, it is in the spirit of education and learning that I share with you my notes on how to complete the LASCON 2017 Badge Game.

Stage 1

On the back of the LASCON badge it reads as follows:

Another year, another game
Solve the puzzles, write your name
These characters aren’t a work of art
Ask a mason how to start
The key word in the text above is “mason”.  If you were to Google the term “mason cipher”, you would come across an interesting kind of cipher called a Pigpen/Masonic/Freemason Cipher.  The idea being that they take a geometric pattern and map the letters of the alphabet to the locations on the pattern.  Here’s an example that you could use to translate this text:
Freemason Cipher
Once translated, you get the following message:
To start the badge game go to nocsal dot lascon dot org
Stage 2
When you go to nocsal.lascon.org it defaults to having a GET parameter of page=winners.php.  This is a sign that it is vulnerable to directory traversal.  There is also a comment in the page source that says “Get badge game winners from /files/winners.php”.  If you navigate to http://nocsal.lascon.org/files/, it has directory browsing enabled and you can see a test.php page there, in addition to winners.php.  If you go to http://nocsal.lascon.org/?page=test.php, you will see it grabs the test.php code and pulls it into the page source.  If you view source, you can see the text is as follows:
// Test ability to grab winners table from the database
$servername = “localhost”;
$username = “lascon”;
$password = “e3fmGYHDrc6MNCEMmLWj”;
$dbname = “lascon”;
$conn = new mysqli($servername, $username, $password, $dbname);
$sql = “SELECT * FROM lascon_winners”;
$result = $conn->query($sql);
$array = $result->fetch_array();
We now have a database username and password.

Stage 3

Even though the database connection that we found uses a servername of “localhost”, it turns out that mysql is open on the public IP interface of the server as well.  We can use a mysql client to connect to nocsal.lascon.org with username “lascon” and password “e3fmGYHDrc6MNCEMmLWj” (mysql -h nocsal.lascon.org -u lascon -p).  Once in the database, the user has access to read the lascon database and will see a “lascon_winners”, “users”, and “websites” table.  When you try to insert into the lascon_winners table, you quickly realize that you do not have insert permissions, so you cannot insert into the lascon_winners table.  In the users table, you see an entry with username “admin” and password “NFJXaTNuc0pyR2Y2c25iNG9Va1c=“.  In the websites table, you see a bunch of sites and one hiding amongst the others is ttpcteebhz.lascon.org.

Stage 4

When you go to http://ttpcteebhz.lascon.org in your browser, you see a form with a spot for a username and password.  You can base64 decode the string you found int he database (NFJXaTNuc0pyR2Y2c25iNG9Va1c=) to get the value “4RWi3nsJrGf6snb4oUkW”.  Once you have that, you can log in with username “admin” and password “4RWi3nsJrGf6snb4oUkW”.

Stage 5

Once logged in with the username and password, you see a blank page.  Once you view the page source, however, you see that it contains a hidden form and fields:

<form name=”submission” method=”post” action=””>
<input type=”hidden” name=”first_name” value=”” readonly />
<input type=”hidden” name=”last_name” value=”” readonly />
<input type=”hidden” name=”phone” value=”” readonly />
<input type=”hidden” name=”email” value=”” readonly />

The last part of the challenge you could accomplish with a proxy tool, but I just used the Developer Tools in Chrome.  I changed the hidden fields to text fields, removed the readonly values, and then added a form submit button. Once submitted, the game is over and you win!

A Quick Summary of Puzzles Solved / Vulnerabilities in the Badge Game

  • Freemason Cipher
  • Directory Traversal
  • Information Disclosure in Comments
  • Directory Browsing Enabled
  • Hard-Coded Database Credentials
  • MySQL Service Publicly Accessible
  • BASE64 Encoded Passwords
  • Hidden and Read-Only Form Fields
  • Missing Form Submit Button

Completing the BSides Austin 2016 Mini-CTF

The BSides Austin 2016 Mini-CTF began with the back of the badge.  There was a large QR code which took a very long time for me to scan with my phone, and when I finally got it, it was just the numbers “07263584”.  Not very useful.  Below that, however, there was  a string of letters and numbers as follows:


The string very obviously looked like BASE64 so I decoded it to get the following URL:


On that page it reads:

That start was easy! You have shown that you are curious and that is the key. As your reward, you may have this:flag 1: BSides{D3c0d3s_R_3Z}Do you want to play some more? If so, read on…

1. Turn in flags by sending an email to bsidesaustin@gmail.com. The email must contain your name, email address, and the flag you are turning in

2. There are three flags total, each should be submitted via email.

3. Do not scan this server with automated tools. They are not necessary and could cause performance issues. If you scan this server, you could be disqualified.

4. Send in flag 1 then click here to continue…

I submitted the flag and moved on to the next page at:


On that page there was a file named coms.pcap.  With the “pcap” extension, I went ahead and loaded up into Wireshark.  It was a 1113 line packet capture file with encrypted Google traffic, YouTube rick rolls, and more.  Only a handful of the requests were for, the IP address belonging to ctf.bsidesaustin.org.  When I followed the TCP stream, it was for a request to http://ctf.bsidesaustin.org:31337/level3/index.html.  When I went to that URL, however, it was as if nothing was listening.  Eventually, I filtered the pcap by that IP as the destination and found a sequence of requests to that IP at odd ports…1025…2300…1337…1337.  This smelled suspiciously of port knocking so I wrote a quick bash script using nmap to test it out:

for x in 1025 2300 1337; do nmap -Pn –host_timeout 201 –max-retries 0 -p $x; done

Finally, I hit the page on port 31337:


Sure enough, now I get a response that says:

Congratulations, you have completed the second challenge!The second flag is: BSidesAustin{C4rV1NG_UP_PC4Ps}

Click here to continue to the final challenge!

I submitted the flag and moved on to the next page at:


On this page we see a network interface test where you can specify an IP as a ping destination, and when you hit “Enter”, it gives you the results of the ping:

PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=64 time=0.026 ms— ping statistics —
1 packets transmitted, 1 received, 0% packet loss, time 0ms

rtt min/avg/max/mdev = 0.026/0.026/0.026/0.000 ms

Entering some non-IP address information, I got a message like:

Error running ping -c 1

So, there is some filtering on it, but it also looks like some data is making it through.  I figured out that I could specify the destination as a GET instead of the POST with by adding “?dest=” to the URL and that worked.  I tried a bunch of different combinations of “;”, “&&”, and other OS command functions that would piggyback on the existing function with no luck.  Eventually, I figured out that “%0A”, the ASCII line feed control character, was not filtered and I could use that to run more commands.  For example:


Returned a listing of “index.cgi” and “the” in that directory.  Then:


Showed that “the” actually expanded to “/the/roof/the/roof/the/roof/is/on/fire/flag.txt”.  Sweet!  I found the flag!  Now to open it.


That returned:

PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=64 time=0.026 ms— ping statistics —
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.026/0.026/0.026/0.000 ms
Great job! The third and final flag is:BSidesAustin{F1lt3rs_R_Fun}

Congratulations, you have completed the challenge!

Final flag submitted.  Game over!

What Powerball, Poker, and SimpleRisk Have in Common

With an estimated Powerball Jackpot of $1.5B, everybody is talking about it right now.  I’ve got my tickets, but with a prize that big, I’m having an easier time listing the things that I can’t buy with the money, rather than what I can.  That said, I keep coming back to a concept that statisticians refer to as “expected return”.  What it means is that even though your odds of winning the Powerball aren’t changing (roughly 1 in 292 million), the bigger the jackpot, the bigger the expected return.  To calculate it, just take the odds and multiply by the reward value.

1/292m x $1.5B = $5.14

So, before you factor in taxes, the possibility of splits, and other factors that might affect your reward, the expected return is something like $5.14 on a $2 ticket.  Not too bad.  Factoring in the cash option ($930M), a 40% Federal tax, an extra 25-28% tax from the IRS for gambling winnings, and perhaps even state taxes, however, this number drops well below the $2 range making it far less appealing to buy a ticket.  I found interesting articles in Business Insider and Wired that elaborate further on this idea.

The same concept can be applied to poker in what they refer to as “pot odds”.  You take the odds of a winning hand and multiply it by the size of the pot.  In poker, often times players are more willing to play what is normally a statistically losing hand if it gives them a shot at more money (ie. a bigger pot).

So what does this have to do with SimpleRisk and risk management?  The classic formula for calculating risk is RISK = LIKELIHOOD x IMPACT and is the exact same formula used for calculating expected return and pot odds.  You’re simply taking the likelihood of an event happening regardless of whether it is a positive or negative outcome and multiply it by the estimated dollar value of that outcome.  Pretty simple.  And that is what Powerball, Poker, and SimpleRisk have in common.

The OWASP Board “Ivory Tower” Dilemma

I have been an active member of the OWASP community in some form since 2007.  I’ve been the OWASP Austin Chapter Leader, served as the Chair of the Global Chapters Committee, and, most recently, was elected (and re-elected) to the OWASP Board of Directors.  In the past, I have heard a number of people in our community compare the Board to an “Ivory Tower”.  They would say that they were unapproachable and preferred to let others do the work while they pulled the strings of the Foundation from behind the scenes.  I think there may be some truth to that statement, but I told myself when I ran for the Board that I wouldn’t be like that.  I want people to feel like I am out there actively trying to solve the problems of our community.  Case in point, in my 23 months on the OWASP Board, I have proposed more Bylaw changes and new policies than anybody else.

As I continue to try to be a man of action, I find that I am often one of the first Board members on the scene in times of crisis.  On multiple occasions I’ve shunned the historical “Ivory Tower” approach to managing the organization and dove head in to the situation at hand.  My assumption has been that I was elected because I have an opinion, not in spite of it.  In each case I’ve tried to present a clear and concise analysis of my view of the situation.  I’ve tried to offer up suggestions on next steps or provide data points that others may not have been aware of.  Being such a diverse community has many strengths, however, one weakness is that it is difficult to drive to a consensus on anything.  It really doesn’t matter what side of the issue you are on, it always seems like some will agree with you and others will not.  Frequently, what begins as an intended friendly and spirited debate, ends with somebody feeling marginalized because a decision was made that they did not agree with.  It’s sad when this happens, but is inevitable when you mix passionate people with issues that do not have binary answers.

This leads me back to the “Ivory Tower” dilemma.  If my desire is to actively be a part of the community, then I place myself directly in a position of potential conflict when I speak.  I’m not allowed to speak as Josh, the community member, because the perception is that I am always speaking with my Board member hat on.  And I have a strong feeling that this perception of Board members speaking authoritatively is what leads a person on the other side to feel marginalized.  Definitely not intended, at least on my part, but that’s what I’ve started to gather from some of the feedback that I’ve received.  So if that’s the case, then I begin to wonder if the situation would have been better off had I held my tongue and refrained from jumping into the discussion in order to let our community continue to fight it out or to let another Board member, our Executive Director, or somebody else communicate the Board’s analysis and actions.  But, if I do that, aren’t I now perpetuating the stereotype of the OWASP Board being an “Ivory Tower”?

I’m not sure that there is a right or wrong answer here and nobody said that being a Board member would be easy, but I can’t say that I ever expected to need to give up my personal voice with the community (the one that likely got me elected to the Board in the first place) in order to serve the Board.  That said, it genuinely saddens me when an extremely valued OWASP volunteer feels the need to leave in order to make a point.  It is a huge loss for the OWASP Foundation and one that I, regrettably, played a role in provoking.  I don’t apologize for my stance on the issue that was being debated.  I feel that we should all be allowed to have an opinion and I still support the actions of the Board thus far.  That said, if I could take back my words, crawl back into that “Ivory Tower”, and let someone else do the talking in this particular situation, I’m sorry to say that I would.

Johanna, I’m sorry that it turned out this way.  You may not believe it, but I sincerely respect and appreciate what you have done for the OWASP Foundation more than words can express.  You have brought order where there was chaos and a dedication to the cause that was matched only by your intellect.  I feel that we don’t have to always agree on a vision in order for me to appreciate your perspective.  I regret that I never conveyed that to you before now.  I’m sorry.

SSH on a Mac Errors with “Write Failed: Broken Pipe”

Recently I had an issue when moving to a new Mac on OSX when I was trying to SSH to a Linux server.  It would make the initial connection and then prompt me for a password.  Once I entered the password, however, it would just hang (ctrl+c wouldn’t even escape out) until eventually it would break to the command line with the message “Write Failed: Broken Pipe”.  After digging through various posts online, most of which were referring to timing out due to inactivity, I finally found a winner.  I edited the /etc/sshd_config file and set the ClientAliveInterval value to 300.  Then, I rebooted my Mac.  The next time I tried to SSH to the same server, everything connected as expected.  I hope this helps someone else in the future who is running up against the same issue I had.

Fixing when crashplan won’t start anymore on your Drobo

Even though the Drobo is supposed to be a pretty rock-solid tool for backing up your files, there are still plenty of reasons why one would want to keep a copy of those files elsewhere just in case.  For example, what would happen if there is a fire and your Drobo is damaged.  Are you OK with losing everything?  I’ve even heard about the rare case where the Drobo drives get out of sync and a complete reformat is necessary; causing you to lose everything.  To prevent this, it is a good idea to install the Crashplan Drobo app and ensure that a copy of your data is recoverable, even if the worst case scenario happens with your Drobo.

If you do as I mention above, chances are that things will work well for a while and then suddenly, one day, you will find that Crashplan is no longer running on your Drobo.  Despite multiple attempts to start it back up, you will inevitably find yourself staring at a message saying either “crashplan is enabled and stopped” or “crashplan is disabled and stopped” and will be clueless, like I was, in terms of how to fix it.  The good news is that after months of struggling with this, I finally came across a post on the DroboSpace forums from the guy who packages the Crashplan application for Drobo.  It was a bit cryptic at first, but eventually I was able to interpret what he was saying and I wanted to share it with everyone in a bit more layman’s terms.

The underlying issue here is that Crashplan is configured to automatically upgrade itself on the Drobo.  When this happens, it downloads the replacement files and goes to run the upgrade script.  Unfortunately, the Crashplan team does not write the upgrade script to work in the Busybox environment (the one that runs on your Drobo) and the script breaks.  By tweaking the script ever so slightly, you can get it to run the upgrade and Crashplan will once again start up on your Drobo.  Here are the steps to do it:

  1. SSH into your Drobo with the command “ssh -L 4201:localhost:4243 root@[your Drobo IP]
  2. Take a look at the /tmp/DroboApps/crashplan/log.txt file and you’ll probably see a message saying something like “Error: Could not find or load main class com.backup42.service.CPService”
  3. Go to the crashplan upgrade directory with the command “cd /mnt/DroboFS/Shares/DroboApps/crashplan/app/upgrade
  4. Here you will see a directory whose name looks like a random value like “1388642400364.1415587076262”.  I believe you should see a new one of these directories for each version you are upgrading to.  Change to that directory using the command “cd 1388642400364.1415587076262” substituting for whatever directory name you see.
  5. Edit the upgrade.sh script inside that directory.  You want to change the “rm -fv” line to “rm -f” and the “mv -fv” line to “mv -f”.  You will also want to search for the two lines that start with “/bin/ps -ef” and change them to use “/bin/ps w” instead.  Save the file.
  6. Change the permissions on the upgrade.sh script to make it executable with the command “chmod +x upgrade.sh“.
  7. Run the upgrade.sh script with the command “./upgrade.sh“.

When the script completes, you should be back at the terminal prompt.  From here, you can go back to the /mnt/DroboFS/Shares/DroboApps/crashplan directory and try starting Crashplan using the command “./service.sh start“.  Check that it is “enabled and running” by running the command “./service.sh status” to get the status.  You may have to run through steps 4-7 multiple times based on how many upgrades back you are, but when all is said and done, you should be back up and running with Crashplan on your Drobo.  Good luck!

Why You Shouldn’t Phish Your Users

As an Information Security Program Owner, I get a barrage of e-mails and phone calls multiple times a day from vendors looking to sell us their latest hotness security product.  Between the e-mails, phone calls, expo floor at BlackHat this year, and several talks that I’ve seen at past conferences, I have noticed a disturbing trend that I thought was worth bringing up: phishing your users.

The concept is simple; you send e-mails to your users with content that appears legitimate along with links or attachments that are designed to simulate a spear-phishing attack.  If the user recognizes it as malicious and deletes it, then they are left to carry on with business as usual.  If, however, they fall victim to your trickery, then they are punished in the form of verbal and written lectures, letters to their management, and security awareness training.  No carrot, all stick.  This situation makes me think back upon an issue that I’ve encountered with my twin daughters at bedtime.  For over a year we struggled to get them to stay in bed at night.  We would lay them down, play some music, and then leave the room and it wasn’t 5 minutes later before they were up playing, yelling, and coming back out into the hall.  We yelled at them, spanked them, turned off lights, and did just about everything we could think of to get them to stay in bed.  None of the punishments we did actually corrected the behavior.  Do you want to know what actually worked?  Offering them a treat in the morning if they stayed in bed all night.  Positive reinforcement.

As much as we hate to admit it, adults aren’t that different from children in this way.  Nobody takes well to being tricked into clicking on links or opening attachments.  Punishing them for it leads to even further resentment.  And where do you think they focus those hostilities?  The Security Team.  Those people who you are trying to protect end up blaming you and your team for getting them into trouble.  Now, what happens the next time you have a problem that you need that user’s assistance to solve?  Absolutely nothing.  Every time you phish a user, you are burning a bridge that you may need later on.  And since we all know how easy it is to phish a user, it just means that you are burning a lot of bridges.

So, what can we do to prevent our organization from being compromised by phishing and other types of social engineering attacks?  To start with, you should incorporate security awareness training to run alongside your new hire training activities.  Make sure that every employee has a baseline amount of knowledge on the issues and how to avoid them.  Next, you should invest in technologies that will detect and prevent these types of malicious activities.  Performing some sort of link and attachment inspection in e-mails and web content inspection for malware will significantly reduce the success rate of these types of attacks.  Lastly, there are a number of vendors who will track real-life phishing attempts to your users and modify the links to be able to perform analysis on who clicked and who didn’t.  This has the exact same effect of phishing your users, where you can sit them down and have a talk about what happened, but without pitting them against the Security Team.  The attacker is now the bad guy and you’re just the friendly information security professional helping to get them back up and running and giving them tips so that it doesn’t happen again.  You are BUILDING BRIDGES.  And, if you want to put an even more positive spin on this process, offer up a reward for those who get phished, but notify the Security Team instead of clicking on the link or opening the attachment.  Everybody wins.  That’s why you shouldn’t phish your users.

My First Six Months as an OWASP Board Member

When I first put my name in the hat for the OWASP elections in the fall of 2013, I thought I knew what I was signing up for.  I thought that my seven year history with the organization in a number of different roles (Chapter Leader, Chapter Committee Chair, AppSecUSA Chair) had me well prepared for the duties of an OWASP Board member.  I told my wife that it wouldn’t be a big deal, mostly something that I could do in my spare time while at work, and that it would feel good to be able to make a difference on a bigger scale than I’d done to date.  I ran for the Board on a platform of wanting to support the growth of the OWASP chapters around the world and wanting to drive visibility, and ultimately buy-in, back to the community.  I told myself that as passionate as I was with these things as a community member, it was time to either put up or shut up.

Here I am, six months later, as an elected member of the OWASP Board of Directors and I can honestly say that no prior experience could have prepared me for this.  It’s not a good thing or a bad thing, it’s just very different than I expected.  As a community member, I remember being at the AppSecUSA conferences and struggling with how to introduce myself to these “famous” OWASP Board Members.  I was a just a chapter leader struggling to come up with ideas to engage the Austin security community while these guys were literally trying to change the world.  They were the figurative “Rock Stars” of my little security world.  Needless to say, I see things a bit differently now, but it’s probably not what you think.

When I look at my fellow Board members, I do still see those “Rock Stars”.  I can’t even begin to tell you how much I look up to guys like Jim Manico for literally spending every day of his life trying to make the world more secure.  I constantly have to tell myself that even though I don’t consider myself a security rock star, the community saw something in me and put me on the Board for a reason and I continue to hold myself responsible for executing on the platform that I laid out in my election materials.  But what I’ve come to realize now, that I didn’t realize before my election, is that even though it feels the other way around, it’s really the community, not the Board that holds the power in OWASP.

When I look back at the discussions that we’ve had as a Board over the past six months, other than setting strategic goals, the vast majority of our meetings have focused on operational and governance issues.  Through this process, I have come to the realization that while extremely important to keeping OWASP, as a non-profit organization, afloat, this isn’t the kind of exciting world-wide impact stuff I thought I had signed up for.  As an example, my first two months as a Board member were spent in large part re-investigating a situation that a previous Board had closed the books on long ago.  In the process of trying to help the individual involved, I was twice accused by that individual (and acquitted) of violating OWASP’s Code of Ethics.  Talk about gratitude.  Since then, it seems like it’s been putting out one small fire after another.  More recently, I’ve spent many hours working with the Board and the Executive Director to grapple with an employee who resigned from the organization only to have members of our community question whether we, as an organization, did enough to keep them here, without knowing all of the details.  It blows my mind how the Board can have unanimous support for an item, feel confident that it’s in the best interest of the organization, and still be called into question as to whether we are somehow being underhanded in our decisions.  It’s like we sometimes forget that the Board is made up of seven people, from all over the world, with vastly different beliefs, desires, and even visions for OWASP.  If you can get that many people, that diverse, on the same page, then there’s something to be said for that.

So, I guess in a nutshell what I’m saying is that while I feel that it’s quite the privilege to be serving on the OWASP Board alongside some of the people I respect most in this industry, there is definitely a part of me that feels like the stuff that OWASP does that has the most profound impact on global security isn’t what we do on the Board, but rather, what the community does in our Chapters and Projects.  The Board is there to support you, the community.  To create the policies to make you successful.  To provide the staff to make your lives easier so that you can spend your time doing things that accomplish OWASP’s mission.  In addition, I want to dispel any notion that the Board is some sort of an Ivory Tower.  There should never be an “us vs them” mentality at OWASP because the Board is made up of people who have been, and in many cases still are, in the trenches right alongside the community.  The Board, to put it simply, is just a group of Chapter Leaders, Project Leaders, and other members of our community who, like me, decided that it was time to put up or shut up.  People who, for whatever reason, the community elected as our leaders to evangelize the OWASP mission and make the community that we hold near and dear to our hearts successful.  To think that anyone would volunteer to be a Board member only to destroy our community is absurd.  While I may not necessarily agree with everything my fellow Board members say or do, I have never questioned their loyalty to OWASP and I hope you don’t either.

With all of the above having been said, I feel that it’s also important to say that being an OWASP Board member is also an amazing opportunity to be a catalyst for change.  Over the past six months the Board has stepped up to the task of driving visibility and control back to our community.  We’ve instituted a new polling system that the Board have used to take the pulse of the community on key issues.  Michael has taken on the responsibility of weekly calls with the community in order to keep them informed of key issues and allow them to provide feedback.  And we are currently working on bringing back the committees under a new structure that will encourage participation and empower our leaders to take action.  OWASP even won the SC Magazine Editor’s Choice Award at this year’s RSA Conference.  Regardless of how you’ve felt about OWASP in the past, I feel quite strongly that the future for OWASP is so bright we’re going to need a good pair of shades.

So, I’ll end this post very similar to how it began.  The OWASP Foundation is currently accepting nominations for the OWASP Board of Directors.  If you’ve ever felt passionate about Information Security or felt like you have big ideas to make OWASP a better community, then now is the perfect time to throw your hat into the ring as I did.  I can’t promise that it’ll make you a security rock star.  I can’t even promise that the work is glamorous.  And my experience, thus far, has been that it’s been countless hours of volunteer work with little appreciation for what gets done.  But, what I can promise, is that OWASP is making the world a better place and the Board plays a vital role in making that happen.  You, too, can be a catalyst for change.

When an “Enterprise” Product Isn’t Enterprise Ready

I absolutely love my job and one of the coolest things about what I do is getting to do proof-of-concepts with bleeding edge technology.  I feel very privileged that many companies out there respect me enough to provide me with these opportunities and I feel that engaging on this level enables me to be a better security practitioner because I routinely have my finger on the pulse of the latest and greatest tools out there.  The problem that I run into, however, is when vendors present me “enterprise ready” tools that are clearly not enterprise ready.  Maybe it’s a cool concept, a working prototype, or even a functional system.  The problem is that “enterprise ready” assumes so much more than just a product that does some stuff as advertised.  To me, at least, it assumes a product that can be easily transitioned to the company’s IT team for long-term support of the platform.   Here are some signs to look out for that will tell you if the tool is truly ready for the big show:

  1. Installation Process: This one could honestly go either way.  Personally, I prefer to have a product that I can install and configure myself.  I cringe every time I hear a vendor mention to me that professional services are involved in an installation.  I get it, sometimes a tool is so highly customized to your environment that you need help, but the majority of the products I use on a daily basis aren’t that way.  If installing a product requires a day of professional services time, then this should probably be your first signal to at least start looking out for the following additional signs.
  2. Initialization Script: I honestly feel a bit silly even having to mention this as I would assume this to be a standard part of any enterprise product, but it’s not.  If I have to poke around in the installation directory looking for the right script to run to start or stop your product, then it’s not enterprise ready.  Even worse, if it’s a more complex product that requires starting multiple pieces and you don’t have a single init script to handle the startup and shutdown in the proper order, then your product is not enterprise ready.  If you’re trying to sell me something to make my life as a security professional easier, then I should spend my time using your tool instead of figuring out how to start and stop it.
  3. Release Notifications: If I buy a product from you and I’m paying you for support, then, I’m typically doing so with the intention that I will be able to move to the next version once it is released.  Maybe it’s because there are bugs that need to be fix or because there is new functionality, but whatever the reason, I want to know when that version becomes available.  I’ll talk a bit more about the upgrade process itself in the next bullet, but if the company does not have a way to notify you when a new release is available, be wary.
  4. Defined Upgrade Process: Have you ever used a tool that you thought was completely awesome until the first time that an upgrade rolled around?  They tell you copy these files over and it breaks.  Now, run this script and it fails.  You engage support and spend hours on the phone with them and then a week later they offer a webex where a support person will take care of the upgrade for you.  I had to ditch a really interesting tool a while back for this very reason and I’m currently dealing with another one where every upgrade requires a support person to come onsite.  It’s a completely ineffective use of both my time and theirs.  When I designed SimpleRisk, one of the first things I considered was how to make it as simple as possible for a remote person to upgrade the tool without assistance.  I’ve at least got it down to copying some files and running a script which anyone can do.  Even better are the companies where it’s click a button to upgrade.  Better still are the companies that just automatically do the upgrade for you.  In any case, be wary of any upgrade processes that are not well-defined.
  5. Backup Plan: This may not apply to all products or all scenarios, but it’s a good idea when evaluating a product to ask yourself how you will back up the data and recover it if a disaster ever strikes.  If the answer is “We’d just wipe and reinstall”, then cool, but if the answer is “F*ck, I don’t know”, it may be worth having that discussion with the vendor.
  6. Monitoring: Nothing bothers me more than when I’m all excited to use my shiny new toy and when I go to log in it’s down.  In reality, I should know it’s down when it happens because there’s a high likelihood that the tool isn’t doing what it’s supposed to if it’s not running.  Ask your vendor what you should be monitoring in order to ensure that the tool is functioning properly.  If they don’t have a good answer for you, be wary.
  7. Product Roadmap: When you purchase a product, you purchase it not only for what it’s capable of doing for you today, but also for the opportunities that it will provide you with tomorrow.  Ask the vendor about their product roadmap to see if it’s in-line with your vision of how you intend to use the product.  Are there features that you can use down the line?  More importantly, do they have plans to continue to invest in the platform that they are selling you or is it just major bug fixes at this point while they move on to something else.  If the vendor can’t give you a straight answer to this question, then you may have problems.

Don’t get me wrong.  There are plenty of tools out there that fail one or more of these signs and that doesn’t mean that you should completely avoid them, but you shouldn’t expect to pay a premium for them either.  Hopefully the vendor is being honest with themselves and labeling it as “Beta” while they work to iron these things out.  If not, you should be honest with them about your willingness to accept a product that is not “enterprise ready”.  Perhaps you’re willing to accept a little bit of pain for a smaller price tag.  Maybe you want to be able to brag to your peers that you were the first to have that product hotness.  Whatever the reason, just make sure that you are aware of what you’re getting into up front.

My First Experiences with a Palo Alto Firewall

I’ve been following Palo Alto as a networking company for a couple of years now.  Their claim is that the days of the port-based firewall are dead and that their application-centric approach is a far better way to enforce your access controls.  Take the HTTP protocol for example.  HTTP typically runs as a service on port 80, but does that mean that everything running on port 80 is HTTP?  As an attacker looking for a way to funnel data out of your organization, why not use the standard HTTP port to send data, since I know you leave it wide open in order for your employees to surf the web.  There’s nothing to say that I actually have to be running an HTTP server on the other end and there’s nothing on my classic firewall to tell any differently.  At first, I was admittedly a bit skeptical.  I didn’t think that you could really tell enough about different applications on the web to be able to separate them out like Palo Alto claims to.  Fortunately, Palo Alto reached out to me and provided me with a brand new PA-200 in an attempt to change my mind.

When the PA-200 arrived, it came with everything that I would need to get it up and running.  That includes the unit itself, a power supply, a D89 to RJ45 console cable, an ethernet cable, and some instructions and warranty information.


On the front of the unit is four ethernet ports for your devices, a management port, a USB port, a console port, and several status indicator LEDs.


By default, the appliance is configured with ethernet ports 1 and 2 paired as a WAN to LAN link as this is the configuration that the majority of the people who buy it will likely use it for.  That said, by following the instructions to connect your computer up to the management port, you can quickly access the user interface that allows you to change this assignment.

Ethernet Configuration

This shows the ethernet 1 and 2 interfaces as both being a “virtual wire” and here we can see the virtual wire that connects the two.

Virtual Wire

From here, we can take a look at the “zones” and see that our two interfaces have been defined as an untrusted (ethernet 1) and trusted (ethernet 2) zone.


To think of this a different way, my cable modem WAN connection (ie. the Internet) goes in my “untrust” zone and my local network (ie. LAN) goes in my “trust” zone.  Now all that’s left is to set our policy and for ease of management to start with, I set it to allow everything out with a default deny all inbound.

Security Profile

With this configuration I had done enough to be up and running on the device and I immediately started to see data populate the dashboard on the top applications running on my network.

Top Applications

It’s color coded based on risk level and the dashboard also provides me a similar view of Top High Risk Applications.  Any of these boxes can be clicked on in order to provide additional data about the protocol, sources, destinations, countries, and more.

Application Information

Now, let me say that while I’m running this on my home internet connection, this thing is a hoss and can do way more than I can throw at it.  With their App-ID technology enabled you can throw 100 Mbps of throughput at it no problem.  In addition to being an application firewall, it also does standard port-based firewalling, VPN, routing, switching, and so much more.  It’s so extremely versatile that this thing could easily be placed in a smaller branch office and replace multiple other devices on their network such as a firewall, router, and VPN concentrator.  More functionality for less money…who wouldn’t want that?  In addition to these default capabilities, additional licensing can also be obtained to allow you to do URL filtering, malware detection, and more.  Having just gotten this up and running, I’m still exploring the ins and outs of all of the functionality, but it’s pretty exciting to have all of this capability in a box that is smaller than the cable modem my ISP provides me.  More posts to come on this as I get deeper into the guts of running my new Palo Alto PA-200 !