DebianThis forum is for the discussion of Debian Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
looks to be the cron:
# that none of the other crontabs do.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# m h dom mon dow user command
17 * * * * root cd / && run-parts --report /etc/cron.hourly
#
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily
)
#
47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly
)
#
52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthl
y )
The user nobody less unprivileged, so it's used for some cron jobs like updatedb for slocate to run as root. Check /etc/cron.* and /etc/updatedb.conf and other files activated by cron.
Not a hacker.
The user nobody less unprivileged, so it's used for some cron jobs like updatedb for slocate to run as root. Check /etc/cron.* and /etc/updatedb.conf and other files activated by cron.
Not a hacker.
Ouf
thanks. Nothing more secured than Debian Stable. (I hope)
IMO debian isn't very secure by default, but has good documentation for getting there. You just need to choose which measures to apply to your setup. Too tight security just makes an ordinary users life hard when you can't even apt-get install anything with /tmp mounted as noexec for instance, used to do that 'cause it's an easy way to stop simple script kiddie attacs. http://www.debian.org/doc/manuals/se...-debian-howto/
Oh and btw, you can set up apt to use another dir than /tmp. (someone would have pointed that out in five minutes )
IMO debian isn't very secure by default, but has good documentation for getting there. You just need to choose which measures to apply to your setup. Too tight security just makes an ordinary users life hard when you can't even apt-get install anything with /tmp mounted as noexec for instance, used to do that 'cause it's an easy way to stop simple script kiddie attacs. http://www.debian.org/doc/manuals/se...-debian-howto/
Oh and btw, you can set up apt to use another dir than /tmp. (someone would have pointed that out in five minutes )
According the the Debian security mailing list earlier this year, mounting /tmp with the noexec flag doesn't work.
Here's a snippet from Luis Mondesi from the security list:
Quote:
> the /tmp was mounted as rw,noexec,nosuid, so it cannot run.
nope. See below.
> but not the /dev/shm, so the hacked script downloaded to /dev/shm, and run
> from there.
>
> what kind applications are using /dev/shm? I googled around,seem not find
> much information.
> right now I mount i as rw,noexec,nosuid.
A lot of stuff does. /dev/shm is recommended by LSB if I'm not
mistaken. I know a few apps who use this (including my own).
Well done tracking this script kiddie.
This is a very stupid hack.
By the way, noexec doesn't buy you anything here. perl bb.txt
should've worked no matter if /tmp is exec or not. The way I see it
they both worked (/tmp and /dev/shm). And besides, noexec can't even
stop executables anyway. That's the stupidest of flags for mount:
I didn't follow it into any great detail, but apparently, noexec doesn't mean that things can't be executed on a partition mounted with this flag.
Peace,
JimBass
What for mounting nfs /tmp ?
I will never do such as. Lucky.
I remove all my apache2 running, be sure of being more secured even !
why cannot we debian be as secured as fedora ? Isnt debian stable used in governments too ? so
na?
That is a matter of conjecture and opinion. Debian, Fedora, really any type of linux can be ultra-secure or hyper-insecure. Fedora and its ilk are designed to be desktop systems. They ship with SELinux enabled, under the assumption that being a desktop system, the user doesn't need services like a webserver, mailserver, or DNS running on their machine. SELinux blocks all of these things out of the gate, and you have to punch a hole in SELinux to get this working. Debian I've always seen as geared more towards being a server. I run it on all of my personal machines without issue, but where I think it shines is as a server box. Now if I had to alter files to get something like Apache2 functional, I'd be infuriated. I also think as a "server-ish" distro, the security is more relaxed, as it is also assumed that the machine will be behind a hardware firewall.
Debian stable can be used and scripted to install a ton of ways. Yes, many governments use Debian stable, and it works fine. But that doesn't mean they put a CD/DVD in a computer, put on a default install and walk away from it! Many places put restrictions in place. I immediately stop password based SSH. The default install allows both password based SSH and root access. That may work for some, but not for me. You have to understand what you are installing, how it will work, and what you need to do to keep that safe.
Also, the noexec thing is not at all unique to Debian. That is part of the mount program, which is common across all linuxes and most unixes as well.
As UnSpawn, the Security moderator and guru, says; the system is as secure as the person running it. Before putting any server on the Internet, build your security in layers dependent on the services being provided.
A badly configured and maintained Linux box is as insecure as any MS based box. Crackers and their followers are becoming very adept at cracking Linux boxes and what's more the tools are more common place as well.
Sysadmins need to be more aware of what they need to do and what is going on, on their systems. Only today I have discovered a gentleman who has been trying all sorts of routes into my box is using tools on a cracked commercial box. The Sysadmin doesn't even know his box has been cracked and is hosting cracking tools.
As UnSpawn, the Security moderator and guru, says; the system is as secure as the person running it. Before putting any server on the Internet, build your security in layers dependent on the services being provided.
A badly configured and maintained Linux box is as insecure as any MS based box. Crackers and their followers are becoming very adept at cracking Linux boxes and what's more the tools are more common place as well.
Sysadmins need to be more aware of what they need to do and what is going on, on their systems. Only today I have discovered a gentleman who has been trying all sorts of routes into my box is using tools on a cracked commercial box. The Sysadmin doesn't even know his box has been cracked and is hosting cracking tools.
but if they use fail2ban and some scripts that check the attacks, and avoid/remove all running apache servers, ftp servers, and keep to sufficient just a single ssh (root kicked) is very secured with behind hardware firewall with only 80 and one pport open; nope ?
+ this in the crontab / watch
Code:
####
# (adapted from an example I found on the net (http://www.burngreave.net/node/319 9-11-2006)
# ... didn't work for me)
LOGFILE="/var/log/auth.log"
HOSTSDENY="/etc/hosts.deny"
BADCOUNT="10"
grep -i "invalid user" $LOGFILE | grep -v Fail | cut -d : -f 4 | cut -d " " -f 6 | sort | uniq -c | while read i
# this does the following:
# look for invalid user entries|
# filter out 'Failed' lines |
# remove everyting before the third ':' (needed because for instance "nov 6" has three spaces and "nov 10" only two) |
# cut out the ip number (field six)
# sort ipnumbers
# count the number of instances and display only only single instances
do
count=`echo ${i} | cut -d " " -f 1`
ip=`echo $i | cut -d " " -f 2`
# echo "count="$count
# echo "ip="$ip
already=`grep $ip $HOSTSDENY | grep sshd`
if [ -z "$already" ]
then
if [ "$count" -ge "$BADCOUNT" ]
then
echo "banned from sshd: "$ip
echo "sshd: "$ip >> $HOSTSDENY
echo "sshd: $ip $HOSTSDENY " >> /root/hostdenys.log
echo "sshd: $ip $HOSTSDENY " >> /dev/tty3
fi
fi
done
what else should we type / do / follow please ?
Last edited by frenchn00b; 02-11-2008 at 01:18 PM.
I used the term layers for a good reason. There is no defined type of security, only security processes to minimise the risk relevant to the running applications. It's as simple as that. As the responsible sysadmin you need to study your own security requirements and implement them.
You mention sshd. Ask yourself the question; Is there a need to ssh into the server from outside the lan? You must take a decision based on that answer. There are a number of variables that apply in differing situations and no one answer is the correct one.
In regards to SSH, I think you would be far more secure disabling password based ssh, regardless of who is allowed to access it (WAN, LAN, one host on the LAN). SSH is still open (at whatever port you use, the default 22 or an obscure one), but it won't ask for a username, and it also won't ask for a non-key-based password. That certainly isn't a one-stop and you're ok kind of thing, but you're whole firewall tweak ban script is unnecessary when nobody who doesn't have a key can get on your machine.
Here are the important lines from /etc/ssh/sshd_config:
Code:
#Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no
Then each user needs to have generated keys with the ssh-keygen command from their 'home' machine, and copy the key into /home/user/.ssh/authorized_keys. That way, when they request to ssh to the machine with the passkey in their authorized_keys file, all is well and good.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.