FAQs

What are the recommended system requirements?

We've had trouble with t2.micro instances, so at the very least, more than 1GB RAM, 1vCPU, etc. 4GB RAM might be overkill but so far it seems pretty reliable for most cases. For particularly large environments, we've increased this amount by quite a lot.

How do I remotely access the web interface?

By default, awspx is only accessible from your local adapter. The preferred way to configure remote access is to setup an SSH tunnel post-installation; however, if this is not viable, you can also modify the INSTALL script to bind to an interface other than your local adapter (not recommended unless you are operating on a trusted network). For example, you can replace 127.0.0.1 with 0.0.0.0 to expose awspx on all interfaces.

How do I debug CLI errors?

The awspx CLI forwards all commands to the awspx docker container. To enter this container's context, run: docker exec -it awspx bash. From here, you can install supporting packages (e.g. awscli, vim, etc) using apt and approach the problem as you would under usual circumstances. A good starting point would probably be to try and recreate the issue without the additional complexity added by the CLI. E.g. to test the validity of your credentials, you could run aws sts get-caller-identity.

Why doesn't sudo awspx ingest --env work?

By default, sudo will not preserve environment variables. This means environment variables set in a user context, such as credentials, will be unavailable to the CLI once the sudo has actually taken place. The CLI will subsequently pass along empty credential values and AWS authentication will fail.

To ensure these values are not discarded by sudo, you can use its --preserve-env option:

sudo --preserve-env=AWS_ACCESS_KEY_ID,AWS_SESSION_TOKEN,AWS_SECURITY_TOKEN awspx ingest --env

How long does the ingestor take to run?

Unfortunately, there isn't a good answer to this question: it depends on the size of the account and the resources in it. Certain services, such as S3, are known to be particularly time-consuming (as discussed here), whereas others are relatively quick (e.g. IAM). That being said, for an account with a few hundred resources, ingestion should take minutes or hours rather than days (see below for guidance on how to speed ingestion up).

How can I speed ingestion up?

The short answer is: skip anything that's not interesting, or relevant. If you're only interested in users, groups, roles, instance profiles, and policies, then running awspx ingest --services IAM would speed things up significantly. If you're only interested in public buckets, then awspx ingest --services S3 --only-types AWS::S3::Bucket would be the way to go.

Try and be as specific as you can afford to be without sacrificing potentially useful information. For more options, see Ingestion Options.

Why does ingesting S3 take so long?

S3 buckets can comprise of many, many objects — for which, one or more requests must be made. This can take a long time. If there is a particular bucket (logs for example) that's hindering ingestion progress, you can skip it, ignore S3 Objects altogether, or exclude S3 from the list of ingested services.

I've loaded a ZIP, why are there no attacks?

ZIPs are created by the ingestor prior to populating the graph. Since computing attacks involves a graph based search, this information is not present in the ZIPs themselves. To include attacks, you must run awspx attacks after loading a ZIP.

Why do attacks include false positives?

Attacks are computing using a graph-based search that presently only considers Allow actions. This means it's possible there are policies denying the very actions giving rise to an attack. See below for further details on Deny actions.

Why do attacks not consider Deny actions?

The short answer is because this is difficult and we haven't got around to it yet. The longer answer is that Deny actions give rise to privilege escalation as well (i.e. detaching a policy enforcing restrictions). Pruning this information prematurely eliminates the possibility of identifying these attacks later. Right now, we've opted to define attacks as a possibility rather than a certainty and leave verifying the veracity of an attack as an exercise to the user.