## mailman anti-spam filters

There has been a recent spate of spammers forging list member or list admin emails, and thus are able to post directly to the corresponding targeted list (as typically list members are always allowed to post to the list they are members of).

All external email passing through the University’s mail servers are given a spam rating, and headers added to the email with its spam score. eg.

X-Spam-Score: 5 X-Spam-Level: ***** X-Spam-Status: hits=5.502 tests=HEADER_FROM_DIFFERENT_DOMAINS, HTML_FONT_LOW_CONTRAST,HTML_MESSAGE,LOCAL_ACCTPHISH1l3,RP_MATCHES_RCVD,SYSADMIN version=3.4.0

A score of 4 or above is likely to be spam. The higher the number, the more likely it is to be spam. Though as the classification is an automated process, there can be false positives.

We can use mailman’s spam filter to match on any header, but in the above example the X-Spam-Score is the simplest to use.

We’ve recently added the following filters to all mailman lists that are not already filtering the mail based on the spam score.

Example of mailman spam filter page, highlighting the options you may want to change.

What the two rules do is to hold for moderation any messages (regardless of who sent them) if the spam score for the message is 4 or greater (9 being the highest score). Note that the matching is actually a regular expression.

The reason they are split into two rules, is to show that you could choose to automatically discard posts with higher scores. So for example the current “[89]” rule could be changed to “Discard” (remember to press the “Submit Your Changes” button at the bottom of the page). From then on, any posts sent to the list with a spam score of 8 or 9 will silently disappear. Note there is no notification this has happened, and you cannot recover any information about what has been automatically deleted. So you should only do this if you are happy with those facts.

One last point, the “Defer” option on the filter page, actually means “disable this rule”, not “defer any matching post”.

If you want help changing any of these settings, submit a support ticket in the usual manner.

Neil

## New SSH server

On Monday 3rd April we will replace the SSH server named schiff which hosts ssh.inf.ed.ac.uk and student.ssh.inf.ed.ac.uk with a machine named bruegel.

All that will happen is that at about 08:00 on Monday we will change the DNS aliases to point to the new machine. This change can take some time to propagate so we will not switch off access to schiff immediately. It will be left running as normal until 12:00 Friday 7th April. This should also allow sufficient time for users logged in to finish their existing sessions and move to the new server.

The IP address for the service will change from 129.215.202.57 to 129.215.202.74, your SSH client may warn you about this change and request verification. For reference the new host key fingerprints are:

RSA     - e9:ca:09:89:a9:42:96:c2:08:4c:8a:1f:1b:34:ee:0c
ECDSA   - d7:5b:79:84:49:94:fb:e5:9a:c7:a3:29:83:65:e4:f8
ED25519 - f4:0e:ba:42:a5:e4:10:99:ba:67:05:e7:44:5f:9f:c2


## Video Conferencing – Moving Forward

We recently polled staff and research students in the School on some approaches and suggested technologies for moving forward with better and more integrated support for Video Conferencing in the School: https://wiki.inf.ed.ac.uk/DICE/VideoConferencing. That page has now been updated with a summary of all the comments received.

The proposal now is that meeting room 5.02 in the Forum will be kitted out with generic hardware (dual monitors, camera, audio system with remote microphone pod and a computer) and made available for anyone to use. We will make at least Zoom available, and one or maybe two other systems, in this room and on School desktops. Everyone can then try these out for a while, alongside the existing Lifesize facility in 4.02.

## Informatics to host a sponsored RIPE atlas anchor

Informatics has been selected to host one of the first five sponsored RIPE atlas anchors!  The other four sites are in Macedonia, France, Romania and Albania.

The RIPE atlas system consists of several thousand network “probes” dotted around the world.  These perform a variety of standard and user-instigated measurements of hosts and services on the Internet, for research and post hoc investigations.  Informatics has hosted one of these probes for a couple of years now.  Anchors are essentially larger and more capable probes, located at sites with good stable connectivity, which can be used as the target for other probes’ queries.

As a result of hosting these systems we earn “credits” which can be use to “pay for” our own measurements.  We have spare credits, and should have many more as a result of hosting the anchor probe.  If you think it would be useful for your own work to make use of the atlas system’s capabilities, please get in touch and we’ll see what we can set up.

And, of course, it’s also good publicity for Informatics across the network operations community, and it’s a way for us to do our bit in a small way towards the smooth running of the Internet at large.

## NAS Appliances in the School of Informatics

Over the last couple of years, we have noticed that more and more of you are buying NAS appliances, boxes containing a number of commodity disks which can be attached to the network and serve that disk space to other machines on the network. This was a cause of concern to the computing staff because these appliances can raise issues of security and reliability and so in an effort to see if these boxes were meeting a need which might be equally well met by a commodity computing provision, I talked to those of you who had purchased this kind of kit in the last couple of years (and a big thanks to all those who took the time to respond to my request for information).

As expected, the biggest attraction of these devices was that they (with one or two caveats) offered substantially cheaper storage than anything offered by the School or the central University. Also attractive was the fact that people had more control over their storage, allowing them to reconfigure it as necessary, and that units could be bought with more disk slots than were required at first allowing for low cost expansion as needs dictated. These are features which would be difficult for the School to match at the moment and so it does seem that the purchase of this kind of equipment may be justified in some cases.

As mentioned above however, there are some real security and reliability concerns over these devices and so to help people decide whether a NAS appliance may be a good fit for their needs, we have created a page detailing some points to consider when contemplating purchasing one of these devices. We would encourage anyone thinking about using a NAS box to read this page and, if they require further advice, contact the computing staff in the usual way.

## User Account Creation and Expiration

Informatics is one of the few schools that maintains its own separately authenticated local user accounts (DICE) rather than using EASE/AD centrally managed accounts. Our accounts are automatically created and expired based on data we receive from the centre. However this is a much more complex process than at first might seem.

We need to pull data from a number of central sources to determine whether a local Informatics account should be generated for a user:

• EUCLID (Edinburgh University Complete Lifecycle Integrated Development) is used to provide data on which students are on our programmes, or on other School’s programmes but taking some of our courses, and we use this to create the set of “current” students that need an account. When the programme registration ends for whatever reason (hopefully the result of an award) or the course ends (effective at the end of a session) or status indicates withdrawal then the local account will enter expiry. There are plenty of issues we see with this data such as changes of programme/status, or a dependence on when the centre update key data that can all cause a lag in local account creation. We also use data from EUCLID to be informed of our “upcoming” students (principally PG students) so that the local account can be created in advance of the actual programme start date.
• OracleHR/IDM (Identity Management System) is used to provide data on which staff are associated with our School and are entitled to a local account. There are many subtle issues with this particular data set (primarily due to the fact that OracleHR at least was never intended to be a feed of live data) that means we often see a lag in account creation for staff, which we would prefer not to have. Also we see issues with new staff that have transferred from elsewhere in the University. Staff that are not “contractually” associated with our School but nevertheless for whatever reason need a local account are also problematic.
• VRS (Visitor Registration System) is used to provide data on visitors who need a local account (not all do). There are issues with this data set due to upstream bugs that have not been fixed and also with handling aspects of the UUN reconciliation process.

As a meta issue we also have to track many accounts that traverse (and change associated UUN as they do) from one data set to another. For example, a student on one of our programmes that after finishing becomes employed as a member of staff and then leaves but is kept on as a visitor. Different account types often overlap as well, temporarily while traversing or for a longer period of time (for example a member of staff who is also registered to do a PhD).

So while we deal automatically with the creation and expiration of many local accounts every day, the vast majority of the few thousand or so we have causing us no trouble, we still often have to deal with anomalies in specific edge cases. Unfortunately individual anomalies can cause a delay in account creation or can result in erroneous account expiration. Each instance must be manually investigated and progressed.

If you do have an issue with your own account or an account you have requested for someone else please contact frontline support who will be able to investigate.

If you sometimes struggle to remember passwords, a password manager can help. It’s a utility which can store your usernames and passwords in a strongly encrypted personal file, and which can generate random passwords for you.

DICE has keepassx2. It can save passwords to a local file, which it encrypts securely. If you need to access your passwords on another system, copy the file to that machine and download a copy of KeePassX to open it with. It’s available for Mac, Linux and Windows.

To get started, read How to: Use KeePassX, one of the Surveillance Self Defense series published by the Electronic Frontier Foundation.

Users of the older keepassx command will find that their older-format password file can be imported into keepassx2.

If you’re a Windows user you might prefer the similar .NET based project KeePass, which KeePassX was based on – although in fact nowadays both projects are available for a variety of platforms. Current versions of KeePass and KeePassX use the same file format, so you should be able to open your password file with either or both of them.

If you’d also like to use your KeePassX or KeePass file on a phone, take a look at the list of unofficial ports of KeePass on the KeePass download page.

## Beware of Domain-squatters

Please take care when you type internet domain names, whether into an address box or at the command line!

Domain-squatters are people who register internet domain names which are very similar to other “real” names.  They do this in the hope of attracting mis-directed traffic, generally either for advertising purposes or so that they can steal credentials for later use.  For example, c.uk is registered to “a non-UK Corporation”, and if you mis-type www.inf.ed.ac.uk as www.inf.eda.c.uk you will be taken to a completely different site altogether.  Roughly half of the possible single-letter .uk domains are registered, as are many two-letter permutations and truncations.

Within Informatics we attempt to block these, by having our own nameservers redirect to the bit-bucket. Many large corporations also register common typos of their own names: for example gooogle.com will redirect to google.com.

Elsewhere though, it’s down to care and vigilance. Don’t just click through unexpected responses. Take a second look to see what’s really going on. And if in doubt, ask.

You can find some guidance on data security on our computing.help pages.

## Changes to local mail service

There have been a couple of changes to the local mail services recently. None of which Informatics users should have noticed, but for the record.

## mail.inf.ed.ac.uk now only relays from Informatics machines

Due to a misconfiguration, mail.inf.ed.ac.uk had been allowing any machine within the University’s network to relay mail through it. This came to light when a compromised machine elsewhere in the University was sending spam out via us. This is now been tightened up, and only machines on the Informatics network can freely relay mail via mail.inf.ed.ac.uk.

## smtp.inf.ed.ac.uk is now running fail2ban

The smtp.inf.ed.ac.uk service has been upgraded to SL7, and at the same time is now running fail2ban. This means that repeated, successive authorisation failures from an IP address, will result in that IP address being denied access for a period of time. This is to stop the bad guys from trying to brute force your password. This is similar to the steps taken on the external ssh access machines.

Neil

On Thursday 26th January we plan to upgrade the NX remote desktop service.

All that will happen is that at about 09:00 we will change the DNS aliases (nx.inf and staff.nx.inf) to point to the new machines. This change can take some time to propagate so we will not immediately remove access to the old servers, they will be left running as normal until 12:00 Friday 3rd February. This should allow sufficient time for users logged in to finish their existing sessions and move to the new server.

The general access service (nx.inf.ed.ac.uk) will move from piccadilly to hammersmith, the new IP address will be 129.215.202.146.

The staff service (staff.nx.inf.ed.ac.uk) will move from northern to jubilee, the new IP address will be 129.215.33.6.

The SSH key fingerprints will change which will cause the NX client to request verification. See the NX help pages for the new key fingerprints and further information regarding the NX service.