Hi all,
I would like to add that there is a DenyGroups directive that can be added
to the /etc/ssh/sshd_config file.
It's probably not too difficult to add the groups related to grid
automatically by the yaim scripts. This might be easier in some system
setups.
DenyGroups
This keyword can be followed by a list of group name patterns, separated
by spaces. Login is disallowed for users whose primary group or
supplementary group list matches one of the patterns. '*' and '?' can be
used as wildcards in the patterns. Only group names are valid; a numerical
group ID is not recognized. By default, login is allowed for all groups.
If a user's group matches a pattern in both DenyGroups and AllowGroups,
login will be denied.
Note that all other authentication steps must still be successfully
completed. AllowGroups and DenyGroups are additional restrictions and
never increase the tolerance.
Regards,
Serge
Ian Neilson
Sent by:
LHC Computer Grid - Rollout <[log in to unmask]>
16-06-2005 17:29
Please respond to
LHC Computer Grid - Rollout <[log in to unmask]>
To
[log in to unmask]
cc
Subject
[LCG-ROLLOUT] The 'How to blacklist a user" discussion and others.
Classification
On Monday 13/06/05 there was activity in several places under the headings
of
'jobs attempting to alter ssh setup', 'please remove user from VO' and
'how to
blacklist a user'.
NOTE: It is confirmed by the ROC security contact in question that this
activity, whilst potentially dangerous and unauthorized, was NOT
malicious.
A number of issues are raised by these discussions which can be analysed
with
the benefit of hindsight of which I give my brief summary of conclusions
for
some of them here.
A) Information was flowing in several places (inter-ROC, ROLLOUT and OSCT)
but, given the spread and timing of the discussions, confirmation of the
true
nature of the activity did not reach the necessary wider audience (site
admins) until too late. It was also not clear who should act.
* confirmed incidents MUST be reported, preferably via the registered site
security contact, to -
project-lcg-security-csirts -at- cern -dot- ch (an equivalent -egee- alias
exists).
* security reports which are not confirmed attacks (e.g. information
updates
and discussion) is via the site security contact to the list -
project-lcg-security-contacts -at- cern -dot- ch (an equivalent -egee-
alias
exists).
Both of the above should reach registered contact addresses at all sites.
Mail
subjects should clearly identify the content as HIGH, MEDIUM or LOW impact
or
INFORMATIONAL. Escalation in both cases due to unavailability and for
coordination should be through the affected ROC(s). The ROLLOUT list is
NOT
seen as appropriate for disclosure of security related information.
I would say the security-contacts list would have been appropriate in this
case.
B) Whilst not grid-specific in its nature, technical information on how to
contain the behaviour was not available and/or not sufficiently
publicised.
The OSCT will review and update where necessary. For the incident in
question
a reference has been created here:
http://goc.grid.sinica.edu.tw/gocwiki/Blocking_batch_jobs_from_creating_ssh_back_doors
(Thanks Steve Traylen).
An additional source of general security information is published here:
http://goc.grid-support.ac.uk/gridsite/operations/security_info.php
and here:
https://cic.in2p3.fr/index.php?id=roc&subid=roc_security&js_status=2
C) Availability of contact data for VO management and access to user
contact
data for site administrators (currently only readily available through
mail
contact with the VO) is unclear. This needs to be addressed, no immediate
solution is available but I will add a web page with contact points for
this
and A) above together with their purpose.
I would welcome feedback on any aspect to help in improving procedures for
the
future.
Ian
| Ian Neilson, LCG/EGEE Security Officer
| Grid Deployment Group, CERN
| Tel: +41 (0)22 76 74929
