TechJockey.NET

Airflow, Azure and OAuth

Andy — Thu, 06 Jan 2022 21:10:32 +0000

NOTE: This is an incomplete article – I will continue to publish more as I can. I have provided the needed code for “webserver_config.py” I have not included information for the “App Registration” in Azure.

This article stems from me not finding enough information, in one place, pertaining to authenticating to Apache Airflow leveraging OAuth and Azure.

I was able to piece what I needed together using documentation from different sources: GitHub, Flask, Apache, etc.

My hope is that this article provide you with the information needed to get authentication functional in your environment.

If you are using the Apache Airflow public helm chart – this is the code that will help get you going. This can be added to your “values.yaml” or “overrides.yaml” file. If not using a helm chart, then add the python portion – starting with the first “from” to the end of the code block and add it to your “webserver_config.py” file.

webserver:
  service:
    type: NodePort
  webserverConfig: |
    
    from airflow.www.security import AirflowSecurityManager
    import logging
    from typing import Dict, Any, List, Union
    from flask_appbuilder.security.manager import AUTH_OAUTH
    import os

    # basedir = os.path.abspath(os.path.dirname(__file__))

    WTF_CSRF_ENABLED = True
    # SQLALCHEMY_DATABASE_URI = conf.get("core", "SQL_ALCHEMY_CONN")

    AUTH_TYPE = AUTH_OAUTH
    AUTH_ROLES_SYNC_AT_LOGIN = True
    PERMANENT_SESSION_LIFETIME = 1800 # force users to reauth after inactivity period time in seconds
    AUTH_USER_REGISTRATION = True
    AUTH_USER_REGISTRATION_ROLE = "Public"

    class AzureRoleBasedSecurityManager(AirflowSecurityManager):
        def _get_oauth_user_info(self, provider, resp):
            if provider == "azure":
                me = self._azure_jwt_token_parse(resp["id_token"])
                return {
                    "id": me["oid"],
                    "username": me["upn"],
                    "name": me["name"],
                    "email": me["upn"],
                    "first_name": me["given_name"],
                    "last_name": me["family_name"],
                    "role_keys": me["roles"],
                }
            return {}
        oauth_user_info = _get_oauth_user_info

    SECURITY_MANAGER_CLASS = AzureRoleBasedSecurityManager

    # In order of least permissive - default is "Public" - see AUTH_USER_REGISTRATION_ROLE
    AUTH_ROLES_MAPPING = {
      "Public": ["Public"],
      "Viewer": ["Viewer"],
      "User": ["User"],
      "Op": ["Op"],
      "Admin": ["Admin"],
    }

    OAUTH_PROVIDERS = [
      {
        "name": "azure",
        "icon": "fa-windows",
        "token_key": "access_token",
        "remote_app": {
          "client_id": "",
          "client_secret": "",
          "api_base_url": "https://login.microsoftonline.com//oauth2",
          "client_kwargs": {
            "scope": "User.read name preferred_username email profile upn",
            "resource": ""},
          "access_token_url": "https://login.microsoftonline.com//oauth2/token",
          "authorize_url": "https://login.microsoftonline.com//oauth2/authorize",
          "request_token_url": None,
        },
      },
    ]

F5 iRule — No Pool Members Available Vanity Page

Jim — Sun, 15 Aug 2021 03:01:50 +0000

I wrote a iRule post located here, where I describe the essentials behind how beneficial iRules can be and the many use cases they have. I stumbled across a situation the other day for a client. This client had an F5 VIP load balancing 2 web servers of theirs. Now if those web servers for some reason are not available due to their healthcheck monitor failing, the users of that web site will receive a white page as the F5 will not proxy the traffic because there are no available pool members. I thought what if this was a big site, should users be left in the dark about a web site they use frequently when it’s not available? Then the idea of having the F5 LTM bounce back a well-formed splash page. This splash page would inform the user that the web site temporarily down, and if they believe this result is in error to contact their helpdesk.

This situation can be remedied with a couple of lines in an iRule.

when HTTP_REQUEST {
    #check if no members available
    if { [active_members [LB::server pool]] == 0 } {
       #create data variables with HTML content to send to client
       set httphost [string tolower [HTTP::host]]
       set data "$httphost
NOTICE: Site Unavailable.If you believe you are receiving this message in error, contact your site administrator."
       #send the HTML string
       HTTP::respond 200 content $data
    }
    #unset variables
    unset $httphost
    unset $data
}

Or:

when HTTP_REQUEST {
   #check if no members available
   if { [active_members [LB::server pool]] == 0 } {
      HTTP::respond 200 content {
         Site Unavailable
If you believe you are receiving this message in error, contact your site administrator.
       } #end of content block
   }
}

This iRule uses the when HTTP_REQUEST event, and the HTTP::respond function. You could also use the HTTP::redirect function, however for something as small as a few lines, might as well have the F5 handle it directly.
You could easily use links from other sources to make a more authentic looking page for your users. I like to embed images for my customers using the img and base64 tag, such as

when HTTP_REQUEST {
  set VSPool [LB::server pool]
  if { [active_members $VSPool] < 1 } {
    HTTP::respond 200 content "


    
    Maintenance Page



    
        Site Unavailable!

         We are sorry, but the site you are looking for is temporarily out of service.
            If you feel you have reached this page in error, please try again.

        Thank you!
    
"
  }
}

Which gives us a embedded image without relying on external URLs. I used https://codebeautify.org/image-to-base64-converter to perform the base64 conversion.

Cisco ACL — Dedicated Internet Edge Drop Device

Jim — Sat, 17 Apr 2021 16:38:19 +0000

A dedicated drop device is a network appliance, usually a router or L3 switch that sites at the very edge of your network infrastructure. Beyond the firewall, and usually acts a as either layer 2 or 3 transit devices for your ISP interconnect uplinks for public or untrusted segments. Distinguishing a dedicated drop devices in your infrastructure interconnected chain of paths can enhance and offload many irrelevant packet transactions from ever hitting your Firewall mitigation appliances. The thought around this approach is to remove processing cycles away from your more expensive security appliances such as firewalls or IPS, allowing said devices to dedicate their efforts toward more complicated session and/or application driven attacks.

Where to start…

A common trend I’ve seen over the years at multiple business is to create such a ACL on the perimeter edge device to block way too much. ACL length kept a short as possible. I’ve seen some grow to over 100 lines, which is unnecessary. The justification is usually an outbreak or single malicious actor caused said actors IP to be added the Drop ACL. In my opinion this is not the point of this Drop ACL. The Drop ACL should be static, well thought-out and compared against services you offer to the public internet, not a “o crap block it now!” access-list. A common counter argument I hear is “our Drop ACL has grown over time to form our own reputation based blocklist”, I believe this should be handled by your firewall or IPS device. Most Firewalls or IPS now-a-days have built in reputation based intelligence, and if needed a user-defined blocklist can be managed much easier as well. The table below is a basic table to document the Drop ACL creation process, this should be brainstormed with NetAdmins, Security Officers, and select business owners to arrive at a well established drop list without negatively impacting your business. For example, you will want to talk with your business owners to know if you do indeed need ICMP or PING because it is used by a legitimate third-party to monitor your network health and status.

Simple Starting List

ICMP	IP Proto 1	Does your business or app require to expose ICMP messages to public/untrusted network?
PING	IP Proto 1 Type 0	Does your business or app require any public endpoint to ping your global IP?
SNMP	TCP/UDP 161/162	Management Service, should not be coming from public/untrusted network
BOOTP	UDP 67/68	BOOTP from external source, common with residential or business ISPs. Not usually seen with dedicated ISPs.
TFTP	UDP 69	Management Service, should not be coming from public/untrusted network
TELNET	TCP 23	Management Service, should not be coming from public/untrusted network
SSH/SFTP	TCP 22	Management Service and Secure File Transfer, should not be coming from public/untrusted network, check with business.
EIGRP	IP Proto 88	More likely then not, you won’t be using OSPF on your Internet Edge, more likely BGP
OSPF	IP Proto 89	More likely then not, you won’t be using OSPF on your Internet Edge, more likely BGP
RADIUS	UDP/TCP 1812/1813	AAA mechanism for user-based authentication/access/accounting. Should never be used on public interfaces. Use on internal OOB management network.
TACACS+	UDP/TCP 49	AAA mechanism for user-based authentication/access/accounting. Should rarely be used on public interfaces. Use on internal OOB management network.
SYSLOG	TCP/UDP 514	Forwarding and transferring syslog based messages. Should not be on public interface for DLP reasons.
etc…

You can see that there is not a “one size fits all” approach, however there are several common overlaps and many of the items on this basic Drop ACL tend to be management or routing protocols. For example from the list above, you should never see SNMP coming from a public endpoint, even if you have a external third-party monitoring your assets via SNMP for you. Another example is, I once worked for a consulting company that used TACACS based connections over the public internet to encrypt user-logins of managed devices. This was scene as acceptable to the business because TACACS is an encrypted protocol. Therefore you will need to decide with your team(s) what makes the most sense.

Adding a Wider Range of items to the List…

Just like the previous section, the Drop ACL should not be a massive list of IP hosts and ranges. I would even argue against things like Geo Blocklist being on this list as most modern Firewalls have this ability built in.

Basic IP Host and Ranges
RFC-1918 “Private Address Space”	10.0.0.0/8 172.16.0.0/12 192.168.0.0/16	Private Ranges, not routable on the internet. Prevent spoofing.
RFC-3927 “Link Local Address Space”	169.254.0.0/16	Commonly used on windows machines when DHCP/BOOTP is not used on a LAN network.
RFC-5737 “Test Network Address Space”	192.0.2.0/24 198.51.100.0/24 203.0.113.0/24	These are IP address ranges used in public documentation TEST-NET-1, TEST-NET-2,TEST-NET-3
RFC-3330 “Special-Use Reservations”	0.0.0.0/8 127.0.0.0/8 255.255.255.255/32	These are special IP address reservations that should not be internet routable, and are common with spoofing and source-less based attacks. 255.255.255.255/32 should never be forwarded outside the subnet source.
RFC-3068 “6to4 Relay Anycast”	192.88.99.0/24	Reserved by IANA to help with migration from IPv6 to IPv4 via 6to4 anycast relaying.
RFC-2544 “Internet Benchmark”	198.18.0.0/15	Block of IP address to be used for benchmark interconnected devices and documentation.
RFC-1112-SECTION-4 “Reserved for Future User”	240.0.0.0/4 255.0.0.0/8	Huge block of IP addresses dedicated for future use by IANA, but never used. SMH.

Crafting a basic Drop ACL brew…

Putting the above two(2) sections into IOS format, I arrived at the following ACL.

ip access-list extended DropACL
permit icmp any any traceroute
permit icmp any any echo-reply
!
remark *******Block Routing Protocols*******
deny ospf any any
deny eigrp any any
remark *******Block Mgmt Services*******
deny udp any any eq bootpc
deny udp any any eq bootps
deny udp any any eq snmp
deny tcp any any eq snmp
deny udp any any eq syslog
deny tcp any any eq syslog
deny udp  any any eq snmptrap
deny tcp any any eq snmptrap
deny tcp any any eq telnet
deny udp any any eq tftp
deny tcp any any eq 22
deny tcp any any eq tacacs
deny udp any any eq tacacs
deny tcp any any range 1812 1813
deny udp any any range 1812 1813
remark *******RFC1918 Spoofing*******
deny ip 10.0.0.0 0.255.255.255 any
deny ip 172.16.0.0 0.15.255.255 any
deny ip 192.168.0.0 0.0.255.255 any
remark *******RFC3330 Spoofing*******
deny ip 0.0.0.0 0.255.255.255 any
deny ip 127.0.0.0 0.255.255.255 any
deny ip 192.0.2.0 0.0.0.255 any
deny ip 169.254.0.0 0.0.255.255 any
deny ip 192.88.99.0 0.0.0.255 any
deny ip 198.18.0.0 0.1.255.255 any
deny ip 240.0.0.0 15.255.255.255 any
deny ip 255.0.0.0 0.255.255.255 any
remark *******Unallocated Spoofing*******
deny ip 128.0.0.0 0.0.255.255 any
deny ip 191.255.0.0 0.0.255.255 any
deny ip 192.0.0.0 0.0.0.255 any
deny ip 223.255.255.0 0.0.0.255 any
!
remark *******Multicast Spoofing*******
deny ip 224.0.0.0 31.255.255.255 any
!
remark ***********************************
remark ***Allow Transit Traffic***********
permit ip any any

Look at that, we kept it under 50 lines! Most of the duplicate lines are because many of these protocols can use either UDP or TCP as transports.

Ask my Dad the ISP for help…

The IETF derived a “best pratice” to further assist in the fight against spoofing attacks. IETF came up with Ingress Filtering in RFC 2827 and RFC-3704. These are not hard tangible items throughout the internet, but a best practice “honor” based method to reduce source address spoofing of internet traffic. In basic terms it documents that ISPs acting as upstream providers for customers should filter packets entering their(ISP) network from these customers and discard them that do not match the source addressing agreed upon and allocated to that customer. See https://www.senki.org/everyone-should-be-deploying-bcp-38-wait-they-are/

This will not really protect you, but it is you doing your part to help in case an asset of yours becomes comprised.

Sources:

Security Through Obscurity

Andy — Fri, 16 Apr 2021 19:30:56 +0000

Security Through Obscurity?

This my first ever post and I feel it’s a pertinent one to mention.

What is it and why is it bad?
Security through obscurity can be said to be bad because it often implies that the obscurity is being used as the principal means of security. Obscurity is fine until it is discovered, but once someone has worked out your particular obscurity, then your system is vulnerable again. [source: https://en.wikipedia.org/wiki/Security_through_obscurity]

Security is an often overlooked topic in organizations. I’ve heard many different arguments for why things were configured a certain way. Once thing that stands is security through obscurity should never be overlooked. Things are always secure, until they’re not. You should never expose something publicly that is not meant to be exposed publicly.

For example:
A typical company, that has publicly hosted domains, will have a public facing presence on the internet. This usually means there will be a public IP address with a Network Area Translation, or NAT for short, to a private IP address on a corporate or cloud network.

This private IP address is typically hosted in an isolated area called a demilitarized zone, or DMZ for short.

The DMZ is designed to be an isolated area of a company network. You need special rules to get in or out of this particular network. And in many cases there are special rules to allow you in to the systems/applications etc. that are within that network.

The main purpose of the NAT is to translate an public IP address into a private IP address. The private IP address is unknown to the public.

When we type the name for websites like “duckduckgo.com” or “reddit.com” our computers know how to translate these into an IP address (there is a lot of magic happening behind the scenes here that we won’t discuss).

Generally, speaking these names translate to a public IP address. That public IP address then is translated by network appliances to a private IP address (as previously mentioned).

There are scenarios, for example when you are on a corporate network or corporate virtual private network, VPN. Where applications used by the company are resolving to private IP addresses. This is normal and expected.

That’s a lot of explaining, right?…

Not entirely, there is a lot more at play that we won’t cover. But for arguments sake the norm for appropriate security is things that should be kept private are not to be exposed publicly.

There are specific networks in the protocol for IP version 4 (IPv4) that are meant to be private. This is the RFC 1918 standard for IPv4. We have several large groups of private IP addresses that are inaccessible publicly unless you specifically allow that traffic into your network through a NAT.

This changes with IPv6, but that is out of scope of the scenario in question.

For the purpose of this case will use “example.com” as the public domain record. Think of “example.com” as “google.com”, you can access it anywhere with an internet connection.

I came across a case in which I discovered an application with a public name record “example.com” was returning an IPv4 private IP address. At its surface, this does not seem to be a particularly large issue. As previously stated with RFC 1918 (the private IP scope) – I am unable to access that site since we are unable to access private resources from a public network without a NAT.

Currently, I’m safe. Nothing to worry about, right?…

Wrong.

Why is this bad?

With public cloud and rapid deployments, dealing with infrastructure at scale, things change quickly. Someone may change the way the code is deployed and inadvertently change the way that application is deployed and give it a public NAT. Now we have what should be a private application on a public network.

-or-

“example.com” has exposed private information. Let’s say “example.com” has an application that is designed to be public and they host through “public.example.com”. A malicious user or program can now take the previously exposed private information and attempt to apply it through this new attack vector.

The point is, just because something at its face may seem secure you need to think about things from every possible angle. It does not mean you should not implement things or delay the implementation of applications. It just means security should be at the forefront of every design that you create and that obscurity does not lead to solid security practices.

The Remote Access VPN Battle — SSL vs IPSec VPN

Jim — Thu, 12 Oct 2017 14:47:20 +0000

I’ve recently posted two articles covering two different VPN connection methods. SSL Remote VPN and IPSec Remote VPN via Cisco ASA security applicance. In the article I promised I would go thru and do a deteail compare and contrast of them. So Let’s get start!!

As promised here is the follow up post I mentioned here regarding setting up an Cisco AnyConnect remote access. Luckly the process is very similar to a remote access IPSec tunnel in the previous article with a few exceptions. Lets work through the differences between Cisco AnyConnect and a standard remote access IPSec Client VPN.

Comparison	SSL Remote VPN	IPSec Remote VPN
Cost	$$ per Connection, SSL certificate costs	Usually none, no SSL certificate costs
Capacity	Seats limited to licensing	Limited to Crypto Hardware
Performance	SSL with DTLS = Very Fast	IPsec without NAT-T = fast
Vulnerability	SSL vulnerabilties released frequently	IPSec requires pre-shared key
Requirements	SSL requires TCP 443, DTLS requires UDP 443	IPSec requires IP Protcol 50 (ESP) and UDP 500(IKEv1), NAT-T requires UDP 4500
Connection Considerations	SSL requires TCP 443 outbound for clients	IPSec requires both Layer 3 and Layer 4 protocols

NOTE: The table here is a quick reference when comprising SSL remote VPN with IPSec remote VPN. There are many things to consider when choosing between the two. SSL VPN is newer than IPSec, however the answer on which is better is not so straight forward.

IPSec remote VPN utilizes a variety of protocols and ports to form a successful tunnel. If you remember from my article on IPSec and NAT-Traversal, port requirements are UDP 500 for IKEv1 exchange, IP Protocol 50 for ESP communication, and if negotiated UDP 4500 for NAT-T. Most of the time these ports and protocols will not be allowed access outbound to the Internet. For instance, many guest networks like hotels and conferences only allow web browsable ports, such as 80(HTTP) and 443(HTTPS) outbound. That is a lot of firewall exceptions to establish an IPSec remote VPN.

SSL remote VPN introduces many connection and scalability improvements, making remote VPN functionality easier for the end user. SSL remote VPN solves the IPSec issues of a opening ports to establish a VPN session. Remote users no longer connect differently depending on where they are nor do they need to know how they are connected to the Internet, no fancy ports need to be opened, no issues with NAT-Traversal, etc. SSL remote VPN uses a very common trusted port for communication TCP 443 (and UDP 443, more on that later). This port is 99% of the time open to communicate with the Internet web sites. Using a commonly allowed port eliminates the issues seen with IPSec when establishing a VPN.

The trade-off, SSL remote VPN communicates via SSL/TLS. As stated this requires TCP, which is a stateful transport protocol. The issue arises when you have a remote host operating an application that uses TCP as well, such as web browser or Remote Desktop Connection. The scenario is now TCP on top of TCP, resulting in heavy overhead. Imaging the following scenario, you have a SSL remote VPN host connected, they then open a RDP session to a server on your network. So far so good. Now what happens when either the RDP session or the SSL remote VPN session requires a re-transmission because of connectivity problems. TCP re-transmission storms. Both the VPN session and RDP session will require re-transmissions, generating heavy overhead. Now this is not to say that either session will not recover, cause they will unless the connection is completely severed, TCP will do its job. Datagram Transport Layer Security(DTLS) to the rescue!!!

Datagram Transport Layer Security (DTLS)

DTLS is the savior and its what makes SSL client VPNs a very competitive remote access VPN technology. DTLS was designed to secure traffic similar to TLS, but without having to rely so heavily on the underlying TCP transport. TLS relies on TCP to guarantee delivery in the event of message fragmentation, message reordering, and message loss. So getting ride of any one of those TCP features will break the TLS crypto logic. DTLS solution to these issues is as follows:

Message Fragmentation — Fragmentation occurs when a packet datagram is too large to fit within an MTU (usually 1500bytes’ish). Fragmentation is detected and handled by the transport technology (TCP/UDP). TCP has mechanisms built in to solve this while UDP does not. DTLS solves this issue by introducing its own fragmentation offset and length value in the DTLS message itself. This ensure that both ends of the communication are provided fragmentation information regardless of the underlying transport.
Message Reordering — Reordering occurs for several reasons, a common reason is delayed delivery of the underlying network. Reordering isn’t a huge issue for transport technologies like TCP because it uses sequence numbering to ensure the original data is reassembled properly. TLS requires the sequential delivery of packets to preform it’s crypto logic, meaning TLS needs the previous packet to be able to decrypt the next packet N+1. DTLS solves this by adding it’s own sequence numbering to the application, allowing it to not be dependent on the underlying transport technology.
Message Loss — Packet loss occurs when a packet in a data stream never reaches its destination in a certain period of time. Message loss is handled very similar to Message Recording. For TLS and it’s TCP transport, re-transmissions are triggered for lost packets when sequence numbering doesn’t compute correctly for a agreed upon window. DTLS fixes this by adding a simple re-transmission timer to it’s application logic, thereby allowing it to re-transmit packets without relying on the transport protocol.

Keep in mind that DTLS built-in functionality of these usually transport specific recovery mechanisms creates the need for additional RAM/memory on the server-side. Another cool fact is most of these “fixes” come from IPSec ESP technology! See RFC4347 for more information.

Helpful links:

Apt-Get HTTP Proxy — One-Liner

Jim — Wed, 11 Oct 2017 19:25:05 +0000

I have a few Debian servers that are behind a firewall and they don’t have direct access to the internet. “Protected Servers”. I occasionally have to update their packages via a web proxy in the DMZ. I know there a countless ways to do this, but I wanted a one-liner that i can use without having to modify the apt-get application or my hosts default proxy settings.

Hope this helps someone else, cheers!

http_proxy="http://172.16.0.5:3128" apt-get update

PAC File and Web Proxy Auto-Configuration (WPAD) HowTo

Jim — Wed, 11 Oct 2017 18:44:16 +0000

Hello! I posted an article a while back on how to use a web proxy to block unwanted content. While this is good and fun, we need an easy way to configure clients to use the proxy. For this article I will be over both PAC file deployments and WPAD deployments. We will use the example proxy server of 172.16.0.5:3128. Let’s go!

First a few common ways clients are configured to use a Web Proxy:

Manual configuration — Client manually inputs configuration data into each of their browsers to use the web proxy for each protocol (HTTP, HTTPS, FTP, etc).
PAC File –– A PAC(Proxy Auto-configuration) file, is a method where the client’s browser is configured with the location of the PAC file via http:// or https:// to be downloaded automatically .
WPAD — WPAD (Web Proxy Automatic Detection) is the automatic and transparent configuration of client’s to use and send their web-traffic to a proxy server. This deployment of PAC files using already existing network protocols such as DNS or DHCP options.
GPO — GPO( Group Policy Objects deployments are primarily used in Windows Domain environments. User will obtain proxy configuration automatically through these Group Policy Objects upon log-in. (not-covered in this article)

The PAC File

A PAC file is nothing more than a text file containing javascript like information regarding where a client’s browser should or should not send web traffic to the proxy. This is helpful to be able to be selective on which destinations or sources a client should send or not send to a proxy server. For example, if you have internal web sites or resources that should not be proxied you can define those conditions in the PAC file.

function FindProxyForURL(url, host) {
        if (shExpMatch(host, "*.example.local")) {
                return "DIRECT";
        }

        if (isInNet(dnsResolve(host), "10.0.0.0", "255.0.0.0") ||
            isInNet(dnsResolve(host), "172.16.0.0",  "255.240.0.0") ||
            isInNet(dnsResolve(host), "192.168.0.0", "255.255.0.0") ||
            isInNet(dnsResolve(host), "127.0.0.0", "255.255.255.0")) {
                return "DIRECT";
        }
        if (isInNet(host,"192.168.0.0", "255.255.0.0") ||
            isInNet(host,"172.16.0.0", "255.255.240.0") ||
            isInNet(host,"10.0.0.0", "255.0.0.0")) {
                return "DIRECT";
        }

    return "PROXY 172.16.0.5:3128";

}

return {value} = is a key function that will send the web request to either, DIRECT – for direction connections, or to PROXY — a proxy server

shExpMatch({host | url}, {expression to match}) = An expression function that will match the host entered to an expression. Returns TRUE if a match is found, else returned FALSE.
host = the FQDN typed into the User’s browser. Ex. youtube.com
— url = the complete URL typed into the User’s browser. Ex. http://youtube.com/video
— isInNet({IP address}, {Network, Netmask} = isInNet will return TRUE if the supplied host (see above) resolves to an IP address within a subnet, else it will return FALSE.
dnsResolve({hostname}) = Use to resovle hostnames to IP addresses.

For a List of PAC Functions, please visit http://findproxyforurl.com/pac-functions/

PAC File Deployments

A PAC file deployment requires a working PACs file, a server to host the file, and to have the User’s browser proxy settings configured to find the file. Using Firefox as the example and assuming the filename proxy.pac is hosted on http://host.example.local/proxy.pac, it would be:

Firefox:

Internet Explorer:

WPAD Deployments (DNS and DHCP)

Much of the Web Proxy Automatic Detection (WPAD) type deployments depend on the client’s browsers implementation, meaning it really depends on how the browser WPAD code was written into the browser application. For example Firefox WPAD process may be different for Safari then it is for Internet Explorer’s. For the most browsers the process is as follows for both types DNS or DHCP:

DNS Option

User’s Browser checks if Auto-Detect is enabled.
Firefox:

Internet Explorer:
User’s browser tries to resolve A record of wpad using the default domain suffix of the host belongs to (example.local)
1. Tries wpad.subdomain.example.local
2. Tries wpad.example.local
3. Tries wpad.local
4. Tries wpad.
On first resolve it the User’s browser will then try to make a HTTP request for against the URL for a file named wpad.dat
http://wpad.subdomain.example.local/wpad.dat
The file is retrieved and loaded into the User’s browser session!

DHCP Option 252

DHCP method requires configuration of the DHCP scope that your User’s will use. A specific DHCP option, option 252 text string is used for this. On your DHCP server, find the scope your Users will be assigned an IP address from and add the DHCP option 252 as a type string. The string value should be the URL to reach the PAC file. For example,

Microsoft DHCP:

Other helpful links:

Smart Mirror Project

Jim — Mon, 02 May 2016 03:41:43 +0000

Like many of you I tend to browse Imgur from time to time. I noticed a few times some folks were showing off their build of a Smart Mirror and I thought to myself that would make a great thejimmahknows post! So here we go!

Supplies:
- - Furring Wood — This will be used as our frame’s trim and mirror.
  - Whitewood — This will be used to frame our box.
  - Perforated Hardboard — Used on the back of our Smart Mirror.
  - Wood Glue — This will be used to tie the Frame and Furring Trim together.
  - Clutch clamps — I had 3 of these at my disposal, I highly recommend having at least to two(2).
  - Two-way Mirrored Acrylic Sheets– I went with 3/16th and the dimensions of the TV.
  - Raspberry Pi — The brains of this operation!
  - Monitor/TV — Choose one to meet your needs. Mine goal was to fine a cheap LED 32in monitor/TV. I settled with a Sharp LC-32LB370U (32″ LED TV)
  - Optional: Nail Set — Use this to nail in the trim, I already had one of these.
  - Optional: Finishing Nails — Just a little extra to tie the Frame and Trim together.
- Some Shopping Pictures
Sizing:
- Remove the bezel from the monitor/TV to get the correct sizing. Below is the Sharp TV bezel removal..
- I also removed the speakers in the last picture in an effort to reduce the TV’s max width.
- I measured this TV as 12 inches by 28 inches
Framing
- Accounting for the sizing obtained in the previous step. I added 3/8 inch to the overall dimensions.
- Cut the pieces appropriately and glued w/screws to hold the frame together as show below…
- I also covered the screw holes using a little Wood Fill Puddy to hide them.
- After it dries, use sandpaper to smooth it out. I went 80 to 120 grit.
The Trim
- Start the Trim process by using the dimension of the frame you created in the previous step. Account for an approxmet overhang of 1 inch of inside frame.
- Use a miter saw to cut the 45 degree angles and using glue anchor it to the frame.
- I would recommend starting with the top pieces of trim..One at a time!!
  and then the bottom one…
- After the top and bottom pieces have finished glue. Move on to the side pieces. Depending on how straight the furring wood is or if its contorted, re-measure before cutting the side pieces so they fit.
  left and then right, i think….
- I added some finishing nails for extra holding strength. Use a speed square to set your nails to compensate for the trims overhang.
- Finished Frame and Trim
The Stand
- A pretty simple design, using some of the spare Whiteboard pieces from the frame construction I cut at 45s to make the supports.
- I chose to use threaded bolts with wing nuts to easily convert it and hang it directly on the wall.
- Lastly I used some scrape plywood or MDF board to cut the base. The base size will depend on how tall and heavy you make yours!!
- A little 2×4 to secure it and we are done with this part!
Time for some Stain!
- Choose whatever color stain you want and I recommend doing this with gloves and outside!!
Putting the stand together
- I decided to drill a 1.25″ hole at the bottom of the the frame for future use. If I ever want to hang the frame I can easily re-route the wires through this hole and out the bottom.
- Putting the Stand and Frame together, using the threaded bolts and wing nuts, make assembling it fast.
- Drill a small hole behind the trim to route the Infrared sensor for the TV
Inserting the Mirrored Glass and TV
- Use rubber stoppers or something similar prior to inserting the glass into places. I found these at Home Depot for under $3.
- Insert the Glass in very carefully!!
- Now lay the TV (without the bezel) on top of the glass)
- Feed the Infra-red wire through the hole we made in the previous step.
- Using Velcro strips and some packing tape secure the Raspberry Pi and cabling.
Adding the back
- Using the Perforated Hardboard, cut the back to fit within the frame. And use Drywall screws to lock it in place.
Let’s boot it up!
- Please visit https://www.raspberrypi.org/help/noobs-setup/ to learn how to setup your Rasberry Pi for the first time.
- There really isn’t much at work here, we wil be running Apache2 a very common web server, tell the Rasberry Pi to launch it at login(which we’ve set to auto-login), and it will host some custom HTML and CSS to present us with what we want to see behind the mirror.
- MichMIch maintains the code with the template on GitHub, grab it here https://github.com/MichMich/MagicMirror
- Oh look at the magic!
The Finished Product
- Tada!
Inspiration (Thank you so much!)
- http://michaelteeuw.nl/post/84026273526/and-there-it-is-the-end-result-of-the-magic
- http://blog.dylanjpierce.com/raspberrypi/magicmirror/tutorial/2015/12/27/build-a-magic-mirror.html

Cisco AnyConnect SSL/TLS Trustpoint

Jim — Mon, 28 Mar 2016 16:48:43 +0000

I wanted to put together a quick tutorial for setting up a Cisco ASA – AnyConnect with SSL/TLS. I’ve done it a few times and I always have to re-lookup each step and the order in which to do it, so why not make a quick post about it to remember!

Optional: Destroy Current Trustpoint

You will have to destroy or clear out the current trustpoint if it already exists. This must be done if you are going to re-generate the key, which is best practice when renewing a Certificate due to expiration or one that has been compromised.

asa01(conf)# no crypto ca trustpoint oldtrustpoint.trustpoint

It will warn you that it will destroy any certificates within the trustpoint.

Generate a Key

Here we start with the generation of our key, using 2048 bits. the key name can be anything you want, but I like call it by the service I will be putting it on, for my case for this tutorial is accessthejimmahknowscom.key

asa01(conf)# crypto key generate rsa label accessthejimmahknowscom.key modulus 2048

Setting up the trustpoint locale and generate a CSR for submission

First we need to set up a trustpoint object, with our locale properties, etc

asa01(conf)# crypto ca trustpoint newtrustpoint.trustpoint
asa01(config-ca-trustpoint)# subject-name CN=access.thejimmahknows.com,O=thejimmahknows,C=US,St=Connecticut,L=Wethersfield
asa01(config-ca-trustpoint)# keypair accessthejimmahknowscom.key
asa01(config-ca-trustpoint)# fqdn access.thejimmahknows.com
asa01(config-ca-trustpoint)# enrollment terminal
asa01(config-ca-trustpoint)# exit

newtrustpoint.trustpoint — The name I gave to this trustpoint which will tie everything together.
subject-name — This command holds the distinguished name of the Certificate’s profile, see RFC3039
keypair — This is what key to pair the trustpoint with, we generated this in the previous step.
fqdn — This is the main FQDN of our service that will use the trustpoint
enrolment terminal — This tells the Cisco ASA to output the CSR (which we will create in the next step) to the terminal screen. Otherwise you will have to SFTP to the ASA and download it.

Invoke the Cisco ASA to generate a CSR based on our locale and key from the previous step

asa01(conf)# crypto ca enroll accessthejimmahknowscom.trustpoint

Answer no to include the device serial number in the subject name, unless your 3rd-party Certificate Authority requires it.
Answer ‘yes’ to display the Certificate Request in the Terminal (makes things easier for submission)
Copy this Certificate Signing Request (CSR) and paste it into your 3rd-party Certificate Authority to obtain a valid signed Certificate

Importing your 3rd-Party’s Chain

Cisco calls this next step of importing your Certificate Authority’s chain certificates as authenticating…I dunno. But we’ll go with it.

asa01(conf)# crypto ca authenticate newtrustpoint.trustpoint
asa01(conf)# {paste in Certificate Authority certificate}

Follow the prompts to successfully import the Certificate Authority’s certificate chain

Importing your User Certificate (Hint: you got this from your 3rd-Party CA)

asa01(conf)# crypto ca import newtrustpoint.trustpoint certificate

You will be prompted to paste in the certificate, do so.
You can either choose…
- certificate — for a PEM-base64 certificate
- pkcs12 — for a binary certificate type.

Lastly, configure the ASA to use the trustpoint for a service. (Mine is for AnyConnect)

asa01(conf)# ssl trust-point accessthejimmahknowscom.trustpoint outside

Here we active this trustpoint on our outside interface.

Useful commands:

show crypto ca certificates — Shows certificates successfully loaded on the Cisco ASA
show crypto ca trustpoint — Shows trustpoints installed on the Cisco ASA

Sources:

F5 BIGIP and HAProxy — Masking 2-Way “Mutual” SSL Authentication

Jim — Fri, 26 Feb 2016 22:22:48 +0000

Hello folks,

So a recent post I published talked about 1-Way vs 2-way SSL Authentication in some decent detail. We learned that 2-Way “Mutual” SSL Authentication can be used to enforce both parties attempting to communicate securely to provide authenticity. In other words, prove to each other that they are who they say they are. This can be very powerful from a security standpoint, but is it practical? The answer is, yes and no. The constraint comes from the aspect of administration (actually create certificates for each client) and manageability (keep accounting and maintaining actively lists of trusts) with the trade-off of proper authenticity. For example at first administering and managing 10 client certificates may be okay, but then imaging 100, or even a 1,000! So in this post I wanted to approach the idea of utilizing some tools we can use to offload some of this administration and management while maintaining Mutual Authentication with another entity. The idea revolves around one major assumption, users of a particular service (In this case a web-server) reside on a privately controlled and trusted network

My idea is if we have a group of clients residing on an internal privately addressed network, we can use either an F5 LTM or HAProxy to proxy our users’s connections destined for a service that is enforcing 2-Way SSL “Mutual” Authentication. The F5 LTM or HAProxy would perform the 2-Way SSL Mutual Authentication on behalf of each connecting user, eliminating the technical need to generate certificates for each client, while maintaining an element of mutual trust to the end service.

The basic idea is: (notice only our F5 LTM/HAproxy and the web-server perform 2-Way “Mutual” Authentication)

Preliminary Steps:

For the following steps please read my 1-Way vs 2-Way SSL Authentication Post.

Create a the web-server’s CSR and Key

root@ca:/opt# openssl req -config openssl-rootca.conf -extensions server_req_ext -new -nodes -newkey rsa:2048 -keyout web-server.key -out web-server.csr -days 365
Generating a 2048 bit RSA private key
................................+++
............................................................................+++
writing new private key to 'web-server2.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Enter Country [US]:
State or Province Name (full name) [Connecticut]:
Locality Name (eg, city) [Wethersfield]:
Organization Name [thejimmahknows]:
Unit Name [Test Unit]:
Common Name (e.g. server FQDN or YOUR name) []:web-server
Contact email for this Certificate [admin@example.com]:

Create the F5 & HAproxy Server-Side CSR and Key

root@ca:/opt# openssl req -config openssl-rootca.conf -extensions client_req_ext -new -nodes -newkey rsa:2048 -keyout ha-client1.key -out ha-client1.csr -days 365
Generating a 2048 bit RSA private key
...................+++
.....+++
writing new private key to 'ha-client1.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Enter Country [US]:
State or Province Name (full name) [Connecticut]:
Locality Name (eg, city) [Wethersfield]:
Organization Name [thejimmahknows]:
Unit Name [Test Unit]:
Common Name (e.g. server FQDN or YOUR name) []:ha-client1
Contact email for this Certificate [admin@example.com]:

Create the F5 & HAproxy Client-Side (connection the client will actual connect to)

root@ca:/opt# openssl req -config openssl-rootca.conf -extensions server_req_ext -new -nodes -newkey rsa:2048 -keyout virtual-service.key -out virtual-service.csr -days 365
Generating a 2048 bit RSA private key
........................+++
.............................................................+++
writing new private key to 'virtual-service.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Enter Country [US]:
State or Province Name (full name) [Connecticut]:
Locality Name (eg, city) [Wethersfield]:
Organization Name [thejimmahknows]:
Unit Name [Test Unit]:
Common Name (e.g. server FQDN or YOUR name) []:mytestvip
Contact email for this Certificate [admin@example.com]:

Using our CA from my previous ariticle, sign all three of these certificates

Sign the web-server’s CSR

root@ca:/opt# openssl ca -config openssl-rootca.conf -extensions server_req_ext -in web-server2.csr -out web-server2.crt
Using configuration from openssl-rootca.conf
Enter pass phrase for /opt/rootCA.key:
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'US'
stateOrProvinceName   :ASN.1 12:'Connecticut'
localityName          :ASN.1 12:'Wethersfield'
organizationName      :ASN.1 12:'thejimmahknows'
organizationalUnitName:ASN.1 12:'Test Unit'
commonName            :ASN.1 12:'web-server'
Certificate is to be certified until Feb 25 15:10:27 2017 GMT (365 days)
Sign the certificate? [y/n]:y


1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

Sign the F5 & HAProxy Server-Side CSR (This is the connection the F5 makes to our backend pool members)

root@ca:/opt# openssl ca -config openssl-rootca.conf -extensions client_req_ext -in ha-client1.csr -out ha-client1.crt
Using configuration from openssl-rootca.conf
Enter pass phrase for /opt/rootCA.key:
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'US'
stateOrProvinceName   :ASN.1 12:'Connecticut'
localityName          :ASN.1 12:'Wethersfield'
organizationName      :ASN.1 12:'thejimmahknows'
organizationalUnitName:ASN.1 12:'Test Unit'
commonName            :ASN.1 12:'ha-client1'
Certificate is to be certified until Feb 25 15:12:16 2017 GMT (365 days)
Sign the certificate? [y/n]:y


1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

Sign the F5 & HAProxy Client-Side CSR (This is the connection our users will connect to, the VIP)

root@ca:/opt# openssl ca -config openssl-rootca.conf -extensions server_req_ext -in virtual-service.csr -out virtual-service.crt
Using configuration from openssl-rootca.conf
Enter pass phrase for /opt/rootCA.key:
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'US'
stateOrProvinceName   :ASN.1 12:'Connecticut'
localityName          :ASN.1 12:'Wethersfield'
organizationName      :ASN.1 12:'thejimmahknows'
organizationalUnitName:ASN.1 12:'Test Unit'
commonName            :ASN.1 12:'mytestvip'
Certificate is to be certified until Feb 25 15:15:09 2017 GMT (365 days)
Sign the certificate? [y/n]:y


1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

Configure Apache web-server to enforce the 2-Way “Mutual” Authentication

Apache Config from previous post.

root@web-server:/opt# vi /etc/apache2/sites-available/default.conf
Listen 443

        DocumentRoot           "/var/www/"

        SSLEngine               on
        SSLCACertificateFile   /opt/rootCA.crt
        SSLCertificateFile     /opt/web-server.crt
        SSLCertificateKeyFile  /opt/web-server.key
       SSLCARevocationFile    /opt/rootCRL.crl
        SSLStrictSNIVHostCheck on
        SSLVerifyClient        require
        SSLVerifyDepth         1

# Allows PHP to read Certificate info
        SSLOptions +stdEnvVars

        LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
        CustomLog "/tmp/access.log" combined
        ErrorLog "/tmp/error.log"

Restart Apache

root@web-server:/opt# service apache2 restart

For Troubleshooting create this index.php file

";

echo "Client Cert =  " . $_SERVER['SSL_CLIENT_S_DN_CN'] . "
";
echo "Server Cert =  " . $_SERVER['SSL_SERVER_S_DN_CN'] . "
";
echo "Server Serial =  " . $_SERVER['SSL_SERVER_M_SERIAL'] . "
";
?>

Masking with F5 LTM:

Importing Certificates
- Import virtual-service certificate
- Import ha-client1 certificate
  - Use the same steps from above.
- Import the rootCA certificate (used to authenticate the web-server)
  - Use the same steps from above.
- All 3 Certificates imported
Create the SSL Profiles
- Create the client-side-connection SSL profile
- Create the server-side-connection SSL profile
Create the Server Pool
- Verify Pool Status is GOOD
Create the Virtual Server aka VIP
- Verify VIP (Vritual Server) looks good
Test by using Chrome to connect to our virtual-service

Certificate revocation

Revoke the ha-client1.crt (The certificate the F5 authenticates with when connecting to the web-server)

root@ca:/opt# openssl ca -config openssl-rootca.conf -revoke ha-client1.crt -crl_reason keyCompromise
Using configuration from openssl-rootca.conf
Enter pass phrase for /opt/rootCA.key:
Revoking Certificate 1005.
Data Base Updated

Re-generate the CRL

root@ca:/opt# openssl ca -config openssl-rootca.conf -gencrl -out rootCRL.crl
Using configuration from openssl-rootca.conf
Enter pass phrase for /opt/rootCA.key:

root@ca:/opt# openssl crl -noout -text -in rootCRL.crl
Certificate Revocation List (CRL):
        Version 2 (0x1)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: /C=US/ST=Connecticut/L=Wethersfield/O=thejimmahknows/OU=Test Unit/CN=MyRootAuthority/emailAddress=admin@example.com
        Last Update: Feb 26 18:42:33 2016 GMT
        Next Update: Mar 27 18:42:33 2016 GMT
        CRL extensions:
            X509v3 Authority Key Identifier: 
                keyid:E3:A6:FD:69:23:0A:25:AF:7B:77:7A:B8:03:0B:B6:8A:CF:F2:B2:B8

            Authority Information Access: 
                CA Issuers - URI:http://ocsp.thejimmahknows.com/rootCA.crt

            X509v3 CRL Number: 
                4100
Revoked Certificates:
    Serial Number: 1003
        Revocation Date: Jan 16 18:55:22 2016 GMT
    Serial Number: 1005
        Revocation Date: Feb 26 18:38:04 2016 GMT
        CRL entry extensions:
            X509v3 CRL Reason Code: 
                Key Compromise

Notice the Serial Number 1005 is revoked in the CRL file now.

Replace the rootCRL.crl file on the web-server and restart Apache

scp /opt/rootCRL.crl root@web-server:/opt/rootCRL.crl

root@web-server:/opt# service apache2 restart

Test using the virtual-service VIP on the F5 again.

Masking with HAProxy:

If you are unfamiliar with HAProxy, I recommend checking out my article on setting up HAProxy. Or my articles on using HAProxy as a F5 LTM replacement.

Before we being, we have to generate and sign another certificate and key because we revoked the ha-client.crt perviously.

root@ca:/opt# openssl req -config openssl-rootca.conf -extensions client_req_ext -new -nodes -newkey rsa:2048 -keyout ha-client2.key -out ha-client2.csr -days 365
Generating a 2048 bit RSA private key
.+++
....................................+++
writing new private key to 'ha-client2.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Enter Country [US]:
State or Province Name (full name) [Connecticut]:
Locality Name (eg, city) [Wethersfield]:
Organization Name [thejimmahknows]:
Unit Name [Test Unit]:
Common Name (e.g. server FQDN or YOUR name) []:ha-client2
Contact email for this Certificate [admin@example.com]:

And Sign it

root@ca:/opt# openssl ca -config openssl-rootca.conf -extensions client_req_ext -in ha-client2.csr -out ha-client2.crt
Using configuration from openssl-rootca.conf
Enter pass phrase for /opt/rootCA.key:
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'US'
stateOrProvinceName   :ASN.1 12:'Connecticut'
localityName          :ASN.1 12:'Wethersfield'
organizationName      :ASN.1 12:'thejimmahknows'
organizationalUnitName:ASN.1 12:'Test Unit'
commonName            :ASN.1 12:'ha-client2'
Certificate is to be certified until Feb 25 19:47:40 2017 GMT (365 days)
Sign the certificate? [y/n]:y


1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

Copy All 3 certificates to our HAProxy server

root@ca:/opt# scp virtual-service.* root@172.16.0.44:/opt/
root@ca:/opt# scp ha-client2.* root@172.16.0.44:/opt/
root@ca:/opt# scp rootCA.crt root@172.16.0.44:/opt/

We need to chain the virtual-service certificate with the root CA certificate for HAProxy to accept it. (For help reference this)

root@test-haproxy:/opt# cat virtual-service.key >> virtual-service-chain.pem
root@test-haproxy:/opt# cat virtual-service.crt >> virtual-service-chain.pem
root@test-haproxy:/opt# cat rootCA.crt >> virtual-service-chain.pem

And ha-client2

root@test-haproxy:/opt# cat ha-client2.key >> ha-client2.pem
root@test-haproxy:/opt# cat ha-client2.crt >> ha-client2.pem

Edit your haproxy.conf file to match

global
        log /dev/log    local0
        log /dev/log    local1 notice
        chroot /var/lib/haproxy
        stats socket /run/haproxy/admin.sock mode 660 level admin
        stats timeout 30s
       user haproxy
       group haproxy
        daemon

        # Default SSL material locations
        ca-base /etc/ssl/certs
        crt-base /etc/ssl/private

        # Default ciphers to use on SSL-enabled listening sockets.
        # For more information, see ciphers(1SSL). This list is from:
        #  https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/
        ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
        ssl-default-bind-options no-sslv3
        tune.ssl.default-dh-param 2048

defaults
        log     global
        timeout connect 5000
        timeout client  50000
        timeout server  50000
        errorfile 400 /etc/haproxy/errors/400.http
        errorfile 403 /etc/haproxy/errors/403.http
        errorfile 408 /etc/haproxy/errors/408.http
        errorfile 500 /etc/haproxy/errors/500.http
        errorfile 502 /etc/haproxy/errors/502.http
        errorfile 503 /etc/haproxy/errors/503.http
        errorfile 504 /etc/haproxy/errors/504.http


frontend vs_172.16.0.44_443
        bind 172.16.0.44:443 ssl crt /opt/virtual-service-chain.pem
        default_backend pool_test2waySSL


backend pool_test2waySSL
        server testweb01 172.16.0.25:443 ssl verify required ca-file /opt/rootCA.crt crt /opt/ha-client2.pem

Success!!

Revocation test

Revoke and re-generate the rootCRL.crl file

root@ca:/opt# openssl ca -config openssl-rootca.conf -revoke ha-client2.crt -crl_reason keyCompromise
Using configuration from openssl-rootca.conf
Enter pass phrase for /opt/rootCA.key:
Revoking Certificate 1007.
Data Base Updated

And re-generate the CRL

root@ca:/opt# openssl ca -config openssl-rootca.conf -gencrl -out rootCRL.crl
Using configuration from openssl-rootca.conf
Enter pass phrase for /opt/rootCA.key:

Reload Apache on our web-server to pick up the new CRL file
```
root@web-server:/opt# service apache2 restart
```
Now we test….

TechJockey.NET

Airflow, Azure and OAuth

F5 iRule — No Pool Members Available Vanity Page

$httphost

NOTICE: Site Unavailable.

Site Unavailable

Cisco ACL — Dedicated Internet Edge Drop Device

Where to start…

Simple Starting List

Adding a Wider Range of items to the List…

Crafting a basic Drop ACL brew…

Ask my Dad the ISP for help…

Sources:

Security Through Obscurity

The Remote Access VPN Battle — SSL vs IPSec VPN

Datagram Transport Layer Security (DTLS)

Helpful links:

Apt-Get HTTP Proxy — One-Liner

PAC File and Web Proxy Auto-Configuration (WPAD) HowTo

The PAC File

PAC File Deployments

WPAD Deployments (DNS and DHCP)

DNS Option

DHCP Option 252

Smart Mirror Project

Supplies:

Sizing:

Framing

The Trim

The Stand

Time for some Stain!

Putting the stand together

Inserting the Mirrored Glass and TV

Adding the back

Let’s boot it up!

The Finished Product

Inspiration (Thank you so much!)

Cisco AnyConnect SSL/TLS Trustpoint

Optional: Destroy Current Trustpoint

Generate a Key

Setting up the trustpoint locale and generate a CSR for submission

Invoke the Cisco ASA to generate a CSR based on our locale and key from the previous step

Importing your 3rd-Party’s Chain

Importing your User Certificate (Hint: you got this from your 3rd-Party CA)

Lastly, configure the ASA to use the trustpoint for a service. (Mine is for AnyConnect)

Useful commands:

F5 BIGIP and HAProxy — Masking 2-Way “Mutual” SSL Authentication

Preliminary Steps:

Create a the web-server’s CSR and Key

Create the F5 & HAproxy Server-Side CSR and Key

Create the F5 & HAproxy Client-Side (connection the client will actual connect to)

Using our CA from my previous ariticle, sign all three of these certificates

Configure Apache web-server to enforce the 2-Way “Mutual” Authentication

Masking with F5 LTM:

Importing Certificates

Create the SSL Profiles

Create the Server Pool

Create the Virtual Server aka VIP

Test by using Chrome to connect to our virtual-service

Certificate revocation

Masking with HAProxy: