In the user interface, there is a menu on the left-hand side. We will be walking through each option under the "Administration" topic as well as some other features:
+
The "Error Viewer" page is an important feature in Assemblyline in terms of service management and development. The errors that you see here are for services only, so you won't see any errors taking place in core components on this page.
+You can see the distribution of errors over a given time range, you can filter for all errors from a specific service by using a Lucene query in the filter bar or by clicking on a service column in the "Service Error Distribution" graph, and you can do the same for a specific error type via the filter bar or the "Error Type Distribution" graph.
+The buttons located on the right of the filter bar can apply pre-defined queries such as unhandled exceptions, canceled tasks, and maximum depth, level, or retries errors. +When you select an error card, a side-drawer appears with the details for that error:
+
By the looks of this error message, the NetRep service had difficulty analyzing the related file to the point where the service timed out. All Assemblyline services retry two times on service timeouts, after which a non-recoverable failure is raised with the phrase "Task Pre-empted". A service developer can look at this error and try to reproduce it locally in their development environment, or a service administrator can raise it to the service owners for them to debug.
+
Assemblyline does not look at file names or file extensions to determine the file type of a file. Instead, it uses file class analysis to assign an Assemblyline file type to each file that it sees, so that this file can be routed to the specific service that is tailored for that file type. File identification is one of the most important features of Assemblyline since the entire analysis of a file relies on the type that it is identified as. The main file in charge of identification can be found here.
+Assemblyline's file class analysis can be broken into a few distinct aspects:
+ +An example of where file identification lives in Assemblyline is on the "File Details" page:
+
You can see that Assemblyline's file type is present as the "Type": document/office/onenote. The MIME type is application/octect-stream and the Magic label is a custom value custom: document/office/onenote. Custom Magic labels will be explained later.
In most cases, a combination of Magic and MIME is enough to produce an identification for a file. We use a subset of Magic labels and MIME types that are high-confidence and label them as "trusted", which you can see in the "TRUSTED MIMES" and "MAGIC PATTERNS" tabs.
+In the "TRUSTED MIMES" view, you can see the MIME types that are high-confidence and are mapped directly to the Assemblyline file type:
+
Trusted Magic labels are a little trickier, so we use high-confidence regular expressions to map labels to Assemblyline file types, as seen in the "MAGIC PATTERNS" view:
+
On top of this, we use custom Magic rules to apply labels to a file, as seen in the "LIBMAGIC" tab. This is where that custom: document/office/onenote label came from for the OneNote file mentioned above.
This is all fine and dandy, but some files do not have obvious metadata or headers where Magic labels and MIME types can be applied, like scripts. This is where the Yara rules come into play.
+
These Yara rules are designed to look for high-confidence pieces of code that are language-specific to determine the file type of the script.
+The best part about all these tabs on the "File Identification" page is that they are all customizable! If you see a file that is being identified incorrectly, you can easily add either a custom Magic label, a trusted MIME type, a regular expression for Magic labels, or a Yara rule.
+You can find the service review interface by clicking the Administration topic then choose Service Review subtopic.
+
This is a page where you can compare different versions of a service and how it behaved in terms of the number of results processed, the average score, the average number of extracted and supplementary files, etc.
+Here is an example of comparing different versions of the APIVector service:
+
You can find the site map interface by clicking the Administration topic then choose the Site Map subtopic.
+
This page is useful for seeing how the URL endpoints map to Python client functions, the method types of these functions, and the RBAC roles required to use them.
+
We have made it through the Administration subtopics, now let's look at over useful features when managing Assemblyline.
+Previously, we talked about workflows on the Alerts page, which could be applied a single time on all alerts currently in the system. The "Workflows" page is where you can create workflows that are persistent and will run on all alerts currently in the system as well as all new alerts that come in.
+
Now let's look at one last feature that is incredibly useful for an administrator, the Dashboard page.
+
This is the ultimate visualization of what is going on with the Assemblyline system. To the point where there is so much information, we must hide it behind cute buttons with tooltips. It is overwhelming at first, but once you know what to look for, using this page is crucial to Assemblyline administration.
+This page can be separated into two main sections: Core and Services cards.
+
Core cards represent core components described in Design and Architecture and Service cards represent services. Let's start by looking at the Ingestion component card.
+
Here are those cute buttons that I was talking about. The small box with a Q in it has a tooltip if you hover your mouse over it which explains what the value next to it represents:
+
You can hover over the other buttons to discover what everything means.
+For Service cards, the following graphic describes what is going on for each service:
+
The following are useful pages to manage and troubleshoot your Assemblyline deployment.
+Assemblyline's heuristic management interface lets you:
+The main difference between heuristics and signatures in Assemblyline is that heuristics are created by service writers, while signatures are written by trusted sources outside of Assemblyline such as CAPE, Suricata, Yara, and Sigma.
+
In this view, you can see the names of the heuristics, how often they have been seen, when they were last seen, and their classifications. By selecting one of these cards, you are brought to a detailed view of the heuristic:
+
Something interesting on this page, if you scroll down, is the "Statistics" section:
+
This graph allows you to visualize when certain files with the same features come into the system, which is useful in campaign attribution and monitoring.
+ + + + + + + + + + + + + +Assemblyline's service management interface lets you:
+You can find the service management interface by clicking the Administration topic then choose Services subtopic.
+
The first page you will be taken to when loading the service management interface will list all the services of the system.
+
This page is important so let's talk about everything, starting with the buttons on the top right of the page:
+
These buttons perform the following:
+You can add a service by clicking the circled green "(+)" sign in the top right corner. This will open a popup window with an empty textbox.
+
Simply paste the service_manifest.yml content of the service you which to add to the system then hit the "Add" button to add it to the system.
Tip
+If your manifest uses the following environment variables, they will be replaced by the right values by the service add API:
+If the system detected that there is a container with a newer version for your current deployment type (dev/stable). The service list will show an update button.
+Development on Assemblyline's supported services is rapid, and releases are cut quite frequently to keep up with malware development. Therefore, this button is helpful to action updating all services that have updates available.
+If you want to update a single service, a button will appear on that service card indicating that a newer version is available.
+
Hovering over the button will let you know which new service version is available and clicking the button will kick off the update for the service.
+The next button after that is "Install all services". If you scroll to the bottom of the page, you can see the services that you do not have installed but are available for installation. This button will install all the available services, if any, or you can install each one manually by scrolling down to the section and clicking on each card's button.
+
At the top right corner of the service management page, you will also find backup and restore buttons for creating and restoring backups for the services configurations.
+The backup button which looks like an "arrow pointing down" will create a yml with a filename of the following format: <FQDN>_service_backup.yml. The file will automatically be downloaded by your browser in your download directory.
Once you want to restore the backup in your system, you can simply click the restore button, "clock with a counter clockwise arrow", This will open a modal window with an empty textbox.
+
Simply paste the content of the backup created earlier in the text box and hit the "Restore" button to restore the services configurations to their backed-up values.
+Let's look at the columns and data in the service table:
+
The "Name" column contains the service name, and the "Version" column contains the version of the service that is running on Assemblyline.
+The "Category" column refers to a service's category, which is a way of grouping services. Available categories out-of-the-box are Antivirus, Dynamic Analysis, External, Extraction, Filtering, Internet Connected, Networking, and Static Analysis.
+The "Stage" column defines when a service should run. Possible stages are FILTER, EXTRACT, CORE, SECONDARY, POST and REVIEW. Stages are executed in the order defined in the list.
+"File types" contains a regular expression that dictates which Assemblyline file types a service will accept. If you want all files to be analyzed by a service, then specify the following regular expression .* as seen in the AVClass and Ancestry services above.
+The "External" column indicates if a service will send a file or related data somewhere outside of Assemblyline's infrastructure. An example of this is the VirusTotal service, which will send a file to the VirusTotal platform for analysis.
+The "Mode" column specifies if a service "runs in privileged mode" or "uses service server". This configuration is explained in the Assemblyline documentation here.
+The "Classification" column is the classification level that the service operates at and will label its results as such.
+Finally, the "Enabled" column indicates if the service is enabled or disabled. If a service is disabled, there will be zero pods running that service, and the service will not accept files.
+If you wish to modify or remove a service, you can simply click on that service from the service list which will bring you to the service detail page.
+The service detail page header contains two buttons shown all time that will let you:
+You will then have a tabbed interface which we will describe each tab bellow.
+The "General" tab will let you see general information about the service.
+
In this tab, you will be able to modify the service's:
+Tip
+You can refer to the service manifest documentation for more information about those different fields.
+The "Container" tab will show information about containers used by the service.
+
In this tab, you will be able to:
+The main service container is the container containing and running the service code. By clicking the main service container, you will be able to modify the parameters used to launch that container.
+
The list of parameters you will be able to modify is the following:
+Tip
+Check the docker config block from the service manifest documentation to know more about the different field you can modify in the docker container configuration.
+Dependency containers are containers use to support the main services in some ways. Either by offering an external place to store data (A database for example) or to perform service updates.
+A service can have multiple dependency containers and these containers are shared between the multiple instances of the service that can be loaded in the system i.e., there will only be one instance of each dependency container.
+By either click the "Add Dependency" button or clicking a dependency container, you will be able to either add or modify container dependencies of the current service.
+
The dependency container configuration window look almost the same and let you modify the same values as the main service container window. There is however an added parameter that you can configure to give the container persistent storage.
+Tip
+Check the persistent volume block from the service manifest documentation to know more about the different fields to configure to get persistent storage in a dependency container.
+The "Updates" tab shows information about how the service updates itself or its signatures.
+
Warning
+This tab is optional and will not be shown for all service. Only services that define and update config block in their service manifest will have that tab shown.
+In this tab, you will be able to view/modify the following information:
+Tip
+Checkout the Modifying sources documentation to know more about the different values you can change in the signature sources.
+Finally, the "Parameters" tab will let you view and customize the different parameters the service can take in.
+
Service parameters are split into two categories:
+User specified parameters are parameters that a user can modify for each specific submission it does in the system.
+They are often but not exclusively used for things like:
+Tip
+When these parameters are defined for a service, they will be shown in the submission options available for the user at submission time.
+Service variable are configuration parameters only shared between the service and your deployment. They are used to help the service configure itself to run well in your environment.
+Service variables are often but not exclusively things like:
+Some services may perform OCR analysis on images given/generated during analysis. Because of this, you're able to override/customize the default OCR terms from the service base using the ocr key in the config block of the service manifest.
Let's say, I want to use a custom set of terms for ransomware detection. Then I can set the following:
config:
+ ocr:
+ ransomware: ['bad1', 'bad2', ...]
+This will cause the service to only use the terms I've specified when looking for ransomware terms. This is still subject to the hit threshold defined in the service base.
Let's say, I want to use a custom set of terms for ransomware detection and I want to set the hit threshold to 1 instead of 2 (default). Then I can set the following:
config:
+ ocr:
+ ransomware:
+ terms: ['bad1', 'bad2', ...]
+ threshold: 1
+This will cause the service to only use the terms I've specified when looking for ransomware terms and is subject to the hit threshold I've defined.
Let's say, I want to add/remove a set of terms from the default set for ransomware detection. Then I can set the following:
config:
+ ocr:
+ ransomware:
+ include: ['bad1', 'bad2', ...]
+ exclude: ['bank account']
+This will cause the service to add the terms listed in include and remove the terms in exclude when looking for ransomware terms in OCR detection with the default set.
Assemblyline's signature management interface lets you:
+You can find the signature management interface by clicking Manage then the Signatures menu from the navigation bar.
+
Warning
+You cannot add new signatures to the system via this interface. Instead, Assemblyline has a source management interface which lets you add a variety of external sources to fetch signatures from. The updater of the different services takes care of loading the source URLs and the new signature(s) into the system. It will also sync existing signatures that have changed since the last import.
+The first page you will be taken to when loading the signature management interface will list all signatures that have been loaded into the system.
+
From this interface you can:
+Once you click on a signature, the detail view for that signature will be shown.
+
This page will show you the following information:
+On the top right, it will also show actions on the signature:
+Signature states are synced with the source they are coming from but the state in your Assemblyline deployment will supersede the state that the rule updater is trying to set. This means that if you disable a rule in your Assemblyline instance, it will remain disabled even if the source where that rule is from changes.
+There are three different signature states: Deployed, Noisy, and Disabled
+You can change the signatures by clicking the current signature state in the signature detail view. This will bring up the state-changing modal window which will let you pick a new state for the current rule.
+
You can access the source management interface by selecting "Update Sources" in the navigation menu.
+
The source management interface will list all services that support external sources and will show you the various sources currently configured in the system.
+
Here is where you can add sources for services that consume signatures or the safelist. In the above screenshot, you can see that the Sigma and Suricata services have configured sources where they ingest rules from.
+On this page, you can manually pull signatures from sources, add new sources, synchronize signatures on your system based on their source or view all signatures from a source.
+With the source management interface, you can add, modify, or delete any sources of any service with the following actions:
+Both options will bring you to an interface that looks like this:
+
The following sections are required to add/modify a signature source in Assemblyline:
+.yara or .yar files will be added as signatures.There are alternate ways that the system administrator can use to modify the signatures in the system:
+The updater can be configured through the service_manifest.yml, which is in the root directory of each service. If you edit the files before pasting them into the system to add that service, the correct signature source(s) will be set once the service is first loaded.
Suricata's updater
+You can find the Suricata updater configuration in its service_manifest.yml file.
+Its config block looks like this: +
...
+update_config:
+ generates_signatures: true
+ method: run
+ run_options:
+ allow_internet_access: true
+ command: ["python", "-m", "suricata_.suricata_updater"]
+ image: ${REGISTRY}cccs/assemblyline-service-suricata:$SERVICE_TAG
+ sources:
+ - name: emt
+ pattern: .*\.rules
+ uri: https://rules.emergingthreats.net/open/suricata/emerging.rules.tar.gz
+ update_interval_seconds: 21600 # Quarter-day (every 6 hours)
+...
+For more information about the update config block, you should check out the update config and update source sections of the service_manifest.yml documentation.
+
Tip
+The source update interface in this section is like the Source management page although there are a few added options for:
+Assemblyline can be configured to take a number of actions with completed submissions. This can be because a submission has been processed, or because an ingested submission is completed as a cache hit. The following actions can be taken:
+The configuration of actions is under "Post-process actions" of the administration navigation menu of Assemblyline. The actions configuration is a yaml formatted dictionary with arbitrary keys and values formatted as PostprocessingAction objects.
+Depending on the context where the submission is being tested for an action different terms are available for the Lucene query in the filter field. If only run_on_completed is set, the filter field may use any part of the Submission or Tagging objects where tag fields are prefixed with "tags.". When run_on_cache is set, irrespective of the value of run_on_completed, the search in filter may only use the following fields:
sidmax_scorefiles.*metadata.*params.*There are no sub-configuration fields of the raise_alert field, it is either true or false.
The resubmit action, when not null, must be a ResubmitOptions object. The additional_services field is a list of services to resubmit to in addition to the services given by a submission's params.services.resubmit parameter provided at submission or ingestion. The random_below parameter lets you further filter selected submissions by their max score, only randomly accepting submissions with score between 0 and the given value. The distribution is exponential with low scoring submissions being ignored more often.
The webhook action will call a webhook url with a body holding a json object with the fields:
is_cache: True if this action is triggered by a submission cache hit in ingester.score: The score of the submission.submission: A Submission object for processed submissions, or a different Submission object for cache hit actions.The webhook field must be a Webhook object.
By default Assemblyline comes with two actions defined:
+default_alerts:
+ enabled: true
+ filter: 'max_score: >=500'
+ raise_alert: true
+ resubmit: null
+ run_on_cache: true
+ run_on_completed: true
+ webhook: null
+default_resubmit:
+ enabled: true
+ filter: 'max_score: >=0'
+ raise_alert: false
+ resubmit:
+ additional_services: []
+ random_below: 500
+ run_on_cache: false
+ run_on_completed: true
+ webhook: null
+The action named default_alerts applies to all submissions (both cache and non-cache) where the score is 500 or more; both resubmit and webhook are disabled on this action, and raise_alert is active.
The action named default_resubmit applies on completion to submissions that are processed which scores zero or more. webhook and raise_alert are disabled, and resubmit is enabled with the following settings: additional_services is set to an empty list, so only the submission's own resubmit service list is used; random_below is set to 500, so submissions with a max_score between 0 and 500 will only be randomly resubmitted.
If upgrading the framework version (4.X → 4.Y, where X < Y) starting from Release 4.2.0.121+ or if performing another major change that affects Assemblyline, it's strongly recommended to pause the Ingester and Dispatcher and allow services to complete what's currently been tasked to them. This can be done by:
+/api/v4/system/status/<component>/ API and setting the variable active=falseThis ensures that if there are any breaking changes between the core and services during a major upgrade (ie. framework), the services will complete their tasks with what they were compatible with.
+This also gives an extended period to upgrade services to the compatible framework version before resuming processing.
+Danger
+Systems upgrading before Release 4.2.0.121 are strongly advised to upgrade to that release at a minimum and pause the Ingester/Dispatcher before proceeding to upgrade to later releases. Alternatively, you can stop submitting files to your system and let existing submissions complete and then perform the upgrade.
+At this stage, you're ready to upgrade the core system and you shouldn't have any services actively processing.
+Depending on the type of deployment (Kubernetes/Docker), the method of upgrading differs:
+SERVICE_VERSION in .env file if necessary, then:
+ docker-compose pull && docker-compose up -d
+release in values.yaml if necessary, then:
+ helm upgrade <deployment_name> /path/to/assemblyline-helm-chart/assemblyline -f /path/to/al_deployment/values.yaml -n <deployment_namespace>
+At this stage, your deployment has been successfully upgraded and your core components should be upgraded to a newer framework release.
+While the system is still paused, on the Services page you should find that all your services are in a disabled state as they're assumed to be incompatible with the rest of the system. If using public services, there should be advertisements to upgrade to the latest compatible version.
+If an advertisement doesn't appear for a service, it implies that there is no release tagged with a compatible version and requires a rebuild of the service using the more recent stable/dev tag.
+Once all services are upgraded, you can resume processing by toggling the Dispatcher/Ingester back to an active status or changing the state using the API and setting active=true
This implies the changes should have little to no impact on systems within the same framework version.
+Setting the system to a paused state before upgrading isn't required.
+When running Elasticsearch in a single node deployment, it will sometimes drop to a yellow status without a real issue.
+This typically occurs when an index has (because of templating or defaults), its number_of_replicas set to more than zero.
+Since the single node deployment can't create a redundant replica, this forces the node to a yellow status.
+The details on the settings around this can be a little different depending on which version of Elasticsearch you are using, but the following should be true for versions 7 and 8.
To check if this is the case for your Elasticsearch node, running the following command will reset the replicas to zero for all indices: +
curl -XPUT -k -u "${ELASTIC_USERNAME}:${ELASTIC_PASSWORD}" https://localhost:9200/_all/_settings -H 'Content-Type: application/json' -d '{"index" : {"number_of_replicas" : 0}}'
+https with http depending on your other settings. If your Elasticsearch doesn't return to a green status within a few minutes of running the command you may have other issues and should look for support.
+If the issue reoccurs often enough to be an issue for you, it should be preventable by ensuring no templates have a non-zero replica value set and creating an index template like the following to establish zero as the default value. +
{
+ "index_patterns" : ["*"],
+ "order" : 0
+ "settings" : {
+ "number_of_replicas" : "0"
+ }
+}
+Assemblyline includes a safelisting system that will let you ignore certain tags generated by services. Although safelisting is available to all users throughout the interface, you can specify more complex rules via the administration interface.
+You can find the system safelist interface by clicking the Administration topic then choose the System Safelist subtopic.
+
Once the safelist management interface is open you will be greeted with a YAML file in an editor. From here you can edit the YAML directly in the interface and hit the "Save changes" button to apply the changes to the system.
+
The system safelist is composed of two sections and each of those sections are composed of tag types with lists of values:
+match is where you list values for specific tag types that you want to safelist by using a direct string comparison (==)regex is where you list regular expressions for specific tag types that you want to safelist by using regular expression matching (.match())Example
+ match:
+ <tag-type>:
+ - <value>
+
+ regex:
+ <tag-type>:
+ - <regular expression>
+There is a safelist installed in the system by default which covers some basic cases. These are the tags that are safelisted by default:
+# Default tag_safelist.yml file
+#
+# The following tags are safelisted:
+# - Domains pointing to localhost
+# - Domains commonly found in XML files, certificates, and during dynamic analysis runs
+# - IPs in the private network IP space
+# - URIs pointing to IPs in the private network IP space
+# - URIs commonly found in XML files, certificates, and during dynamic analysis runs
+#
+# Note: - You can override the default tag_safelist.yml by putting an
+# updated version in /etc/assemblyline/tag_safelist.yml.
+# - If you want to add values to one of the following tag types,
+# you must copy the default values to the new file.
+# - You can nullify values by putting an empty object or an empty list
+# in your new file
+
+# Match section contains tag types where each tag type is
+# a list of values that should be safelisted by using a direct
+# string comparison.
+match:
+ # Direct match to dynamic domains
+ network.dynamic.domain:
+ - localhost
+ - android.googlesource.com
+ - play.google.com
+ - schemas.android.com
+ - xmlpull.org
+ - schemas.openxmlformats.org
+ - schemas.microsoft.com
+ - settings-win.data.microsoft.com
+ - vortex-win.data.microsoft.com
+ - wpad.reddog.microsoft.com
+ - verisign.com
+ - csc3-2010-crl.verisign.com
+ - csc3-2010-aia.verisign.com
+ - ocsp.verisign.com
+ - logo.verisign.com
+ - crl.verisign.com
+ - ctldl.windowsupdate.com
+ - ns.adobe.com
+ - www.w3.org
+ - purl.org
+ # Direct match to static domains
+ network.static.domain:
+ - localhost
+ - android.googlesource.com
+ - play.google.com
+ - schemas.android.com
+ - xmlpull.org
+ - schemas.openxmlformats.org
+ - schemas.microsoft.com
+ - settings-win.data.microsoft.com
+ - vortex-win.data.microsoft.com
+ - wpad.reddog.microsoft.com
+ - verisign.com
+ - csc3-2010-crl.verisign.com
+ - csc3-2010-aia.verisign.com
+ - ocsp.verisign.com
+ - logo.verisign.com
+ - crl.verisign.com
+ - ctldl.windowsupdate.com
+ - ns.adobe.com
+ - www.w3.org
+ - purl.org
+
+# Regex section contains tag types where each tag type is
+# a list of regular expressions to be run to safelist
+# the associated tags.
+regex:
+ # Regular expressions to safelist dynamic IPs (Private IPs)
+ # Note: Since IPs have already been validated, the regular expression is simpler
+ network.dynamic.ip:
+ - (?:127\.|10\.|192\.168|172\.1[6-9]\.|172\.2[0-9]\.|172\.3[01]\.).*
+ # Regular expression to safelist static IPs (Private IPs)
+ # Note: Since IPs have already been validated, the regular expression is simpler
+ network.static.ip:
+ - (?:127\.|10\.|192\.168|172\.1[6-9]\.|172\.2[0-9]\.|172\.3[01]\.).*
+ # Regular expression to safelist dynamic URIs
+ network.dynamic.uri:
+ - (?:ftp|http)s?://localhost(?:$|/.*)
+ - (?:ftp|http)s?://(?:(?:(?:10|127)(?:\.(?:[2](?:[0-5][0-5]|[01234][6-9])|[1][0-9][0-9]|[1-9][0-9]|[0-9])){3})|(?:172\.(?:1[6-9]|2[0-9]|3[0-1])(?:\.(?:2[0-4][0-9]|25[0-5]|[1][0-9][0-9]|[1-9][0-9]|[0-9])){2}|(?:192\.168(?:\.(?:25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9][0-9]|[0-9])){2})))(?:$|/.*)
+ - https?://schemas\.android\.com/apk/res(-auto|/android)
+ - https?://xmlpull\.org/v1/doc/features\.html(?:$|.*)
+ - https?://android\.googlesource\.com/toolchain/llvm-project
+ - https?://schemas\.microsoft\.com(?:$|/.*)
+ - https?://schemas\.openxmlformats\.org(?:$|/.*)
+ - https?://schemas\.openxmlformats\.org/officeDocument/2006/relationships/(image|attachedTemplate|header|footnotes|fontTable|customXml|endnotes|theme|settings|webSettings|glossaryDocument|numbering|footer|styles)
+ - https?://schemas\.microsoft\.com/office/word/2010/(wordml|wordprocessingCanvas|wordprocessingInk|wordprocessingGroup|wordprocessingDrawing)
+ - https?://schemas\.microsoft\.com/office/word/(2012|2006)/wordml
+ - https?://schemas\.microsoft\.com/office/word/2015/wordml/symex
+ - https?://schemas\.microsoft\.com/office/drawing/2014/chartex
+ - https?://schemas\.microsoft\.com/office/drawing/2015/9/8/chartex
+ - https?://schemas\.openxmlformats\.org/drawingml/2006/(main|wordprocessingDrawing)
+ - https?://schemas\.openxmlformats\.org/package/2006/relationships
+ - https?://schemas\.openxmlformats\.org/markup-compatibility/2006
+ - https?://schemas\.openxmlformats\.org/officeDocument/2006/(relationships|math)
+ - https?://schemas\.openxmlformats\.org/word/2010/wordprocessingShape
+ - https?://schemas\.openxmlformats\.org/wordprocessingml/2006/main
+ - https?://www\.verisign\.com/(rpa0|rpa|cps0)
+ - https?://wpad\.reddog\.microsoft\.com/wpad\.dat
+ - https?://ocsp\.verisign\.com
+ - https?://logo\.verisign\.com/vslogo\.gif04
+ - https?://crl\.verisign\.com/pca3-g5\.crl04
+ - https?://csc3-2010-crl\.verisign\.com/CSC3-2010\.crl0D
+ - https?://csc3-2010-aia\.verisign\.com/CSC3-2010\.cer0
+ - https?://ctldl\.windowsupdate\.com/.*
+ - https?://ns\.adobe\.com/photoshop/1\.0/
+ - https?://ns\.adobe\.com/xap/1\.0/
+ - https?://ns\.adobe\.com/xap/1\.0/mm/
+ - https?://ns\.adobe\.com/xap/1\.0/sType/ResourceEvent#
+ - https?://purl\.org/dc/elements/1\.1/
+ - https?://www\.w3\.org/1999/02/22-rdf-syntax-ns#
+ # Regular expression to safelist static URIs
+ network.static.uri:
+ - (?:ftp|http)s?://localhost(?:$|/.*)
+ - (?:ftp|http)s?://(?:(?:(?:10|127)(?:\.(?:[2](?:[0-5][0-5]|[01234][6-9])|[1][0-9][0-9]|[1-9][0-9]|[0-9])){3})|(?:172\.(?:1[6-9]|2[0-9]|3[0-1])(?:\.(?:2[0-4][0-9]|25[0-5]|[1][0-9][0-9]|[1-9][0-9]|[0-9])){2}|(?:192\.168(?:\.(?:25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9][0-9]|[0-9])){2})))(?:$|/.*)
+ - https?://schemas\.android\.com/apk/res(-auto|/android)
+ - https?://xmlpull\.org/v1/doc/features\.html(?:$|.*)
+ - https?://android\.googlesource\.com/toolchain/llvm-project
+ - https?://schemas\.microsoft\.com(?:$|/.*)
+ - https?://schemas\.openxmlformats\.org(?:$|/.*)
+ - https?://schemas\.openxmlformats\.org/officeDocument/2006/relationships/(image|attachedTemplate|header|footnotes|fontTable|customXml|endnotes|theme|settings|webSettings|glossaryDocument|numbering|footer|styles)
+ - https?://schemas\.microsoft\.com/office/word/2010/(wordml|wordprocessingCanvas|wordprocessingInk|wordprocessingGroup|wordprocessingDrawing)
+ - https?://schemas\.microsoft\.com/office/word/(2012|2006)/wordml
+ - https?://schemas\.microsoft\.com/office/word/2015/wordml/symex
+ - https?://schemas\.microsoft\.com/office/drawing/2014/chartex
+ - https?://schemas\.microsoft\.com/office/drawing/2015/9/8/chartex
+ - https?://schemas\.openxmlformats\.org/drawingml/2006/(main|wordprocessingDrawing)
+ - https?://schemas\.openxmlformats\.org/package/2006/relationships
+ - https?://schemas\.openxmlformats\.org/markup-compatibility/2006
+ - https?://schemas\.openxmlformats\.org/officeDocument/2006/(relationships|math)
+ - https?://schemas\.openxmlformats\.org/word/2010/wordprocessingShape
+ - https?://schemas\.openxmlformats\.org/wordprocessingml/2006/main
+ - https?://www\.verisign\.com/(rpa0|rpa|cps0)
+ - https?://wpad\.reddog\.microsoft\.com/wpad\.dat
+ - https?://ocsp\.verisign\.com
+ - https?://logo\.verisign\.com/vslogo\.gif04
+ - https?://crl\.verisign\.com/pca3-g5\.crl04
+ - https?://csc3-2010-crl\.verisign\.com/CSC3-2010\.crl0D
+ - https?://csc3-2010-aia\.verisign\.com/CSC3-2010\.cer0
+ - https?://ctldl\.windowsupdate\.com/.*
+ - https?://ns\.adobe\.com/photoshop/1\.0/
+ - https?://ns\.adobe\.com/xap/1\.0/
+ - https?://ns\.adobe\.com/xap/1\.0/mm/
+ - https?://ns\.adobe\.com/xap/1\.0/sType/ResourceEvent#
+ - https?://purl\.org/dc/elements/1\.1/
+ - https?://www\.w3\.org/1999/02/22-rdf-syntax-ns#
+Tip
+You can also find the default safelist in the code: tag_safelist.yml
+We will update this page with typical issues and solutions.
+You can post your question to our Discord community!
+Rules' hit count are not calculated live. There is an external process that calculates them daily for performance optimization.
+However, you can click on the rule itself and it does calculate the stats for that specific rule and updates it right away.
+Depending on the host mentioned in the error, ensure the deployment has access to the registry and its able to call the associated API.
+The following modifications will have to be made to your values.yaml:
+Let's say the domain of the registry is 'registry.local' and is hosted on port 443 +
configuration:
+services:
+ image_variables:
+ REGISTRY: "registry.local/"
+ allow_insecure_registry: true
+Let's say the local registry is hosted on port 32000 +
configuration:
+services:
+ image_variables:
+ REGISTRY: "localhost:32000/"
+ update_image_variables:
+ REGISTRY: "<HOST_IP>:32000/"
+ allow_insecure_registry: true
+To fix this issue add vm.overcommit_memory = 1 to /etc/sysctl.conf and then reboot or run the command sysctl vm.overcommit_memory=1 for this to take effect. This has to be performed on the host that's running the deployment.
By default, coreDNS is configured to the Google's Public DNS when trying to resolve external domains outside the cluster.
+You can configure it to use a different DNS via:
+sudo microk8s disable dns && sudo microk8s enabled dns:1.1.1.1
If this still poses an issue, refer to: Teleport - Troubleshooting Kubernetes Networking Issues
+The quickest way to monitor the status of your cluster is:
+kubectl get pods -n <assemblyline_namespace>
There are other tools such as k9s and OpenLens (an OSS fork of Lens) that allow you to monitor your cluster in a more user-friendly manner.
+Depending on the amount of activity you're receiving, you'll likely have to tweak the TargetUsage and ReqRam settings in your values.yaml for your particular deployment, either to cause it to scale faster or slower.
+Refer to: Kubernetes - Horizontal Pod Autoscaler for more information.
+It's possible the domain you're accessing the UI with doesn't match the setting configuration.ui.fqdn in your values.yaml.
+If your setting is set to 'localhost' but you're accessing the UI using '192.0.0.1.nip.io', there is no ingress path using '192.0.0.1.nip.io' as a base.
The simplest solution is to update your values.yaml to the appropriate FQDN and redeploy.
+Yes! This would involve creating a configmap containing your CA bundle and using coreVolumes, coreMounts, and coreEnv in your values.yaml to pass that information onto the core deployments.
An example of this configuration would be: +
coreEnv:
+ - name: REQUESTS_CA_BUNDLE
+ value: /usr/share/internal-ca
+coreMounts:
+ - name: internal-certs
+ mountPath: /usr/share/internal-ca
+coreVolumes:
+ - name: internal-certs
+ configMap:
+ name: internal-certs-config
+This error can typically happen if the Assemblyline ingress' class name doesn't match the class name of the ingress controller on the system. You can fix this by
+assigning the name of the class to ingressClassName in your values.yaml and re-deploy.
A service task can pre-empt for a number of reasons, such as:
+No! The sky's the limit (or more accurately), you're bound to the resources allocated on your cluster. +That being said, it's best practice to use what you need rather than what you want (especially if it's unwarranted).
+Yes and no. You can add a service with to the system with a lesser system version but it won't be enabled due to potential compatibility issues. +It's advised to rebuild the service and tag with the system version that you want to deploy on.
+This can stem from loading the service initially with production values which causes an issue with the service's service_delta. +It's best practice to add a service using the default manifest and update the values after it's been registered.
+If you have many services that require an update in values or if there's many values to update in a single service, consider using the Assemblyline client.
+Check the following on your service's updater instance:
+/tmp/updater/update_dir*/*/ of the updater container?Yes! Changes made involving our API trigger messaging events made to other components to Assemblyline causing the system to be more responsive. +In the case of services with updaters, they'll be notified immediately and the service will gather the new rules after a submissions has processed.
+Managing users effectively is a key aspect of maintaining the security and efficiency of Assemblyline. This guide provides you with step-by-step instructions to utilize the user management interface within Assemblyline to manage user accounts with ease.
+To begin managing user accounts in Assemblyline, follow these steps to access the user management interface:
+
The initial screen of the user management interface displays a list of all user accounts currently in the system.
+
Here are various actions you can perform from this interface:
+To view further details about a particular user, simply click on their username in the user list. This will open the user detail page, which provides comprehensive information about the user, including:
+
On the user detail page, you can take various administrative actions:
+To change a user's access to the system:
+To update a user's roles:
+To set or change usage quotas:
+To change a user's password:
+To permanently remove a user account from the system:
+To apply any changes to the user account, you'll need to select the Save changes button located at the bottom of the window.
+By following the detailed steps outlined in this guide, you can effectively manage user accounts within Assemblyline to ensure a secure and streamlined operation.
+ + + + + + + + + + + + + +