Japanese chart figures are now in for 8th – 14th April, revealing that Nintendo Labo VR has managed to enter the charts in second place in its opening week.

The game managed to sell more units that this week’s other big Switch release, Final Fantasy X/X-2 HD Remaster, with Famitsu’s estimates reporting a total of 26,634 sales. This debut puts it ahead of Nintendo Labo: Vehicle Kit‘s opening week sales, but still significantly behind the sales experienced by the first two Labo kits.

It was Earth Defense Force: Iron Rain which managed to take the top spot, though, with an estimated 55,573 sales. Labo VR released a day later than both Earth Defense Force and Final Fantasy, potentially causing the VR kit’s sales to look a little weaker than they might have done.

Here are the top 10 (first numbers are this week’s sales, followed by total sales):

1) [PS4] Earth Defense Force: Iron Rain (D3Publisher) {2019.04.11} – 55.573 / NEW
2) [NSW] Nintendo Labo Toy-Con 04: VR Kit (Nintendo) {2019.04.12} – 26.634 / NEW
3) [NSW] Final Fantasy X/X-2 HD Remaster (Square Enix) {2019.04.11} – 16.839 / NEW
4) [NSW] Super Dragon Ball Heroes: World Mission (Bandai Namco Games) {2019.04.04} – 14.132 / 85.122
5) [NSW] Yoshi’s Crafted World (Nintendo) {2019.03.29} – 13.197 / 91.672
6) [NSW] Super Smash Bros. Ultimate (Nintendo) {2018.12.07} – 11.346 / 3.018.497
7) [PS4] Sekiro: Shadows Die Twice (From Software) {2019.03.22} – 11.034 / 223.995
8) [NSW] Minecraft (Microsoft Game Studios) {2018.06.21} – 9.123 / 728.968
9) [NSW] New Super Mario Bros. U Deluxe (Nintendo) {2019.01.11} – 8.447 / 568.545
10) [NSW] Mario Kart 8 Deluxe (Nintendo) {2017.04.28} – 7.834 / 2.254.250

As for hardware, Switch is still sitting at the top of the chart, selling an estimated 54,101 units this week. Here are this week’s figures, followed by last week’s in brackets:

1) Switch – 54,101 (46,850)
2) PlayStation 4 – 6,662 (8,347)
3) PlayStation 4 Pro – 5,131 (5,507)
4) New 2DS LL – 2,676 (3,469)
5) New 3DS – 664 (919)
6) PlayStation Vita – 575 (482)
7) Xbox One X – 47 (60)
8) Xbox One S – 19 (33)

< Last week’s charts

Any surprises this week? Did you expect Labo VR to reach number two? Let us know in the comments.

Note: This trailer contains a small amount of bad language.

A brand new trailer for the upcoming Saints Row: The Third – The Full Package has just been released, coming alongside the announcement of the game’s Deluxe Pack which is available to pre-order from GAME starting today.

The game is set to launch on 10th May (so in just under a month’s time) but if you really can’t wait, here’s a look at what you’ll get by picking up the Deluxe Pack:

The Deluxe Pack contains an array of Saints Row inspired goodies including:

– A set of Saints Row Analog Stick Thumb Grips, for extra control
– A2 Double-sided Poster, featuring iconic Saints Row: The Third artwork
– Purple Microfibre Screen Cloth, adorned with the Saints Row: The Third insignia
– 2 Console Sticker Sheets, showcasing iconography from the world of Saints Row
– 3 Double-sided Lithographs, featuring artwork of six of the series’ most beloved characters
– Double-sided Alternative Artwork Inlay, that owners can use to personalise their boxed copy
– Deluxe Game Case Sleeve, featuring the original 2011 artwork for extra nostalgia

The standard release, called ‘The Full Package’, will be available from the Nintendo Switch eShop on its release day of 10th May. It’s priced at £34.99 / $39.99 and comes with the following game features (also present in the deluxe release, of course):

· City of Sin – Disrupt and dismantle the Syndicate stranglehold on weapons, cybercrime, and criminal rackets. Discover the secrets of Steelport, where there is action on every street corner, for better or, more likely, worse.
· Weapons of Crass Destruction – It’s one thing to defeat your enemies. It’s another to humiliate them. Hover jets, human cannonball cars and melee weapon warfare are all part of the fun.
· Joy-Con Crazy Customisation – Create the most outlandish characters ever seen, from washed-up celebrities to maskless ninja pirates. Inside every sinner, there is a Saint. Who will you become?
· Portable Over The Top Co-op – Fly solo, or play online with a homie and for the first time – two players can play side to side via online or local multiplayer. Give freefall skydiving a try, landing in your partner’s flaming pickup as you make a desperate run toward a heavily armed Syndicate base. Steelport is always more fun with a friend.
· The Full Package – Includes all three mission packs and more than 30 DLC items. All previously released content is included on the game card.*

* Two DLC packs – the Bloodsucker Pack and the Unlockable Pack, have been omitted for game balance and improvement based on feedback.

Are you excited to take Saints Row on the go? Let us know with a comment below, yo.

Mdadm stands for Multiple Disk and Device Administration. It is a command line tool that can be used to manage software RAID arrays on your Linux PC. This article outlines the basics you need to get started with it.

The following five commands allow you to make use of mdadm’s most basic features:

1. Create a RAID array:
   
   
   # mdadm –create /dev/md/test –homehost=any –metadata=1.0 –level=1 –raid-devices=2 /dev/sda1 /dev/sdb1
2. Assemble (and start) a RAID array:
   
   
   # mdadm –assemble /dev/md/test /dev/sda1 /dev/sdb1
3. Stop a RAID array:
   
   
   # mdadm –stop /dev/md/test
4. Delete a RAID array:
   
   
   # mdadm –zero-superblock /dev/sda1 /dev/sdb1
5. Check the status of all assembled RAID arrays:
   
   
   # cat /proc/mdstat

Notes on features

mdadm --create

The create command shown above includes the following four parameters in addition to the create parameter itself and the device names:

1. –homehost:
   By default, mdadm stores your computer’s name as an attribute of the RAID array. If your computer name does not match the stored name, the array will not automatically assemble. This feature is useful in server clusters that share hard drives because file system corruption usually occurs if multiple servers attempt to access the same drive at the same time. The name any is reserved and disables the homehost restriction.
2. –metadata:
   mdadm reserves a small portion of each RAID device to store information about the RAID array itself. The metadata parameter specifies the format and location of the information. The value 1.0 indicates to use version-1 formatting and store the metadata at the end of the device.
3. –level:
   The level parameter specifies how the data should be distributed among the underlying devices. Level 1 indicates each device should contain a complete copy of all the data. This level is also known as disk mirroring.
4. –raid-devices:
   The raid-devices parameter specifies the number of devices that will be used to create the RAID array.

By using level=1 (mirroring) in combination with metadata=1.0 (store the metadata at the end of the device), you create a RAID1 array whose underlying devices appear normal if accessed without the aid of the mdadm driver. This is useful in the case of disaster recovery, because you can access the device even if the new system doesn’t support mdadm arrays. It’s also useful in case a program needs read-only access to the underlying device before mdadm is available. For example, the UEFI firmware in a computer may need to read the bootloader from the ESP before mdadm is started.

mdadm --assemble

The assemble command above fails if a member device is missing or corrupt. To force the RAID array to assemble and start when one of its members is missing, use the following command:

# mdadm --assemble --run /dev/md/test /dev/sda1

Other important notes

Avoid writing directly to any devices that underlay a mdadm RAID1 array. That causes the devices to become out-of-sync and mdadm won’t know that they are out-of-sync. If you access a RAID1 array with a device that’s been modified out-of-band, you can cause file system corruption. If you modify a RAID1 device out-of-band and need to force the array to re-synchronize, delete the mdadm metadata from the device to be overwritten and then re-add it to the array as demonstrated below:

# mdadm --zero-superblock /dev/sdb1
# mdadm --assemble --run /dev/md/test /dev/sda1 
# mdadm /dev/md/test --add /dev/sdb1

These commands completely overwrite the contents of sdb1 with the contents of sda1.

To specify any RAID arrays to automatically activate when your computer starts, create an /etc/mdadm.conf configuration file.

For the most up-to-date and detailed information, check the man pages:

$ man mdadm 
$ man mdadm.conf

The next article of this series will show a step-by-step guide on how to convert an existing single-disk Linux installation to a mirrored-disk installation, that will continue running even if one of its hard drives suddenly stops working!

So you may not be aware, but Asmodee Digital launched a newsletter last year. I can’t exactly remember when but it was early 2018 I believe. By and large, it’s not the most useful newsletter in the world – it’s infrequent, a lot of the stuff it talks about we already know or is repeated, and generally it’s a bit vague even at the best of times. We do appreciate getting it though.

Case and point, the most recent newsletter lists these games are being ‘In Development’:

I mean this is fine – the Gloomhaven icon has a link to the official page, but the others don’t have anything. Some of this we knew, some of this we didn’t, but without any information regarding platforms, price, time-table etc… it’s just a bunch of icons at this point. Again we appreciate it, but we can’t always do anything with what it contains.

Then, every so often, there will be some utter bombshells, dropped in ever so casually:

So yeah, Zombicide. April 24^th. Mark your calendars I guess… we knew this was coming, but there hasn’t really been a peep out of the studio on this since it was announced so to suddenly learn it’s release next week is a bit of a surprise. The “finally” comment throws me me a bit – I mean, it’s not even out on Steam, so it’s not like we’ve been waiting around watching our PC-based brethren play this while we clutch our mobile phones in frustration. Unlike with their legions of other PC-only digital board games.

All that aside, another milestone in board games is only a week away. It’s good that we’re seeing both iOS AND Android ports at the same time. We’ll try and have a review ready for when it drops.

The Game Creators are working on a successor to their game framework AppGameKit, previously reviewed here.  The new product AppGameKit Studio builds on the existing framework while building a complete all in one IDE for game development.  This adds a scene editor, integrated code editor, debugging, online help and more together into a single application.  Key features from the website are:

Drag & drop assets to visualise your scenes
Code with AppGameKit Script
Easily browse app media assets
Run live debugging sessions
Access online help

AppGameKit Studio is currently in beta, but is available for purchase for a discounted price.  You can learn more about AppGameKit Studio here.  See Studio in action in the video below.

GameDev News

In the previous articles, we introduced idempotency as a way to approach your server’s security posture and looked at some specific Ansible examples, including the kernel, system accounts, and IPtables. In this final article of the series, we’ll look at a few more server-hardening examples and talk a little more about how the idempotency playbook might be used.

Time

Due to its reduced functionality, and therefore attack surface, the preference amongst a number of OSs has been to introduce “chronyd” over “ntpd”. If you’re new to “chrony” then fret not. It’s still using the NTP (Network Time Protocol) that we all know and love but in a more secure fashion.

The first thing I do with Ansible within the “chrony.conf” file is alter the “bind address” and if my memory serves there’s also a “command port” option. These config options allow Chrony to only listen on the localhost. In other words you are still syncing as usual with other upstream time servers (just as NTP does) but no remote servers can query your time services; only your local machine has access.

There’s more information on the “bindcmdaddress 127.0.0.1” and “cmdport 0” on this Chrony page (https://chrony.tuxfamily.org/faq.html) under “2.5. How can I make chronyd more secure?” which you should read for clarity. This premise behind the comment on that page is a good idea: “you can disable the internet command sockets completely by adding cmdport 0 to the configuration file”.

Additionally I would also focus on securing the file permissions for Chrony and insist that the service starts as expected just like the syslog config above. Otherwise make sure that your time sources are sane, have a degree of redundancy with multiple sources set up and then copy the whole config file over using Ansible.

Logging

You can clearly affect the level of detail included in the logs from a number pieces of software on a server. Thinking back to what we’ve looked at in relation to syslog already you can also tweak that application’s config using Ansible to your needs and then use the example Ansible above in addition.

PAM

Apparently PAM (Pluggable Authentication Modules) has been a part of Linux since 1997. It is undeniably useful (a common use is that you can force SSH to use it for password logins, as per the SSH YAML file above). It is extensible, sophisticated and can perform useful functions such as preventing brute force attacks on password logins using a clever rate limiting system. The syntax varies a little between OSes but if you have the time then getting PAM working well (even if you’re only using SSH keys and not passwords for your logins) is a worthwhile effort. Attackers like their own users on a system with lots of usernames, something innocuous such as “webadmin” or similar might be easy to miss on a server, and PAM can help you out in this respect.

Auditd

We’ve looked at logging a little already but what about capturing every “system call” that a kernel makes. The Linux kernel is a super-busy component of any system and logging almost every single thing that a system does is an excellent way of providing post-event forensics. This article will hopefully shed some light on where to begin: http://www.admin-magazine.com/Archive/2018/43/Auditing-Docker-Containers-in-a-DevOps-Environment. Note the comments in that article about performance, there’s little point in paying extra for compute and disk IO resource because you’ve misconfigured your logging so spend some time getting it correct would be my advice.

For concerns over disk space I will usually change a few lines in the file “/etc/audit/auditd.conf” in order to prevent there firstly being too many log files created and secondly logs that grow very large without being rotated. This is also on the proviso that logs are being ingested upstream via another mechanism too. Clearly the files permissions and the service starting are also the basics you need to cover here too. Generally file permissions for auditd are tight as it’s a “root” oriented service so there’s less changes needed here generally.

Filesystems

With a little reading you can discover which filesystems that are made available to your OS by default. You should disable these (at the “modprode.d” file level) with Ansible to prevent weird and wonderful things being attached unwittingly to your servers. You are reducing the attack surface with this approach. The Ansible might look something like this below for example.

name: Make sure filesystems which are not needed are forced as off lineinfile: dest="/etcmodprobe.d/harden.conf" line='install squashfs /bin/true' state=present

SELinux

The old, but sometimes avoided due to complexity, security favourite, SELinux, should be set to “enforcing” mode. Or, at the every least, set to log sensibly using “permissive” mode. Permissive mode will at least fill your auditd logs up with any correct rule matches nicely. In terms of what Ansible looks like it’s simple and is along these lines:

name: Configure SElinux to be running in permissive mode replace: path=”/etc/selinux/config” regexp='SELINUX=disabled' replace='SELINUX=permissive'

Packages

Needless to say the compliance hardening playbook is also a good place to upgrade all the packages (with some selective exclusions) on the system. Pay attention to the section relating to reboots and idempotency in a moment however. With other mechanisms in place you might not want to update packages here but instead as per the Automation Documents article mentioned in a moment.

Idempotency

Now we’ve run through some of the aspects you would want to look at when hardening on a server, let’s think a little more about how the playbook might be used.

When it comes to cloud platforms most of my professional work has been on AWS and therefore, more often than not, a fresh AMI is launched and then a playbook is run over the top of it. There’s a mountain of detail in one way of doing that in this article (http://www.admin-magazine.com/Archive/2018/45/AWS-Automation-Documents) which you may be pleased to discover accommodates a mechanism to spawn a script or playbook.

It is important to note, when it comes to idempotency, that it may take a little more effort initially to get your head around the logic involved in being able to re-run Ansible repeatedly without disturbing the required status quo of your server estate.

One thing to be absolutely certain of however (barring rare edge cases) is that after you apply your hardening for the very first time, on a new AMI or server build, you will require a reboot. This is an important element due to a number of system facets not being altered correctly without a reboot. These include applying kernel changes so alterations become live, writing auditd rules as immutable config and also starting or stopping services to improve the security posture.

Note though that you’re probably not going to want to execute all plays in a playbook every twenty or thirty minutes, such as updating all packages and stopping and restarting key customer-facing services. As a result you should factor the logic into your Ansible so that some tasks only run once initially and then maybe write a “completed” placeholder file to the filesystem afterwards for referencing. There’s a million different ways of achieving a status checker.

The nice thing about Ansible is that the logic for rerunning playbooks is implicit and unlike shell scripts which for this type of task can be arduous to code the logic into. Sometimes, such as updating the GRUB bootloader for example, trying to guess the many permutations of a system change can be painful.

Bedtime Reading

I still think that you can’t beat trial and error when it comes to computing. Experience is valued for good reason.

Be warned that you’ll find contradictory advice sometimes from the vast array of online resources in this area. Advice differs probably because of the different use cases. The only way to harden the varying flavours of OS to my mind is via a bespoke approach. This is thanks to the environments that servers are used within and the requirements of the security framework or standard that an organisation needs to meet.

For OS hardening details you can check with resources such as the NSA (https://www.nsa.gov), the Cloud Security Alliance (https://cloudsecurityalliance.org/working-groups/security-guidance/#_overview), proprietary training organisations such as GIAC (https://www.giac.org) who offer resources (https://www.giac.org/paper/gcux/97/red-hat-linux-71-installation-hardening-checklist/102167), the diverse CIS Benchmarks (https://www.cisecurity.org) for industry consensus-based benchmarking, the SANS Institute (https://uk.sans.org/score/checklists), NIST’s Computer Security Research (https://csrc.nist.gov) and of course print media too.

Conclusion

Hopefully, you can see how powerful an idempotent server infrastructure is and are tempted to try it for yourself.

The ever-present threat of APT (Advanced Persistent Threat) attacks on infrastructure, where a successful attacker will sit silently monitoring events and then when it’s opportune infiltrate deeper into an estate, makes this type of configuration highly valuable.

The amount of detail that goes into the tests and configuration changes is key to the value that such an approach will bring to an organisation. Like the tests in a CI/CD pipeline they’re only as ever as good as their coverage.

Chris Binnie’s latest book, Linux Server Security: Hack and Defend, shows you how to make your servers invisible and perform a variety of attacks. You can find out more about DevSecOps, containers and Linux security on his website: https://www.devsecops.cc

It’s a new era at Nintendo of America. Reggie has left the building and the appropriately-named Doug Bowser is now officially at the helm as the president. To celebrate his first day in this role, @thetruebowser shared a photo of his new office on Twitter.

We’re not entirely sure what’s going on, though, as it appears someone else has already taken charge:

In all seriousness, Doug Bowser has been shadowing Reggie since 2015, so we’re sure he’ll do a fantastic job. If you would like to find out more about the new president, be sure to check out our extensive feature about him.

And while you’re here, feel free to welcome Bowser to his new role in the comments below.