Browse Source

Imperfect initial commit, but too far to go back

DarkFeather 1 year ago
Signed by: DarkFeather GPG Key ID: 1CC1E3F4ED06F296
84 changed files with 2812 additions and 0 deletions
  1. +50
  2. +42
  3. +80
  4. +25
  5. +45
  6. +26
  7. +26
  8. +88
  9. +50
  10. +52
  11. +24
  12. +82
  13. +26
  14. +10
  15. +1
  16. +42
  17. +51
  18. +10
  19. +48
  20. +49
  21. +31
  22. +68
  23. +19
  24. +86
  25. +66
  26. +10
  27. +75
  28. +34
  29. +154
  30. +21
  31. +36
  32. +22
  33. +21
  34. +67
  35. +6
  36. +68
  37. +62
  38. +4
  39. +5
  40. +33
  41. +9
  42. +8
  43. +42
  44. +2
  45. +2
  46. +2
  47. +3
  48. +2
  49. +2
  50. +2
  51. +2
  52. +2
  53. +4
  54. +2
  55. +3
  56. +2
  57. +4
  58. +2
  59. +2
  60. +2
  61. +3
  62. +5
  63. +1
  64. +34
  65. +102
  66. +58
  67. +65
  68. +28
  69. +30
  70. +51
  71. +13
  72. +20
  73. +27
  74. +152
  75. +19
  76. +53
  77. +18
  78. +17
  79. +22
  80. +134
  81. +32
  82. +25
  83. +31
  84. +58

+ 50
- 0
Classes/ View File

@ -0,0 +1,50 @@
This group is dedicated to playing [ Artemis Spaceship Bridge Simulator], learning teamwork to overcome challenges and improve communication, within a fun, science-fiction atmosphere.
# About the Game
## Instructions to Install
* If you are an [[User:DarkFeather/Sandbox#Stations|LO]], purchase [ a bridge license] and download the 2.4.0 installer -- otherwise, get a copy of the installer from your captain.
* Install Artemis for all users on your system.
* Get a copy of the mod from [ the AniNIX].
* Copy the contents of the mod to "C:\Program Files (x86)\Artemis\dat". You should be prompted whether you want to replace files; confirm the replacement.
* Launch Artemis from "C:\Program Files (x86)\Artemis\Artemis.exe". You should see yellow LCARS-like buttons rather than the standard blue and advanced models.
## Stations
Every ship requires a commanding crew; while it is possible to command a ship alone, greater challenges can be beaten with a crew. Each crew should strive for a five-person command staff, though if a crew is short personnel some stations may be overloaded. The LO will be be one such position that's always overloaded.
* Helm: The helm officer (HO) controls the course and speed of the ship, managing maneuvering, impulse, and warp or jump drives. Helm also has access to shield and mainscreen control. All vessels require a HO.
* Weaponry: The weapons officer (WO) controls all weaponry onboard. They are in charge of loading or unloading torpedo tubes and phaser targeting. All vessels require a WO.
* Engineering: The engineering officer (EO) controls power distribution throughout the ship for all systems and the damage control teams.
* Science: The science officer (SO) is in charge of gathering information and managing the sensors. Science provides shield harmonics to the WO and a course to the HO.
* Captain: The captain is in charge of coordinating the other officers and monitoring communications.
* Licensing: These individuals have purchased a bridge license. To accomodate the developer's licensing requests, each crew should have at least one licensing officer (LO). This position should overloaded with another station.
* Commander Air Group: The CAG is in charge of the fighter stations on board vessels with a fighter complement. This station may be overloaded or a dedicated one on carrier-class vessels.
## Backstory
Multiple timelines have converged as a shared threat in the temporal cold war. The nexus is a stellar nursery. The Federation [ Starfleet] has led the charge to prevent damage to the timeline, and now both factions have setup up a dense network of stations in the stellar nursery, supported by civilians. The opposing factions have been raiding the border, and temporal operatives from Starfleet have contacted other factions for help. It is still unknown who is leading the opposing factions against Starfleet, though there is suspicion of an [ Iconian] influence.
Allied factions:
* [ Romulan Republic]
* [ Klingon Empire]
* [ Rangers]
* [ Independent Planets]
* [ Colonial Fleet]
Opposing factions:
* [ Orion Syndicate]
* [ Dominion]
* [ Borg Collective]
* [ Cardassian Union]
Native (and hostile) species to the nursery:
* [ The Dragon Race]
* [ The Biomechs]
# Roster
## LOs
* Mark Jambor
* Connor Ford
## Static Crews
## Enlisted Personnel

+ 42
- 0
Classes/ View File

@ -0,0 +1,42 @@
This is in support of team-building between [[TeamRed]] and [[TeamBlue]] staff, or any other group. ARGs like [ Seek] and puzzle rooms also offer good opportunities, but this paradigm works for a geodiverse staff. It's good to use these games as a kick-off to penetration testing, as a way to familiarize the teams with each other's communication styles before given their assignments.
The AniNIX domain has rules in its [[AniNIX::Shadowfeed]] to support running these simulations. Geodiverse teams may want to use TeamSpeak, Discord or Skype for voice relay.
# Team Purple Anectdote
Some organizations have noticed a tendency in red-team and blue-team crews to become combative with one another. Sites in this situation have found it useful to randomly shuffle the teams between assignments, so that personnel operate as a mixed "Team Purple", with red- and blue-team prefixes only applicable to the individual assignment.
# Basis
A number of recent scifi series have been focusing on small crews operating out of a mobile fully-complete base of operations, a starship. This makes for a very interesting model -- real-world penetration testing teams may use small Sprinter-style vans rigged with a complete [[Service_and_Host_Layout|AniNIX clone domain]] onboard, rigged into the roof. Living space can be rigged in the back with the crew riding forward.
Some example shows include:
* [ StarGate Atlantis]
* [ Dark Matter]
* [ Star Trek: Enterprise]
## Space-based naval engagements
Space operations are supplied by the [ Artemis Starship Bridge Simulator]. Crews operate a starship in scenarios and naval battle simulations with diverse roles.
## Ground special operations
Ground operations are supplied by the [ Unvanquished freeware]. This is a mixed base building and small-team game -- TeamBlue will operate with classic Human ranged weapons, while TeamRed aliens focus on melee attacks and unconventional warfare.
# Example layout
Here we have some basic layouts to provide structure for the operation -- creative teams can add their own story and intrigue. Space operations require more coordination than ground operations, but here are the default roles. Additional teammates can be added as generic infantry/fighterpilot roles.
* Commanding officer: Starship engineer and ground engineer
* Executive Officer: Starship weapons officer and ground heavy weapons specialist
* Intel Agent: Science/Comms officer and ground overwatch
* Specialist: Starship helmsman and ground recon infantryman
:<b>Note</b>: If any team is to be at a numerical disadvantage, it should be TeamRed. TeamBlue should have 1-2 more players in unbalanced scenarios. This lets them rush on the ground while protecting their base and to use fighter support in space combat to intercept nuclear weapons. Artemis is particularly vulnerable to weak weapons officer getting overwealmed and missing an incoming nuke, while Unvanquished also has trouble with phase balancing between the teams allowing well-timed rushes. This weighting thus matches real-world manpower discrepancies.
## TeamBlue onboard the TSS Nakhimov
Named for [ Admiral Pavel Nakhimov], Team Blue operates out of a warp-drive [ Terran juggernaut] with a [ human away team]. These crews should focus on maintaining close unit integrity and defensive base security, slowly marching the whole of their firepower into range with a well-researched strategy. Strong coordination and well-rehearsed close-quarters procedures keep the crew alive and out of TeamRed's easy reach.
## TeamRed onboard the XSS Qahirah
Named for the [ Abbasid conquerors'] capital now known as Cairo, Team Red operates out of a jump-drive [ Ximni battleship] with an [ alien away team]. These crews should focus on unconventional ambush tactics -- ground crews should use early dretch units to probe for weaknesses, focusing on picking off stragglers with predatory tactics later. In space, the scanning abilities of the ship should be used to identity gaps in the cover being used by TeamBlue to make calculated jumps.
## AI Support
Individual teams can manage team-building exercises for their role with Artemis scenarios and Unvanquished [ navmesh bots] to take the place of the other team.

+ 80
- 0
Classes/ View File

@ -0,0 +1,80 @@
I want to emphasize the importance of cybersecurity by showing how a few bad practices can disclose supposedly secure information. Moreover, I want to emphasize the tools that
# This Demo is Not...
* How to hack your friend’s FaceBook
* How to become an evil hacking mastermind
* How to control the Matrix
# Materials
* Control of Wifi network and wifi's DNS, if using physical hardware, or some method of controlling routing.
* Demo computer (VM or physical)
* For easy installation, install [[ShadowArch#How_to_Install_ShadowArch|ShadowArch]] with a graphical environment and a Holocron layout.
* Run the following. This Makefile is viewable in [ the ConfigPackages git repo]. <pre>make -C /usr/local/src/ConfigPackages/WhiteHatDemo democlient</pre>
* You will still need to sync /etc/hosts with the demo server.
* Users can access a virtualized demo client with VNC over [[SSH]].
* Demo server with lighttpd, telnet server, ftp server, OpenSSH server, Wireshark.
* For easy installation, install ShadowArch with the GUI option, and run the following: <pre>make -C /usr/local/src/ConfigPackages/WhiteHatDemo demoserver</pre>
* Lighttpd should be configured with both unsecured and secured traffic.
* Lighttpd will need one URL that is auth protected -- simple auth is sufficient.
* There should be a remote-capable user "testuser" with a preset initial password.
* You should also sync /etc/hosts with any demo clients.
* [ Kali Linux] iso -- if you're using physical hardware for the demo, use a [[Holocron]] flashdrive
* A demo user with a read-write VNC view of the democlient, a pentester with physical access to the server and client, and a class with read-only VNC sessions watching the client.
# Exercises
## Account Credentials
<!-- This should be updated to be a BurpSuite assault -->[[Category:TODO]]
* An obviously dumb password should be set in the server's /etc/lighttpd/.lighttpdpassword and disclosed to the demouser.
* The pentester "guesses" the password and discloses why it's weak.
* Talk about [ strong passwords].
### Mobile PIN Break
* Talk about how PINs are important
* Talk about guessing pins from smudges
* Financial data, email accounts, text messages, and such are all accessible.
* Talk about [ phisihing] via a captured phone with SMS
## Encrypted network traffic
The key takeaway is to encrypt all network traffic. While a [ VPN] and similar network encryption models help, these tools are very simple and controllable.
### Browsers
[ SSL] allows us to validate that we are talking to the site we expect to.
* Use wget to mirror a login page to the demo server. The Makefile defaults to
* Redirect the traffic to unsecured traffic
* Have the demo user connect to the site over unsecured HTTP.
* Have a user connect to the same site over HTTPS and see the warning message.
* Optionally, remove the diverted routing and have the user reconnect to the site over HTTPS without seeing the warning.
* Capture traffic on [ Wireshark] and ask the demo user to confirm their password in the capture.
* Talk about SSL chain of trust.
SSL encryption also prevents capturing session information.
* Have the demo user go to the demoserver's web server over unsecured HTTP.
* The root page will have a POST HTML form.
* Use Wireshark to capture the data and show the TCP stream.
* Have the demo user repeat the process over HTTPS.
* SSL will prevent following the stream.
### Telnet/FTP
* Have the demo user reset his password on the server with telnet.
* Capture traffic with Wireshark and show the password.
* Have the demo user pull down a file over FTP, change it, and put it back up.
* Capture traffic with Wireshark and show the change.
* Explain SFTP/SSH correlation to HTTPS -- encryption matters.
## Storage bypass w/ iso
[ Disk encryption] makes it harder to access data. While physical access is death, strong encryption can delay access beyond heat death of the universe, which is long enough.
* Have the demo user set the root password and add a file in /root.
* Power off the machine and have the pentester take control.
* Ask the class if the files are secure.
* Boot the machine with the iso instead and find the file.
* Optionally, set the root password and boot the original system.
* Talk about encrypted storage and how this recovery would be harder.
### File recovery
Just because a system has files deleted from it doesn't mean that the data is lost.
* dd 0's onto small partition on demo server
* Create ext4 filesystem
* Have the demouser create a file, display its contents, and delete it.
* The pentester "steals" the hardware and boots with a Kali iso
* Run "extundelete <disk> --restore-all -o /root" to recover the file
* Talk about secure deletion with shred or similar programs and the added difficulty of disk encryption.

+ 25
- 0
Entities/ View File

@ -0,0 +1,25 @@
A Bastion host is a gateway to accessing other hosts. It is a safeguard against admin error.
# Etymology
Bastion hosts are named because they are the first line of defense against administrative error -- they prevent admins from being locked out of correcting their changes.
# Capacity and Components
A Bastion host needs minimal CPU or memory.
# Hosted Services and Entities
Nothing is hosted by a Bastion.
# Connections
See [[:Category:Entity|the entity list]] -- any host should be able to connect to a Bastion with [[SSH]] and X11, and it should be able to dial to any service provider.
# Additional Reference
Bastion hosts should be deployed alongside any Hypervisor and set to start on boot. The encrypted credentials volume should be encrypted per [[ShadowArch]]'s recommendations, and it should not be added to /etc/fstab or /etc/crypttab.
To create a Bastion:
1. Create a new VM in the Hypervisor and mark it to start on boot. For an example Hypervisor, see [[Forge2]].
1. Install ShadowArch with the Spartacus layout and without encryption or GUI -- encryption complicates boot and GUI is unnecessary. Applications with GUI will be X11-forwarded.
1. Log in as root and convert the exfat partition from the Spartacus layout to an encrypted ext4 or xfs one.
1. "make -C /usr/local/src/ConfigPackages/Bastion install"
1. Log in as the bastion user on the new VM and run new-ssh-key for each [[SSH]]-capable host.
1. Set a NAT rule in the router to allow access to the Bastion host on a non-22 port.

+ 45
- 0
Entities/ View File

@ -0,0 +1,45 @@
The Core is the central VM on which the AniNIX's primary services are built. It is both a production platform and software repository location.
# Etymology
The Core is so named because all the rest of the AniNIX is built around it.
# Capacity and Components
The AniNIX is a [[ShadowArch]][[Category:ArchLinux]] installation. It receives the following resources from [[Forge2]]:
* 4 Cores
* Virtualized GPU
* 2TB storage
* USB device assignment
* Virtual bridged network interface
* Bluetooth adapter passthrough
* CD/DVD drive
* BluRay drive
# Hosted Services and Entities
# Connections
# Additional Reference
## Storage stack
The AniNIX uses the following storage stack, from user-accessed files to bits on disk. Bootability is from an unencrypted [ EXT4 boot sector] and MBR [ GRUB] bootloader.
* Files
* [ XFS Filesystem]
* LUKS volume
* LVM physical volume
* 2TB Physical disk
The output of "lsblk -o NAME,KNAME,SIZE,FSTYPE,TYPE,MOUNTPOINT,LABEL,PARTLABEL" gives the following layout. Additional shares mounted to accomodate users are not shown.<pre>
sda sda 1.8T disk
├─sda1 sda1 500M ext4 part /boot COREBOOT
└─sda2 sda2 1.8T LVM2_member part
├─corestorage-coreswap dm-0 10G crypto_LUKS lvm
│ └─coreswap dm-3 10G swap crypt [SWAP]
└─corestorage-core dm-1 1.8T crypto_LUKS lvm
└─sysroot dm-2 1.8T xfs crypt /
sr0 sr0 1024M rom </pre>

+ 26
- 0
Entities/DarkNet.d/ View File

@ -0,0 +1,26 @@
In the wake of the catastropic [ FCC vote to kill Net Neutrality], [[DarkNet|privacy VPN]] machines may become more prevalent to allow unfettered and uncensored access to the Internet. In the meantime, some less-drastic measures can be taken to help allow access to fettered, deprioritized, slow-laned, or censored traffic.
Please visit the #freenet channel on [ AniNIX::IRC] with questions or suggestions.
# Recommendations
These settings are mostly for good encryption to prevent eavesdropping and good compression of traffic to better tolerate throttled links.
* Install Google Chrome.
* Turn on [ Data Saver] in your [chrome://extensions extensions].
* Android users may find this inside Chrome under the triple-dot icon at the top right.
* Conduct a security review of Chrome as a best practice against ISP eavesdropping and deep packet inspection (which can be used for throttling or controlling your traffic).
* Check under [chrome://settings Chrome's settings] > "Advanced" > "Privacy and Security" to make sure the settings meet your need. We strongly encourage the "Protect you and your device from dangerous sites" and 'Send a "Do Not Track" request with your browsing traffic' options.
* Visit [] to run an account audit.
* Set up Google Authenticator or other two-factor solutions.
* Disable automatically downloading updates and instead patch machines weekly or when they're being shutdown. **Note: we strongly encourage patching! Make sure that you regularly check for patches.**
* Windows users can do this by following [[Forge2#Windows Update|these instructions]] under the Windows Update header.
* Linux users should make sure to download patches at night and perhaps share package files from a central package cache.
* Android users can do this from the Google Play store under Settings > Auto-update apps.
* Coordinate large downloads to occur during minimum usage hours. This is dependent on sysadmin analytics.
* Install Tor Browser to access censored content.
* Windows users can download from [ Tor].
* Android users can install [ Orfox] and [ Orbot].
* Set "Compression yes" in ~/.ssh/config. Older clients may need to additionally add "CompressionLevel 8".
# Fight Back
* We still have a widget added to the WebServer root to allow you to continue to petition Congress against the FCC's decision.
* [ Several states are suing.] Stay informed through [ EFF] and [ BattleForTheNet], and contribute where you can.

+ 26
- 0
Entities/ View File

@ -0,0 +1,26 @@
The DarkNet VM is the privacy protection of the AniNIX. The AniNIX does not believe in security by obscurity or in censorship; as such, everyone should have a voice.
# Etymology
The DarkNet is named for an anonymous network whose access is controlled only by the admins and whose usage is known only to them. It's entirely closed and anonymous.
# Capacity and Components
* [[ShadowArch]]
* 1 core
* 1024M of RAM
* 150G of storage
* Virtualized NIC
# Hosted Services and Entities
The DarkNet uses a small package list but runs more than the standard ShadowArch install. Also included are the xfce4, xorg-server, tor-browser-en(AUR), transmission-gtk, transmission-cli, and openvpn packages.
## Abilities
* Encrypted storage by default to a passphrase known only to admins.
* Tor proxy service, integrated with both text lynx and GUI tor-browser-en browsers.
* Lynx is aliased to "torsocks lynx" globally
* Anonymous VPN via OpenVPN (details available on request)
<!-- we use cryptostorm[d0t]is with prepaid Visas purchased with cash -->
## Hosted
# Connections

+ 88
- 0
Entities/ View File

@ -0,0 +1,88 @@
The Forge2 is the primary hardware platform on which the AniNIX runs.
# Etymology
The Forge2 the second Forge build, the original having been two towers instead of one.
It is so named because the exterior is solid black with soft red LED's internally -- this creates an appearance similar to a furnace.
The Forge builds are also so named because projects are created, developed, and tested in these frames.
# Capacity and Components
* 6-core hyperthreaded core i7 at 3.4GHz, water-cooled by Corsair H100i two-fan cooler
* 24 GB RAM
* 13.2 TB onboard storage. One hotswap slot open.
* 60 GB solid state boot drive for Windows 10 Pro Hypervisor (Hyper-V)
* 1 1TB drive dedicated to additional user space and VM's
* 1 2TB drive dedicated to Windows data formatted as NTFS
* 1 2TB drive dedicated to Windows Backup formatted as NTFS
* 2 2TB drive dedicated to [[Core|AniNIX::Core]] -- see Core for the filesystem hierarchy there.
* One hotswap bay for [[Aether|AniNIX::Aether]] backups.
* 1 150GB drive for the [[DarkNet]] VM
* USB 2.0 & 3.0 and eSATA slots
* 2 10GB NIC's -- one for VM's and one for Windows
* Bluetooth Adapter
* Hyper-V virtualization under Windows 10 Pro[[Category:Microsoft]]
* 1200W Corsair power supply
* EVGA x79 Dark motherboard with PCI-e SATA extender
* SLI'ed GTX 760 GPU's with 4GB onboard cache each
* Corsair K70 Keyboard w/ red LED and Corsair M65 mouse.
* CyberPower UPS
# Hosted Services and Entities
# Connections
# Additional Reference
## Gallery
A gallery will be added. [[Category:TODO]]
# Hypervisor Notes
Hyper-V integrates VM's with Windows, allowing VM's to be started at Windows boot, providing direct disk access, and managing assignment of cores, memory, and disk.
ShadowArch guests with a GUI should include xf86-video-fbdev and set GRUB_CMDLINE_LINUX_DEFAULT="quiet video=hyperv_fb:1920x1080" to get maximum screen resolution.
Hyper-V comes with a few limitations. PCI and USB devices can't be passed through without 3rd-party software, but this was considered acceptable.
Hyper-V guests require significant configuration to prevent performance problems. Dynamic memory should be disabled to prevent a guest from overrunning the host. Data Exchange, Backup, and Guest Services should all be disabled from integration services. Disable checkpoints. Automatic start action should either be on startup or disabled, and automatic stop action should always be poweroff.
Hyper-V itself also requires configuration of the Windows host. The default High Performance power profile turns off monitors when not in use but does not put the entire frame to sleep -- this is the desired behavior.
## Antivirus
Make sure Hyper-V, if using [[VirusScan|antivirus]] follows the [[VirusScan#Hyper-V|Hyper-V considerations]].
Presently, this still caused drops in virtual disks, crashing several VM's, so we are suspending antivirus on the hypervisor, along with most general-purpose browsing. Read the following for other user experiences.
## Windows Update
The Windows Update service, if it deems the system too out of date or in need of critical fixes, may forcibly restart the system. We recommend keeping the Windows Update service disabled on hypervisors until patching is desired. This can be done in services.msc.
We recommend addtionally setting the "gpedit.msc > Computer Configuration \ Administrative Templates \ Windows Components \ Windows Update \ Configure Automatic Updates" option if you have a Pro or Enterprise license.
## Sleep Mode
Sleep mode, even immediately interrupted, has been observed to break network connectivity and VM uptime. When running as a Hypervisor, it is advisable to disable sleep and hibernate modes. Change these from Group Policy under Administrative Templates>System>Power Management>Sleep Settings. Enable "Turn Off Hybrid Sleep" and disable "Allow Standby States (S1-S3) when sleeping".
## Previous Hypervisors
### VirtualBox
Oracle VirtualBox is a free hypervisor that can run on almost any OS. This makes deployment and device driver management entirely on the stock OS, which was Windows in our case thus alleviating driver problems. Management is also easy, particularly with an admin account, so it's easy to assign cores, memory, and such to a VM. VirtualBox can assign raw disk access with VBoxManage. Use Windows Disk Manager (diskmgmt.msc) to identify the disk. In the case below, 7 is the disk number.
<pre>"C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" internalcommands createrawvmdk -filename "C:\Users\Admin\VirtualBox VMs\raw7.vmdk" -rawdisk \\.\PhysicalDrive7</pre>
VirtualBox was dropped due to buggy integration with the running OS and the inability to start VM's at OS Boot.
### ArchLInux/KVM-enabled KVM
The Forge2 frame has a 60GB SSD installed for KVM-enabled QEMU virtualization inside a minimal ArchLinux host. This implementation allows passing any host resources to the guest, including USB and PCI devices which is an advantage over other Hypervisors.
While Intel VT-d provided by the motherboard ostensibly supports this passthrough, it had hardware caps on the x79 that the AniNIX could not afford (4 hard drives, 1 CD drive) without disabling KVM, and the network bridging created problems for VPN clients.
# Alternatives
You could in theory put the hardware for an AniNIX network clone in the Cloud. There are steps to set up ArchLinux in [ Microsoft Azure] and [ Google Cloud]. This may be advantageous for sites that have uptime concerns, low local resources, or physical security concerns.
From a cost perspective, power and network for a Forge2 and [[Shadowfeed|AniNIX::Shadowfeed]] costs roughly $100 per month with a $6000 buy-in. Equivalent cloud solutions would need to supply at least one full backup image with highly available power and network, along with [[Forge2#Capacity and Components|equivalent capacity]].
You should look at [[Aether|AniNIX::Aether]] notes on cloud computing if you consider this as an option.

+ 50
- 0
Entities/ View File

@ -0,0 +1,50 @@
AniNIX::Forge3 will be a successor to [[Forge2|AniNIX::Forge2]] and [[Infrastructure|AniNIX::Infrastructure]]. [[AniNIX::Core]] will be turned into hardware rather than VM, and a new systemd+qemu [[ShadowArch]] install will take the role of [[Hypervisor]] from [[Windows]]. Options being evaluated are below.
**This is not yet live.**
# New Rack Layout
* Forge2 bottom shelf, relegated to Windows [[Games]] and typically powered off.
* Requires 27.2 x 9.9 x 25.5 inchs
* Middle shelf: 2 PSU's in lateral
* Next shelf: soundproof-wrapped 2 x [ SuperMicro X8DTU-F servers] -- one as [[Core]] and one as [[Hypervisor]]/Dev.
* Requires 32" x 19" x 4"
* Hypervisor will virtualize [[Darknet]], [[Sharingan]], [[Aether]], [[Maat]], [[Cerberus]], and [[DedSec]] VM's.
* Top shelf:
* [[Shadowfeed]]
* [[Geth/Nazara]]
* [[Print]]
* Dev switch
## Network
WAN link runs from modem to Shadowfeed WAN. Shadowfeed LAN are
1. Nazara
1. PRD ether
1. Switch WAN
Switch LAN are
1. Dev ether
1. Dev IPMI
1. Dev table ether
1. Windows
## USB
Each PSU has a USB that should be able to connect to Nazara. This will allow Nazara to monitor active power state into Nagios.
## Power
UPS 1 sockets are provided from one wall outlet, max load 1200W and average load 300W.
1. HA
1. PRD PSU (500W)
1. Dev PSU (500W)
1. Surge only
1. Dev table strip
1. Laptop charger (100W)
UPS 2 sockets are provided from a second wall outlet, max load 1300W and average load 100W, on a 25' 12-gauge outdoor extension cable.
1. HA
1. Shadowfeed
1. Nazara
1. Switch
1. Desk light (typically off)
1. Non-HA
1. Windows (1200W)

+ 52
- 0
Entities/ View File

@ -0,0 +1,52 @@
The Games are a list of PC or emulated games available for users to play.
# Etymology
Let's not play games -- this service is self-named.
# Relevant Files and Software
<!-- This could be expanded. -->[[Category:TODO]]
## AAA Titles
* The [ Assassin's Creed] series
* Dishonored
* Deus Ex: Human Revolution
## Indie games
* Hacknet_
## MMO's
* [ Star Wars: The Old Republic] -- AniNIX members are presently playing for the Empire faction and working with the [ Mando Cabure] guild. Ping an admin on IRC or Discord to join the gaming.
<pre># This game can be installed on ShadowArch with the following:
pacman -S wine-staging wine-mono
winetricks d3dx9 vcrun2008 msls31 winhttp
1. Download launcher from
wine ./SWTOR_launcher.exe
timeout 60 wine ~/.wine/drive_c/Program\ Files\ \(x86\)/Electronic\ Arts/BioWare/Star\ Wars\ -\ The\ Old\ Republic/launcher.exe
vim ~/.wine/drive_c/Program\ Files\ \(x86\)/Electronic\ Arts/BioWare/Star\ Wars\ -\ The\ Old\ Republic/launcher.settings
1. Change bitraider_disable to true and download mode to SSN.
wine ~/.wine/drive_c/Program\ Files\ \(x86\)/Electronic\ Arts/BioWare/Star\ Wars\ -\ The\ Old\ Republic/launcher.exe
* [ Star Trek Online]
## Independent Games
: These are excellent for a [[Games/Team-building_Exercise|team-building exercise]].
* [ Artemis Bridge Simulator]
* [ Unvanquished]
## Emulators
* Desmune
* VisualBoy Advance
* ScummVM
# Available Clients
We are investigating NVidia SHIELD technology for the AAA titles.
The [[Games#Independent Titles|independent titles]] have game clients that can be downloaded and the AniNIX made to be the hosting server.
# Additional Reference
## Recovery
Recovering games used to be a tired process of maintaining product keys. Today, this is less an impact. Instead, one should buy games through services that allow reinstallation of the same. [ Steam] and [ Uplay] both support this functionality. SWTOR and MMO's like it do not install unique content directly to the local machine, so they are easily reinstalled.
Independent games or freeware should be preserved through keeping copies of the installers.
## Streaming
Linux [[Tachikoma]] or [[DedSec]] hosts can stream from a Games install using Steam in-home streaming. Wireless AC connections are recommended, and [ firewall rules] need to be made.

+ 24
- 0
Entities/ View File

@ -0,0 +1,24 @@
The Geth Armature is a robotic body that allows the Geth to interact with the real world.
# Uses
1. Physical patrolling
1. Lock inspection
1. Invalid care, for those unable to move on their own.
1. Hardware inspection, in the case of an [[Sharingan|AniNIX::Sharingan]] alert.
1. Potentially firing off other Geth-controlled units, such as carrying an IR module into range of a Roomba.
# Hardware
We're coding for [ RoboBuddy from SwiftStream], but the process to be documented will be very similar for any mobile IP camera. Key requirements:
* Articulation on the camera
* Onboard lights
* Durability of frame
* Self-recharging
* Good resolution
# Softare
In development! [[Category:TODO]]
# Etymology
While many Geth mobile units were modeled after their Quarian creators, larger security units were more utilitarian. The collapsible, giraffe-like Armature were the heavy armor that could be deployed into hostile territory to protect their holdings. Similarly, ours protects our locations.

+ 82
- 0
Entities/ View File

@ -0,0 +1,82 @@
<b>WARNING: Holocrons should not hold copies of sensitive information.</b><br />
The Holocron is a mobile USB designed to take over any computer hardware and run as an element of the AniNIX.
# Etymology
Named for the [ Sith Holocron] from the Star Wars universe, the Holocron is a method for AniNIX admins to craft and record all their personal code and knowledge, including [[Aether|AniNIX::Aether]] backups, [[Foundation|Git]] repo checkouts, etc. It should be secured and difficult to crack to protect the secrets within, just as its namesake -- the better the traps, the better the knowledge it can hold.
# Capacity and Components
Holocrons have no defined capacity since they are not bound to any set of hardware. The portable storage space is bound to the drive on which it's written.
# Hosted Services and Entities
No services or entities are hosted.
# Connections
Holocron can dial to any host desired. It should have VPN, SSH, remote-desktop, browser, code version control, and file transfer clients available.
# Additional Reference
Implementation details for Holocron are below.
## Host drive
We currently recommend a [ Corsair Survivor Stealth] for Holocrons. This offers 64GB of flash storage with the following layout, in a form that is both impact- and water-resistant, making it a resilient tool.[[Category:Corsair]]
fd0 2:0 1 4K 0 disk
sda 8:0 0 1G 0 disk
sdb 8:16 1 59.6G 0 disk
|-sdb1 8:17 1 40G 0 part /mnt/xplatfrm
|-sdb2 8:18 1 9.3G 0 part /boot
`-sdb3 8:19 1 9.3G 0 part
`-spartacus 254:0 0 9.3G 0 crypt /
sr0 11:0 1 544K 0 rom
<b>WARNING: Do not store sensitive information on Holocrons!</b><br/> Though a Holocron has its root encrypted, /boot is not and the device is portable. Physical access is death! The storage can be cloned and cracked with sufficient computing resources. The encryption is a delay but not a hard-stop protecting your information. If you have access to an encrypted machine like [[Core|AniNIX::Core]] there is no reason to keep sensitive information on this, a client device. If you have nothing else, this encryption is better than none.
The Israelis and such have been working out ways to listen with directional mics to crack encryption, and I have no guarantee they didn't use some similar hardware assault to crack the encryption. The algorithm might be smart enough, but the hardware may give rise to a more direct way. Moreover, with the hardware being mobile, the firmware and bootloader could be assaulted to broadcast key signatures from memory, or someone could record you entering the decryption password. Some example vectors are below:
* [ Accoustic attacks on RSA]
* [ A sample LUKS crack]
* [ Another potential LUKS crack]
## Installation
1. Install [[ShadowArch]] to the / partition. Remember to remove the first four lines so that your mount options are used with your storage layout.
1. Create a folder /boot/iso in the / partition.
1. Edit /etc/grub.d/40_custom:
1. See [ Arch's multiboot] for individual GRUB entries.
1. Also see [ Arch's netboot] for a GRUB entry to use for netboot.
1. Load ISOs and pack for travel.
Example 40_custom file:
1. !/bin/bash
exec tail -n +3 $0
probe -u $root --set=rootuuid
set imgdevpath="/dev/disk/by-uuid/$rootuuid"
menuentry 'ArchLinux ISO' {
set isofile='/iso/archlinux.iso'
loopback loop $isofile
linux (loop)/arch/boot/x86_64/vmlinuz archisodevice=/dev/loop0 img_dev=$imgdevpath img_loop=$isofile earlymodules=loop
initrd (loop)/arch/boot/x86_64/archiso.img
menuentry "Kali Linux ISO" {
set isofile='/iso/kali-linux.iso'
loopback loop $isofile
linux (loop)/live/vmlinuz boot=live findiso=$isofile noconfig=sudo username=root hostname=kali earlymodules=loop
initrd (loop)/live/initrd.img
menuentry "CentOS ISO" {
set isofile='/boot/iso/CentOS.iso'
loopback loop $isofile
linux (loop)/isolinux/vmlinuz noeject inst.stage2=hd:/dev/sdb2:/$isofile
initrd (loop)/isolinux/initrd.img
## Recommended uses
* ArchLinux ISO: This ISO can be used to have a clean point from which to start -- its signature and size can be compared against [ the ArchLinux page] for integrity.
* Kali Linux ISO: This ISO is a hack suite, porting the latest tools with the user.
* CentOS ISO: This allows a user to access an enterprise network using a trusted OS with a known signature.
* ArchLinux local install: This is a portable workspace for the carrier -- packages installed here will be persistent, and allow the user to boot their own toolset without any or much network traffic.
* Cross-platform storage: This allows Spartacus to perform as a usual flash-drive.

+ 26
- 0
Entities/ View File

@ -0,0 +1,26 @@
The Infrastructure is a conglomerate of machines with mostly proprietary firmware providing power and connectivity to the AniNIX.
# Etymology
This should be self-explanatory -- the Infrastructure describes the lowest-level connection between the digital world of the AniNIX and the physical world. The Infrastructure passes raw resources from the physical world for the AniNIX to manipulate.
# Capacity and Components
The capacity of the Infrastructure is limited by the following areas:
* Power: 1500VA / 900W with surge protection on all sockets and battery power on three sockets for roughly 20 minutes of operation under the usual AniNIX load. [[Category:HasBattery]] Power is provided by Madison Gas & Electric [[Category:MG&E]] via a CyberPower UPS [[Category:CyberPower]]
* Network: Charter Communications modem providing, ostensibly, a 500MB/s upload and 6Gb/s download speed. results fluctuate. [[Category:Charter]]
# Hosted Services and Entities
# Connections
# Additional Reference
For hosts seeking insight into the Infrastructure, they can install the PowerPanel software from CyberPower. ArchLinux contains a copy of it in the AUR: [ linked here]
The following files are then critical for configuration, after the USB device is connected to the monitoring host:
* /etc/pwrstatd.conf
* /etc/powerpanel/
* /etc/powerpanel/
* /etc/powerpanel/
* /usr/lib/systemd/system/pwrstatd.service

+ 10
- 0
Entities/ View File

@ -0,0 +1,10 @@
Print is the printer/scanner of the AniNIX, aimed at offering the option to convert materials from digital to physical and vice-versa.
# Etymology=This entity is self-named.
# Capacity and Components=A [[Category:Brother]]Brother MFC-J430W will fill this role nicely, with color printing, scanning, and (unused) faxing abilities. It can be easily installed from [ ConfigPackages].
# Hosted Services and Entities=There are no hosted aspects.
# Connections={{Reference|Core}}

+ 1
- 0
Entities/ View File

@ -0,0 +1 @@
[[Category:TODO]]Roomba is a cleaning bot for the AniNIX

+ 42
- 0
Entities/ View File

@ -0,0 +1,42 @@
Rufus is an overlay to make use of unused clock cycles on AniNIX hardware. It allows the AniNIX to take what would otherwise be wasted power and network presence and put it to either profit or charity.
# Etymology=Rufus is named after the naked mole rat from the Kim Possible TV series; a ubiquitious companion to the protagonists, Rufus' species is also capable of great feats of digging, given their traditionally subterranean habitat. The Rufus system is equally useful at mining resources for the AniNIX, keeping it online.
# Capacity and Components=Capacity depends on the number of rigs available. A "rig" may simply be a [[Geth/Hub|AniNIX::Geth hub]], a running VM, or a full-featured rig.
Our full-featured rigs are built from cheap consumer-grade parts.<ref name=motherboard>[ Motherboard Ethereum mining presentation], accessed 2/5/18]</ref>. We have a list of our current desired parts at [ Newegg].
# Hosted Services and Entities
## Ethereum
[ Ethereum]<ref name=eth></ref> is a decentralized currency and contract blockchain.
Install and upgrade python3. From that, we can install [ PyEthApp] to mine the currency.
pip3 install pyethapp
Multiple miners can be supported in a single network, but port 30303 must be forwarded to the first node. Other nodes in the cluster will connect their ethminer to that node.
Funds can be transferred to an Ethereum wallet by TODO.[[Category:TODO]][[Category:Coinbase]]
## Bitcoin
Bitcoin<ref name=btc></ref> is another decentralized blockchain currency -- in fact, it was the first and most popular.
Mining is done by connecting GPU's or [ ASIC miners] to your host. From there, install bfgminer and benchmark the attached ASIC's. This can be done by standalone block mining or pool mining, where a group of miners agree to mine for the same block through shared and decentralized work.
When satisfied with the operation of the benchmarking, bfgminer can be run with all hardware and a Coinbase address to receive the funds.
## Folding@Home
[ Folding@Home]<ref name=fah></ref> is a Stanford project for protein folding research, helping researchers solve disease problems. This is our premiere project for our [ charity work].
Install the [ Folding@Home package] from Stanford. This will allow you to receive units of work from Stanford and process them.
[ BOINC] is a Berkley project for supporting underfunded research projects by allowing open computing resources.
Install the [ boinc-nox]<ref name=boinc></ref> package from Berkley. Enabling the service will use your compute resources for the needy projects.
# Connections=Rufus runs on any available hardware.
# Additional Reference=[ Contact an admin] for current ROI -- example math can be seen in [ this presentation]. Also, [ this presentation] offers an overview of how Ethereum the protocol works.}}
# References

+ 51
- 0
Entities/ View File

@ -0,0 +1,51 @@
The Shadowfeed is the networking gateway between the AniNIX and the outside world -- it broadcasts the AniNIX signal and allows the network to communicate.
# Etymology
The Shadowfeed is named after a resistance communications network in the Star Wars universe. The [ Shadowfeed] was a disseminated network routed through existing communications technology, allowing a separatist movement to broadcast its message.
# Capacity and Components
The Shadowfeed is an Netgear R7000 Nighthawk router hardware flashed with DD-WRT firmware.[[Category:DD-WRT]][[Category:Netgear]] It can hold numerous clients wirelessly, and it supports wired USB 2.0 and 3.0 hard-drives to create simple NAS storage. There are five physical slots, one occupied by wired connection to the Forge2 frame, one by a connection to the Verizon wireless tower, and one to the Infrastructure. One remaining slot is free with a 100ft Cat5e cable and the other reserved for hotswap in case of port failure or LAN need.
<b>Note:</b> the best place we've found to grab firmware updates is [ this upload site for Kong's builds]. Ensure that you are on build 33525 or later to avoid being vulnerable to [ KRACK]. Follow the instructions [ from the DD-WRT Wiki] to flash your router with new firmware or to patch. Make sure to watch for the peacocking notes! Use the dork "kong dd-wrt build <buildnumber>" -- if you use Chromecasts for [[Geth|AniNIX::Geth]], make sure to look for explicit validation of the devices, or run your own extensive regressions.
# Hosted Services and Entities
Nothing is hosted by the Shadowfeed, but it is manageable by either SSH or an onboard webserver.[[Category:Lighttpd]]
# Connections
The Shadowfeed has a number of hosts and entities that connect to it -- unknown entities are routed to a guest network, while known hosts are allowed inside the DMZ where they can access internal services. Direct AniNIX network members are listed below.
# Additional Reference
## Add NAT Rule
iptables -t nat -I PREROUTING -p tcp -d $(nvram get wan_ipaddr) --dport 3389 -j DNAT --to [ -s SourceIP ]
iptables -I FORWARD -p tcp -d --dport 3389 -j ACCEPT
iptables -t nat -I PREROUTING -p udp -d $(nvram get wan_ipaddr) --dport 3389 -j DNAT --to [ -s SourceIP ]
iptables -I FORWARD -p udp -d --dport 3389 -j ACCEPT
## Direct config alteration
nvram show will get all the current options, whereas nvram get variable will return a variable.
nvram set or unset change variables.
nvram commit pushes the change.
## Guest Wifi
[ See here.]
## Sample Startup Script
The following will insert firewall lines into your sample startup script to harden your network edge. This allows [[WebServer|web]], [[SSH]], [[IRC]], [[Geth|AniNIX::Geth]], and [[Nazara|bastion]] access through the firewall, dropping all others. It also sets up the block chain for [[Cerberus|AniNIX::Cerberus]].
iptables -N severe
iptables -I INPUT 2 -i vlan2 -j DROP
iptables -I INPUT 2 -i vlan2 -p tcp -m tcp --dport 22 -j ACCEPT
iptables -I INPUT 2 -i vlan2 -p tcp -m tcp --dport 80 -j ACCEPT
iptables -I INPUT 2 -i vlan2 -p tcp -m tcp --dport 443 -j ACCEPT
iptables -I INPUT 2 -i vlan2 -p tcp -m tcp --dport 6641 -j ACCEPT
iptables -I INPUT 2 -i vlan2 -p tcp -m tcp --dport 6697 -j ACCEPT
iptables -I INPUT 2 -i vlan2 -p tcp -m tcp --dport 9022 -j ACCEPT
iptables -I INPUT 2 -j severe
iptables -I FORWARD -j severe

+ 10
- 0
Entities/ View File

@ -0,0 +1,10 @@
|Tachikoma|Tachikoma are individual user or service machines.|
These are named after [ Tachikoma from Ghost in the Shell]. These AI-powered tanks offered personal transportation, concealment,
# Capacity and Components
Capacity is indeterminate -- depends on the hardware being used.
# Hosted Services and Entities=No services should be hosted for Tachikoma, despite [[SSH|an SSH server for remote access]].
# Connections=Varies by purpose}}

+ 48
- 0
Entities/ View File

@ -0,0 +1,48 @@
Omnitool is a mobile smartphone client of the network.
# Etymology
The Tricorder is named after the fictional and ubiquitous devices from the Star Trek universe. Because the Tricorder is useful in a number of situations, hand-held in the same way, and is almost always handled by an Admin save during sleep, the name was apt.
Besides, we like the subtlety, craftiness, and paranoia of the Romulans.
# Capacity and Components
This is a Verizon Wireless Droid Turbo smartphone running the Android OS. [[Category:USCellular]][[Category:Google]]
* 48 hours of usability
* 5.2" Gorilla Glass 4 Display with 1920x1080 resolution
* 32 GB of onboard storage, encrypted with Android PIN
* Microphone
* 16MP Camera
* CDMA, GSM, WCDMA, UMTS, LTE Network-capable with US Cellular SIM
# Hosted Services and Entities
The Tricorder can host a couple remote-management tools.
* Apps can be remotely installed with [ Google Play Store].
* Location identification, remote locking, and remote wiping can be achieved with [ Google Device Manager].
* SMS, notifications, and call response can be remotely controlled with a vivoactive HR or [ Pushbullet].
# Connections
This device has clients for the following entities.
This device physically can connect to the following.
This device can also extend Bluetooth and WiFi technology to the following devices, to extend the AniNIX's reach.
* Drones, such as the Parrot AR.Drone 2.0, over WiFi
* Smart devices, like the Garmin vivoactive HR smartwatch or smart scales, over bluetooth
* Car and other stereos over Bluetooth (this is particularly useful for playing back audio from Yggdrasil)
* Bluetooth-capable devices for file transfer
* WiFi-capable devices via ad-hoc WiFi network
# Additional Reference
* [ Reference page]
* [ Star Trek Wiki page]
## Recovery Path
Please encrypt your Tricorder for privacy reasons. For those concerned, here is your recovery path, should the device be rendered inoperable or inaccessible.
* The Google Play Store records all applications installed on the phone.
* Music, pictures, and video should be replicated from [[Yggdrasil|AniNIX::Yggdrasil]]. Please use an [[SSH|SFTP]] client to regularly store your necessary files on your AniNIX account, or upload your files to a trusted storage service. For insecure files, [ Google Drive] is sufficient and free.
* Customizations will be lost but should be easily recreated.
* SSH Keys should be recreated. Remove any existing public keys from servers the device had access to.
* Android devices can be remotely wiped, locked, or pinged from Android Device Manager.
Most severe problems with an Android device can be fixed with a factory reset, patching, app re-installation from the Play Store, and pulling down any desired files. While this is a cumbersome process, for non-rooted, encrypted devices, this is often the easiest route.

+ 49
- 0
Entities/ View File

@ -0,0 +1,49 @@
: <b>Warning: Windows may reformat non-Windows partitions with no warning during boot. We recommend keeping strong backups and controlling when Windows Update runs. See [ OMGUbuntu's article] for end user experiences.</b>
Windows is a ubiquitous desktop environment for home computing, still compromising the majority of the market. The AniNIX hosts a virtualized Windows host to access the tools and software developed for that OS.
# Etymology
The Windows host is named for the OS it runs.
# Capacity and Components
Windows' components are provided by Microsoft. [[Category:Microsoft]] The Windows host is granted networking, USB assignments, the GTX 760 pair, 2TB of storage, 8 GB RAM, and 4 cores from [[Forge2]].
# Hosted Services and Entities
## Customization
There is a desktop theme available to skin the Windows desktop environment in the same fashion as [[ShadowArch]], the WebServer and the Wiki. Download it from [ this link].
## Standard Packages
Available from [ WolfPack's repo]:
* SeaMonkey Browser
* Chrome Browser can be used in place of SeaMonkey or in addition to support Chromecasts.
* PuTTY Terminal Emulator
* WinSCP File Transfer
* Launchy to emulate Linux Alt+F2 running
* VNC viewer
* Xming X11 server
* DaemonTools Lite for mounting ISO's.
## Hypervisor Role
A Hypervisor should also be deployed.
* A Windows 10 Pro license offers Hyper-V, which allows enterprise-style VM availability
* VMWare Workstation or VirtualBox are also alternatives.
## Work Role Packages
* WebEx
* AnyConnect
* One productivity suite from:
* LibreOffice
* Microsoft Office
* Notepad++
# Connections
# Additional Reference
Remember the following things when dealing with Windows:
* Windows updates and upgrades stand a very good chance of being destructive to other systems and itself. Never upgrade without a backup, and everything installed on Windows should have an independent recovery plan. See [[Games#Recovery]] for an example.
* Windows tries to send data to Microsoft. Check account settings to opt out.
* Always disable autorun to help slow malware.
## Unified Credentials
Install [ pGina] for LDAP authentication, including with [[Sora|AniNIX::Sora]].[[Category:LDAP]]

+ 31
- 0

@ -0,0 +1,31 @@
Version 2, December 2004
Copyright (C) 2004 Sam Hocevar <>
Everyone is permitted to copy and distribute verbatim or modified
copies of this license document, and changing it is allowed as long
as the name is changed.
Trademark 2017 (
The "AniNIX" name and |> logo are trademarked as of 2017/11/21.
AniNIX materials may be reproduced and re-used (though you must
contact the admins of the network to get written permission to use
the AniNIX name or logo) so long as such reproduction or re-use
does not inhibit the original AniNIX use of the same.
Attribution is appreciated for other materials but not legally
required or necessary.
"AniNIX" trademark serial: 87177883
|> Logo trademark serial: 87177887

+ 68
- 0
Layouts/ View File

@ -0,0 +1,68 @@
This offers a detail of the security hierarchy of the AniNIX, which is layered in the following sections.
# Physical security
Physical security includes storing the [[Forge2]] in a locked second-floor building. [[Cerberus]] offers reporting on events in this location. Admins co-locate with this location and are trained in combat and close quarters defense. Physical intrusions will be rebuffed to the fullest extent of the law.
# Network/Software protection
{{Organizer|Trusted DMZ|
Most of the services in the AniNIX are monitored by network-level intrusion detection
## Open-access Services
## Password-Restricted Services
## Remote Access
The SSH service supports password and key authentication.
{{Organizer|Guest DMZ|
Any visitors to the AniNIX premises are given access to the outside Internet via the Shadowfeed, but this access is isolated away from AniNIX systems.
# Filesystem security
The Hypervisor content lives here.
{{Organizer|LUKS-on-LVM Volume|
Most of the data lives inside these layers.
The Windows data lives here.
# Backups
[[Windows]] and [[Core]] are backed up locally on mirrored, non-RAID disks. They are also backed up to a 4TB hard drive from the [[Forge2]] to an off site safety deposit box in a bank, making it very difficult to destroy all copies of these hosts.
Should all backups be lost, the [[Aether]] project also backs up Core's critical configuration files and a list of files in [[Yggdrasil]] to an anonymous list of servers. [[Grimoire]]'s databases are independently archived to a password-based tarball and stored in cloud storage.

+ 19
- 0
Layouts/ View File

@ -0,0 +1,19 @@

+ 86
- 0
Operation/ View File

@ -0,0 +1,86 @@
This is intended to give contributors a baseline for editing.
# Proper naming
Services on this network are properly titled in the below format. This should always be used the first time a service is referenced.
<pre>AniNIX::{ServiceName}[/{Area}][ \\ {Title}]</pre>
# Grammar
Grammar is a writer's toolbox. You can't build good sentences without knowing how to use your tools. Since a wiki article should be as clear as possible for all those reading it, editors should keep their edits as grammatically correct as is possible, in order to ensure clear communication of the information being provided.<ref name="acwiki">['s_Creed_Wiki:Manual_of_Style Assassin's Creed Wiki MoS]</ref>
## Capitalization
Words should be capitalized at the start of each sentence, and when they are denoting a name or title, in line with current grammatical precedent, for example:<ref name="acwiki"/>
::"The Aether project should be used to back up critical servers."
## Titles of works
Titles of works should be italicized to make clear that they are names; the titles of articles, chapters, and other short works should not be italicized, but are enclosed in double quotation marks.
# Writing Style
:*“I believe the road to hell is paved with adverbs”* -- Stephen King
We now come to the meat of an article: the words themselves. When you're editing wikis, you're both academic and artist. You have to be accurate, but you also have to be interesting. Neither one can dominate; you have to skillfully balance both.<ref name="acwiki"/>
**Keep your writing concise.** Don't use two words where one will do. Keeping your writing simple will make it easy to understand and easy to expand on. Use complete sentences whenever possible. When you write, use grammar as a toolbox: know the rules, but only break them on purpose.<ref name="acwiki"/>
**Check your spelling and grammar.** Do not use 'u' in place of 'you' or '2' in place of 'to'. Write the way you would for a class paper or a newspaper article.<ref name="acwiki"/>
**Keep all of the topics you cover within the scope of the article.** What that means is, you don't need to give a detailed history of all AI on the page about [[TheRaven|AniNIX::TheRaven]]. Consider the article's title as your point of origin and write from that perspective. Make use of the wiki's ability to link to more detailed articles or external sources for more information.<ref name="acwiki"/>
**Write from an impersonal perspective.** Do not use "I." For example, do not write, "In the years that followed, Ezio began a quest to rediscover the lost history of the Order, <strike>As far as I know</strike>." Avoid drawing attention to the author (yourself) as much as possible.<ref name="acwiki"/>
**Be bold.** If you know something is wrong, correct it. If you think you could word something better, write it. If an article has a glaring deficiency, fill it. Even if your first attempt isn't golden, you can fix it later or someone else will come along and fix it for you. Don't be afraid to screw up.
<ref name="acwiki"/>
**Use present tense.** These services, enttitles and policies are active, living, and fluid -- because they're changing now, we use present tense to describe current state.
# Images
Images make an article memorable and pretty. They can speak where words fail. At the same time, misplaced or untidy images can detract from an article. When choosing images, keep in mind placement, size, and the appropriateness of the image to the section. Let images flow with the text instead of break it up.<ref name="acwiki"/>
Large images such as screenshots should use the "thumb" (example:<code><nowiki>[[Image:CoolImage.png|thumb]]</nowiki></code>) option which displays large images as thumbnails. Images should generally be right aligned to enhance readability by allowing a smooth flow of text down the left margin - the "thumb" option does this by default. If an infobox is not being used in an article, a right aligned picture in the lead section is encouraged.<ref name="acwiki"/>
Images should be kept to a minimal number -- three or fewer inline images per article. High-quality images should be stored in [[Yggdrasil|AniNIX::Yggdrasil]].
### Galleries
When an article has many images, or can be improved by having more, and having inline images can detract from its readability, the use of a <code><nowiki><gallery></nowiki></code> section is encouraged. See the [[#Useful_Snippits|Useful Snippets]] for how to implement that.<ref name="acwiki"/>
Galleries should be five images or less. More images than that or exceptionally high-quality images should be in [[Yggdrasil]].
# Useful Snippets
## Tables
| Cell 1 || Cell2
## Transclusion
This will include an entire other page in yours.
## Links
Internal: <pre>[[Wiki]]</pre>
External: <pre>[ WebServer]</pre>
## Styling
## Images
[[File:Image|thumb|250px|right|Some caption]]
## Gallery
## If/then
<pre>{{#if:{{{add|}}}|==Additional Reference

+ 66
- 0
Operation/Archive/ View File

@ -0,0 +1,66 @@
{{DowntimeRCA|Windows Update Failure|cause
As background, [[Windows|AniNIX::Windows]] was installed originally as Windows 7 Home. It was later upgraded to Windows 10 Home and then Windows 10 Pro to add functionality for Hyper-V and Remote Desktop (though only to targeted IP's -- this service is considered a convenience and a vulnerability).
The AniNIX was brought down after a Windows update on 8/24/2016. The AniNIX had had other downtimes recently on calls with Microsoft as the Windows cdrom.sys driver was not recognizing drives that were ostensibly plug-and-play. Many fixes, including reordering SATA slots, registry updates, calls with drive manufacturers for drivers, adding/removing the hardware in Device Manager, etc. had been tried and not succeeded. This issue was on hold at the time of the update.
When Windows started again, it would only flash a "CRITICAL_PROCESS_DIED" error message. Booting with [[Holocron|AniNIX::Holocron]] showed no memory issues or other hardware problems. Using a Windows installation medium (on USB), we were not able to restore to a system restore point before the update or correct the issue with the installation. We were also not able to access the prior system images taken with the Windows backup utility.
Discussions with Microsoft indicate that the upgrades fro Windows 7 to Windows 10 Pro had suffered silent failures that were not logged to the user. While the operating system would limp along in functionality, it was unable to be repaired and required a reinstall.
|length=~24 hours
At this point, the [[Forge2|AniNIX::Forge2]] frame was disconnected and all SATA lines except for the 60GB SSD were severed. Windows 10 Pro was re-installed to this disk, and display drivers were re-installed. The standard and Hypervisor packages were re-installed. [[Games]] were left to be rebuilt over time.
The frame was then brought down again and other drives reconnected, with the exception of the original Windows 10 drive. This drive will be left disconnected and system images abandoned short-term as a form of backup. Instead, backups will be taken of all installers used during the recovery process along with the Windows 10 Pro product key and registry.
{{DowntimeRCA|Windows Virtual Disk Failure|cause
On 9/17/2016, the [[Forge2#Hypervisor_Notes|AniNIX::Forge2]] Hypervisor logged error messages about a reset being sent to the RAID1 device, an [[Windows]] warning-level event with an id of 129 and source storahci. From then on, every five seconds, error messages were logged about disks: "An error was detected on device \Device\Harddisk1\DR1 during a paging operation." with an error ID of 51 and source of disk. Also every five seconds, NTFS error of id 140 was logged with the error message "The system failed to flush data to the transaction log. Corruption may occur in VolumeId: F:, DeviceName: \Device\HarddiskVolume1. (A device which does not exist was specified.)".
These error messages occurred silently for several hours. Finally, on trying to access a mounted virtual disk inside [[Core|AniNIX::Core]] on 9/18/2016, ArchLinux displayed a cascade of block update failures and required a reboot. All virtual machines on the Forge2 were to be rebooted, but none came up as Hyper-V could not detect the disks. The entire frame was restarted, VM definitions repaired manually, and services restored.
This issue recurred a few days later and perhaps once a week after.
|length=6 hours over a series of downtimes
|resolution=Hyper-V resource files and executables were excluded from antivirus scanning. When the antivirus didn't respect this, we dropped antivirus from the Hyper-V host.
|commits=[ Wiki change]
{{DowntimeRCA|Windows Update Service Reboots|cause
The Windows Update Service, if it does not see a reboot recently, will reboot the host to install updates. This causes downtimes on the [[Core]] VM and other service VM's; remote recovery has also been made difficult by BIOS randomly changing the boot device.
Thanks to Mathisen from ##windows on Freenode, we found a GPO we're testing. Set the "gpedit.msc > Computer Configuration \ Administrative Templates \ Windows Components \ Windows Update \ Configure Automatic Updates" option to Enabled and "Notify to download / Notify to install". This should stop automatic reboots but requires a Pro or Enterprise license.
|length=2 hours from unattended host
|resolution=Apply Group Policy.
{{DowntimeRCA|Charter ISP Outage|cause
At 0043 CST on 11/18/2016, the Charter Residential modem lost connectivity with the wider Internet. Service was not restored until 6:45 a.m., and the admin was physically away from the system. At 1045 CST same-day, a direct check of the IP address luckily showed that the AniNIX had recovered its original IP before the outage.
Admins have changed ISP contracting to be notified immediately of outages and resumption of service.
The upcoming changes to the [[Cerberus|AniNIX::Cerberus]] project will include detection of changes in WAN IP and will notify admins of changes so that the remote DNS can be updated. Admins will also investigate dynamic DNS services.[[Category:TODO]].
|length=6 hours of technical downtime, extended to 10 hours of practical downtime by a lack of reporting tools on ISP outages.
* [ Wiki]}}
{{DowntimeRCA|Windows Sleep Hangs Core VM|cause=Admin Error -- accidentally clicked sleep during RDP disconnect
|length=8 hours
|resolution=I was able to access the [[Shadowfeed|AniNIX::Shadowfeed]] and [[Forge2|AniNIX::Forge2]] entities by port forwarding through [[Bastion|AniNIX::Bastion]] from my [[Tricorder|AniNIX::Tricorder]], as I was offsite. I was able to restart [[Core|AniNIX::Core]] and supply passphrases to unlock the storage.
This downtime was exacerbated as I did not check [[Heartbeat|AniNIX::Heartbeat]] after resuming the hypervisor.
We've added notes for removing sleep options on servers and remote Heartbeat monitoring in response to this incident.
|commits=* [ Wiki for Forge2 notes]
* [ Wiki for Heartbeat notes]
{{DowntimeRCA|Windows Wake Hangs Hypervisor|cause=Code issue|length=30 minutes|resolution=All services were restarted.|commits=None yet. I plan to move Bastion to its own host, and to ensure Forge2 runs VMware ESXi rather than Hyper-V. This will take time and planning.}}
{{DowntimeRCA|Alliant Energy Outage|cause=Power company|length=9 hours|resolution=AniNIX staff noticed connections drop to AniNIX services on 2018-09-18 12:05 CDT. At this point, power had already been out for 22 minutes and UPS power was exhausted, resulting in a shutdown of AniNIX hardware. Alliant notified AniNIX on-site admins 40 minutes later of the outage, and power was restored by 16:00. Unfortunately, AniNIX staff were not able to resume service operation until 21:15.|commits=We will add monitoring either through [[Nazara|AniNIX::Nazara]] or [[Forge2|AniNIX::Forge2]] of the UPS, but this will not prevent an outage. The [[Forge3|rebuild]] may improve uptime capacity, but until a generator is on-premise, this outage is unpreventable. That generator cost will take significant time to defray.}}
{{DowntimeRCA|Charter ISP Outage|cause=ISP|length=4 hours|resolution=AniNIX on-site admin detected the outage at 2018-10-04 00:05 CDT and restarted modem hardware on-site several times. When this didn't work, the admin contacted the ISP and reported the outage. ISP acknowledged the outage and field techs were sent to repair the outage in the area. Service was restored at 04:10 CDT|commits=None. Our Zapier/Freshping alerting service worked appropriately, and [[Sharingan|AniNIX::Sharingan]] sent out notifications as designed when service resumed.}}
[[Category:RCA Archive]]

+ 10
- 0
Operation/ View File

@ -0,0 +1,10 @@
Bug bounties are requests for penetration testing against the AniNIX services.
# Rules
1. Do not test against AniNIX production services without prior authorization. Instead, set up a replica using [ShadowArch](/AniNIX/ShadowArch) and any other AniNIX Foundation repository.
1. Report bugs immediately to AniNIX staff via [AniNIX IRC](ircs://
1. Control the scope of your pentesting. Using root access to the host to conduct a Direct Memory Access attack on CryptoWorkbench, for example, is not an exploit in that project. Physical penetration is always outside scope.
# Active Targets
## CryptoWorkbench
The [CryptoWorkbench](/foundation/CryptoWorkbench) has a --blind option. This is intended to prevent data exfiltration and CLI access, despite being a CLI tool. Install ShadowArch, and use the CryptoWorkbench "make sshuser" command to set up the captive user. If you can use the captive user over SSH to gain a prompt or exfil data through the CryptoWorkbench, please announce it to the admins.

+ 75
- 0
Operation/ View File

@ -0,0 +1,75 @@
The AniNIX is not a collection of one-offs. The following considerations should be evaluated before testing or releasing a new project, and quality assurance should report if any of these design principles aren't met.
# Meeting the need
Any design should be evaluated against the need it is intended to meet. Ask the following questions:
* Does an existing package fulfill the need better than custom development by the AniNIX? [TheRaven](/AniNIX/TheRaven) is a fairly specialized package, but [Yggdrasil](../Services/ was superior to our self-written Siren and an externally-maintained package, which saves the network human hours.
* Is the implementation going to fit the state of the industry? This is a slightly nebulous question, but Bazaar was deprecated in favor of Git for the Foundation project because Git is more widely used and better supported. Following the state of the industry usually means superior features, testing, support, and adoption.
* Will filling this need justify the resource expenditure?
* Will end users adopt this solution and fill their need that way, or will the effort be wasted when a more professional solution will be released and adopted later?
# Security-First Design
## Remote Access vs. Local Only
Remote access isn't needed in all cases and opens the network to vulnerabilities. The CryptoWorkbench in the Foundation doesn't need to be remotely accessible when users can deploy their own with git; the Foundation itself doesn't need to allow the world to write to it to allow cooperation. These kinds of projects, that are either read-only or non-deliverable, can be safely monitored with [filesystem intrusion detection](../Services/, virus scanning, and existing controls over remote access to the host.
[SSH](../Services/ and [IRC](../Services/ do allow remote access, and require additional safeguards to those above. Network intrusion detection becomes a need, since this is a means by which attackers can exploit a service. Firewall rules will need to be opened and monitored.
## Penetration Testing Planning Before Release
Identify a plan and set aside resources to test the project before release. Failed attempts at open chroot accounts on [Core](../Entities/ have been identified and shut down before being generally released; these kinds of attempts allow the AniNIX to have confidence in the released projects while not stifling the developer's ideas. Failed ideas that are insufficiently secured are a good exercise in development, and they can be tabled for later when better controls or designs are available.
## Appropriate User Rights
Running services as root is generally a bad idea for non-security services. Make sure to have a unprivileged account for any other service, particularly if they allow remote access.
## Physical Access
The AniNIX does not believe in the cloud (or, as it is affectionately known, Computers Living On Unknown Datacenters). Cloud computing centralizes storage in a place that is difficult if not impossible for end users to secure and protect; particularly for sensitive information like social security numbers, this is not acceptable. Redundancy of the cloud is also very expensive and hard for small groups to achieve.
In contrast, if any given user can replicate shared data from the AniNIX and each other on storage that they monitor and secure, the network becomes harder to destroy, impede, or rob. This decentralized model ensures that users know where their data lives, and any given user can stand up the network.
For services that are hosting information like passwords, the device should be physically secured and the storage encrypted. While they can be made useless by destruction, this should prevent physical access resulting in an immediate compromise.
## Privacy
Guarantees of privacy are a major concern in designs. The AniNIX needs to be able to protect itself while doing its best to provide the same right to others. This ties in with concerns of Remote Access -- remote access that isn't by read-only transport requires an account which can be paired with an individual. This should be used for collaboration with the network and for maintaining user preferences.
However, tools like documentation and source code should be available from behind privacy tools and without identifying a user. When governments can outlaw information, as many repressive regimes in the Middle East and elsewhere have done, the AniNIX seeks to make sure that the peopke still have power by information.
Furthermore, any communication across a wwider network should be encrypted. [WebServer](../Services/ controls most of this via the Let's Encrypt SSL certificate for the web apps, but SSH also encrypts its communication. Unencrypted communication is insecure and not private by default and should be prohibited as much as possible.
# End User Experience
Services developed in isolation are interesting exercises, but in the end it is the user's comfort and trust in the service that will keep it being used.
## Reliability and Stability
Physical devices should have redundant components and power sources as much as possible. Protections against failures in services, such as frequently saving state and quickly restarting after a failure, are highly encouraged.
Projects should crash rarely if ever -- any crash should be investigated immediately and the relevant code revisited. Frequent crashes are perhaps the highest cause of end-user dissatisfaction.
## Performance
Performance is second only to stability in terms of the end-user experience. Services should be fast and light to meet the needs of users -- the state of development today doesn't tolerate slow and/or intensive processes for all but the most critical projects.
Ensure that memory is allocated only when needed and deallocated as soon as possible. Processing should use efficient algorithms to meet the goal and should be open to re-evaluation. Network should minimize the use of images in transport -- X11 forwarding and video streaming should only be used in services that the user expects to be noncritical and potentially slow.
## Graphical Design
[Minimalism]( is a key principle in the AniNIX design. An uncluttered interface with simple, intuitive options reduce the barrier to entry and improve adoption.
The AniNIX, as you can see by this page, follows a white-on-black color scheme with red for important or interactive elements. White-on-black results in less light emission from screens, and in low-light conditions this means less effect on the night vision. [A study in August 2013]( found that white and blue light were the most disruptive to the animal test subjects, while red light was the least. [A LensCrafters study]( also found blue disruptive. Red accents, therefore, offer the least disruption while keeping readable text with the highest contrast. The three-color scheme further assists the colorblind, who should still be able to clearly identify the static and interactive elements on the interface.
GUI elements will generally be deployed by a Web page, as this is a cross-platform means of providing access and easy to code. Should packages choose to include a local GUI, they are responsible for meeting these principles with a best-effort approach.
## Mobile Access Design
With the rise of the smartphone, remotely accessible services should offer a simple means via some app to reduce network traffic. The app interface should be intuitive and quick to use.
## Etymology
The AniNIX attaches a unique name, such as Sora for OpenLDAP or Yggdrasil for Emby, to packages and services it instantiates. The reason for this is that the name defines a scope of functionality the AniNIX expects to rely on -- should the underlying package change, such as replacing Plex Media Server with Emby, documenation and AniNIX packages will use the same name.
Names given should be chosen for relevance to the function being provided (Singularity being a pull service, Foundation being the basis on which we're built, etc.) and for ease of memory. Only the most basic services, such as IRC, WebServer, and SSH, will be left unnamed.
These names are not intended to supercede the licensing or attribution of other packages -- applications, once installed, should only update the minimal allowable elements to be usable under AniNIX principles. Whereever possible, this should be done via the application's provided interface, such as enabling dark modes. We also should not remove any links that the application provides to its own documentation, licensing, or websites. This means that AniNIX etymology only applies to administrators and is otherwise invisible to end users.
# Maintainability
Make sure that a project can be easily maintained. This means following the Development Best Practices and submitting Markdown documentation for the project.
Ensure that projects are configurable for key elements, particularly for things like passwords that change often, and they should use well-known and understood languages per the Development Best Practices.

+ 34
- 0
Operation/ View File

@ -0,0 +1,34 @@
I'm defining scope for the various [[:Category:Service|services]] and special-use [[:Category:Entity|entities]]. Use this as a reference for [[Design Principles|design review]]. [[Category:Layout]]
# Infrastructure
* [[SSH]] for read-write access to servers
* [[WebServer]] for server read-only and application access
* [[Grimoire]] for data storage
* [[Shadowfeed]] for networking
* [[Infrastructure]] for providing resources like power, cooling, and connectivity to the outside world.
* [[Tricorder]] and [[ShadowArch]] for end-user environments.
# Maintenance
* [[Aether]] for backups
* [[Heartbeat]] for monitoring
* [[Maat]] for regular regressions
# Security
* [[Sora]] for authentication
* [[Cerberus]] for intrusion detection/prevention
* [[VirusScan]] for malware <!-- TODO roll in with Cerberus -->
* [[DedSec]] for penetration testing
* [[DarkNet]] for privacy
* [[Cerberus]] for testing patches
# Content
* [[Yggdrasil]] for media
* [[Wiki]] for documentation
* [[Singularity]] for news
* [[IRC]] for communication
* [[Foundation]] for code
# Special Interest
* [[Geth]] for real-world interaction and automation
* [[TheRaven]] for artificial intelligence
* [[Holocron]] for portable toolsets.

+ 154
- 0
Operation/ View File

@ -0,0 +1,154 @@
Like all organizations, the AniNIX has a set of coding and development best practices. See [HelloWorld](/AniNIX/HelloWorld) for an example project that should implement these recommendations and provide a skeleton to use.
# Packages
Each package should have a single, dedicated purpose. Developers should be careful against scope creep -- if additional functionality is needed beyond the purpose of the package, another package should be created to fill the need.
## Commenting
All source files should be commented with at least one descriptive comment per operational unit. Ideally, there will be no more than 20 lines between comments, unless so dictated by function. Block comments should be at the beginning of functions summarizing the work the function does, the parameters if any, and the return value if any.
/// <summary>
/// Put the summary here
/// </summary>
/// <param name="xname">A parameter for X</param>
/// <param name="yname">A parameter for Y</param>
/// <returns>The return value</returns>
Source files should also maintain a header block tracking ownership and scope. Some source systems will also require dependency and versioning information in this block. This information is optional; the AniNIX deploys by rolling release, so the PKGBUILD installed into pacman or the Git source repo will have the version. Makefiles and PKGBUILDS will also track dependencies.
* File:
* Description:
* Package:
* Copyright:
* Author:
Avoid so-called "code-golfing" in source-code -- source should be easy to read, consistent, and verbose. Comments and other space-consuming elements can be stripped out in compilation for space-conscious projects.
## Safe Coding
All inputs should be sanitized to match the developer's expectations during operations. Unlimited reads are unacceptable -- bound the reads with a buffer to contain the memory pressure to a reasonable space and to prevent overflows.
All memory that is allocated should be deallocated before the process exits -- zeroing the memory segment is optional.
## Portability
Packages should be reasonably portable to other systems, but there is no expectation of unlimited portability. The network should generally test against ArchLinux -- portable projects should also strive to test against CentOS, Kali Linux, and Windows.
## External Standards
AniNIX projects should follow international standards to ease user interaction.
* [Standard keyboard shortcuts](
* [Android]( and [Google Web]( principles
* [Standard command-line options](
## Version Control
[Git](../Services/ is the version-control mechanism of choice. Packages being developed by Core admins should be added as a folder immediately under the foundation folder on checkout. Commit messages should be specific, and changes should be attempted in a development branch before being merged to master.
## Makefiles
All packages should include a Makefile with at least the following rules.
* compile: This should include all the steps necessary to compile the package. When this is done, the final executable should be able to run from the same directory as the Makefile.
* install: This should include all the steps necessary to installed the compiled files to the OS and set appropriate permissions. The compile step should be a dependency.
* uninstall: the reverse steps from install
* clean: This should remove any files built by compile.
* test: this should include the rules needed to run the package without installing.
* diff: this should compare local build with installed executables or scripts.
* reverse: this should pull the installed copies of scripts back to the source directory
* checkperm: make sure permissions are set.
Here's a skeleton Makefile to use.
pkgdirname != basename `git config remote.origin.url` | sed 's/.git$$//'
install: compile
test: compile
python3 -m pytest
@bash -c 'printf "This will reset the repository and lose all work. Confirm? [YES/no] " ; read answer; [ "$$answer" == "YES" ] && exit 0; exit 1'
cat .gitignore | xargs rm -Rf
Standalone packages like [CryptoWorkbench](/AniNIX/CryptoWorkbench) should include a PKGBUILD for the ArchLinux package manager.
## Language
Filenames should indicate language using standard extensions.
### bash
All OS scripts should be written in bash and include /bin/bash as a dependency.
* We don't use CSH/TCSH for [reasons](
* KSH has other problems.
* ZSH is being considered but presently has too low an adoption rate.
* Old-school SH is missing features.
[A style guide]( is available.
All Web sites should be written in HTML with minimal inline CSS -- a proper stylesheet should be included.
* For web pages expected to compile from server execution, PHP should be the chosen language. We have not been able to convert to Facebook's HHVM yet.
* For web pages expected to execute functions on the client browser, Javascript should be the chosen language and the Javascript should live in script file.
### C
Low-level applications should be written in C and require /usr/bin/gcc as a dependency. Re-useable functions should be written in linked libraries.
See man pages for documentation.
### C#
All large-scale applications should be written in C# and include the /usr/bin/mono and /usr/bin/mcs dependencies on compile. C# has been evaluated to be an industry-standard and portable language with a lesser exploit history, superior typing, and better resource management than Java.
[Documentation]( is available.
### Python3
QA and proof-of-concept code should be written in Python3 -- this is a standard among ethical hacking classes, and the programming python3/pdb interfaces make writing code easy.
[Documentation]( is available.
## Integration
* Services that do not need to run as a privileged user (notably Cerberus' main HIDS and Heartbeat) should deprivilege.
1. Hook for depriviliging
if ! getent passwd raven; then useradd -M -G git,ircd,api -d ${CONFDIR} raven; fi
Configuration and installed files should go to the following locations:
* Configuration should go into /usr/local/etc/PackageName/
* Direct executables should go into /usr/local/bin
* Indirect executables, such as compiled Mono projects, should go into /opt/aninix/PackageName/
* Logfiles should default to /var/log/PackageName/
## Code Reuse
All projects should seek to maximize code re-use. Any source code that could be generalized should go into [Uniglot](/AniNIX/Uniglot). This repository should be included a dependency in PKGBUILDS and checked by Makefiles.
## OS Integration
# Process
## Design
Projects should be designed with an established scope. This scope should be outlined in the package The appropriate language should be selected.
## Development
Initial development should be done to get the package in a working condition following the above requirements. The appropriate should be updated with development notes, dependencies, and a wishlist as development proceeds.
## Peer QA
If working with a group or any available peers, these peers should read through the code. Comments should be submitted in Gitea issues or pull requests -- quick conversation can be had on IRC until all is sorted. Until all peer comments are handled to the group's satisfaction, the process will hang.
## QA
All packages should be tested automatically and manually before being released. This should include unit tests for functionality, sanitizing inputs, stability, etc.
## Release
Release via Foundation and preferably also [Maat]( Web view is provided by AniNIX Foundation, and git cloning programs are available for all major distributions.
## Bug Reporting and Fixing
Bugs should be announced to the network staff via the IRC system. If the bug is geniune, an issue should be created and published to track the resolution. Bug fixes should trump new enhancements and specific fixes tracked as pull requests.

+ 21
- 0
Operation/ View File

@ -0,0 +1,21 @@
Here are some disclaimers end-users should be aware of.
# Privacy
The AniNIX retains minimal information about its users and will not share this information with anyone unless a warrant is issued by the government. We do not buy, sell, trade, or otherwise knowingly disclose personal information.
The AniNIX offers a best-effort at privacy to its end-users via the security practices, but this is no guarantee against government or corporate eavesdropping or monitoring. You are expected to use good judgement in what you post, contribute, and how you connect to the AniNIX. Please watch our [warrant canary](/AniNIX/WarrantCanary) for our best-effort against interference.
You can request a review of what information the AniNIX is storing on you in [IRC](ircs://
These tenants are in line with FFTF's [Security Pledge]( We encourage other sites to take it up.
# Copyright
The AniNIX name (serial number 87177883) and the [Core icon](/img/AniNIX.png) (serial number 87177887) are trademarked for the network as Classes 009 (computers), 038 (telecommunications), and 041 (education) trademarks for the name and logo. Please do not create or distribute new products using this name without prior written permission from the admins. They should only be used to credit this network for services rendered.
All content provided by the AniNIX is provided as-is with no guarantee or warranty. You should review all of a package's source files before installing for completeness and test in a testing VM appropriately.
All source code is publicly available and free to use -- we encourage everyone to use and modify it as desired. No copyright is placed on the content within this network and may be reproduced with credit. AniNIX source code is licensed under the [WTFPL]( -- only the AniNIX name and Core icon are not covered by this license.
Moreover, the AniNIX subscribes to the [Open Source Way]( -- anyone is welcome to generate a patch from AniNIX Foundation and submit it, or suggest ideas for Wiki improvements. These can be discussed with our community in [IRC](../Services/, and we will maintain an open commit history for both documentation and source code in the interest of transparency. Direct commits to AniNIX resources will require an [AniNIX Sora](../Services/ account and are subject to admin review, to prevent security risk to the rest of the community.
The AniNIX makes use of external source packages, such as MediaWiki, Emby, Tiny Tiny RSS, SSH, SSL, Lighttpd, etc. We make no claim to the source or authorship of these packages -- the AniNIX only offers a means to easily install these other packages. Any etymology of AniNIX services instantiating one of these packages that is not identical to the name of the package is for the ease of use for users administering thier own machines. The AniNIX will not obfuscate the package to hide its original authorship and will limit rebranding to the limits allowed by the package. See [our etymology notes](Design for more details.

+ 36
- 0
Operation/ View File

@ -0,0 +1,36 @@
To get started with the AniNIX stack, some familiarity with key concepts and technologies is encouraged.
# The AniNIX
Contributing users should be familiar with the following pages, though these are only a selection of [[:Category:Operation|our operational policies]].
* [[User Ethics]] for the integrity required of contributors and users
* [[Design Principles]] -- how to design projects
* [[Development Best Practices]] for safe project work
* [[QANs]] for requesting bug fixes, and [[Bug Bounties]] for ongoing research projects.
# Basic Applications
RSS (Really Simple Syndication) is a format of [ XML] files presented over Internet HTTP links. It requires a reader like [[AniNIX::Singularity]], but many sites will have an orange icon with a dot and three curves to indicate their RSS feed -- we have one on our [ Root] page.
IRC or Internet Relay Chat is our primary means of communication. IRC clients connect to an IRC server -- the server also hosts services, such as a channel registry (ChanServ) and nickname reservation (NickServ). Our [[IRC|IRC Wiki page]] has details on clients to connect to our IRC, as well as links to tutorials and a channel mode listing.
[[Wiki]] is a Web application for community-driven content. Wikipedia maintains a [ Getting Started] guide that's excellent reading for new users of the application.
Git through [[Foundation|AniNIX::Foundation]] is a complicated system. While known as the "stupid content tracker", there are books written on Git for its many features. New users should start with the [ git] man page and [ turorial].
The shell is the user's primary method of interacting with the OS -- this is done with a local or remote terminal emulator. TLDP has a very [ valuable guide] that new persons should read.
# Code Development
One of my favorite places for learning code development is [ Codingame], where students are given challenges to solve in their programming language of choice. Compiled code on the AniNIX generally is written in C# or C, and we'd recommend new users choose one of these if they want to contribute to new projects.
Users should also see [ W3Schools] for front-end development through the HTML/CSS/PHP/JavaScript stack for a [[WebServer]]. HTML is used to create the structure of the page, CSS the format of colors etc., PHP for server-side code, and Javascript for client-side code.
# The Operating System
To get started on the operating system, Google:
* [ Unix Basics]
* [ OSI Model] and IPv4 Routing
* [ ArchLinux General Recommendations]
# Learning about Security
* Users should try to go through [ Surveillance Self-defense] from the Electronic Frontier Foundation.
* Younger users can use [[:Category:Google|Google]]'s [ Be Internet Awesome].

+ 22
- 0
Operation/ View File

@ -0,0 +1,22 @@
The AniNIX is currently recruiting user involvement. As such, we're providing some example background here for new persons, broken down by background. Unless a technical means is provided, your best method of passing along your feedback is [ the IRC web client] or [[IRC|your own IRC client]]. Thank you to everyone who is contributing now!
# Everyone
Everyone should be willing to report issues with AniNIX software, documentation, or provided services -- connect to [[IRC|AniNIX::IRC]] to report these issues. Also sign into this service if you have an idea for new functionality, enhancements or other improvements the AniNIX should be considering!
# Administrative, Legal, or Business Staff
Administrative, legal, or business staff are especially encouraged to review the mission statement, design principles, and development best practices in [[:Category:Operation]]. This is the "business" and "legal" model on which the AniNIX runs and is currently vague in non-technical aspects.
# Artists
Graphic designers are encouraged to review [ the CSS stylesheet] and [[Special:NewFiles]] to help provide artistic direction. The current aim is a near-terminal like look with white-and-black icons surrounded by red hexagon. Review [[Design_Principles#Graphical_Design|our design principles for graphics]] to understand our motivations and aims. We welcome criticism and debate on these points.
# Educators
Educators will be exceptionally helpful in reviewing documentation. Anything on this Wiki could be reviewed for clarity and understanding. If concepts aren't adequately explained we need to know so that we can link to wider documentation or clarify.
Of particular interest to educators is [[:Category:Class]]. These are offerings from the AniNIX personnel are used in demos and for teaching, and we could always use review and comments on our methodology.
# Physical Activity Professionals
The [[Martial_Arts/Cardio|cardio]] page could always use new exercises or providers to follow.
# Technical Personnel
These folks are the core of the AniNIX contributing community. This wiki and [ the Foundation git repo] need review and comments. Submit [[QANs]] as you see the need.

+ 21
- 0
Operation/ View File

@ -0,0 +1,21 @@
These are cybersecurity incidents that the AniNIX has had to remedy due to some failure in our detection and prevention systems.
**Note**: We explicitly exclude routine incidents, such as IP's banned for SSH brute-force, files quarantined after virus scanning, and other routine housekeeping.
{{Incident Report|Attacker used a default password to pull down a Perl SMTP spambot and email list to spam fake Bank of America emails to users, attempting to phish them into clicking an xplotica link.
|title=January 2018 Spambot Detection
|date=11-29-2017 through 1-4-2018
|who=IRL identity unknown; last source IP (Netherlands residential)
|vector=Attacker used a default password to access a monitoring user account; spambot and target lists were downloaded from a GoDaddy webhost (now nonfunctional).
|detect=Detection was provided by the ISP and [ Abusix]. The Postfix service was shut down, and forensic analysis performed starting with the /var/spool/mail folder.
|impact=This has negatively impacted the AniNIX's reputation as an SMTP source -- we are following up with Abusix and Google to restore our reputation.
Current forensic investigation does not indicate a compromise to any AniNIX privileged information.
|actions=* Monitoring user password has been rotated on all systems.
* Automatic password rotation for service accounts added to the ConfigPackages and other repos in [[Foundation|AniNIX::Foundation]]
|plan=[[Cerberus|AniNIX::Cerberus]] needs updates to better monitor lastlog output and the sshd "Accepted" regex in journald. Postfix will be evaluated for appropriate MTA settings and restored to service later.
|logs=[file:///home/cxford/Desktop/Incident Response - 1-4-2018|Contact an admin for access.]}}

+ 67
- 0
Operation/ View File

@ -0,0 +1,67 @@
# CERT Grab-bag
CERT, or Computing Emergency Response Team, is an acronym for first-responders to cybersecurity and computing incidents.
The FBI maintains a cyber incident reporting service -- should the incident be of a sufficiently malicious nature, it should be reported to the authorities. See [ this whitepaper] for a breakdown of how to report.
CERT individuals should keep a copy of the following things at all times in a grab-bag:
* The above whitepaper for FBI contacts
* The [ AniNIX CERT Form]
* Copies of [[Category:Layouts|AniNIX layouts]]
* Scratch paper and thumb drives for evidentiary capture, along with chain of custody labels
<ref name=cisspcertskillset>[ Skillset via YouTube], accessed 1/4/18</ref>
# Incident vs. Disaster
An incident is an unplanned event affecting a service or agency, where a disaster reflects multiple services or agencies.<ref name="linkedinethicalintro">[ LinkedIn Intro to Ethical Hacking Course] by Lisa Bock</ref> A catastrophe is defined as one-step worse -- a destruction of AniNIX software and hardware necessitating rebuilding the same and likely a relocation of any operations and facilities.
# Required Follow-ups
: See TOGAF, COBIT, and ITIL standards for design methods for incident response. Also available is documentation from [ NIST] on how to formulate security plans.
If any disruption of service is caused, an [[RCAs|root-cause analysis (RCA)]] will be filed and users will be notified via [[Singularity|RSS]] and [[IRC]]. Alternatively, cybersecurity incidents will be documented as [[Incident Reports]] and deep-dives can be requested of AniNIX staff.
As the AniNIX learns of better configuration processes or usage methodology, this Wiki will be updated, which will automatically notify users subscribed to [[Special:RecentChanges]] via RSS.
Critical patches to AniNIX software and scripts should be added to [[Foundation|AniNIX::Foundation]] immediately with a proper commit message and notifications sent.
# Service-level incident response
The AniNIX maintains onsite [[Security_Layout#Backups|backups]] -- the affected service will be stopped, repaired from best-effort backups, and restarted. Unaffected services will not be disrupted.
# Software Disaster Recovery
Should a collective failure of software occur, all services will be stopped until the damage can be repaired. The AniNIX has onsite backups to this end.
## ISP events
In the event of an ISP event, a redundant method of providing access is available, but some services will be significantly limited or disabled to limit bandwidth usage. If ISP's are unavailable, admins should send the following:
:Hello, all,
:Internet access to the network is currently unavailable. To meet with an admin or check on the status, please visit the AniNIX Discord Channel. We will let you know when services are back.
::**Attach Discord static invite here**
:Thank you for your patience.
:AniNIX Admins
Admins should also keep a list of [[Sora|registered users]]' emails in a local location -- we recommend storing them in an [[Tricorder|AniNIX::Tricorder]] along with the last known good IP of the AniNIX.
# Hardware Incident Response
In the event of the failure of a redundant or unnecessary hardware component, an admin will:
* Review if the hardware needs to be removed. If not, it will be scheduled to be removed on the next downtime and review ends.
* Review if the hardware can be removed online. If so, the hardware will be removed as soon as safely possible; all reasonable effort will be made to keep maintenance off-hours.
* If none of the above criteria are met and time is available, a notice will be issued at the discovery of the problem and the hardware replaced or repaired off-hours.
* If there is no time, hardware will be replaced ASAP and service-providing components restarted. A notice and apology will be issued immediately thereafter.
Some redundant storage, for example, will be exchanged for failing components.
# Hardware Disaster Recovery
Should hardware critically fail, the AniNIX does not currently have a support agreement with any hardware provider -- overnight shipping and package tracking will be used to offer a best-effort at restoration of hardware. Users should be aware that some non-redundant, expensive hardware may halt service from the AniNIX for up to 48 hours. Should this happen, the AniNIX will re-evaluate the cost of the downtime against the cost of the hardware component.
If necessary, restoration from the safety-deposit backup will be utilized.
# Complete Disaster Recovery
In the event of a complete disaster, the first line of defense is a hard-drive stored in a safety deposit box with a complete backup of the [[Core|AniNIX::Core]] VM, which includes the source code to rebuild all other machines.
# Catastrophic Loss Or Attack
Should all else have been compromised, a large number of [[Aether|AniNIX::Aether]] nodes will allow rebuilding the system from source code, though there will be a massive loss of data. Some of this will be recoverable over time through file lists stored in the Aether packages, but other data will be lost. This is the last-ditch recovery method.
AniNIX admins maintain "bug-out" bags for massive environmental, political, or criminal disturbances, with copies of the Aether package on encrypted storage. They are trained to safely self-evacuate and rebuild the network in a safe location. This recovery method will take a long time to effect; users should watch the domain name for a return of some IRC daemon with which to use to communicate with admins. As soon as possible, admins will reach out to the userbase to announce when services will be restored, the reason for loss of service, and the extent of data loss.
# References

+ 6
- 0
Operation/ View File

@ -0,0 +1,6 @@
The mission statement of the AniNIX is simple:
1. Provide an example suite of services and serve a small userbase
1. Provide documentation and source code to allow anyone to replicate the system.
1. Contribute actively to the global community by involvement in the open-source community and charity work.

+ 68
- 0
Operation/ View File

@ -0,0 +1,68 @@
Provisioning is the process by which new users, services, and hosts are added to the network.
# Users
## Notes on Administrative and Daemon Users
These users should always be created as local users. Daemon users should be given /sbin/nologin or /bin/false as their login shell to prevent them from doing bad things -- systemd service files will appropriately set UID/GID on processes and shells aren't needed. These daemon users should always have local credentials to be immune to failures in remote services like [[Sora]]
* Many services, like IRC, TheRaven, Heartbeat, Sora, and others will use a daemon user at the OS level. These should be local passwords.
* At the OS, the admin will be the root user.
* SSH should have one deprivileged user that is local.
* IRC will have netadmins provisioned with local passwords; these netadmins will need a corresponding LDAP account only for IRCServices. Failure to log in with IRCServices is more acceptable than losing control of the daemon itself. The IRC modules can be unloaded and registration enabled if a local account is needed.
* Wiki can only be either LDAP-enabled or local; as we want unified credentials, loss of edit privileges for everyone is acceotable in the case that LDAP has failed.
* The following snippet can be used to lock down a specific wiki so only administrators (sysop) can edit.
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['*']['read'] = false;
$wgGroupPermissions['user']['read'] = false;
$wgGroupPermissions['user']['edit'] = false;
$wgGroupPermissions['sysop']['read'] = true;
$wgGroupPermissions['sysop']['edit'] = true;
## Groups
Most groups will be local to a given host; ssh-allow and git permissions will be local, for example.
LDAP should at least have an ldapuser group to act as the primary group for LDAP users.
## [[Sora]]
This project should be the central credential store for end-users on the AniNIX. Below are some notes to help with the setup.
### [[ShadowArch|OS]]
OS Accounts can be added with PAM/NSLCD authentication being enabled. See [ the Arch Wiki] for basic steps to set this up.
<b>Note:</b> Make sure [[SSH]] services are secured with a required group of ssh-allow before enabling this. See [ this link] for how to enable SSH access.
### [[IRC]]
All LDAP accounts are enabled for IRC NickServ access -- the LDAP uid will be the owning nickname. Group membership is allowed, but admins may drop nicks if another user is being created with the uid.
### [[Wiki]]
Wiki's have LDAP groups attached to them; those who will be editors on a given Wiki will be given the Wiki's group to log in with.
### [[Singularity]]
[[Category:TODO]] We are working to integrate the ttrss-ldap-auth-git package from the ArchLinux AUR.
## [[Yggdrasil]]
Yggdrasil currently relies on for account management. Users seeking access to this project will need a account for streaming access. File access can be given with an SFTP jailed account in Sora.
## Template User Notification
Hello, <user>,
You have a new set of credentials to the AniNIX! Your new user ID is <uid> and your initial password is <password>. Please [[SSH#Available_Clients|SSH]] to <uid> and change your password as soon as possible.
You now have access to all the [[:Category:Public_Service|public services]] of the AniNIX! Your credentials will work across the board. Please make sure to review [[:Category:Operation|our operational documentation]], particularly the User Ethics page, to understand what the AniNIX is and how to properly contribute.
If you have any questions, please stop by [ our IRC network] and sign in to NickServ. We'd be happy to talk with you anytime -- admins are indicated with the '@' or '~' sign in the #lobby channel. Again, welcome to the network!
# Services
Services should be provisioned from the [[Foundation]] -- this ensures that standards are followed and a best-attempt is made at security practices. Configure the service post-install to fit your need.
# Hosts
Hosts should be provisioned on an as-needed basis. A default AniNIX network includes the following:
* [[Shadowfeed]]
* [[Core]]
* [[DarkNet]]
* [[Bastion]]

+ 62
- 0
Operation/ View File

@ -0,0 +1,62 @@
This is a list of active quality-assurance notes (QANs) being worked on by AniNIX staff. Lists are sorted in order of priority.[[Category:Operation]][[Category:TODO]]
If you see a problem with our code, go to [ IRC] and send a memo to the #tech channel with what you've found. These will be parsed into the ideas list or assigned-QANs lists below by admins.
/ms send #tech <some note>
Alternatively, you can make a new page as a child of this one, using [[:Template:QAN]], and assign it to yourself to work on the project. These will appear in [[Category:Open QANs]] automatically for assignment.
# Ideas
## GDPR WebApp
Add /gdpr WebApp to Webserver to download user content. Look at Sharingan source.
## Foundation
* Finish PKGBUILDs
* Identify why CGIT is suppressing "Receiving objects" and other typical git-clone messages.
## Maat
* Look into either using [ GPG keyserver] or adding key fingerprint to [ PKGbuilds]
* Test Jenkins for E2E, but require Lighttpd auth before proxying app, like Sharingan.
## Sora
* ldap-adduser.bash should make use of 'sed -i "s/^term: /c\term: Newething/" file' to simplify
* Improve regexes to handle names like TJ or emails like
* Add MemberOf overlay
<!-- ==ExploitChecks
* Add BEAST, BIND, DirtyCOW, CVE-2016-4484, [ VENOM], [ StackGuard] -->
## CryptoWorkbench
* Update to include flag for suppressing color usage
* Update to improve helptext and error checking
* Consider ncurses for line recall and better capture of input. [ Curses Sharp] could do this. MARKING FOR FUTURE -->
## TheRaven
* Add suppress functionality for printing URL headers in conf.
* function to remind users/channel in X amount of time with a given message.
* r.translate function that acts on the last message and translates with Google translate.
* Add PostGres integration
* Implement karma system -- nospaces-- or (with spaces)-- should update key
* Implement counter system -- r.counter keyword sets timestamp, r.counterdiff keyword returns time delta.
* Update searches to allow returning top result if possible. Use searches script folder?
* Add random copypasta linker/quoter via URL
* Discord support
* Set attributtes on lists so that r.whitelist/r.blacklist/etc. can be generalized. Steal from CryptoWorkbench subscription model.
* Add IQ/word notification so that TheRaven can notify admins of useful conversations via Djinni
## CSS/.Xresources
Because CSS.
* Spacing between white borders is inconsistent.
* Standardize color requirements between CSS and .Xresource files.
* Consider []'s layout
* [[Template:Reference]] has odd spacing of icons in some browsers.
* [ Repo tables] need to include tabulating borders.
## SSH
Consider offering certificate authentication. [ See Facebook's example.]
## IRC
Write MailServ daemon to proxy emails to MemoServ and allow outbound?

+ 4
- 0
Operation/ View File

@ -0,0 +1,4 @@
These are some recent unplanned downtimes on the AniNIX, starting from 8/24/2016. We provide this list and root-cause analyses (RCA's) so that other networks can learn from them or suggest better practices for us to follow. Past years' RCA's are recorded in [[:Category:RCA Archive]].
{{DowntimeRCA|Charter ISP Outage|cause=ISP|length=4.5 hours|resolution=AniNIX off-site admin detected the outage at 2019-06-18 16:08 CDT. Phone calls to the ISP confirmed a physical outage. ISP acknowledged the outage and field techs were sent to repair the outage in the area. Service was restored at 20:16 CDT.|commits=Our Zapier/Freshping alerting service worked appropriately, and [[Sharingan|AniNIX::Sharingan]] sent out notifications as designed when service resumed. However, admin staff had run out of coffee -- coffee will be purchased to prevent further outages, as the tech stops working when the coffee runs out.}}

+ 5
- 0
Operation/ View File

@ -0,0 +1,5 @@
The AniNIX does want to be accessible to end-users, and social media is a global phenomenon that most people are aware of. However, we feel a general distrust for global social media -- self-hosting is optimal for retaining privacy and unifying credentials across services in a way that the AniNIX can protect its end-users.
Currently, our approach to social media is to identify platforms where we may have an interest in promoting the network, and to establish accounts in those areas with a single post linking back to the AniNIX equivalent. Please see [ our social index] for accounts and platforms on which we have a presence today.

+ 33
- 0
Operation/ View File

@ -0,0 +1,33 @@
TeamBlue acts as the defensive side of penetration testing and is the primary testground for [[Cerberus|AniNIX::Cerberus]] and all of [[:Category:Security|our security best-practices]].
|word=Blue teams are colored after police and friendly forces in penetration testing exercises.
|cap=1 core, 2GB RAM, 30GB hard-drive.
|host=TeamBlue should have the extras from Cerberus installed.
|conn=This box is expected to be attacked by TeamRed. We may add CFEngine for compliance and patching control, and use this machine to test patches before pushing them to Core, Bastion, DarkNet, and Team VM's.
Watch [ ArchLinux's Security application list] for tools specific to your use case.
# Security Essentials
Alien Vault recommends the following five security essentials for a "blue" security team.<ref name=avwebcastpci>[ How to Simplify PCI-DSS Compliance with Unified Security Management], accessed 9/7/2017</ref>
## Asset Discovery
This can be coordinated through a nmap script like below, or through [[Geth|AniNIX::Geth]]'s [ discovery].module.
## Vulnerability Assessment
We're looking at a couple candidates for this: [[Category:TODO]]
* lynis
* OpenSCAP
## Intrusion Detection
This functionality is provided by [[Cerberus|AniNIX::Cerberus]]. We're considering Tripwire and OSSEC to replace AIDE inside Cerberus.