Re: Default valid shells and home dir permissions
On Thu, Jan 12, 2012 at 7:48 AM, Davit Avsharyan avshar...@gmail.com wrote: I know how to change it :). I just wanted to understand why it comes with 755 and not 700 ? Few years ago, if I'm not mistaken, everything was 700. No less than 9 years. In 2003 I see the 755: http://anonscm.debian.org/viewvc/adduser/trunk/adduser.conf?revision=10view=markup Can't find earlier references there, but in /usr/share/doc/adduser/changelog.gz there is the following entry: * ability to set a global mode for creating directories in variable DIR_MODE in adduser.conf (closes: #29389) With this date: Sat, 20 May 2000 14:16:20 +0200 One possible reason for this default, maybe if I'm not mistaken, to keep UserDir working in apache (?) -- Iñigo -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKDTd8TO3f6TXOQKA7XVpvrmJ-s9p4m=nPWhYKg=7ojmo...@mail.gmail.com
Re: Default valid shells and home dir permissions
On Thu, Jan 12, 2012 at 12:26 PM, Chris Davies
chris-use...@roaima.co.uk wrote:
Davit Avsharyan avshar...@gmail.com wrote:
1/ I'm wondering why most of the system users have valid shells by
default ?
/cat /etc/passwd | grep -E '(sh|bash)' | wc -l
*21*/
That's not necessarily sufficient to determine valid shells: the absence
of a shell definition implies the use of /bin/sh, so you need to check
that, too.
Something like this should probably give you a definitive list -
SS=$(grep '^/' /etc/shells | xargs)
for S in $SS ''; do
getent passwd | awk -F: -v S=$S '{if ($7 == S) print $1, $7}'
done
Chris
Why filter to those in /etc/shells ? I mean... the filter should be
applied by the system :)
getent passwd | awk -F: '{print $1, $7}' | column -t
But neither of both codes take in mind if there is sudo in the system,
and what is gained in its config.
Also, neither of both codes think about ForceCommand in ssh... So I
maybe listed as /bin/bash, but I me be able only of run /usr/bin/cal
once as my shell and get kicked.
root@infinity:~ # adduser deleteme
Adding user `deleteme' ...
Adding new group `deleteme' (1002) ...
Adding new user `deleteme' (1002) with group `deleteme' ...
Creating home directory `/home/deleteme' ...
Copying files from `/etc/skel' ...
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for deleteme
Enter the new value, or press ENTER for the default
Full Name []:
Room Number []:
Work Phone []:
Home Phone []:
Other []:
Is the information correct? [Y/n] y
root@infinity:~ # printf -- Match User %s\n\tForceCommand %s\n
'deleteme' '/usr/bin/cal' /etc/ssh/sshd_config
root@infinity:~ # /etc/init.d/ssh restart
Restarting OpenBSD Secure Shell server: sshd.
root@infinity:~ # su - deleteme
deleteme@infinity:~$ ssh localhost
The authenticity of host 'localhost (127.0.0.1)' can't be established.
RSA key fingerprint is f5:7f:f7:bf:e5:43:33:03:b9:9a:71:e5:cf:6f:80:1a.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'localhost' (RSA) to the list of known hosts.
deleteme@localhost's password:
January 2012
Su Mo Tu We Th Fr Sa
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31
Connection to localhost closed.
deleteme@infinity:~$ logout
root@infinity:~ # getent passwd | awk -F: '/deleteme/{print $1, $7}'
deleteme /bin/bash
root@infinity:~ #
--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/djs2u8xfrv@news.roaima.co.uk
--
Iñigo
--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/cakdtd8sr3pw5vgwzo2jqckywkotuh8mu-f+qnlwvbthj92w...@mail.gmail.com
Re: Default valid shells and home dir permissions
On Thu, Jan 12, 2012 at 5:11 PM, Chris Davies chris-use...@roaima.co.uk wrote:
Poison Bit poison...@gmail.com wrote:
Why filter to those in /etc/shells ? I mean... the filter should be
applied by the system :)
Mainly because it's a convenient list of real shells, and some of the
remote service applications require a shell to be in that list. FTP is
one such that springs to mind. As a counter example, /bin/false is a
possible shell but it doesn't provide a particularly useful environment
for the user. You could change the scriptlet to check for the 7th column
being either empty or an executable file if you preferred.
Thanks, so my example should be more like:
getent passwd | awk -F: '!/bin\/false/{print $1 $7}'
If there is a single thread doing it, there is not race condition on
reading valid shells and then parsing a list of users.
But neither of both codes take in mind if there is sudo in the system,
and what is gained in its config.
I don't recall the OP mentioning access via sudo. (BICBW.)
Indeed, neither FTP, it was about:
why most of the system users have valid shells by default ?
Also, neither of both codes think about ForceCommand in ssh... So I
maybe listed as /bin/bash, but I me be able only of run /usr/bin/cal
once as my shell and get kicked.
ForceCommand requires an interactive shell-like login on the target,
so I don't believe that's relevant here.
My point was that the user with /bin/bash in such parsing, can still
have a ForceCommand /bin/false in sshd_config, but indeed this is not
relevant on why so much system users have a valid shell.
So returning to topic... I've no idea on why, my system just references this:
zmore /usr/share/doc/base-passwd/users-and-groups.txt.gz
Greets
--
Iñigo
--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/cakdtd8sgeycrsfpksc9dk-ppycqy_t1rqgx5xsa5xjwxwzh...@mail.gmail.com
Re: need help with openssh attack
On Thu, Dec 29, 2011 at 4:51 PM, Thijs Kinkhorst th...@debian.org wrote: On Thu, December 29, 2011 16:37, Nicolas Carusso wrote: How about creating a Referense list with all the suggestions that we are doing? If all of you agree, Let's start now. SECURITY LIST ** There's already the Securing Debian HOWTO: http://www.debian.org/doc/manuals/securing-debian-howto/ Perhaps it's an idea to see if your suggestions are in there, and if not, to suggest additions/changes/patches to the Debian Documentation project. You can get in contact through debian-...@lists.debian.org. chroot is done other way than the guide now days, so the patch is indeed needed. I've seen the change port 22 tip since I know ssh, and I still see servers hacked in 2012. Also, I see neither in the guide, neither in the points stated here, talk about disabling unneeded forwarding. I think one big step, is to try to understand each option in the sshd_config man page, and to test the results in each environment, and each admin evaluate each option to _house_ policies. SSH in the main firewall? is this the policy? AllowTcpForwarding Specifies whether TCP forwarding is permitted. The default is “yes”... By fortune, the default for GatewayPorts is no, but if that is not your policy... But maybe other defaults doesn't like you: MaxAuthTries Specifies the maximum number of authentication attempts permitted per connection. Once the number of failures reaches half this value, additional failures are logged. The default is 6. MaxSessions Specifies the maximum number of open sessions permitted per net‐ work connection. The default is 10. There are lot of other options, about timeouts, MaxStartups, PermitEmptyPasswords, PermitTunnel, StrictModes Maybe that if you read the manual of the tool just installed, you start finding incomplete security lists, etc. Anyway... at the end... As well as you can search for filezilla XMLs indexed online (ip/user/pass of lot of environments), I've seen public+private keys (+amazon IDs) in bitbucket pushed as mydotfiles and indexed by search engines. While the sysadmin fights to secure ARP, TCP, IP, DNS, SSL and then the services over, and the ssh developer does privilege separations and its security stuf, the web developer will index the credentials in a search engine. Put the credentials in a plain email, worldwide messenger service, post-it in the tasks table or in a shared folder with anonymous access for a co-worker. Step one to know how to secure a service in your server: do you know how to attack such service ? Do you know the common threats available in the net to attack such service ? then play chess Not every SSH attack will be a worm that exploits a code fault in port 22 of random network ranges. But maybe you get an attack of just another tech person like you trying to do it (DoS the service (or the server), be root, do the machine heat ram and kill other process, etc). Or maybe you get someone that just got the credentials from anyplace. That young student doing practices by 1 month has access to all company backups ? And... last but not least: system/security updates is not enough in some environments, so maybe add to the list: * maintenance (renew ssh keys periodically or on events, delete rules for old users/groups/hosts, etc) As well as, if you follow best practices and makes some cpu parse your logs by you... report attackers maybe other task of the maintenance process. You can report any abuse to the responsible internet providers, but that does not implies results. Some attacks will be in the ssh log, and others in the iptables ulogd. Did you already configured your firewalls, network, and sshd_config? good job! next chapter: your desktop ~/.ssh/config also allow the same and more options (disable unused protos, ciphers, methods, etc). If you're root of ssh client machines, you should do the same in each one. Greetings, this mail is too long to see if I can DoS Debian servers delivering it. ;-P -- Iñigo -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cakdtd8s_e7h_nsygnvczzdytb+k9djbi8ucxh5mxy8ulx-r...@mail.gmail.com
Re: Debian LTS?
On Thu, Oct 6, 2011 at 8:26 PM, 4k3nd0 4k3...@googlemail.com wrote: This is a major issue about Debian anyway. A good reason why i choose Debian instead to other distribution is simply, that the software is good tested and stable. That is what matters. System to maintain getting even harder with new Technologies like XEN/KVM. I just want to run the System and it should running on it on as possible without great times on maintaining. A LTS on Debian don't have to be every release, but Lenny should be one for example either wheezy then... LTS doesn't mean to back-port everything like RedHat does. Just to allow for the System to be more up to date with special feature or have to be intime Software. So that you have a supported Database all the time and so that it keep being supported. i would welcome a LTS of Debian Greeting's from Germany, 4k3nd0 In 5 years, upstream goes from svn to git, changes major version, more than one time, software may even be renamed, unsupported, etc in that time... I could love an LTS _wellsupported_ too, but if I just want to say mmm well security... I've a little probability that it happens to me, will don't care about it (system administration manual fail), then I just point my sources.list to archive.debian.org and keep a infinite Term service (to install/uninstall deb packages compiled with the same toolchain). I could not want a system that gets bakported (accross versions, changes, etc) security upgrades for a 07% of what it's installed in _any_ machine (kernel, libc, libpcap, ssl, etc). I could not sleep happy. People do not know howto educate a manager about opensource, lets keep debian stable supported as is by 5 years. I'm not the one to could say that backporting security patches for a basic system is only a money problem. Ofcourse that people moves by money, in special all those like me that need it, but you need excellent skills too, in most bugs, and debian could need more disk space, more build jobs for every arch, more concurrently supported versions, more bugs to track, etc etc etc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cakdtd8qja-egk8p-e8eovcxme8s7zd2d2trqdzeyvbrbf_-...@mail.gmail.com
Re: Debian LTS?
On Wed, Oct 5, 2011 at 10:45 PM, acot...@gmail.com wrote: Yes. Are you considering Total Cost of Ownership, comparing to the option of LTS? Best regards. So Debian should have rolling releases, LTS with that name, and network manager by default, and as there are no bugs to work on, and Debian as upstream can't be improved, lets keep Debian developers backporting security patches _where and when possible_ during 5 years for the whole main archive for every arch, while others work in frondesks, pythonization, etc as main line. mmm archs... Or in adition with rollings, LTS, and default network managers, debian should get just x86 and amd64 then? What's next? telepathic man pages to be free as in blob? If I think in many programs I use to use (libc, SSL,iceweasel, nginx, etc, etc, etc) and its history in 5 years, and this thing about debian LTSs and I just discard the idea, maybe I'm wrong and Debian is plenty of resources and excellence to do that job with all posible upstream paranoids. On 05/10/11 21:02, Brivaldo Junior wrote: Hi, IIRC, the current release schedule has stable releases 2 years apart, so total maintenance time is 2 years (stable) + 1 year (oldstable) = 3 years. And that's 2 years less for LTS ... especially in bigger Setup's LTS-Support is mandatory so there (because there is no Debian LTS's) Debian cannot be used due to the lack of Support. Instead - Redhat or Ubuntu or any other distribution with LTS-Support is used there. Maybe for you... in one bigger setup here... we use Debian and plan updates every 2/3 years without problems. Regards, Brivaldo Junior -- Alexandre Cotta Godinho Telem.: (+351) 910 873 189 IM»» AIM : acottag GTalk: acot...@gmail.com MSN : acot...@hotmail.com -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cakdtd8tcspy8n6ykq-7z2xw1wrg7sctgl0asasmh79gblmd...@mail.gmail.com
Re: Debian LTS?
On Thu, Oct 6, 2011 at 12:24 AM, Noah Meyerhans no...@debian.org wrote: On Wed, Oct 05, 2011 at 09:15:18PM +0100, Bart Swedrowski wrote: I have been forced to use switch from Debian to RedHat and clones in my last job specifically because usual life time of a server was 3.5 - 4 years. Same here. In my exerience, large sites typically use a 3-5 year lifetime for hardware, and the OS is never upgraded once a host goes into production. If you've got thousands of hosts, all of which are doing just fine in terms of software functionality and are in a static, generally unchanging production configuration, there's very little benefit to performing an OS upgrade. In my experience: if a company does not perform operative system upgrades, the company does not have more than 5 years and does not understand how open source, and in special linux kernel, works. You can migrate data between service versions or environments, have rollbacks, backups and etc. The monolitic one server, all services, never upgrade maybe just an architecture issue, totally outside of the Debian issues. If Debian needs to match company rules, to be in the edge like the others, lets start by do not purge firmwares. On the other hand, many of these large environments don't see a lot of value in Debian's major contributions. The Social Contract is not typically not a very important consideration when large enterprises choose a software platform. The OS environments are pretty strictly defined and generally don't change much, so they don't see a lot of value in Debian's package management tools. Canonical and Redhat both need to earn money, and it's worth a lot of money to big companies to have an LTS software platform. Debian doesn't need money, and (afaict) there's not a particularly large community of volunteers interested in the difficult task of maintaining an LTS platform. It's a generally thankless task that involves working on ancient versions of packages, often coming up with new fixes to old bugs so you can maintain existing interfaces, when the obvious fix would involve changing the behavior of a program or a library's API or some such. noah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFOjNkDYrVLjBFATsMRAlCKAJ9JiBadPRfnGM9s62Xts0DQGq1p5gCfX9Z4 e2tpdSHDJGGCdEZ/+qtvwO4= =q9rb -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKDTd8SnqYYY5rwwWrh9jmLkdU57=7WZBW0J863+omnHw9=z...@mail.gmail.com
Re: Debian LTS?
On Thu, Oct 6, 2011 at 12:33 AM, Poison Bit poison...@gmail.com wrote: In my experience: if a company does not perform operative system upgrades, the company does not have more than 5 years and does not understand how open source, and in special linux kernel, works. Or has management issues, but that's another history. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKDTd8RMkM=0791bmthck2zrdzwnw0ngwniheveh8mec0q-...@mail.gmail.com
Re: Debian LTS?
On Thu, Oct 6, 2011 at 12:40 AM, Noah Meyerhans no...@debian.org wrote: On Thu, Oct 06, 2011 at 12:33:39AM +0200, Poison Bit wrote: In my experience: if a company does not perform operative system upgrades, the company does not have more than 5 years and does not understand how open source, and in special linux kernel, works. I'm certain I can name several large companies that have been around for more than 5 years and whose services you rely on that do not perform os upgrades on hardware once it enters production. Unlisted N reason: or does not care about network security You can migrate data between service versions or environments, have rollbacks, backups and etc. Across a fleet of 15000 hosts? With no downtime? Without impacting the schedule of whatever software you actually run on these hosts? Don't they got daily updates? are they network exposed? Don't they jump LTS neither never? The monolitic one server, all services, never upgrade maybe just an architecture issue, totally outside of the Debian issues. That's not what I'm describing at all. Those places can and should upgrade. I'm talking 1 service to 1 host, multiplied by thousands. These are the companies that want LTS support. That companies of that size, may want to help Debian to help them, keeping packages many years supported without being like a debian oldstable php. Maybe that companies may have ALL Debian developers happy and got the LTS as a result, good luck. noah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFOjNzSYrVLjBFATsMRAn3YAJ4/UFmXXcDpOjS0tswUO10Qr8GzDwCeOqF/ B2sMvKQI1+bEr4lZF9O1viw= =obBh -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cakdtd8q4t6mqbwopa4t_z_f9p-r5d6jr2txxuqphmat1d5g...@mail.gmail.com
