69
This is not a sign of a problem for your server. There's an important detail here, which is:
104.27.182.86 is not your server. That IP belongs to cloudflare.
Cloudflare provides a large number of services to websites and sits in between the public internet and a server. Someone who uses Cloudflare doesn't point their DNS to their own server - they point ...
43
In general, you're correct you'll need the permission of the hosting company where you are scanning services deployed on their infrastructure. This is partially so that their Intrusion Detection Systems are aware that it's an authorised scan.
Both AWS and Azure have policies detailing the process and what's acceptable to test. The AWS one is here and the ...
37
Your threat model is focused on external parties breaking in. But the threats are broader than that.
Low-level hardware backups, VM snapshots, and disposed hardware can all contain data. And because these things tend to be seen to have lower risks, they are often mishandled. So, it's not a "Mission Impossible" style of threat that is likely. It's ...
35
The answer depends on your risk appetite. Restricting access to the SSH port to only known IP addresses reduces the attack surface significantly. Whatever issue might arise (private key leaks, 0-day in SSH, etc.), it can only be exploited by an attacker coming from those specific IP addresses. Otherwise the attacker can access the port from anywhere, which ...
32
This is perfectly normal. There is a big shortage of IPv4 addresses. In fact, we should have run out of them a long time ago. But since so much infrastructure is based on IPv4, it keeps getting "extended" in many ways. One of them, which has actually been around for a very long time, is to host multiple domains on a single server with a single IP address.
A ...
31
The ssh key would be distributed to a small set of people.
No, don't do that. Never share private keys. Have your folks generate key pairs on their own and collect their public keys. Take reasonable measures to ensure the pubkeys actually come from the right people.
Or if you don't mind the hassle, you can try a unified authentication scheme instead for ...
17
This is a subdomain takeover.
They typically happen in one of 2 ways:
You have an A record pointing to an IP address that no longer exists and an attacker can gain control of the IP address in question
You have a CNAME record pointing to a domain that no longer exists, and the attacker can register the domain.
The reasons can vary depending on the ...
16
An AWS Account ID can be shared, when required.
Like the documentation says, the main thing anyone can use your AWS Account Number for is to construct ARN's. For example, if I had an AWS Account which held an AWS Lambda function, and someone on another account, who I had explicitly granted permission to, wanted to manipulate it, they would use by account ...
12
The Access Key ID is used for identifying the access key in logs, configuration, etc. It could in some environments be considered sensitive data if you're looking to not release who accesses which systems and when, but it is not secret.
11
I found the solution to removing minerd. I was lucky enough to find the actual script that was used to infect my server. All I had to do was remove the elements placed by this script -
On monkeyoto's suggestion, I blocked all communication with the mining pool server - iptables -A INPUT -s xmr.crypto-pool.fr -j DROP and iptables -A OUTPUT -d xmr.crypto-pool....
9
Spectre is far harder to use than Meltdown. In a cloud hosting situation, an attacker needs to know:
What software the target is using
Where in memory that software is
Where in memory the target data is
The behavior of the host CPU's branch predictor
The behavior of the host CPU's speculative execution system
and possibly some other things I'm forgetting
...
9
While the AWS Access Key ID is like a username (and the Secret Access Key is like a password), the Access Key ID is also designed to be shared and AWS does this explicitly with the AWS Presigned Object URL feature as mentioned by John Hanley in a previous comment. This is an expanded response.
AWS Presigned Object URLs are shareable links designed to be ...
8
If your server resides in EC2, you can use IAM to create a role for that server and allow it access to KMS without needing to have the AWS access keys on the server.
http://docs.aws.amazon.com/kms/latest/developerguide/control-access.html
7
tl;dr Auditors
Many data security audits require data to be encrypted at rest. Often the threat model is an old hard drive ending up on eBay or picked out of the dump. If the data is unencrypted on these drives and they are not properly handled/destroyed there could definitely be data loss. There is also the classic "truck backing up into the datacenter" ...
7
Your first goal is (if you don't want to reinstall) is to determine how it managed to get there in the first place. If the attacker was crafty, they'd of run "timestomp" to modify the dates of binaries. You minimizing SSH does little if you're running a vulnerable version of Wordpress, or Joomla, or something different. For example, there was a Nagios ...
7
You should also check with your ISP. Depending on government regulations and their own operating policies, they could be required to block your pentest actions if detected, or cancel your service completely. They may even be required to report you to law enforcement agencies.
7
You are asking yourselves the right questions but asking us the wrong one.
Security controls, like AV, are meant to address threats in order to reduce the impact to an acceptable level. You have identified the threats and the likely impact of those threats. Great! Now you need to see if signature-based AV addresses those threats and reduces impact to an ...
7
Knowing an AWS account ID doesn't expose you to any attack in itself, but it can make it easier for an attacker to obtaining other compromising information.
Rhino Security Labs demonstrate a potential compromise vector via misconfigured IAM roles in a blog post here:
AWS account IDs uniquely identify every AWS account and are more
sensitive than you ...
6
From the documentation [0][1], we see that you prove to AWS that you know the Secret Access Key using HMAC, not using Digital Signatures. This means that when verifying the authentication, AWS must be able to generate the exact Secret Access Key for your Access Key ID.
Thus, their promise to never show you the Secret Access Key again is a matter of policy, ...
6
Indeed you're right, anyone with access to the server can get plain-text key.
Fundamentally your application needs to be able to get the plain-text key -- and hence any attack that fully compromises the application is also going to be able to get the plain-text key. But that's not what KMS is for.
KMS is for Key Management, and specifically the management, ...
6
First, a word of caution: AWS requires that you inform them of any security related test you plan on running to their infrastructure [link].
Second, Kali is not a vulnerable operating system, it is an operating system that comes with pre-installed tools so you can perform security tests on other machines.
And third, an AWS EC2 is already a virtual machine, ...
6
I would not run antivirus on my servers, for a couple reasons:
They are massive pieces of software
The whole idea of a server is to execute one task, and only one, in the fastest way possible. There are some accessory tasks that you need to run, but the idea is the same. AV engines slows down your service.
They usually run with root permissions
Your ...
6
Looks like you just found out how a Load Balancer inside a CDN with SNI works
You can also check others hosts (SANs) behind this particular CDN with OpenSSL, like so:
echo | openssl s_client -showcerts -servername arturofm.com -connect arturofm.com:443 2>/dev/null | openssl x509 -inform pem -noout -text
...or you can use your browser's certificate ...
6
It seems that it's not possible obtain a certificate from Lets Encrypt for a public IP address, without a domain name. See https://community.letsencrypt.org/t/certificate-for-public-ip-without-domain-name/6082.
Notwithstanding, are you sure you really want to ask users of your API to access it by its public IP? If you ever need to move your API to a ...
5
The problem is that the minerd is probably the payload of some (other) malware, so you can't really tell what else has been compromised on the system. Possibly there isn't anything else resident on the system, and you are just getting re-infected each time you kill the miner.
Alternatively there is some management/dropper process which has opened a back-...
5
Regarding the general managment of private/public keys, there are already other answered questions here on SE: What is the best practice: separate ssh-key per host and user VS one ssh-key for all hosts? and What's the common pragmatic strategy for managing key pairs?
Regarding AWS specific details: you can and should create your own key pairs outside of AWS ...
5
The preferred way to go is to generate a presigned POST request (your backend server asks for it with your own admin credentials).
Then from client-side you upload using this pre-signed POST.
It's effectively a way to have temporary credentials, but much more easy & secure to deploy as it can be restricted to the exact file you need to have uploaded.
...
5
First, it is perfectly normal for content delivery networks to have such certificates. And given the IP address this looks like Amazon AWS, possible their CloudFront service which serves as a TLS termination point and load balancer which then forwards the traffic to the appropriate system. This is actually typical behavior which you will also see at ...
5
The first point to observe is that if you click one of the above addresses you shouldn't be able to open it. They all point (clearly in the case of Azure) to a link-local IP address. These are reserved addresses in the space 169.254.0.0/16 that are not forwarded by routers, and crucially are only accessible from a given instance.
The second point to note ...
5
tl/dr: As long as the bucket is not publicly accessible (i.e. you need access keys to read/write), then don't worry about the name. It
isn't private because your employees probably know it and
hackers/penetration testers routinely perform brute-force searches for
bucket names. Also, asking "What if someone figures out how to hack
buckets?" is ...
Only top voted, non community-wiki answers of a minimum length are eligible
