Skip to content

Instantly share code, notes, and snippets.

@EugeneLiang

EugeneLiang/gist:e0520472e2cf6970c57d9db8e259701b

Last active March 23, 2017 03:17
Show Gist options
  • Save EugeneLiang/e0520472e2cf6970c57d9db8e259701b to your computer and use it in GitHub Desktop.
Save EugeneLiang/e0520472e2cf6970c57d9db8e259701b to your computer and use it in GitHub Desktop.
Download ZIP
Thing to do for security (LB)
Raw
gistfile1.md

Assuming EC2 was hacked

Range of IP：61.20.0.0/16 This is a more serious situation, as the other machines on this VPC may be scanned and hence exposed.

Further assuming the hacker puts in a trojon horse, and LB refuses to pay up, the hacker might attack other machines since he has scanned for other machines.

How do we know if the above will happen? If your machines are using the same ssh public key to connect, there's a very good chance that other machines are also hacked.

Next, the production machines's port 22 is 0.0.0.0/0, this is EXTREMELY DANGEROUS.

Short term solution

短暫處理方式 Close all port 22 for all EC2 machines that you are using. If you really need to connect, only allow internal IP ( for instance people logged in to LB's internet connection ) to connect.

The following security groups are vulnerable

  • sg-03a4b867 ec2-laravel-prd1
  • sg-1dbd547a rds-loveboni-166-dev1
  • sg-27aff043 ec2-designbible-prd1
  • sg-37ac4250 ec2-loveboni-166-dev1
  • sg-40c64c27 eb-middleware-dev1
  • sg-51b25c36 ec2-express-dev1
  • sg-55a66732 ec2-laravel-dev1
  • sg-830f2ae7 ec2-loveboni-dev1
  • sg-8bcf6cec ec2-designbible-dev1
  • sg-93bb52f4 ec2-loveboni-prd1
  • sg-9653a4f1 ec2-loveboni-166-stg1
  • sg-b48120d3 ec2-express-stg1
  • sg-c2adb1a6 ec2-loveboni-166-prd1
  • sg-d3bc55b4 ec2-loveboni-adm-stg1
  • sg-f2948896 ec2-express-prd1
  • sg-f4f13a93 ec2-cakephp3-dev1

Solution for the above security group issues:

  • Use command line to scan all machines within the above IP range for trojans. If you are using Ubuntu, there are some open source packages to fix this.
  • Rebuild all EC2s under the current VPC. DO NOT use the hacked machinese to rebuild AMIs since it is already hacked.

Assuming DB was hacked

Solution

  • change all DB related passwords
  • set DB's security such that it only allows internal VPC to connect

Other suggestions

Suggestions for EC2

  • place services in private subet,, while web related services MUST only be accessed by ELB. If you need a springboard to connect, please use private P )
  • The springboard machine can be placed in public subnet, but ONLY is only accessible by internal internet connection ( as in LB's corporate internet connection )

Suggestion for VPC

  • create private subnet
  • create public subnet

Suggestions for Security group

  • in general we should avoid using 0.0.0.0/0 , unless we are SUPER sure that the particular service is external facing. Even if this is public facing service, we should config the security group on top of ELB, and not EC2.

Suggestions for AWS account

  • EVERYONE is to enable 2FA, else it's only a matter of time hacking will happen again.

Suggestions for Github account

  • EVERYONE is to enable 2FA
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment