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