Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

move to t2.nano instances #6

Open
sprocketsecurity opened this issue Oct 30, 2018 · 9 comments
Open

move to t2.nano instances #6

sprocketsecurity opened this issue Oct 30, 2018 · 9 comments
Labels
enhancement New feature or request

Comments

@sprocketsecurity
Copy link
Contributor

currently proxycannon-ng uses t2.mirco instances. test change with t2.nano to reduce cost.

@sprocketsecurity sprocketsecurity added the enhancement New feature or request label Oct 30, 2018
@yourDomainAdmin
Copy link
Contributor

Hey @sprocketsecurity. So I've tested with t2.nano instances instead of t2.micro - everything seems perfect. Ran speedtest through the whole setup - download & upload speeds are 95mbit/sec and 103.75mbit/sec respectively (my home connection is 100/100).

Here is average utilization figures during the speedtest:

t2.nano instances:
CPU utilization: 0-1%
Memory utilization: 22-23% (out of 0.5GB on nano instance)

Control server:
CPU utilization: 1-30% (due to OpenVPN encryption)
Memory utilization: 26%

Should I do a PR for "main.tf"?

@sprocketsecurity
Copy link
Contributor Author

ya, if you confident all is good, please submit the PR! Thanks @UrfinJusse !

@yourDomainAdmin
Copy link
Contributor

I'll do some real-world testing today with password spraying OWA and VPN for two clients. If everything looks good, I'll submit PR tomorrow morning. Better be safe :)

@metaDNA
Copy link

metaDNA commented Nov 7, 2018

Careful with this one, it violates AWS' Pentesting Policy if you plan to use this infra for that purpose.

"Testing of m1.small, t1.micro or t2.nano EC2 instance types is not permitted. " Source

@yourDomainAdmin
Copy link
Contributor

Good point @metaDNA . I wonder if it's not allowed testing OF those smaller instances or FROM those smaller instances. Looking at their reasoning ("This is to prevent potential adverse performance impacts on resources that may be shared with other customers") it seems that they don't want you testing those instances. Gray area?

@metaDNA
Copy link

metaDNA commented Nov 7, 2018

@UrfinJusse Most def a gray area.. but that's where we live isn't it ?¿ To your point, I'm sure the boxes can handle it in either direction, it's likely just out of an abundance of caution.

My only thought was when filling out the AWS form, it may get auto-rejected if they see the nano boxes in there.

@yourDomainAdmin
Copy link
Contributor

Agree. I guess I can try to submit a form and see what happens. Worst case scenario - test with t2.micros. Price difference will be negligible for password spray purposes (1-2hr?).

@sprocketsecurity
Copy link
Contributor Author

If solely operating in AWS, I'm curious if we could ditch the instances altogether. re: #7

I don't know enough about AWS VPCs to understand if this is possible. I'd be curious to hear your thoughts.

@metaDNA
Copy link

metaDNA commented Nov 7, 2018

I think you still need to have an endpoint with an IP on it or ElasticIP. VPCs on their own do not hold IP addresses. Now that said, we could potentially look into adding multiple ENIs (Elastic Network Interfaces) to a single host and doing the loadb routing through that. For example: a c1.medium can have a total of 2 ENIs and 6 IPs associated with a single VM. That said, 6 t2.micros are about $50USD/mo and a c1.medium is ~$95/mo so I don't know that you save a whole lot cost wise, may just be easier to manage programmatically though that's TBD too. Source

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants