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.
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.
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.
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)
Table of Contents
- About SSL Authentication
- Quick Review
- Creating a Certificate Authority
- 1-way “Standard” SSL Authentication
- 2-way “Mutual” SSL Authentication
- Advanced SSL Authentication: CRLs, CDP, and OCSP
- Concept Review
About SSL Authentication:
SSL Authentication is nothing more than proving the authenticity of one or both parties in the formation of an SSL “Secure” connection.
1-way “Standard” SSL Authentication is the most common, you use this every time you log into Facebook, your bank website, google, etc. The point of this type of authentication is for you (as the client) to verify the authenticity of the web site you are connecting to and form a secure channel of communication.
2-way “Mutual” SSL Authentication is less common than the traditional “one-way” SSL authentication we are a custom to when visiting secured websites. When we connect to our banking website or our favourite web e-mail site, we as the client are verifying the identify of the site we are requesting content from. This “one-way” authentication allows us as the client to connect with confidence that the web site we are receiving content from has been verified. this authenticity check is performed by our client browser with a little help from a third-party certificate authority.
Let’s first review a one-way SSL connection.
- The Client browsers receives https://google.com in it’s address barf
- Client browsers knows based on https:// that this connection will require an SSL handshake and sends a CLIENT_HELLO to the destined web server (google). This includes other things like SSL/TLS version, acceptable ciphers, etc
- The web server receives the CLIENT_HELLO request and sends a SERVER_HELLO back to the client. SERVER_HELLO contains SSL version, acceptable ciphers, and the server certificate.
- The client receives the servers certificate and it is verified against a list of known Certificate Authorities.
- If the certificate is proven to be in good standing, the client sends back a pre-master secret is encrypted inside the server’s certificate. Remember only the server can decrypt anything encrypted with it’s certificate because only the server has the decryption key. Server Certificate encrypts, Server Key decrypt’s.
- At this point both client and server have the pre-master secret and can calculate a master secret to use to symmetrically encrypt and decrypt data between them.
So as we can see from a traditional SSL handshake, the client is never verified as authentic. Now, in most situations this is fine, as most connect types of this nature only need to verify the server because that is where the content is coming from.
The difference: In a 2-way mutual authenticated SSL handshake, the server will ask the client to send its own certificate for verification. Just like the client asking for the server’s certificate in the 1-way SSL handshake above, the server will perform verification of the client certificate before continuing to the pre-master and master secret phase of the SSL handshake. If authenticity of the client cannot be verified the server closes the connection.
How is mutual trust obtained? Both the server and client must generate their own SSL certificate and keys, and both must be signed by the same Certificate Authority. This ensures that both the server and the client’s certificate are trusted. This allows authentication to remain asymmetrical, instead of symmetrical. For example, rather than have a shared password that 3 clients and the server use to encrypt and decrypt data. Each client and the server have their own certificates and keys that will be used for communication with the server. Asymmetrical authentication and encryption is better at enforcing authenticity because everyone has their own cert and key used to establish a secure connection with the server. Symmetrical authentication is faster at encrypting and decrypting but suffers from having every client use the same key.
What happens if a client key is compromised? In the symmetrical authentication scenario, mentioned previously, you would have a serious security issue on your hands. Each client would be at risk and the likely hood of eavesdropping would increase. An attacker only has to obtain one key to gain visibility into every connection. Asymmetrical on the other hand has a different way of handling this. Because each client has it’s own certificate and key pair, and the signing of each certificate is performed by a third-party Certificate Authority, one simply has to revoke the compromised client in the form of a CRL certificate(more on this later). Other client connections will not be compromised or have to be re-generated. The server verifying the client certificate will fail only for the revoked for the compromised client.
What happens if my Certificate Authority’s key is compromised? This is the worst case scenario that can happen in your PKI infrastructure.An attacker can impose and generate a new certificate authority certificate and start signing certificates that can be used to fake authenticity. In essence break the certificate authority’s trust. Keep in mind a Certificate Authority key cannot decrypt your connections.
As promised here is my article on how to setup a SSL remote VPN, an alternative to IPSec Remote VPN from this article. What’s great is the steps to setup an SSL remote VPN service are very similar to IPSec remote VPN!! So let’s get started.
As with IPSec remote VPN we will need similar design considerations for SSL remote VPN.
- First, a subnet is required for client’s to be put on when successfully authenticated and authorized via the SSL remote VPN. This can be the same subnet as one already existing on your network or a separate one with a firewall in-between The later being best in practice and security.
- Secondly, deciding on split-tunneling vs all-tunneling. The difference being on the client would you like all traffic to be forced across the tunnel or allow clients to communicate with both their local network and the networks on the otherside of the VPN. For best practice and security, all-tunneling is recommended.
- Third, Access Lists and tunneled networks. Here we will decided what SSL remote VPN users will have have access to in our other networks. We will also, in the case of split-tunneling, create an access-list of what networks to tunnel for the Remote VPN user.
- Fourth, provisioning standard network services for VPN user’s. Remote VPN user’s will need a default gateway, DNS servers, domain suffix, an address pool, proxy settings, etc.
I’ve posted a few articles on how to set up a Forwarding Proxy using Squid, and using benefits like caching and content blocking (Ads, adult, gambling, etc). This can bring centralized web security and delivery to you and your users. However, users need to be expliclty configured to use the Proxy service. This means having their web browser like Firefox or even Internet Explorer set with the DNS or IP address of the Proxy server. This can be an issue if youhave little or no management of the user’s Web Browsers configuration. This is where a content-routing protocol like WCCP(Web Cache Communication Protocol) comes into play. With WCCP we can influence specific user traffic to be encapsulated and re-routed to your Proxy server. The difference between this and some of the other ways to force web traffic to your Proxy server(like iptables redirection) is the original Web packet generated by the user’s device is not altered. Instead it is encapsulated when it reaches your WCCP receiver running on an upstream egress router(user gateway towards Internet). It is then re-routed via this encapsulation to your Proxy server which is WCCP aware.
Before we begin, you will need a few things:
- Squid Proxy Server 3.4+ compiled with WCCP
- Router or Security device capable of running the WCCPv2 service(See vendor list here…)
- Some knowledge of Web Proxy Technology.
- A Web Browser to test with.
- Your favorite beverage and some patients.
Notice: Cisco ASA only supports having the user subnet(s) and the cache-engine(Squid Proxy server) behind the same Cisco ASA interface(inside,dmz,outside,etc). The reason for this is the WCCP processing on the ASA happens after interface ACL, meaning for example ACL on your inside interface are processed before any WCCP manipulation can begin.
- User requests a web resource on outside interface(usually the Internet) of Router/Firewall.
- WCCP Server (Router/Firewall) catches this interesting traffic(traffic we want to redirect) and encapsulates it within a GRE tunnel to the WCCP Client(Squid Proxy Server) on the other end of the tunnel.
- WCCP Client (Squid Proxy Server) decapsulates the GRE payload and fetches the original client request just like an ordinary Web Proxy would.
- WCCP Client receives a response from the external web server.
- WCCP Client (Squid Proxy Server) serves the web page back to the original User by spoofing the source IP address(This is key). Spoofing is done by rewriting the source IP address field of the packet with the External Resource’s IP address. This makes it look like the packet the user receives is from the external web site.
**This article is old, see new Blocklist2ACL 2.0 project.**
Hi folks! A little script I wrote with VBscript that pulls in IP blocklists from different third party URLs and converts them in to well-formatted Cisco ASA access-lists. The idea stemed from the old days of running PeerGuardian and Moblock to inhibit known malicious or unwanted IP address from attempting to connect and stopping them right then and there on your computer’s firewall. It is similar to URL Blocklists that focus on URLs and Domain Names, but instead filering is done by IPs only. I wanted to take this IP Blocklist concept that has primarly been done at the Desktop Fireweall layer and abstract it to the Network Firewall. In this case a Cisco ASA that way all traffic that any connection that crosses the Firewall will be filtered by this list.
The script is fairly straightforward and the source code is below so you may look through it. Feel free to improve upon it and share it with others. I have a few years of writing vbscripts, but am in no way a professional coder. Also, if you by any chance know Linux Shell or Qt and could potentially port this to Linux or even better JAVA for platform independence, let me know!! That would be sweet.
Resetting the Windows administrator’s password or Linux root account password is a common troubleshooting practice when faced with systems infected with mailware, data corruption, and system recoveries. This article does not prompt malicious use, but instead stress the point that an account password does not protect your data.
In principle, passwords are stored locally, anything stored locally can be obtained and modified by slaving that physical data. For example, a hard drive can be removed, added to a different computer already running it’s own OS. That drive will now show up as a slave drive and the contents easily accessible. The following tutorial does not use any third party tools, and only relies on the initial media used to install the OS.
- Resetting Stock Windows Administrator password using Installation Disc
- Resetting Non-Stock Administrator Password using Windows Installation Disc
- Resetting Linux Root Password using Single User Mode
Hello, hello! Recently I posted a two part article on creating a Guest wireless network using OpenWRT, VLANs, and Firewall rules. Now we left things kinda open from a security standpoint. WE gave our Guest users full Internet access with no restrictions on sites, bandwidth usage, or ports!! Yikes! For this article I am going to walk you through the steps to close those gaps. We are going to first configure a Web Proxy server that will proxy outbound Internet connections. This allows us to check where and what are Guests are trying to get their hands on. Good and bad. We will also force Guests to connect to this Web Proxy server transparently. What I mean by that is the Guests will not be required to do anything on their side to connect, our firewall will take care of that. And lastly, I want only allow limited bandwidth of HTTP traffic. You will see later on how we can accomplish this. I’ve expanded upon this article of mine that uses squid proxy to filter Ads.