• 0 Posts
  • 7 Comments
Joined 1 year ago
cake
Cake day: July 1st, 2023

help-circle
  • Do a search for you server OS + STIG

    Then, for each service you’re hosting on that server, do a search for:

    Service/Program name + STIG/Benchmark

    There’s tons of work already done by the vendors in conjunction with the DoD (and CIS) to create lists of potential vulnerable settings that can be corrected before deploying the server.

    Along with this, you can usually find scripts and/or Ansible playbooks that will do most of the hardening for you. Though it’s a good Idea to understand what you do and do not need done.


  • Another reason for going with a swap file vs partition (if you need either) are nvme and SSD drives.

    A partition that’s only a few GB and written to constantly will wear out a solid state drive quickly.

    Using a swap file in a larger partition that has other data allows the drive to even out the wear across more storage cells.


  • True on the digit by digit code decryption. That I can forgive in the name of building tension and “counting down” in a visible way for the movie viewer. “When will it have the launch code?!” “In either 7 nano seconds or 12 years…”

    If they had been more accurate, it would have looked like the Bender xmas execution scene from Futurama:

    https://www.youtube.com/v/aRdRZ6TKo4s?t=25s

    I did like the fact that they showed war-dialing and doing research to find a way into the system. It’s also interesting that they showed some secure practices, like the fact there was no banner identifying the system or OS, giving less info to a would be hacker. Granted, now a days it would have the official DoD banner identifying it as a DoD system.

    I remember with Windows 95, LAN Manager passwords were hashed in two 7 digit sections which made extracting user password from the password hash file trivial:

    https://techgenix.com/how-cracked-windows-password-part1/

    Looks like it was worse than I remember. The passwords were first converted to all upper case first!




  • To add to that, back in the day you had to find out what engine a particular game used as there were huge compatibility issues with certain engines and others ran a fair amount slower via Wine. Some engines, however, ran incredibly well under Wine.

    That said, there were some cool things you could do in Wine like define a pseudo monitor to run your game on. Example, back in 2010 (before widescreen monitors were more common) I had a triple head setup on Linux. I could specify in Wine an arbitrary monitor size (like say 2560x1024) and run games “full-screen” centered on my setup while having other windows open on the edges of my real desktop.

    Even games that officially didn’t support multiple monitors and on Windows (would force themselves to one screen and black out the other ones) ran well via Wine with this setup.

    It was a bit involved to get working the first time though!

    Played through the HL2 games, Supreme Commander, Rift: Planes of Telara, and even Wow that way (though WoW had other issues with non 4:3 displays).


  • Before Proton there were many projects that were helping run windows games and apps on Linux. Many of these were massive undertakings:

    Wine (translate windows API calls to Linux API calls)

    Wine tricks (automates the installation of many Window app dependencies)

    Crossover and their work on wine & wine bottles (a mini windows drive environment for each program)

    Loki’s early work on SDL to simplify sound and input for Linux and other *nix targets.

    Mono (open source implementation of . Net a library used by a fair amount of windows apps (also includes Moonlight - the open source implementation of MS Silver light)

    DXVK a impressive and efficient Direct X 10 & 11 to Vulcan translation layer (later incorporated D9VK - Direct X 9 to Vulcan) which also helps older games run better in Windows in addition to adding compatibility for Linux

    And many other pieces I’m forgetting now, make up Proton. Valve did an awesome thing in packaging all the community developed components, put some of those devs on their payroll, and even paid Crossover to work on the project that ultimately became Proton.

    Now with Proton, what would require lots of individual steps and separate downloads (setup a separate wine environment for each application, add dependencies, install DXVK, install needed open source frameworks, add any registry tweaks needed, etc) is now mafically automatically handled behind the scenes in one step by one tool by just installing a Windows game on Linux via Steam (though Proton can work without Steam as well).

    Since all the work is open sourced, the community is able to have their own version of Proton with newer fixes and components that Valve could not distribute themselves due to licensing: Glorious Eggroll.

    There were many attempts in the past to make an all-in-one tool to handle setting up wine and other compatibility tools (Lutris, Transgaming, PlayOnLinux, etc). So Valve wasn’t necessarily the first, they just offered a well put together, funded, and easy to use implementation.