Quick and Dirty OPENSSL

Making a new cert? Here are some things below that should help.

#The openssl command to generate a private key is:

openssl genrsa 2048 > private-key.pem

#The CSR is generated based on the private key. The following command is used for the CSR creation:

openssl req -new -key private-key.pem -out csr.pem

Once you’ve completed your certificate with one of the Major Certificate Authorities You can then import your certificate into Amazon’s Certificate Management Service to be used on ELB. Amazon also will create SSL Certificates

Once you have your cert created, encrypt your private key:

gpg -c ./private-key.pem 

#and remove the original

rm -f ./private-key.pem

Certificate checkers:

Qualys [ SSLLABs ] Cert Checker

sslshoppers Certificate checker

Posted in Uncategorized | Leave a comment

Joining Machines to AWS provided Microsoft Directory Services

This one is quick and dirty, folks  – some quick resources if you are doing AWS Directory Services on AWS.

How to automatically Configure your systems to join an AD Domain on AWS

Terraform Directory Services for AWS Page

AWS System Manager Documents from the ‘IT Hollow Blog’

Quick windows shortcuts

#Open up Network control Panel quicky

%SystemRoot%\system32\control.exe ncpa.cpl

#Open up System Settings Quickly:

%SystemRoot%\system32\control.exe sysdm.cpl


Posted in Uncategorized | Leave a comment

Getting AWS IAM info via AWS CLI and Linux

Hi friends, I wrote a script that is useful for getting AWS IAM info: [ account number, users, list of groups to which each user belongs and any policies attached directly to the user ] in one place.  The script consists of a main.sh and a helper.sh. Place both scripts in your home directory. The scripts assume you already have the AWS CLI tools installed and your API key is configured.

Main.sh Script 

touch aws_user_list
touch aws_iam_list
aws iam list-users | grep UserName | cut -d ':' -f 2 >temp; sed 's/\"//g' temp >temp1; sed 's/,//g' temp1 >aws_user_list;
printf "The AWS Account Number for this report is " >aws_iam_list
aws sts get-caller-identity --output text --query 'Account' >>aws_iam_list;
aws iam list-users --output table >> aws_iam_list;
cat aws_user_list | source ./helper.sh >> aws_iam_list;


helper.sh   Script

while read LINE; do echo $LINE; aws iam list-groups-for-user --user-name $LINE; aws iam list-attached-user-policies --user-name $LINE; aws iam list-user-policies --user-name $LINE



# Script pieces

aws iam list-users --output table
aws iam list-groups-for-user --user-name
aws iam list-attached-user-policies --user-name
aws iam list-user-policies --user-name

#get your AWS account ID from CLI 
aws sts get-caller-identity --output text --query 'Account'

For future, next rev of script I need to iterate through a list of groups:

aws iam list-attached-group-policies --group-name 

aws iam list-group-policies --group-name
Posted in AWS, AWS Certified Solutions Architect, Uncategorized | Leave a comment

AWS: Find Private IP addresses attached to Security Groups

Hi friends. Ever wonder how to get  dynamic private IP addresses (say ones assigned to an internal ALB) associated with your Security Groups? Ok to start, this is crude, I’ll admit it – but it works – and when I find a better way I will share.

First, since we are using VPC and not classic  no more querying by Security Group name – we have to get the Security group ID ( also now dynamic in AWS ).  So for our first query you have to know what attribute you want search.

#The following will give Security group IDs for all SG's using

aws ec2 describe-security-groups --filters "Name=ip-permission.cidr,Values=" --query "SecurityGroups[].[GroupId, GroupName]" --output text

#OR list your groups which groups use port 80

aws ec2 describe-security-groups --filters "Name=ip-permission.to-port,Values=80" --query "SecurityGroups[].[GroupId, GroupName]" --output text

# and then grab the security-group id from the output of the above command and place it in the values section below

aws ec2 describe-network-interfaces --filters Name=group-id,Values=sg-xxxxxx | grep PrivateIpAddress
Posted in Uncategorized | Leave a comment

PaloAlto VM Firewalls with AWS ELB/ALB

Hey friends – wanted to continue sharing my knowledge as I uncover how to use Palo Alto FW inside AWS. Here is some information about this Cloud Formation Template by Palo Alto.

Basically, the link above leads to a collection of scripts, CF templates that build configuration of Palo Alto Firewalls sitting behind an ELB, and in front of an ALB, like this:

All credit due to Palo Alto, the Cloud Formation Template works well. What is not so great however, is the technical documentation detailing the wizardry with which they pulled this off.  The tricky part about a design like this is that Firewalls are not a traditional LB target, meaning that they FORWARD traffic, rather than responding directly to the LoadBalancer itself like a server would. Further complicating matters, AWS ALB and ELB use DNS aliases. Keep-alives sourced from the external ELB pass through the Firewall – the firewall does not respond to keep-alives.

For this to work, Palo Alto has a NAT policy which basically takes external inbound LB traffic(untrust) and NATs the destination IP to the AWS ALB (internal load-balancer ) private IP(trust). That  last point is critical to understand if you ever hope to get something like this to work. Along with the Cloud Formation Template, Palo Alto basically has included 20+, (yes 20! ) python scripts that work in conjunction with CF and Lambda to automate this deployment. One / or more of those scripts figures out what the private IP is for the internal load-balancer and creates a NAT object for the internal load balancer in the FW configuration template prior to FW deployment and that is how they are getting around the fact that the ALB private IP is dynamic, built on-the-fly each time CF is run.  This little piece of info should be included in their documentation, presently, it is not.

Although I give serious, ( and I mean SERIOUS props),  to the Engineer who figured how to automate that piece with python and coded it all  – this ultimately is another ‘shoehorn’ of making something that was not built or designed to run in AWS, run in AWS.  The maintenance of the 20 + python scripts is not scalable – nor does it fit nicely into Terraform.

Palo Alto needs to work harder to integrate more deeply into the AWS API. Really, for a Cloud enabled Firewall, this should just be a CF template where you specify the ALB ( internal ) and the AWS API builds the initial FW policy based on resource attributes AWS has spun up internally.

Posted in AWS, AWS Certified Solutions Architect, Palo Alto FW, Palo Alto Networks | Tagged | Leave a comment

PaloAlto’s “fix” for making VM Series FW work with AWS ELB

I want to share my experience using Palo Alto FW in AWS ( using Terraform ).

Palo Alto has some good examples out there of how their stuff works with Terraform and AWS, such as this github repo for thier two-tier implementation using Terraform. The two tier design here is a small starting point upon which to code out your platform. However, it does not take into account how the PA’s work with multiple AZs or Load Balancers, both of which will most likely be needed in your implementation.

Multiple AZ’s are not hard to do, but if you want Elastic Load Balancers in the mix, there is a Management Interface swap that needs to happen in order for the Palo Alto VM FW to work with AWS ELB.

This seemingly tiny, insignificant detail has been challenging to integrate into Terraform, and although PaloAlto does provide some documentation, it is not enough. Here is what I learned:

  • An EIP association is also needed for eth1 ( what will become mgmt. interface ) if you are not using a Bastion host to connect initially.
  • Another EIP association is also needed in Terraform for FW eth0 so device can read and get bootstrap from S3 Bucket. ( this EIP can later be torn down – but yes, you need TWO EIPs at boot time to make this work! ) [ UPDATE: a VPC endpoint w/ routing can replace the need for this second EIP ]
  • FW Initial Ruleset must permit ssh / web to the IP of Ethernet 1/1 new mgmt ( that’s obvious but included here so not be be over looked )
  • Ethernet 1/1 was not assigned to a Zone in PAN-OS initial config bootstrap when I got it working.
  • Terraform interface templates for Palo Alto need to have mgmt. interface associated to device_index = 1 ( instead of zero ) in initial config.  Configuring for Terraform, thus AWS, the actual interface assignments are abstracted, so you configure them as you will use them AFTER the swap.

Also of note, the PAN-OS does not “see” this change in the GUI. You will still implement your rules and zones as though there was not an interface change. Eth 1/1 shows up in Network interfaces…  The only place to see this is in the CLI with this lengthy command:

Fig 1. Normal boot:

admin@PA-VM> debug show vm-series interfaces all

Interface_name       Base-OS_port       Base-OS_MAC             PCI-ID         Driver
mgt                     eth0          06:82:4e:66:99:9a       0000:00:03.0      ixgbevf
Ethernet1/1             eth1          06:1a:e7:12:01:e0       0000:00:04.0      ixgbevf
Ethernet1/2             eth2          06:39:13:1b:e9:d4       0000:00:05.0      ixgbevf

Fig 2. Booting with the command ‘op-command-modes=mgmt-interface-swap’ in the init.cfg

admin@sample-cft-fw> debug show vm-series interfaces all

Interface_name       Base-OS_port       Base-OS_MAC             PCI-ID         Driver
mgt (interface-swap)    eth0          06:db:de:02:e5:22       0000:00:04.0      ixgbevf
Ethernet1/1             eth1          06:9f:0e:8b:de:ec       0000:00:03.0      ixgbevf
Ethernet1/2             eth2          06:5d:86:02:b1:4e       0000:00:05.0      ixgbevf

It’s hard to notice a difference, but if it worked, you’ll see the (interface-swap) after mgt. ( above ) .  Palo Alto provides this graphic to explain it, but it does not really line up well with the output above since the VM interfaces are extracted into AWS.

In Terraform, it lines up as so:

device_index = 0 will be eth0  in AWS, which is initial mgmt in Palo Alto (before swap), communication to the S3 bucket for bootstrap happens from this interface.

device_index = 1 will be  eth1 in AWS, (which would be new mgmt if swapped)

device_index = 2 will be eth2 in AWS, not affected by swap

Also, before getting it to work in Terraform, I tried the command to swap interfaces on a FW VM series running n AWS that had booted normally; using Palo’s CLI:

set system setting mgmt-interface-swap enable yes

It responded with:

Reboot system to take effect new changes. After reboot use IP address of eth1 (external to VM) for management

After it booted again, I had trouble getting back into the Firewall with  ssh. Got connection refused. Could have been various reasons, but at this stage, I think it was that I did not wait long enough. Another Engineer I am working with said that this worked for him but he had to wait a long time after boot.

This Management interface swap feels very much like the Palo Alto VM Firewall has been ‘shoe-horned’ to work in and with AWS.  I have always loved Palo Alto, but not really a fan of this fix.

I’ll be writing more as I learn. I hope this helps you! Oh, before I go, here are some handy PAN-OS CLI commands you will use if you are doing this same thing:

op-command-modes=mgmt-interface-swap # for bootstrap
set system setting mgmt-interface-swap enable yes # PA cli
debug show vm-series interfaces all # show your stuff
set mgt-config users admin password #you'll need this to get to the web GUI
save config
Posted in AWS, Palo Alto FW, Palo Alto Networks | Leave a comment

Front row perspective from Brian Krebs’ 2017 Keynote!


I had the amazing honor of getting front row for Brian Krebs’ KeyNote speech at the SailPoint Navigate Conference Last week in Austin, TX! Brian is an exceptional a Public Speaker, just as he is an exceptional writer. Krebs has been my teacher for a few years now (extensive reading and studying of his blog: https://krebsonsecurity.com ) During the Keynote, he captivated the audience by highlighting what he has learned in his experiences. I wrote as fast as I could by hand in my notebook, tried to capture as much of it as I could; and put it all together here:

Opening thoughts: 

  • Authentication and Identity Compromises are why there are so many Security breaches; the attacker essentially becomes the user with stolen, compromised credentials
  • Weakest part of the organization is the farthest point out – the users
  • “Everyone gets pen-tested whether or not they pay for it” < that is so true! 
  • Most breaches in the last decade, the org has had no clue the attacker was on their Network.
  • Security Awareness Training is still an effective method to help mitigate breaches.
  • We have no business using “static identifiers” in 2017! How do we get better?
  • Two Factor can blunt many attacks!  Industry relies on tools too much, need to rely more on human to interpret the tools. Target had tools, but people could not make sense of what they were getting.
  • Trained, Sec Ops to do basic ‘block and tackle’ , curious human beings to look at tool output needed to find the bad guys.
  • Build a solid SecOps team (  If orgs cut back on Security people, their visibility decreases.)
  • Mitigate Account Take-over [ e.g., using your same creds across multiple web services ]; credential replay can be done by bots at a slow rate to avoid SecTool detection; need a human eye on the screen.

Krebs then changed up topics to predictions:

  • Ransomware attacks may become more targeted and attackers will better understand the data ( and the value of that data ) which they are encrypt so they can ask a proper ransom for it.
  • IoT – will be a major challenge.  Shodan lists all kinds of targets. Krebs’ site was DDoS’d [ 620 Gbps ] by a massive Botnet consisting of IoT devices; expect this trend to continue.
  • Potentially more disruptive attacks [ WannaCry ]

More Solutions outlined:

  • Get beyond Compliance; don’t just meet the audit; go further
  • Invest in 2FA everywhere!
  • Do your back-ups correctly, don’t leave them open, or exposed!
  • Drills exercises; red team vs.  blue team so your team will be ready and can run the playbook!
  • Secure what you have
  • Watch out for vendor ‘kool-aid’ that their tools can replace people, simply not true!
  • Strengthen and invest in current employees
  • Assume you are compromised
  • Watch out for your business partners

After the speech was over; he wanted to stay up and answer questions for the audience; unfortunately, the vendor rushed him off stage so some c-level person could speak, ( but not before I got to shake his hand and thank him for all his work and how much he has helped me professionally )! thank you, Brian ! It was great to finally meet you!

Posted in Cyber Security, Ransomware | Leave a comment