Well another week another security issue. This time it is a weakness in SSLv3. This is an older protocol (replaced by TLS) but can still be used in some circumstances. The Mozilla Security Blog article contains details. A quick fix for Firefox users is to install SSL Version Control plugin to disable use of SSLv3. SSLv3 will be disabled by default in Firefox 34 when it is released towards the end of November.
In my previous post I outlined my thinking about moving from Fedora to OpenSuse. I installed OpenSuse 12.3 onto mylaptop and had a play about. The installer was clean and easy to use and everything was setup with the minimum of effort.
Two issues with Fedora prompting a move were the control over the firewall and the Arduino software not being up to date. I was disappointed to that the installation of the Arduino software didn't come with a desktop icon setup but the latest version was there to use. Now onto the firewall; things were not good.
OpenSuse has completely removed the iptables scripts for managing the firewall. It seems you will use their firewall daemon and associated setup program. So basically the future looks like I will be being forced into using a wrapper of some sort around the iptables rules for my firewall. What's more, after doing some reading it would appear that more applications will rely on this dynamic functionality in the future. So what do I do? I can, on Fedora at least, use my existing script in the short term but need to migrate it. Alternatively I can change distro, waiting a little longer for the inevitable push towards dynamic firewalls.
Where does this leave me now then? I'm thinking of staying with Fedora at the moment. Fedora 19 will be due out in around 3-4 months time. At this point I think a clean installation of my main machine will probably be in order. In the mean time I can work on migrating my current firewall script over to the Firewalld system. It will mean I have to manually install the latest Arduino software but that is at least a manageable task.
OpenSuse was removed from the laptop and Fedora 18 reinstalled. A clean installation does appear to have changed a few things. A series of upgrades over the years had left a few legacy options it seems. The Fedora installer was not as user friendly as the OpenSuse installer, especially when it came to creating the dual boot with Windows on a separate hard disk. That said it did install and I'm sure it will improve in the future.
I have been trying to get my Windows 7 (Pro) machine to connect to the CUPS printer on my Linux server. Whilst it used to work with Windows XP (Home) via IPP (Internet Printing Protocol) I was having no luck with Windows 7. One reason for the problem is my network security and firewalls. I lock down everything unless it is actually needed. This means that all the auto discovery services on the network can't talk to each other. Still knowing the IP address and ports of the relevant machine/service to connect to is normally enough to get things working. Not in this case however. For some reason either at the Windows or CUPS end the IP address was causing a problem. The problem being that the it wasn't being resolved to a machine name when trying to setup the IPP connection.
Machine "Server" with IP "192.168.7.7"
The solution to the problem in the end turned out to be quite simple. On Linux machines there is a file /etc/hosts in which you can specify a mapping between IP addresses and hostnames. It turns out that Windows has the same file, its just hidden away in C:\Windows\System32\drivers\etc\hosts. Copying in the hostname information gives Windows the information it needs which it cannot find out itself due to the network discovery restrictions.
This has solved my problem but it was useful to be able to connect another Linux machine to the printer first confirming my CUPS setup was initially working. I had also tried disabling the firewall on the server to ensure that it wasn't a bad configuration, when that didn't work it was obvious that the problem was not in my case CUPS related. It is also a good idea to backup any working config files for future reference/use.
The mailserver project which I have been working on for many months now is getting to the point where it will soon be taking over the role of hosting all my email. No problems have been discovered over the past month and my upgrade script to regenerate the security certificates worked perfectly. A recent update to Dovecot, the IMAP system, means that a little more testing is in order due to modifications made to the config files.
When I finally release my documentation for the process it will outline the working setup at that time. No point in releasing something out of date.
I have at long last done a little more work on the mailserver project. The latest thing to report is the addition of dspam to filter out spam. In addition to this clamAV is also integrated.
The next step will be to do some more testing and then plug in another application which should make training and using the spam filter a little easier.
The documentation surrounding the addition of dspam and antivirus to the setup I am working on has been very hard to come by and in some cases is conflicting. Having made significant progress recently I am hoping to eventually have my setup production ready by the end of the year*. *Might as well give myself plenty of time.
In the past few weeks I purchased some new Anti-virus and Firewall software from ESET to replace my expiring & bloated AVG install. The first machine to get the upgrade was my XP desktop machine; everything went well. I was impressed with the lighter feel to the software and the added fact that it didn't seem to be hogging the system resources quite as much. A weeks trial later I decided it was stable and usable enough to be used on my laptop; running Windows Vista. The install was painless and the software scanned my system and there were no obvious issues.
The problems arose when I came to reboot the machine following some windows updates and some minor web application updates. Continue reading "Windows Vista – Still Crap"
I have been developing my own iptables firewall scripts for my Linux machines. On the whole the process has been going quite well. Part of my research into the firewall rules involved buying a few reference books, one of which contained what claimed to be a very secure script. I copied the base rules over to use as a base to add my own rules to and things have progressed very well.
Today I was going through the code trying to open some ports for another service when I noticed an anomoly; one of the rules I had copied was badly wrong. I went back to the book to compare what was listed; I was expecting to have made a typo. I found the book listed the flawed code in its main script but earlier in book it was used in its intended context. Had I not gained a sufficient understanding of the iptables rules and how they fit together I would not have noticed this error. It is worrying to think it has been exposing my machines to uncessesary danger. A few quick ammendments and all my machines are once again secure. The added bonus of the correction was that it removed some of the extra packets being logged and dropped by the firewall.
I will be very careful of what I copy from reference books from now on. I will also be paying much more attention to my firewall scripts in general to ensure I keep the rules sensible and secure.
Over the easter weekend I have decided once again to setup my network just the way I like it. Up to this point everything is going well, the Samba shares on the linux machines are at last accessible through the firewall and the Linux machines can access the Windows shares. Now the problems start.
It's all well and good being able to share the files but I want to restrict access to just me. The linux machines allow this to be done very simply in the configuration of the shares in smb.conf. XP Home on the other hand has none of this, it has "Simple File Sharing". This Simple File Sharing (SFS) is as it sounds, simple. It is to allow the users in the home to share a few files amongst machines and it achieves this. The major drawback is that it doesn't allow for any restriction of the share, its either available or it isn't.
Given the fact that the people attempting to use SFS probably have a weak or unsecured network this is a big mistake. XP Pro also has SFS but this can be disabled for "Advanced" sharing controls. Microsoft have basically released a crippled product whilst at the same time making it insecure. A novice user can in a few clicks share the C: drive and even make it writeable. If this novice user put the machine, a laptop perhaps, on a public network they could allow anybody access to copy/modify their system. There is a point at which things become too simple for their own good.
I am now posed with a problem I have spent alot of time and effort configuring my Linux machines to be very tightly secured with custom firewalls on each, do I really want XP Home to be the weak point? It's time for a rethink of my approach to the problem, ridding myself of XP Home or any version of Windows for that matter may ultimately be the best solution.