AniNIX/Wiki
3
0
Fork 0
Code Issues 9 Pull Requests 3 Releases Activity

Imperfect initial commit, but too far to go back

Browse Source
This commit is contained in:
DarkFeather
2020-01-02 05:22:16 -06:00
commit 06f37260ec
84 changed files with 2812 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

86
Operation/AniNIX::Wiki:Manual_of_Style.md Normal file
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">[http://assassinscreed.wikia.com/wiki/Assassin'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
<pre>
{|class="wikitable"
|-
| Cell 1 || Cell2
|-
|}
</pre>
## Transclusion
This will include an entire other page in yours.
<pre>{{:Wiki}}</pre>
## Links
Internal: <pre>[[Wiki]]</pre>
External: <pre>[https://aninix.net/root.php WebServer]</pre>
## Styling
<pre>
*Bold*
**Italic**
</pre>
## Images
<pre>
[[File:Image|thumb|250px|right|Some caption]]
</pre>
## Gallery
<pre>
<gallery>
Image:Example.jpg|Caption
Image:Example.jpg|Caption
</gallery>
</pre>
## If/then
<pre>{{#if:{{{add|}}}|==Additional Reference
{{{add}}}|}}</pre>
[[Category:Operation]]

66
Operation/Archive/RCAs_2016-2018.md Normal file
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
|resolution
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.
|commits
}}
{{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=[https://aninix.net/mediawiki/index.php?title=Forge2&type=revision&diff=722&oldid=712 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.
|commits
https://aninix.net/mediawiki/index.php?title=Forge2&type=revision&diff=767&oldid=722
}}
{{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.
|resolution
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.
|commits
* [https://aninix.net/mediawiki/index.php?title=Incident_Response&type=revision&diff=769&oldid=741 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=* [https://aninix.net/mediawiki/index.php?title=Forge2&curid=64&diff=984&oldid=932 Wiki for Forge2 notes]
* [https://aninix.net/mediawiki/index.php?title=Heartbeat&curid=83&diff=985&oldid=980 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
Operation/Bug_Bounties.md Normal file
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://aninix.net:6697).
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
Operation/Design_Principles.md Normal file
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/Yggdrasil.md) 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/Cerberus.md), virus scanning, and existing controls over remote access to the host.
[SSH](../Services/SSH.md) and [IRC](../Services/IRC.md) 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/Core.md) 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/WebServer.md) 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](https://en.wikipedia.org/wiki/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](http://www.jneurosci.org/content/33/32/13081.full) found that white and blue light were the most disruptive to the animal test subjects, while red light was the least. [A LensCrafters study](https://www.lenscrafters.com/lc-us/vision-guide/blue-light-computer-eye-strain?j=2179694&sfmc_sub=150010356&l=175_HTML&u=101219824&mid=6010051&jb=5345&cid=EC-2179694-5/14/2017&&smtrctid=150010356) 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
Operation/Design_Scope.md Normal file
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
Operation/Development_Best_Practices.md Normal file
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](http://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts)
* [Android](https://developer.android.com/guide/practices/ui_guidelines/index.html) and [Google Web](https://support.google.com/webmasters/answer/35769#1) principles
* [Standard command-line options](http://www.tldp.org/LDP/abs/html/standard-options.html)
## Version Control
[Git](../Services/Foundation.md) 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$$//'
compile:
install: compile
uninstall:
test: compile
python3 -m pytest
clean:
@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
diff:
reverse:
checkperm:
```
## PKGBUILD
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](http://www.grymoire.com/Unix/Csh.html#uh-0).
* 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](http://www.daveeddy.com/bash/) is available.
### HTML/CSS/PHP
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](https://docs.microsoft.com/en-us/dotnet/csharp/index) 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](https://docs.python.org/3.7/) 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 README.md. 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 README.md 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](https://maat.aninix.net). 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
Operation/Disclaimers.md Normal file
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://aninix.net:6697).
These tenants are in line with FFTF's [Security Pledge](https://www.securitypledge.com). 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](http://www.wtfpl.net/about/) -- only the AniNIX name and Core icon are not covered by this license.
Moreover, the AniNIX subscribes to the [Open Source Way](https://opensource.com/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/IRC.md), 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/Sora.md) 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 Principles.md#Etymology) for more details.

36
Operation/Getting_Started.md Normal file
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 [https://en.wikipedia.org/wiki/XML 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 [https://aninix.net/ 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 [https://en.wikipedia.org/wiki/Help:Getting_started 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 [https://linux.die.net/man/1/git git] man page and [https://linux.die.net/man/7/gittutorial 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 [http://tldp.org/LDP/Bash-Beginners-Guide/html/ valuable guide] that new persons should read.
# Code Development
One of my favorite places for learning code development is [https://www.codingame.com/start 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 [https://www.w3schools.com/ 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:
* [http://google.com/search?q=Unix+Basics Unix Basics]
* [http://google.com/search?q=OSI+Model OSI Model] and IPv4 Routing
* [https://wiki.archlinux.org/index.php/General_recommendations ArchLinux General Recommendations]
# Learning about Security
* Users should try to go through [https://ssd.eff.org/ Surveillance Self-defense] from the Electronic Frontier Foundation.
* Younger users can use [[:Category:Google|Google]]'s [https://beinternetawesome.withgoogle.com/en_us Be Internet Awesome].
[[Category:Operation]]

22
Operation/How_to_Get_Involved.md Normal file
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 [https://aninix.net/irc/ the IRC web client] or [[IRC|your own IRC client]]. Thank you to everyone who is contributing now!
[[Category:Operation]]
# 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 [https://aninix.net/style.css 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 [https://aninix.net/foundation the Foundation git repo] need review and comments. Submit [[QANs]] as you see the need.

21
Operation/Incident_Reports.md Normal file
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 196.52.32.4 (Netherlands residential)
|type=Spambot
|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 [https://www.abusix.com/ Abusix]. The Postfix service was shut down, and forensic analysis performed starting with the /var/spool/mail folder.
|assets=[[Core|AniNIX::Core]]
|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.]}}
[[Category:Operation]]

67
Operation/Incident_Response.md Normal file
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 [https://www.fbi.gov/file-repository/law-enforcement-cyber-incident-reporting.pdf/view 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 [https://aninix.net/mediawiki/index.php?title=Template:Incident_Report&printable=yes 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>[https://www.youtube.com/watch?v=PhROeWMPBqU 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">[https://www.linkedin.com/learning/introduction-to-ethical-hacking/information-security 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 [https://duckduckgo.com/?q=NIST+Creating+security+plans+for+federal+information+systems&ia=web 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 aninix.net 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
[[Category:Operation]]

6
Operation/Mission_Statement.md Normal file
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.
[[Category:Operation]]

68
Operation/Provisioning.md Normal file
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.
<pre>
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['*']['read'] = false;
$wgGroupPermissions['user']['read'] = false;
$wgGroupPermissions['user']['edit'] = false;
$wgGroupPermissions['sysop']['read'] = true;
$wgGroupPermissions['sysop']['edit'] = true;
</pre>
## 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 [https://wiki.archlinux.org/index.php/LDAP_authentication 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 [https://eng.ucmerced.edu/soe/computing/services/ssh-based-service/ldap-ssh-access 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 Plex.tv for account management. Users seeking access to this project will need a Plex.tv 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>@aninix.net 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 [https://aninix.net/irc 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]]
[[Category:Operation]]
[[Category:Security]]

62
Operation/QANs.md Normal file
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 [https://aninix.net/irc/ 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.
<pre>
/ms send #tech <some note>
</pre>
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 [https://wiki.archlinux.org/index.php/GnuPG GPG keyserver] or adding key fingerprint to [https://wiki.archlinux.org/index.php/PKGBUILD#validpgpkeys 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 blar@something.subdomains.jp
* Add MemberOf overlay
<!-- ==ExploitChecks
* Add BEAST, BIND, DirtyCOW, CVE-2016-4484, [http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3456 VENOM], [https://access.redhat.com/security/vulnerabilities/stackguard 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. [http://curses-sharp.sourceforge.net/API/ Curses Sharp] could do this. MARKING FOR FUTURE -->
## TheRaven
* Add suppress functionality for printing URL headers in conf.
* r.in 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 http://www.bash.org/?random
* 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 [https://exercism.io exercism.io]'s layout
* [[Template:Reference]] has odd spacing of icons in some browsers.
* [https://aninix.net/foundation/TheRaven Repo tables] need to include tabulating borders.
## SSH
Consider offering certificate authentication. [https://code.fb.com/security/scalable-and-secure-access-with-ssh/ See Facebook's example.]
## IRC
Write MailServ daemon to proxy emails to MemoServ and allow outbound?

4
Operation/RCAs.md Normal file
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]].
[[Category:Operation]]
{{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
Operation/Social_Media.md Normal file
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 [https://aninix.net/pages/social.php our social index] for accounts and platforms on which we have a presence today.
[[Category:Operation]]

33
Operation/TeamBlue.md Normal file
View File

@@ -0,0 +1,33 @@
{{Entity|TeamBlue|
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.
{{Reference|Cerberus}}{{Reference|VirusScan}}
|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.
{{Reference|Core}}{{Reference|Sora}}
|add
Watch [https://wiki.archlinux.org/index.php/List_of_applications/Security 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>[https://www.alienvault.com/forms/webcast-thank-you/how-to-simplify-pci-dss-compliance-with-unified-security-management 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 [https://home-assistant.io/components/discovery/ 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.
## Behaviorial Monitoring
We use [[Heartbeat|AniNIX::Heartbeat]] to set each system's baseline and audit logs for user behavior.
## Log Management
We're evaluating using [[AniNIX::Bastion]] as a rsyslog host.
## Encryption
### At rest
We use dmcrypt to encrypt files by default at the storage layer via [[ShadowArch|AniNIX::ShadowArch]]
### In motion
We use [[:Category:SSL|SSL]] for encrypting data in motion.
}}
# References
[[Category:Security]]

9
Operation/TeamGreen.md Normal file
View File

@@ -0,0 +1,9 @@
{{Entity|TeamGreen|
TeamGreen runs regular QA regressions and reports results on the [[Foundation|AniNIX::Foundation]] repositories.
|word=Similar to [[TeamRed]] and [[TeamBlue]], this box is named for ensuring the quality of AniNIX code.
|cap=1 core, 1GB memory, 30GB hard-drive.
|host=TeamGreen should host a set of Docker images generated from the ConfigPackages/TeamGreen repo. We are considering using Jenkins to monitor the repo and update regressions, but there are security concerns with that application. TeamGreen code should be written in Python3 using doctest, py.test, hypothesis, and Radon.
|conn
{{Reference|Foundation}}
|add
1. See [https://www.digitalocean.com/community/tutorials/docker-explained-using-dockerfiles-to-automate-building-of-images this article] on how to build Docker images for projects.}}

8
Operation/TeamRed.md Normal file
View File

@@ -0,0 +1,8 @@
{{Entity|TeamRed|
This host acts a penetration testing box.
|word=Most high-level organizations have adopted active penetration testing policies. Usually the offensive sector is known as a "red team" as opposed to the defensive "blue team".<ref name=cso>[http://www.csoonline.com/article/2122440/disaster-recovery/emergency-preparedness-red-team-versus-blue-team-how-to-run-an-effective-simulation.html CSO] accessed 6/21/17</ref>
|cap=1 core, 2GB RAM, 30GB drive
|host=No real services are hosted by this machine. It is an array of tools based on either [https://www.kali.org/ Kali Linux] or the [[ShadowArch]] -k flag. It may make extensive usefulness of the [https://aninix.net/foundation/ExploitChecks ExploitChecks] in AniNIX::Foundation.
|conn=This machine targets [[TeamBlue]].
|add=}}
[[Category:Security]]

42
Operation/User_Ethics.md Normal file
View File

@@ -0,0 +1,42 @@
AniNIX users should follow good ethical principles when using the network. AniNIX resources should be used in accordance with these principles -- activity outside the network is not ours to dictate.
# Our Mission Statement
{{:Mission Statement}}
# Open Source
> Main article on [https://opensource.com/open-source-way OpenSource.com]
Open-source means that are willing to provide access to as much information as possible, sharing our experience, work, and assets with the world. (We cannot disclose security tokens and other privileged information for our own self-preservation.) We intend for anyone to take the AniNIX model and inspect it, modify, or enhance it by looking at our documentation and source code. We believe this yields the benefits of control, training, security, and stability to our users, as the more people inspect something the fewer errors are likely to be present.
# The Hacker Ethic
> Main article on [https://en.wikipedia.org/wiki/Hacker_ethic Wikipedia]
When you give people the means to be creative for themselves and to share their work, they can create beautiful communities of industry and passion. With proper moderation against malice, the human collective evolves, and the AniNIX seeks to include this.
The AniNIX subscribes to the Hacker Ethic and should build itself to support the same. In order, these are the ideals development in the AniNIX should encourage:
* <b>World improvement</b>: The world is not a friendly place to your average person. Compute power can be leveraged to improving people's lives, not just in the pursuit of personal power or profit at the expense of others. Projects within the AniNIX should serve the betterment of the wider world in some fashion or at least some portion of the userbase. We do not use our resources to profiteer from others, particularly their lack of access.
* <b>Openness and sharing, particularly open-source</b>: We are world citizens, with equal human rights. Sharing, collaboration, and openness improve the lives of everyone and let us grow as a planet. AniNIX projects and source should be openly available; security keys and credentials may be obfuscated to protect the network.
* <b>Decentralization</b>: True democracy is the voice of the people -- the rule of the majority. Too much centralization results in an easy target that can be destroyed by those seeking their own power and profit and to silence opposition. When everyone in the masses has a voice that can't be silenced, they carry immense weight for revolutionizing and improving life.
* <b>Equal, free access to computing</b>: The Internet is the last bastion of human free speech and stream-of-consciousness, and open access for everyone gives everyone a voice. Computers allow free educational materials and community-building, and learning to use them promotes intellectualism and self-education. No one should be barred based on race, gender identity, gender expression, sexual orientation, ability, age, cultural identity, IQ, religion, socioeconomic status, etc. -- the sole grounds for blocking access is to prevent specific, malicious actions, such as identity theft, human trafficking, etc.
## AniNIX Application
* The AniNIX provides a number of [[Category:Charity|free-to-access offerings]] in the interest of giving back and we support a number of [https://aninix.net/pages/charity.php charitable organizations] to support the aim of world improvement.
* The Wiki and [[Foundation|AniNIX::Foundation]] offer all the documentation and code necessary to replicate AniNIX services.
* The Wiki and Foundation combination allow replication of the complete AniNIX suite, allowing for multiple instantiations and decentralized access.
* The AniNIX makes as many of its applications Web-accessible as possible to reduce the barrier to entry -- even a public library terminal should have sufficient resources. We also provide the [[ShadowArch]] installer and [[Holocron|AniNIX::Holocron]] project to give everyone access to their own secure computing environment for minimal cost.
# Good-faith Contributions
All contributions to the AniNIX should be done in good faith -- users will not be punished for bad work submitted in an honest fashion. However, in the interest of promoting good faith, they should also be respectful of criticism and advice on how to improve their work. The AniNIX seeks to improve steadily and welcomes debate and discussion.
If you have concerns or suggestions, please use the talk page of a topic to discuss them.
# Respect to Peers
Please respect your peers in all communication. The AniNIX administrators reserve the right to terminate services at any time to any user found to be disruptive or damaging to the network. We seek a collaborative, not elitist, environment, and all viewpoints should be welcome in a debate.
# Handling of Malware
The AniNIX, being security-minded, handles malware. Please make sure you only transfer malware in secured, inert formats to other users and clearly label it as such so that they know to analyze it.
The use of malware to attack, harm, or malign the network will not be tolerated. Ensure all testing is done in isolated networks with protected machines to prevent accidental assaults.
Be sure to read [https://www.law.cornell.edu/uscode/text/18/1030 18 US Code 1030] (thanks to Cornell for providing a copy), particularly section a5A, before distributing or publishing malware source.
[[Category:Operation]]