Sunday, 20 September 2015

to HTTPS or to HTTP?

I have to say that HTTPS makes sense in environment where there is a need to protect and HIDE the information inside the communications channel. Examples for this being banking or financial transactions as well as passwords.And even here I'll make a claim that I not utterly convinced beyond all doubt that HTTPS is the best option method to protect those data...

But does it make sense to encrypt EVERYTHING? like what https://letsencrypt.org/ is trying to achieve? (Okay, I'm all FOR the cheap/free SSL certificates, but... but ... it won't solve it all)

No it doesn't. Let me give you an example where encryption is not only a pain in the back, but counter productive: Package distribution.

Firstly I'm typically in situations where I need to reload/reinstall packages to test reliable recreation of systems. However, I'm also limited to costly internet connections, so I want to cache the packages, simply setup something like squid ro apt-cacher-ng, and I'm set.... except for those that does https:// <ARGH!!>

Let me explain, the first problem you'll hit is that apt-cacher-ng doesn't do the CONNECT statement for proxies, and why should it? it should cache the data, not bluntly allow a tunnel. I'm not even going to explain, but you'll see it in various ways and means, and I don't believe it's the right thing, as simply put it this way: I could still capture (ala cloudflare.com's SSL) your connection (since you are behind *my* firewall and proxy) and I could abuse some CA issues and then I'll be able to make you think you are connecting to the right place. But besides that, what are we actually hidding in that transaction? It boggles my mind, but let's continue.

The main concern with regards to package distribution, is the reliability of the package downloaded, and that that downloaded package haven't been tampered with. You know that this problem have been solved and used for the past 20 (twenty) odd years now? Simply sign the package with your GnuPG key, and distribute your public key, and then everybody can check that the file recieved, is the actual file that you've signed. This is as secure, if not better, than trying to trust CAs out there in the wild to confirm that your HTTPS connection was the right HTTPS connection you've said it was.... and then I'm still not sure if the file on my disk haven't been tampered with while it was busy downloaded...

Thus, THINK BEFORE ENCRYPTING

Yours loving encryption himself



Monday, 25 August 2014

iPXE pxeboot and Linux (The 40+ year old explanation)

Okay, I'm over the hill, and it starts to show, but after a morning's caffeine usage to get to the gist behind it, here are a few pointers and experiences to get a tutorial going.

  1. You are intelligent enough to setup tftp server
  2. Your brains don't freeze on a DHCP server's config files
  3. You are purveyed with tcpdump, dhcpdump and strace
  4. You can configure and server HTTP pages with whatever means you like.


Thus, I'm not going to detail the above to bore nor confuse, but rather help you with the iPXE understandings (and freshening your linux kernel parameters :) )

The other assumptions:

  • You have a PXE enabled BIOS/network adapter and want to chainload iPXE from it with a UNDI stack
The basic idea/process:

  1. Have your PXE network adapter, get a DHCP IP and information about the next image to load. This will be undionly.kpxe (You could do an ipxelinux.0, but that's adding complexity for now)
    1. The normal PXE understands TFTP, so you'll add the following parameters to give to the client:
    2. next-server "ip_of_tftp_server";
    3. filename "undionly.kpxe"
and right here I fell asleep and decided I'll wait for the digital KVM module for the Dell 1955 blades...


MS Powershell: The blessed curse

Right, well where do I start? I had to do scripting and scheduling on Windows Server 2008R2SP1 (don't ask, but at least it's not 2012).
Good, RTFM a tad, then found this new thing that just rocks in the Windows world called PowerShell! It's the best thing that perhaps could've happen in the Windows server world since... since... since... NT 3.5.1? Okay,  NT 4 was nicer and W2K looked polished, but ... but... they've always missed that one ingredient that is loved by the Un*x SysAdmins: A decent shell with scripting that doesn't suck like .BAT batch files. PowerShell 2.0 is that missing element! (And 3.0 added the remote management lmuch like what we Un*x SysAdmins used to do with SSH... It rocks, I'll admit that, and it does a few things better with it object model compared to the plain-ol' character strings in the Un*x world... it has it down falls too, but on average, I'll say I do like what they've done with PowerShell up to 4.0 (haven't yet loaded 5.0... as I don't think it'll run on my 2008R2 servers...)

But, let's get to my curse for the day: Scheduling and PowerShell (and a non-encore: schtask.exe)

Windows have this "fancy" thing called "Windows Task Scheduler". Quite extensive in what/how/etc. you have to tweak and turn, just I'm missing the documentation and the flow diagrams to explain when what will or won't work, but that's still "manageble". The fun is that PowerShell have cmdlets and scheduling that nicely fits into the Windows Task Scheduler... except that it doesn't open up all the Task Scheduler functionality *I* want and need ;(

I have the need for the period 07:00-18:00 to execute a PowerShell script every 5 minutes ( I wanted 1 minute intervals as my actual need is around a on-demand wake up when somebody drops/rename/change a file and any file in a certain directory)... Nope, the standard PowerShell job scheduling doesn't have that function, but there are several other ways people use a start job to do things like that, but that is just adding way too much complication in my live (Oh, then there are the COM object direct manipulation... I'm not going that way today, and the Task cmdlets appears to be 2012 specific ;()
But don't worry, schtasks.exe (DO notice the taskS there O_o) is there! Well... it's not so easy as telling it to execute D:\scripts\Send.ps1, no, that is way too easy and we'll have to make life difficult, so they threw a spanner in the works that it starts NotePad.exe... NotePad.exe?? Googling didn't show me anything related, so I checked the script, executed the script etc. but it all works as advertised in the PowerShell ISE... until I got the strange idea in my head: try the script in cmd.exe... VOILA! it opens a notepad.exe with the contents of the script. The Problem: Windows doesn't have a She-Bang (#!/bin/powershell.exe) like in Un*x scripts, so... well... let's just say, test you schtask.exe & at.exe script executions using cmd.exe before deploying/test on schtask.exe or at.exe, as you'll need something like "powershell.exe <script_path_name>"

Well... I don't need any deeper knowledge, as the scripts work (good enough for what we should be doing with them) and the timing appears to be adequate, so let's move on to the next problem in this project.