New answers tagged

0

Let me make sure I understand the question properly: if you have write access to another user's .bashrc and/or .profile then you can plant any arbitrary code to be executed by them the next time they launch a shell / login, right? So why not add the following line to .bashrc / .profile cp /root/flag.txt /home/<your_user> or if you want to leave less ...


1

Assuming that you mean "can host X, which terminates the IPSec tunnel, apply iptables filters to the de-tunneled traffic?" then the answer is yes. Here's a Server Fault Q&A on this exact topic - With iptables, match packets arrived via IPSEC tunnel - which states You need to use the policy module, and specify the ipsec policy, to match this ...


1

In general, you wouldn't expose build data. However, in order to run commands such as rpm -qi you would need to have a shell account on the server. This implies a certain level of trust for your user. It would be possible to restrict the use of the rpm command to administrators (assuming it is not already the case), which implies an even higher level of ...


2

You can ro (read-only) mount removable drives. As to how you can set automount options is answered on another question.


0

Yes, this is possible, even with arp_filter set to 0. Server listening: # nc -nlvu -s 192.168.250.1 -p 123 listening on [192.168.250.1] 123 ... Connection from Client 1 - Client 1 is set to route all traffic via server, so it does not need any ARP response for eth1: # ncat -nvu 192.168.250.1 123 Ncat: Version 7.01 ( https://nmap.org/ncat ) Ncat: ...


2

With fwknop deployed, anyone using nmap to look for SSHD can't even tell that it is listening - it makes no difference if they want to run a password cracker against SSHD or even if they have a 0-day exploit. I have some notes here for using fwknop. I can also ssh into containers behind NAT with no port open externally.


1

I suppose a good question would be why do you even have SSH open to the WAN, anyway? ... As others have mentioned, administering via a private network is the Holy Grail. The best approximation (and the reason I even bother to answer here) for a WAN connection is an IP wrapper or firewall ruleset that only allows SSH from a particular IP address. One such ...


1

It is a bit like moving SSH to a different port. You just hide something (poorly) and that shouldn't be something to rely the security of a system on. It might throw off the attackers that really don't know what they are doing (and they will not get into ssh anyway if it is setup properly) but is useless otherwise.


7

You are basically correct. It is obfuscation. Obfuscation is not without value, but you should not rely on it. The first answer is correct, BTW, that it is good practice to host management services such as SSH on a separate network (i.e., not the internet).


39

Unless that IP address belongs to a dedicated management network which implements additional security, it is a waste of resources. Both IPs are, obviously, ending up on the same server. This means that, unless they come in through different networks (i.e. a management network that implements additional protection), there will be no difference locally ...


0

well i got it to work by following theses steps : You have first to install a compatible version of samdupm2 and bkhive (because I have tested the ones on the repositories and it doesn't work well) using this commands : curl http://http.us.debian.org/debian/pool/main/s/samdump2/samdump2_1.1.1-1.1_i386.deb > samdump2_1.1.1-1.1_i386.deb dpkg -i ...


8

Do as many mitigations as you can. Your goal is to force a wide variety of potential attackers to spend more effort, resources, computer time (and thus electric bill), and most especially "skilled" (rare or scarce, and thus valuable) person-hours. No one protection works against every threat. Not every threat can be protected against while still remaining ...


1

Here you go: Generete SSH keys + protect them with password Allow only specific user to login (AllowUsers) Allow from specific IP username@192.168.1.1 Change default port Create firewall rules and last thing install fail2ban.


0

You successfully blocked that specific ip, but let me tell you something you're gonna get thousands of such malicious computers trying to brute force your ssh in order to get into your box. Some tips: Switch to authentication via certificates than passwords Change default ssh port (this is quite helpful - default is 22) Some lower level tips: Disable ...


1

I'm going to qualify the below advice by pointing out that, obviously, securing computers from technical attacks is its own entire industry, and people spend their whole careers doing exactly that. There is no bottom to the rabbit hole of securing your machine. So the below advice obviously doesn't cover everything. But, in practical terms, if you follow it ...


2

I read some article about linux kernel having vulnerabilities The linux kernel is a huge piece of software. Here is a list of 1338 vulnerabilities that have been previously discovered and patched in the linux kernel. Can you be more specific? how should I prevent remote acces to my station and other things? The topic of hardening a linux system ...


2

Not just to keep an old thread alive but some people might have missed a important part of the long story behind this... It's been about an well known infamous and persistent bug when using /dev/urandom from Java versions 1.4 to versions 1.7. See the links below : http://bugs.java.com/view_bug.do?bug_id=6202721 ...


1

The general process of rooting a phone works by exploiting a vulnerability in the respective Android OS to conduct a privilege escalation which in turn makes you (a non-root user) root. You can then install modified firmware. This is, by definition, relying on security holes There is no guarantee that using the exploit on your phone to root it doesn't ...


2

I will confine my answers to Nexus phones. I have rooted my Nexus phone. I am sure that rooting will work on new Nexus phones. ( Samsung phones can also be rooted) Rooting does not rely on any particular security hole. The broad idea is to be able to execute commands as a root user (as like in the linux system). Rooting a phone in itself cannot be termed ...


3

A few things come to mind. Avoid storing things locally that should not be exposed. Data like sessions, cookies, passwords, account details, whatever. There have been numerous and various ways that data gets dug out of mobile apps and reused. As a rule of thumb, if it's data that is specific to that user (the user's session, the user's ID, the user's ...


3

The development platform has as close to nothing to do with the security of your app. It might, if your development machine is not properly secured or directly targeted. The number one rule you have to follow is to not implement your own crypto. Use well known and tested libraries.


1

Using either the Windows (host) firewall or the guest OS firewall to do that is not recommended. All VM tools already provide that kind of control. Have a look at the different types of networking available. You want a host-only network. By design that can only be used between the host and the VM, it is never accessible outside the host. I should also have ...


1

You really do want SELinux, or an alternative such as AppArmor, SMACK, or AKARI/TOMOYO. Take these examples from the book SELinux System Administration -- Consider the example of the shadow file again. A MAC system can be configured so that the file can only be read from and written to by particular processes. A user logged on as root cannot directly ...


1

Do not give the keys away from your owned and maintained hardware. If you don't have a root on your computer, user Smart Card (or Yubikey). As already said, nothing protects your keys (or data) from physical access and root user. Not even SELinux (root can do everything, if is unconfined!). Cryptography does the job only partially (encrypted keys can be ...


3

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 ...


2

Let's start with making sure we have a clear understanding of what 'brute forcing' is. A brute-force attack is when an adversary attempts to guess every single combination of characters, starting at one length, and increasing the length by one until the password is cracked. e.g. 1, 2, ... a, b, ... 11, 12, ... 1a, 1b, ... aa, ab, ... etc. Depending on the ...


3

You could try the exploit directly on any given host and determine your own level-of risk. My initial thought is that even on Android, many kernels have SMEP/SMAP enabled, thus preventing the canned exploit code above. One would need to rewrite the exploit with ROP or use a similar SMEP/SMAP bypass technique. (Update 2016/Feb/06 -- Collin R. Mulliner ...


1

Since most everybody talks mostly of disadvantages (which are real), I'd like to share several advantages here: you really want to avoid automated attacks. Unless your are a high-profile user, vast majority of attacks will not be targeted to you, but automated best effort attacks which would just try default ports. Avoiding them helps in several ways: ...


3

To answer your questions in order: You can see all authorized keys by running the following script with root privileges. #!/bin/bash for X in $(cut -f6 -d ':' /etc/passwd |sort |uniq); do if [ -s "${X}/.ssh/authorized_keys" ]; then echo "### ${X}: " cat "${X}/.ssh/authorized_keys" echo "" fi done Any valid user may create ...


5

Stateful firewalls are mindful of incoming connections that are part of a circuit that was previously established. iptables can certainly do this. The short answer is that you need a firewall rule that blocks all new incoming connections, but allows established incoming connections.


1

In my experience this sysctl -w net.ipv4.conf.all.send_redirects=0 will not work properly on some systems what works for me is echo 0 | tee /proc/sys/net/ipv4/conf/*/send_redirects


0

Strictly speaking, both are insecure compared to USB boot etc. However, every layer of security drops the probability of generic attacks succeeding. Using a VM with incoming network connections disabled should be immune to the vast majority of malware on the host. You could disconnect the USB keyboard from the host and attach it exclusively to the VM to ...


0

Setting up a Linux VM dedicated for Internet Banking is a good idea, but if the VM is used for other purposes have a browser dedicated for Internet Banking only where everything that is not required is turned off (i.e. scripts, flash, etc...). As mentioned by Jonathan a VPN is a good idea too.


4

If you want to do home banking on a public network I would always recommend using a VPN. This should protect you against MITM attacks and other funny things that can happen on a public network. There is nothing wrong with using a Windows tablet to connect to your bank. Be sure to install a decent antivirus/malware and install your Windows security updates. ...


1

If you have very sensitive data, you should keep it somewhere, where there's no direct internet access. In that case, Linux on a virtual machine will do the job(but still, it's not 100% safe in this case). If you need an internet access, I suggest installing plugins like HTTPS Everywhere and uBlock/uMatrix/NoScript in your web browser, to keep the ...


3

A virtual machine can't protect the guest OS from the host (without specialized hardware features to support it). You will not gain any security from running Linux in a VM if Windows gets infected, and if your VM gets infected then that's still the environment you intended to use for security sensitive things that's new insecure. Have you tried live USB ...


2

Is it okay to use the well-known password of 20 bytes of 0s as the owner/SRK passwords? tpm-luks has the options to use those well-known passwords to perform these operations so that they can be non-interactive. Since the system is locked down, I am assuming no one will be able to exploit this? If you leave the owner and password as default or ...


3

There is always some risk and in this case if the system isn't hardened internally it might be trivial for a "user in the know" or a bad actor to access other users data in a matter of minutes if not seconds. In this case you still have all the local privilege escalation issues and local security hardening issues which could allow local users to become root ...



Top 50 recent answers are included