Tag Info

New answers tagged

4

Allowing a less trusted user to run apt-get update is ok. They worst they can do is consume a lot of bandwidth and fill up some disk space, and they have plenty of other means to do this unless you've taken stringent measures to prevent this. Allowing a user to run apt-get upgrade is likely to give them root access. Some packages query the user and might ...


0

Your script will have to be able to access the password. You can't use a hash of the password: if you did, the hash would be the password, since that would mean anyone with the hash could log in. You should put the password in a separate file, and read it from your script. Take care to reproduce the password exactly (for example, don't use echo -e "$PASS" ...


2

You can set up OpenSSH so that a particular account can only run one command (the command sent by the client is ignored). In /etc/ssh/sshd_config, add lines like: Match User anonymous ForceCommand /usr/bin/telnet localhost 34843 PasswordAuthentication yes PermitEmptyPasswords yes AllowAgentForwarding no AllowTcpForwarding no PermitTTY yes ...


3

A iptables rule like this works fine *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [1:156] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp --dport 587 -j ACCEPT -A INPUT -j REJECT --reject-with ...


2

If you're not comfortable working with the iptables commands you could use UFW instead. UFW stands for Uncomplicated Firewall and is a way esaier tool to use than iptables. Install ufw on your Raspbery Pi with: sudo apt-get install ufw After you've installed ufw you can setup the defaults with: sudo ufw default deny incoming && sudo ufw default ...


0

Is possible to make a telnet secure using those solutions A)A ssh tunnel,is absurd(why use tunnel when you can use ssh?) but works ssh -L 23:localhost:23 -N -f your host Of course close the port 23 with firewall and let open the 22 or ssh personal port to forbid direct telnet access B)A tls or ssl(i prefer TLS) stunnel,is very easy to do,on server you ...


0

The simplest way of stopping the traffic is (assuming VPC is being used) by adding it to the VPC Network ACL of that instance and denying all traffic from that IP Address. One thing to remember is the deny rule number should be less than the first rule number.


3

The good old arpwatch is still useful. Other than that, it might be a good idea to capture all network traffic for a few days and analyse it.


0

To expand upon @Gilles answer. Some sites I've encountered, won't save passwords because the user and password fields are not enclosed in a form. I've created this userscript to handle such cases: https://github.com/JavierParra/userscripts/blob/master/forceRememberPassword.user.js


1

As already stated, Puppy uses a different security model (or different paradigm, if you prefer) and must be judged experientially, in the real world. My experiences can be summed up as follow: Debian: hacked, with apps phoning home. Slackware: hacked. Arch: never stayed stable long enough to be hacked. Windows XP: I uninstall the ethernet driver after it ...


0

They are not risky(except for finger) but it depend if can reach from outside(internet) or from local net,in the first case they are risky,but depend if you must use service associated or not. My rule are A service is necessary / used? Y=OK N=Simply shutdown it and turn off on boot Is possible to upgrade to secure service(imaps instead of imap)? Y=do it ...


2

Run netstat -pan --tcp --udp (Linux-specific syntax) on each server to find out which programs are listening to which ports, and disable those you don't need. Don't leave them running just is case, any open port is a potential risk.


3

You should use the same CA and make sure it's secured (as anyone compromising it would be able to issue certificates for it and perform a MITM attack). You might consider putting a machine offline and using it for this purpose only. As long as it's for internal use only, a self-signed cert will work fine. Remember that you'll have to install the CA root ...


0

Your question scares me. Generally speaking you don't create a CA for VPN services. You request a CA sign a CSR (Certificate Signing Request) in order to perform a repudiation for the TLS protocol which your trying to implement. I believe what your really asking is about a x.509 certificate, or specifically 'Should I create a separate x.509 certificate for ...


0

I must first mention that I am absolutely no specialist in security. For the python part, It seems like wrapping mlock into python is not difficult using ctypes. From the limits and permissions section of the man for mlock, it seems that a regular user can lock a limited amount of memory. Running uname -a on my system gives me max locked memory (kbytes, ...


3

On Linux use mlock http://linux.die.net/man/2/mlock mlock() and mlockall() respectively lock part or all of the calling process's virtual address space into RAM, preventing that memory from being paged to the swap area. The man page has more details.


2

There is an incredible amount of files that one can modify to "install a backdoor" on the system (editing /etc/group is the easiest, but there are lots of more stealthy way to achieve it). It is also possible to disable this noexec protection by editing /etc/sudoers file! I wouldn't rely on NOEXEC to make "sudo $editor" secure. it is not secure. DO use ...


0

In short, Sudo allows privilege escalation, while a user's groups allow access to things owned by the group.


2

D-Bus isn't using the magic cookie file here; it's passing credentials over the UNIX domain socket (SCM_CREDENTIALS). The magic cookie file is only one of several D-Bus authentication mechanisms. D-Bus implements a SASL-compliant interface (see RFC4422) to support a wide range of authentication mechanisms. One of these mechanisms is called "EXTERNAL" ...


1

One thing to be aware, is that STIG locks down /tmp with noexec. If you already spent some time on the box, it's possible that you won't be able to execute the files out of that folder. Try another location for download/install. Also, run your installer as SUDO


0

The problem isn't 'what could happen' as much as what couldn't happen. I mean, vi is quite a powerful tool, and using it as a privileged user gives many potential avenues of attack and exploit. And that's why you shouldn't do it - because you're playing 'block the mousehole' in a big old house. Anything interactive is 'risky'. Avenues of attack: Shell ...


0

I was running into the same issue on my Ubuntu box, here's what I did to get rid of it. Go install the libjansson 2.7 library. You can find it here. Run these commands to recompile with the new libjansson library. ./configure <whatever flags you had before> --with-libjansson libraries=/path/to/lib/dir --with-libjansson-includes=/path/to/include/dir ...


8

Can the "foouser" escape to root prompt? Presumably foouser can now open any system binary and "edit" it into something else completely, leaving whatever kind of security hole foouser can dream up. This has particular potential if you do it to a setuid binary, such as passwd, because it means a non-root user could use it do privileged things it was not ...



Top 50 recent answers are included