There are a lot of sites online...serious sites...with reams of technical knowledge and mired in the depths of their trenchant and ponderous, you know.... seriousness! I want this site to be a bit fun, light and definitely spirited. A hard to grasp concept, for sure, but isn't that true about wind? You can't grasp it, you can only see its effects. It's Breezy! You know what I mean?
I'm definitely having some fun here! I configured Apache so that it will serve up more than one website by using the "Name-Based Virtual Host" feature. Simply stated, Apache is configured so that when a client tries to connect to the web server, the server will read the HTTP request for the FQDN (fully qualified domain name)of the URL and will serve up the web page from the correct site. This definitely saves $$ since I can host several sites on my one static IP address, rather than hosting sites on separate IP addresses.
Apparently (and here I prove that I'm no expert!) HTTP v1.1 is required on the web client since it is the client who sends the initial request...this in turn identifying the site being connected to. Clearly ancient browsers will not work. For more information on this feature, navigate over to this document on the official Apache.org website.
I'm going to be teaching my 1st CCNA bootcamp this week in a long time. I have been focused on teaching the CCNP and CCSP curriculum for a while, so it will be nice to come back "down to earth" for a bit and get my hands dirty with basic networking, routing, and switching. I will (I'm sure!) have some links and interesting little sidebars to put on the Breezy! site during the week as a result.
/Eric
An ice storm blew through the area of Canada that I live with wind and freezing rain knocking down power lines, trees and other assorted things. Many things that used to be vertical became horizontal. We were without power for 24 hours, a mere inconvenience when compared to the 2 weeks that we were without power in the famous Ice Storm of January 1998.
We went up to a local hardware store to pick up a gas powered generator, a 2.5 KW model to use as a backup for the next time that we were without power for a while. After all, it does get cold here! It would be nice to have water in the taps instead of ice. Having the furnace running would be nice too. Anyway, I digress. The young guy that answered the phone at the hardware store while I was phoning around trying to find someone with a generator for sale opined that I would probably not want his single remaining generator since it was an "electric generator". I asked him what he meant by "electric generator" since it *was* a unit which produced electricity that we wanted. He said that as far as he could tell, the unit had to plugged into the wall to produce electricity. Big pause. I said that I'd be right down to pick it up as it was exactly what I needed. I told him to go right ahead dissuading other people from buying it until I was down there because it was obvious that it wasn't very saleable anyway since only people with specific needs would require a plug-in generator! A little background....there was not a single generator to be found in a 100 kilometre radius of my house. People were frantically trying to obtain these things out of a real sense of need as basements flooded due to submersible pumps failing; cows had to be milked, etc. My neighbours had had a big head start on me since I had come home late the 1st night of the storm from a business trip.
Its axiomatic in the network security field that one should never buy hardware and implement a network security architecture without first completing the blueprint. That's exactly what a Network Security Policy is...a blueprint and a framework for network security implementation. It sounds obvious, but if common sense were so common we wouldn't have to call it common sense. It would just be "sense".
Similarly (and to paraphrase B. Fraser, editor of RFC 2196, "the Site Security Handbook"), a Network Security Policy is a formal statement by which all of the owners, custodians and users of a corporation's network resources must abide. I think back to my first Cisco PIX firewall customer. This customer, the CEO of a large, multi-site family-owned HVAC firm, was referred to me by another customer. When I asked my soon-to-be-new customer how he wished to implement his firewalls and what kind of network security policy he was enforcing with the hardware I got a blank stare. (Actually it was long pause because the initial contact was by phone, but "blank stare" sounds so much more interesting!) He hadn't actually thought it all the way through. He just had a nebulous fear that when he retired his old ISDN (shudder!) circuit-switched network and installed DSL between his sites that he was opening himself up to the possibility of Internet-based exploits. Of course he was right in being fearful of attacks. Certainly he had intellectual property, inventory, customer records and trade secrets that he needed to protect but he had not performed proper, rigorous due diligence in determining his needs, nor whether he would realize a reasonable return on investment (ROI).
I found the issue with the exploding TinyCA2 GUI for the certificate authority. (cross reference here ). Of course, there is no documentation for TinyCA2, I had to search (and search and search and....) until I found the missing element. The issue is with OpenSSL, or more properly with tinyCA2 which is just a GUI to OpenSSL. The URL for a CRL DP (Certificate Revocation List Distribution Point) has to be in the format URI:http://www.breezy.ca/CRL/breezy.crl Note the "URI:" prepending the URL. This is well documented in OpenSSL but not in tinyCA2.
Now that I had my own internal DNS server (running BIND9) on my home network, it was only natural that I setup a VPN group for split DNS. The advantage is that my email clients and other software are set up to use server resources on the breezy.ca domain. My SMTP server is configured so that only internal IP addresses can send email. Therefore if I want to use my inside mail server, its domain name must resolve to an internal IP address. When I'm on the outside of my network (travelling for work for example) I want my mail server's domain name to resolve to this internal IP address while I'm connected to my home VPN. Similarly, I have other internal devices (such as my PIX firewall) that I need to resolve to internal IP addresses. I could put entries into the host table of my PC but that isn't particularly elegant. The solution? Split DNS. Now when I'm connected to my home VPN, my two DNS servers are:
One of the strengths of Open Source is that it's...well, open!
I have posted a number of useful links and interesting information in the new Network Security Forum. While you should probably find this information worthwhile, don't forget that these are forums......we want your input. If you have some links of your own or would like to comment on the information that's there, we would love to hear from you.
You can go to the new forum by clicking here , or clicking on the forums link in the navigation block.
Keep it Breezy!
/Eric
Another new feature will allow you to click a link that will "email this article to a friend" in various content areas (such as forums) on the Breezy! site.
/Eric
I added two new modules to Breezy! Registered users can now subscribe to content (blogs, stories, forums, etc.) and look at their material in aggregate by clicking on the "my subscriptions" link. Creators of content can, by checking a box, receive notifications of replies or comments to the content. Registered users can also click on a "write to author" link which is displayed with all content in order to send a private message to the content's author.
Recent comments
1 day 5 hours ago
1 day 20 hours ago
1 day 21 hours ago
2 weeks 5 days ago
4 weeks 5 days ago
5 weeks 2 hours ago
7 weeks 4 days ago
9 weeks 4 days ago
17 weeks 4 days ago
26 weeks 1 day ago