asp@cos.com (Andrew S. Partan) (03/26/88)
I noticed that someone (root@altel.UUCP in <21@altel.UUCP> and
<22@altel.UUCP>) sent out 2 checkgroups messages to the whole net.
Neither was what Spaf had posted. This also happened last month (a
different person, if I remember properly).
Presumably, this person will not do it again. However, I can not
assume that this will not happen again. What I would like to do is
find a way of stopping this (at least on my system) until Spaf (or
someone 'in the know') starts posting them again.
Does anyone know of a way of trapping any incoming checkgroups messages
and turning them into mail to usenet so that the usenet administrator
could apply them as she see fit? This would stop unauthorized people
from sending out checkgroups messages and having them applied to our
system. I looked thru the news documentation and found no way of doing
this.
Failing such a way, I guess that we shall have to keep an eye out for
'bad' checkgroups messages and reapply the latest 'correct' one that we
have on hand if a bad ones gets sent.
As far as I can tell, the checkgroups message only updates
~news/newsgroups. It does not modify ~news/active. Is this correct?
Thanks for any help,
--asp (Andrew Partan @ Corporation for Open Systems)
-- asp@cos.com or asp%cos.com@uunet.uu.net
-- {uunet, sundc, decuac, hqda-ai, hadron}!cos!asp
ASN.1 Object Identifier: "{joint-iso-ccitt mhs(6) group(6) 157}"
DISCLAIMER: Opinions expressed are not necessarily those of the
Corporation for Open Systems, its members, or any standards body.geoff@utstat.uucp (Geoff Collyer) (03/28/88)
I assume that you are running an old B news, as the C news checkgroups
has always been non-destructive and the B 2.11 checkgroups looks
non-destructive too. You should find a shell script in
/usr/lib/news/checkgroups which implements the checkgroups control
message. You just need to comment out any rmgroup and newgroup commands
or other commands which alter the active file or files under
/usr/spool/news.
--
Geoff Collyer utzoo!utstat!geoff, utstat.toronto.{edu,cdn}!geoffjane@tolerant.UUCP (Jane Medefesser) (03/29/88)
It's very simple - rename your ~news/checkgroups file to something else and
make the checkgroups file have 1 line of executeable code: "exit 0". When
you see that checkgroups message come in, run it by hand. I did this a long
time ago and although it's tedious to run checkgroups by hand, I never have
a problem having it run amuck on it's own...
============================================
(*Look, ma - no offensive quotes!!!*)
Jane Medefesser uucp: {pyramid,mordor,oliveb,sci}!tolerant!jane
Tolerant Systems
San Jose, Ca 95134klr@hadron.UUCP (Kurt L. Reisler) (03/29/88)
In article <1231@cos.com> asp@cos.com (Andrew S. Partan) writes: >I noticed that someone (root@altel.UUCP in <21@altel.UUCP> and ><22@altel.UUCP>) sent out 2 checkgroups messages to the whole net. >Neither was what Spaf had posted. This also happened last month (a >different person, if I remember properly). > The one I got indicated that EVERY SINGLE newsgroup in my active file needed to be deleted. Fortunately, it is close enoough to April 1st to just ignore those kinds of things. Kurt
dhb@rayssd.ray.com (David H. Brierley) (03/30/88)
I noticed a major problem with the bogus checkgroups message that came
through here. Two or three groups that had recently been changed from
moderated to un-moderated were suddenly changed back to moderated. As
new articles came in for what is now supposed to be an un-moderated
group, inews thought that they were unapproved articles posted to a
moderated group so it mailed them to the moderator. I feed all my
moderated article stuff to gatech and when the messages got there they
were sent back as undeliverable since the folks at gatech had already
deleted the mailing aliases.
The way I see it, there are two things that can be done to prevent the
propogation of bogus checkgroups messages. The first way is to compare
the name in the "Approved" line with a list of names contained in a
file that is maintained by the system administrator. This will not
prevent someone who is intent on sending out a forged message but all
of the bogus checkgroups message that I have ever seen were not
forgeries, they were mistakes. If the name does not match any of the
names in the list, the article should be mailed to the administrator.
An alternative which is a little more secure would be to require a
sequence of cross-checks, such as: submitted by a known authorized
person, submitted with a specific distribution such as "local", and to
be really secure, submitted from the local machine. A determined
forger would still be able to generate a valid message on any given
machine but it would be a lot harder to get that message to propogate
around the network.
Since the first method would catch all the bogus checkgroups that I
have ever seen, including the ones that came around recently, I think
that would be the best general solution. If you are really paranoid
about forged checkgroups messages, disable the checkgroups code in the
inews program and run the thing by hand. As soon as I get some free
time I will generate a patch to allow local control over who can submit
checkgroups messages and will then post the patch to the net. Unless
someone either beats me to the punch or can show me some overwhelming
reason why this would be a bad thing to do.
--
David H. Brierley
Raytheon Submarine Signal Division / 1847 West Main Road / Portsmouth, RI 02871
Phone: (401)-847-8000 x4073
Internet: dhb@rayssd.ray.com
Uucp: {cbosgd, decuac, gatech, necntc, sun, uiucdcs, ukma} !rayssd!dhbdave@galaxia.zone1.com (David H. Brierley) (03/30/88)
After I posted my original note I realized that checking the Approved: line
isn't going to gain me anything since the article in question had a line that
said it was approved by "spaf". Maybe if I check both the Approved line and
the From line. That should catch all the accidental postings. I think that
something as potentially dangerous as a checkgroups message should also be
required to have a valid Distribution line. I am going to keep working on
it until I come up with something that will prevent most of the common
mistakes but still allow a single person to easily administor a group of
machines. Since there is no easy way to prevent forgeries I am not going
to be concerned about them.
--
David H. Brierley
Home: dave@galaxia.zone1.com ...!rayssd!galaxia!dave
Work: dhb@rayssd.ray.com {sun,decuac,cbosgd,gatech,necntc,ukma}!rayssd!dhb