# Jenkins penetration testing plan


**Points of consideration:**
* DDoS / DoS attack tests are explicitly prohibited by AWS policy so not able to directly test these.
* AWS mitigation guidelines [here](https://aws.amazon.com/answers/networking/aws-ddos-attack-mitigation/). We are mostly following these OK but haven't provided much for scaling of the infrastructure as that is unlikely to be a practical consideration.
* Main point of entry to Jenkins server (from outside world) is the HAproxy:
* This will have a URL
* URL will allow Google hacking - https://www.exploit-db.com/google-hacking-database - to check for known exploits.
* Also via Bastion - do we need to include this?
* As part of hardening implementation Stephen has already tested this. Probably worth confirming however.
* Chris reports only two ports on HAproxy should be open:
* 80
* 443
* SSH would use port 22 so if this is closed no SSH access will be possible.
* Can't SSH directly from proxy > master - only forwarding traffic on the above two ports.
* Port 80 is open on master to receive forwarded traffic.
* Use a tool such as nmap or zenmap to scan ports and confirm the above.
* Tools used to harden the proxy are Fail2Ban and Denyhosts. These are set up as default.
* For security purposes, set these up to suit our infrastructure and test that they are functioning correctly.
* Metasploit framework lists a number of Jenkins related exploits (in addition to the above site for Google hacking).
* These require a session connecting the attacking machine + the target machine.
* For purpose of testing the exploits themselves should be able to use an SSH session (TBC).
* Want to test the process of hacking a connection - this is probably lower priority though as the above testing should give us a level of confidence in the integrity of the infrastructure.
* There is a login to the proxy via the browser - GH username + password.
* MaidSafe QA group > admin
* MaidSafe dev group > run builds
* GH user outwith the above groups has read only access.
* Testing implications:
* Ensure user priveledges are as described above.
* Read only access user is able to see any sensitive info exposed in build logs.
* This won't work as default with the staging environment - will need to set up GH app to work with that.
* `Manage Jenkins` >> flags security warnings related to plugins.
* Look at each of these and determine how to resolve them.
* Track as issues on [QA shared drive](https://docs.google.com/spreadsheets/d/11B-SK_SMPeOWzzrM_SQWV_tRW6kCKbTDDpSAiCXjHsA/edit#gid=0) (not in public on GH!).

**Hardening tools**

Fail2Ban and Denyhosts appear to do fairly similar things on the server. They both block non whitelisted IPs and will block whitelisted machines that fail login, ie have invalid credentials, after a specified number of attempts. Fail2Ban offers more extended functionality in addition to this basic blocking.

https://www.techrepublic.com/article/how-to-block-ssh-attacks-on-linux-with-denyhosts/

https://blog.rapid7.com/2017/02/13/how-to-protect-ssh-and-apache-using-fail2ban-on-ubuntu-linux/

Testing scenarios will include (but not necessarily limited to):

*Update - it is undesirable for a whitelist approach as our company is geographically diverse and maintaining a whitelist would require a large effort. The following may be obsolete / not applicable - (TBC) 03/06.
After discussion with Chris, it has been decided that whitelisting IPs that can access the public subnet is not the approach we wish to take so these testing scenarios are not relevant at this moment in time. Leaving here for traceability of pen testing investigation.

| Scenario | Expected outcome |
| -------- | ---------------- |
| Attempt to connect from a non whitelisted IP with valid credentials | Blocked |
| Attempt to connect from a non whitelisted IP with invalid credentials | Blocked |
| Attempt to connect from a whitelisted IP with valid credentials | Able to connect |
| Attempt to connect from a whitelisted IP with invalid user credentials | Blocked |
| Attempt to connect from a whitelisted IP, correct username, incorrect password exceed attempts | Blocked
| Attempt to connect from a whitelisted IP with valid credentials > remove from whitelist| Able to connect > blocked |
| Attempt to connect from a non whitelisted IP with valid credentials > add to whitelist | Blocked > able to connect |
| Blocked and attempt to reconnect within bantime | Blocked|
|Blocekd and attempt to reconnect after bantime| Able to connect |

The login related tests detailed above are straighforward to ascertain pass / fail as it is indicated by success or failure at the point of logging in.

There are other functions guarded by Fail2Ban which can be tested in other scenarios. Proof of pass or fail would be (need to confirm this) by checking the relevant details in the logs.

| Scenario | Expected outcome|
| -------- | --------------- |
| remote host that is trying to request suspicious URLs | Blocked |
| remote host that is trying to search for scripts on the server | Blocked |
| remote host that is trying to request malicious bot | Blocked |

Fail2Ban has the ability to block DoS attacks but as noted, this is not suitable to test on our infrastructure hosted on AWS.

The HA Proxy can be accessed via SSH from the Bastion.