Yes, that's safe. There's nothing inherently insecure about having a hidden directory under /etc. The only reason rkhunter flags it is that it's uncommon for legitimate programs to do it, and when malware does it, it makes it less likely that you'd otherwise notice it.
It is safe in the sense that no, it will not make the system unstable, nor will it make it vulnerable from a security standpoint.
That said, as MechMK1 points out, the only reason to use hidden directories is so that it doesn't fill the user directories with fluff they don't care about. The /etc directory, on the other hand is meant to contain such fluff, ...
How safe is it to decompress untrusted files
Just looking at the CVE's for unzip you will find several possible code executions, modifying the permissions of existing files, overwriting arbitrary files outside the current directory....
The CVE list for unrar is shorter but includes also code execution.
What steps can be taken to minimize the threat ...
CloudFlare's Origin CA is working as intended. It's not trusted by browsers. It's only trusted by CloudFlare's servers. Its purpose is to secure communications between CloudFlare and your origin, not for general usage.
Reference: Introducing CloudFlare Origin CA
If you want a free, publicly trusted certificate, check out Let's Encrypt. (It's a legitimate ...
You've misread or mistranslated several things. Debian is not doing any data collection and it is downloading, not uploading.
Upgrades do not upload anything. The only data that's sent from your computer is the requests to download the updated list of package versions and the package files for the packages that you install or update. The mirror from which ...
It isn't. The threat model attempts to be resistant to external attack, but if all it takes is a malicious line in a build script on a package used on most systems (e.g. libc, x11, etc.) then all they need to do is compromise one build machine to gain near-universal control.
Attempting to protect against this is hard, and the only way to do it is to build ...
There are a number of things you can do:
Set up a private key that uses a key-stretching algorithm to protect brute-forcing the passphrase.
Configure AllowUsers in sshd so only named accounts can gain access
Use fail2ban or fwknop to further prevent outside attacks (remember that CVE-2008-0166 caused Debian users to generate only one of 32,767 possible keys)...
You can check it at /var/log/apt/history.log . There you'll find info about what packages were installed by users in the system. I think there is no info about the repository from they were installed. Anyway you can get that info with dates. I guess you know when exactly this happened.
Hope it helps.
It's unlikely that this is coming from avast secure DNS. More likely, you're running an open DNS resolver and an attacker with a botnet is trying to DDoS Avast SecureDNS by using open resolvers to direct traffic to Avast.
You description of local services which you only access through secure SSH forwarding is to vague to evaluate the security of your setup. What this setup is doing is restricting the access to the service to specific hosts, but nothing more. Use of 4096 bit encryption of the transport does not magically make the service itself secure, it protects only the ...
It is impossible to prove that an attacker has not compromised your server. It is always possible that an attacker accessed and installed malware that would be left behind.
The safest thing to do is to reinstall the OS. This is the only way you can truly know that it is an uncompromised OS. The password for the account should be changed so with public ...
As per the page you linked, there's a workaround.
Add the following to your policy.xml:
<policy domain="coder" rights="none" pattern="EPHEMERAL" />
<policy domain="coder" rights="none" pattern="HTTPS" />
<policy domain="coder" rights="none" pattern="MVG" />
<policy domain="coder" rights="none" pattern="MSL" />
I am assuming you are asking whether or not a partition UUID is sensitive information.
A UUID is a random value assigned to the partition of a drive. It is used to reference the drive without needing to know its current location (for example, /dev/sdc3). All knowing a UUID allows someone to do is to reference the partition by that UUID instead of a path. ...
The issue with SHA-1 is not an issue unless you are trying to generate two pieces of data who's SHA-1 collide. This is a lot different than generating one SHA-1 that collides with an existing SHA-1 which is what you would have to do to compromise sourceforge or github. This is a statistical difference that is best described with the birthday attack (https:/...
Someone with a debugger (like gdb, or anything else that can use the Linux Kernel's tracing capabilities and can utilize binaries) will have an easy time figuring out how to circumvent your copy protection.
You'd have to encrypt your binary (that's possible), and use some machine-specific secret (e.g. the CPU ID, TPM chip data) to decrypt it. Problem: you ...
From the post and ensuing dialogue:
The machine is a Debian wheezy / 7.0 that aparently has not seen updates for around two years.
There are logs lacking, that indicate the attackers cleaned up traces of their activity.
The OP complains of a divergent behaviour, which corroborate the last hypothesis. [ and the compromised page ]
As for the length of time ...
I did not analyse your script. However, it looks complex.
Why don't you use ARPtables? It's like IPtables, but for ARP.
Block ARP traffic from all machines (default: DENY)
arptables -P INPUT DROP
Allow router (fixed ARP)
arptables -A INPUT --source-mac d8:d7:21:22:5a:f4 -j ACCEPT
This way you will only exchange ARP packets with your router.
You have several ways to sandbox Firefox (or any similar application), depending on your exact requirements.
From the lighter to the heavier solution, you mainly have:
Firejail is a software precisely designed to easily sandbox other applications while keeping them on the same root filesystem. It relies on standard Linux features (namespaces and seccomp-...
Host Intrusion Detection Systems (HIDS) can offer this feature : File integrity checking.
I don't try it personnaly but according to the documentation AIDE can do this.
The idea is to create hash values of the files you want to verify they don't change then compare them regularly with new calculated values.
Is there a way to secure the server again without the need of re-installing the OS?
If the device really was compromised the answer is: no
And of cause there is no way you can be a 100% sure that nobody accessed your system in this 24 hours but being sure is just the highest possible kind of probability and we can talk about probability.
When we asume ...
Here is a reference for you: https://imagetragick.com
According to that page, you should verify magic bytes for the file you are processing, and you should use a policy file to disable the vulnerable ImageMagick coders.
The site provides a sample global policy. However it is not one size fits all. You can use it as a starting point.
The SSL warnings should go away if you turn on Cloudflare's reverse proxy ("orange-cloud" the DNS record that points to your Debian VPS). You will be presented Cloudflare's browser-trusted Edge certificate when you request your URL.
For fully encrypted end-to-end connection, use the "Full (strict)" SSL setting in Cloudflare's Crypto tab. This way ...
If so, are they due to host architecture ...
From the talk: "times three, because there are three combinations between endianness and bitness".
From the Debian wiki (archived here): (text reformatted by me)
The broken version of OpenSSL was being seeded only by process ID.
Due to differences between endianness and sizeof(long), the output ...
This is because a stable release of Debian must stick with the feature version of the time when it turns stable.
Debian team clearly states it in their Q&A:
2.2 Are there package upgrades in `stable'?
No new functionality is added to the stable release. Once a Debian version is released and tagged `stable' it will only get security updates. That ...
The only way to make "sure" data cannot be regenerated is to use the writing "random data to entire disk" method. The LUKS header is just a "road map" to the data's encryption, loss of it makes it harder but not impossible to reconstitute. All encryption should be equal to the threat level one experiences on a certain machine.
As lack of information next time plizz include kernel version, docker version and if the client application connects with root user.
Possible exploits that they used:
compromised database client the application so check that too for vulnerabilities
as docker containers share kernel with the host and other containers check kernel version for possible ...
An "ESTABLISHED" connection seen in the output of a netstat command reffers only to the TCP connection. If the port was accepting connections from any remote IP, anybody could stablish a TCP session, where the SSH daemon would ask for login and password, but it does not mean a SSH session is stablished.
You could easily try it yourself: login to your ...