HOC finished at 172.4 after a buy signal at 152.7, a gain of 12.9%
KENZ finished at 534 after a buy signal at 503, a gain of 6.16%
ALNT finished at 341.5 after a buy signal at 338.2, a marginal gain of 0.98%
IMG finished at 290.8 after a buy signal at 275.8, a gain of 5.44%
Based on a long investment of £500 per share over two weeks, a total profit was shown of £127.11, 6.38%.
It is somewhat higher than overall FTSE gains, but it looks like the model needs improvement.
Particularly the sell signal on BKG at 2232, it finished at 2400, a gain of 7.5% merely shows that the model may just be relying on volatility of the stock for signals and not necessarily concerning with direction.
More model training and process refinement is to take place and we will see how the week two stocks progress at the end of next week (I have not followed their performance this week).
I’ve been experimenting with Asterisk again, using the FreePBX distro (220.127.116.11).
I have noticed that I get a lot of entries in the Asterisk log that look like this:
[2013-07-06 05:11:06] NOTICE[C-0000001f] chan_sip.c: Failed to authenticate device 555<sip:firstname.lastname@example.org>;tag=e9a98a30
[2013-07-06 05:11:08] NOTICE[C-00000020] chan_sip.c: Failed to authenticate device 555<sip:email@example.com>;tag=eebd8857
[2013-07-06 05:11:12] NOTICE[C-00000021] chan_sip.c: Failed to authenticate device 555<sip:firstname.lastname@example.org>;tag=243f3815
[2013-07-06 07:19:42] NOTICE[C-00000022] chan_sip.c: Failed to authenticate device 5555<sip:email@example.com>;tag=a049427e
[2013-07-06 07:19:45] NOTICE[C-00000023] chan_sip.c: Failed to authenticate device 5555<sip:firstname.lastname@example.org>;tag=c3c7f81b
[2013-07-06 07:19:48] NOTICE[C-00000024] chan_sip.c: Failed to authenticate device 5555<sip:email@example.com>;tag=6be78a0b
[2013-07-06 07:19:49] NOTICE[C-00000025] chan_sip.c: Failed to authenticate device 5555<sip:firstname.lastname@example.org>;tag=1979ada5
Where, of course, aaa.bb.ccc.dd is the address of my SIP server. Unfortunately, while FreePBX contains a fail2ban module, asterisk doesn’t provide enough information in the log file to act upon these messages.
The way I have got around this involves making some custom modifications to the Asterisk configuration.
Firstly, we need to enable Asterisk (v11) security logging feature:
Edit, /etc/asterisk/logger_logfiles_custom.conf and add the following:
fail2ban2 => security,notice,warning,error
This will create an additional log file, called /var/log/asterisk/fail2ban2
Now we need to edit the fail2ban configuration in /etc/fail2ban to process the security logged items. FreePBX configuration is in jail.local, so we will add ours to jail.conf:
Finally, we create a simple regex to get the IP address that we want to ban, and put it in the /etc/fail2/ban/filter.d/asterisk11.conf
# Fail2Ban configuration file
# $Revision: 250 $
# Read common prefixes. If any customizations available -- read them from
#before = common.conf
#_daemon = asterisk
# Option: failregex
# Notes.: regex to match the password failures messages in the logfile. The
# host must be matched by a group named "host". The tag "<HOST>" can
# be used for standard IP/hostname matching and is only an alias for
# Values: TEXT
failregex = SECURITY.* SecurityEvent=\"InvalidPassword\".*RemoteAddress=\"IPV4/UDP/<HOST>/
#VERBOSE.* logger.c: -- .*IP/<HOST>-.* Playing 'ss-noservice' \(language '.*'\)
# Option: ignoreregex
# Notes.: regex to ignore. If this regex matches, the line is ignored.
# Values: TEXT
# ignoreregex =
That’s it, we now intercept messages like this one from the security log, and manage to ban these device attempts:
In the news today, some rather sensationalist articles about what Google was collecting via WiFi on their Streetview tours.
Firstly, it needs to be pointed out, the information gathered:
Was unencrypted WiFi – If you run an unencrypted WiFi Home or Business network then really you are taking the risk – and you should be a lot more worried about Joe and Mary’s teenage son next door rather than the 3 seconds worth of network traffic that a Google streetview car would have picked up as it passed your house.
The Daily Mail (Fail) article suggests that they harvested information ‘from home computers and laptops’ as they passed by. This is simply untrue, they harvested information from the radio waves, just as you harvest information from all manner of radio frequencies when you retune your AM radio. Google’s only crime here is analysing what they heard. It should be pointed out that at no point did any interaction between data stored on a computer make its way to Google’s streetview car unless you transmitted it to them.
That being said – if the street view car was passing by at the time, and, you were clicking send on an email or hitting enter on a instant message, and, you’re stupid enough to not use encryption at a protocol level for any of those services, then and only then would Google have harvested some information. Perhaps a sentence in a IM conversation or a few paragraphs of your email or perhaps the URL and a quarter of a web page you happened to be browsing at the time.
There are enough conditionals there to make it seem to me that Google simply under-estimated the stupidity of our nation to protect our home computer assets. I believe their main aim in sniffing wireless traffic was to obtain BSSID information (a globally unique identifier for Wireless Access Points) to correllate it to GPS information which would allow Android phones to be able to get accurate geolocation information without necessarily having a GPS lock on the phone.
There is an opensource tool which does this very thing (called Kismet), and it saves tcpdump information to file of the sniffed wireless networks. One parameter of tcpdump is the snaplen, specified with the ‘-s’ parameter. This parameter specifies how much of the packet to save to disk. To get reliable BSSID information this probably needs to be set to around 32-bytes, just enough to get the necessary headers from the BSSID beacon frames (which by the way, you can configure to turn off as well, and would be recommended as part of an overall secure setup). I truly think that the engineer coded this parameter with zero ‘-s 0’, saw that he got the BSSID information with this parameter and left it at that. Unfortunately the ‘-s 0’ parameter value has a special meaning, and captures the entire packet.
The Daily Mail article has so many inaccuracies in it that I would expect it to be edited later. It is sensationalist, and blatently incorrect from a technical sense.
So it came to a point where I needed to choose a Hypervisor.
The choices (from the free ones) appeared to be Vmware’s offerings, either vSphere 4.1 or vSphere 5.0 or a free hypervisor such as Xen or Virtualbox.
Vmware’s offerings are touted as Tier-1 Hypervisors. That is, the hypervisor itself runs on the bare metal. Whereas KVM or Virtualbox are Tier-2 Hypervisors – relying on an underlying OS kernel.
This is where I began to hit Vmware’s limits on the ‘free’ aspects of ESXi.
My server has 8 Cores, 48GB Memory and a 2.7TB Disk Array.
ESXi v5.0 (or whatever they mean to call it now – deliberately blurring the feature set of their free product with their paid-for product) has a limitation of 32GB RAM, anything above that is unusable to the OS.
Well, OK, I’m not going to waste 16GB of memory for the sake of being on a Tier-1 Hypervisor.
ESXi v4.1 doesn’t have the memory limitation, although it appears to have fewer features (I was really interested in the PVLANs for instance, but it appears that those are paid-for only features as well!). Never the less, I tried it out – and well what do you know it has a lmitation of 750GB for local storage!
A further irksome issue I had with Vmware in testing was when I was trying to set up their Networking. I essentially wanted to implement multiple subnets, with a single interface bridged to one of the physical interfaces on the host server. Should be simple enough, no? Well think again – when I tried to do this Vmware insisted that I assign an IP address to this interface. Why? It’s a bridged interface, it doesn’t need an IP address, it doesn’t necessarily need to even run IPv4 – I might want to run IPX/SPX or IPv6 instead – in any case the bridge does not need to be assigned any Layer-3 address.
I googled on this networking faux-pas and found other people asking the same question, why does it need an IP address, with people giving ill-informed answers that “because it’s the bridge interface”. Nonsense, these people don’t know their networking.
So, now I was left with either going with something like Xen Server or perhaps going with the Hypervisor I actually use on my Laptop (Virtualbox). I thought there would be an obvious downside to Virtualbox – “it’s clearly designed for desktop virtualisation”, I thought. I had a brief look at Xen, however, and started to get confused. So XenServer is Citrix right? Citrix sell XenServer, then there is XenSource? How does that fit in? The Wikipedia says that RedHat / CentOS 6 don’t support dom0, what is dom0…
Well, too many questions, not enough answers, no good documentation.
So I opted for Virtualbox – turns out it has a pretty good Vboxheadless mode which allows me to run all my VMs through a VRDP session to their consoles (essentially using Microsoft’s Remote Desktop Services protocol RDP). I intended nearly all my VMs to be Linux based, and be primarily controlled via SSH – so this is fine for me.
There is also a companion project called phpVirtualbox – which provides a near identical GUI to the Virtualbox interface via a Web Browser.
It should also be noted that, surprisingly, Virtualbox is probably more dynamically controlable via the command line than it is via either of the GUI interfaces – and is very suited to a roll your own VM Hypervisor set up.
For some years now I have been running a VPS system to host my email, my www.coochey.net website and the placeholder for the www.netsecspec.co.uk website, it has also served me as Linux launchpad and a mini-test/lab platform. I had started off on the lowest tier and over time upgraded to a tier 4 VPS. It, however, was still incredibly limited. For one the VPS system had no swap file space available to it and the physical memory assigned to it was 512Mbytes. This meant that running a LAMP server at all would generally require a light footprint SQL server, and that, in itself, has its limitations.
So, in the past few weeks, I decided to change the way I was operating.
Now, there has been a lot of talk recently about ‘The Cloud’, in particular Amazon’s (EC2) elastic cloud offering, there is also the more general hosting solutions out there by many small providers. I’m sure that these methods suit some people, but as I work in managing and building IT infrastructures I decided to purchase an actual server and co-locate it with a hosting provider. This gives me flexibility to run what I like, how I like.
I looked online and found a supplier (RackServers, also known as Evolution Computers) had a large range of reasonably priced SuperMicro servers. I went ahead a 1U server from them suitable for running a virtual environment. The rough specification was Dual Quad Core CPU, 48Gb RAM and 4 SAS drives.
The plan was to have the server delivered to me where I would do the initial configuration and then have the server couriered to the co-location provider for installation into the rack, all they needed to do was connect the power and network connections and it would be up and running.
So, the server arrived:
In actual fact, it was just well packed, which I appreciated from the supplier, and I could re-use the packaging when I needed to courier it back out.
Yet another box, within a box.
Eventually within all the packaging, there it is:
The first thing to do on taking delivery of a server is to take off the hood and have a look under the bonnet. Supposedly this is to check to any components that may have come loose in shipping, see if any capacitors are bulging, but for me it was just to awe at the technology I’ve bought so that I could justify it for myself. After all, I will probably rarely see this server once it is co-located.
To the top, the processor and memory banks, covered by a perspex shroud to ensure air flows through them from the fan array on the right. On the bottom left is the SAS RAID controller with battery backup (not visible) connecting to 4 SAS hard drives off to the right of the picture. You can also see a bank of 6 SATA interfaces connecting the DVD/CDROM drive.
Overall technical Specifications:
2 x Intel Xeon E5620 2.4Ghz Quad Core Processors.
6 x 8Gb DD3-1333 ECC Registered DIMMs (space to upgrade to a total of 12).
1 x LSI Logic 9260-4i SAS Raid Controller (512Mb Cache), with battery backup.
4 x 1Tb SAS2 Seagate Constellation ES drives (64Mb Cache).
Processors and Memory with the Shroud Removed:
Everything looking good it’s now time to apply some power and boot up and start off with some initial configuration.
As I live in Spain and am only in the UK currently for business purposes I have generally been working from a laptop. So in order to set up the system I had to purchase a keyboard. I eventually chose one of the mini-keyboards that you can get from Maplin stores. They’re less that £20, and while I know that you can get a keyboard for about £6, I quite liked this one – I would never use it as an everyday keyboard, but to have something that easily fits into your laptop bag when you need to visit a datacenter could be very useful indeed (I think I don’t like looking like a dork carrying a full size keyboard around too!). It is perhaps too small, and takes a bit of getting used to finding certain keys, but it did the job.
In my next post I will go through the reasoning on why I decided not to go via the Vmware ESXi / Vmware vSphere Hypervisor route and eventually chose a headless Virtualbox setup.
Well, you may have noticed the old site went away, and I’ve put this wordpress site in instead.
Not good, you might think! What with all the wordpress vulnerabilities about. Well, it’s actually part of a much bigger project and rather than have a not-found or a 404 on the site I thought I would at least get something up and running here.
Here is not where here used to be. All the sites associated with me are now being transferred to a co-location provider in the UK.
If you’re looking for my CV then it is still here.
If you’re looking for my Phone Number it’s +44 7983 877 438.