Odd Blocks reports

Peter_Bates · November 22, 2013, 3:19pm

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello all

As part of the RTIR installation, I followed from the README:

Using RT’s configuration interface, add the email address
of the Network Operations Team (the people who will handle
activating and removing Blocks) as AdminCC on the Blocks queue.
RT → Queues → Blocks → Watchers

The emails it generates lack a ‘To:’ field (I can see this is because
the message is a BCC) which is leading to confusion in our Networking team.

The email also contains at the top:

Fri Nov 22 14:37:20 2013: Request 6758 was acted upon.
Transaction: Ticket created by xxx
Queue: Blocks
Owner: xxx
Requestors:
Status: pending activation
Ticket <URL: https://rt.cert.ucl.ac.uk/Ticket/Display.html?id=6758 >

As they can’t access the RTIR interface this is also causing confusion.

Is this generated from a template, or where do I go to change this

- and can I set up the Blocks queue to just have the Network team
  as a standard To: / correspondent and not BCC or CC?

Thanks.

Peter Bates
Senior Information Security Officer Phone: +44(0)2076792049
Information Services Division Internal Ext: 32049
University College London
London WC1E 6BT
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSj3YaAAoJELhVoVpEMS6Rl/wH/jkLHxTlo5SDqFzxi8IMon0S
pnLLmsjgV8PD7Lq38SgJbtGmpWDQ5cJOVCt5wRvJGrEW4fC+QgJFz2P6M2gY/IMh
840c6AIzRXNcwJQbG/WzmFiQvbaXjIzoZ7V1AJxvmZA99vWXtBqzmmchvESk5kQH
45RfjNnlUZBqh8aT8ytd7EMW6+ZfP2epCQG7OKX1dEs221zYw/Y7Aij2NBYg1cl2
KsfeOXxhCgoCrw9PZ2ynG//PTLxkV7XzmmJPKz/hD8gGTINOXwx0OSZxzEh8a7NV
FN76VUevFAhmrY4i9dCWF8Z13WGPh13aHx3VSQ3ipgdn6ExyGR9L9QpS5yjcHpY=
=bHi0
-----END PGP SIGNATURE-----

Tony_Arnold · November 23, 2013, 11:52am

Peter,

I’ve been through the same thing. I originally had our network team
configured as admincc watchers on the blocks queue. This made sending
block requests very easy as we didn’t have to put anything in the
correspondents field when creating the block.

However, the status of tickets in the blocks queue can be automatically
updated by correspondence. So I create a block in ‘Activation pending’
state. Message goes off to network team who then reply. This changes the
state to ‘Activated’. Similar thing happens on removal.

This does not work when the network team is configured as watchers
rather than specified as correspondents. This is because the state
change only gets done if the incoming e-mail is from one of the
requesters of the ticket.

So we took off the watchers and we now specify the network team
explicitly every time we create a block. We have to specify the members
of the team explicitly, we cannot even use their group mailing list address.

All a bit of a pain really.

Regards,
Tony.On 22/11/13 15:19, Peter Bates wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello all

As part of the RTIR installation, I followed from the README:

Using RT’s configuration interface, add the email address
of the Network Operations Team (the people who will handle
activating and removing Blocks) as AdminCC on the Blocks queue.
RT → Queues → Blocks → Watchers

The emails it generates lack a ‘To:’ field (I can see this is because
the message is a BCC) which is leading to confusion in our Networking team.

The email also contains at the top:

Fri Nov 22 14:37:20 2013: Request 6758 was acted upon.
Transaction: Ticket created by xxx
Queue: Blocks
Subject: Brute force block for 6 hosts
Owner: xxx
Requestors:
Status: pending activation
Ticket <URL: https://rt.cert.ucl.ac.uk/Ticket/Display.html?id=6758 >

As they can’t access the RTIR interface this is also causing confusion.

Is this generated from a template, or where do I go to change this

and can I set up the Blocks queue to just have the Network team
as a standard To: / correspondent and not BCC or CC?

Thanks.

Peter Bates
Senior Information Security Officer Phone: +44(0)2076792049
Information Services Division Internal Ext: 32049
University College London
London WC1E 6BT
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSj3YaAAoJELhVoVpEMS6Rl/wH/jkLHxTlo5SDqFzxi8IMon0S
pnLLmsjgV8PD7Lq38SgJbtGmpWDQ5cJOVCt5wRvJGrEW4fC+QgJFz2P6M2gY/IMh
840c6AIzRXNcwJQbG/WzmFiQvbaXjIzoZ7V1AJxvmZA99vWXtBqzmmchvESk5kQH
45RfjNnlUZBqh8aT8ytd7EMW6+ZfP2epCQG7OKX1dEs221zYw/Y7Aij2NBYg1cl2
KsfeOXxhCgoCrw9PZ2ynG//PTLxkV7XzmmJPKz/hD8gGTINOXwx0OSZxzEh8a7NV
FN76VUevFAhmrY4i9dCWF8Z13WGPh13aHx3VSQ3ipgdn6ExyGR9L9QpS5yjcHpY=
=bHi0
-----END PGP SIGNATURE-----

Tony Arnold, Tel: +44 (0) 161 275 6093
Head of IT Security, Fax: +44 (0) 705 344 3082
University of Manchester, Mob: +44 (0) 773 330 0039
Manchester M13 9PL. Email: tony.arnold@manchester.ac.uk

Kevin_Falcone · November 25, 2013, 8:07pm

Using RT’s configuration interface, add the email address
of the Network Operations Team (the people who will handle
activating and removing Blocks) as AdminCC on the Blocks queue.
RT → Queues → Blocks → Watchers

The emails it generates lack a ‘To:’ field (I can see this is because
the message is a BCC) which is leading to confusion in our Networking team.

The email also contains at the top:

Fri Nov 22 14:37:20 2013: Request 6758 was acted upon.
Transaction: Ticket created by xxx
Queue: Blocks
Subject: Brute force block for 6 hosts
Owner: xxx
Requestors:
Status: pending activation
Ticket <URL: https://rt.cert.ucl.ac.uk/Ticket/Display.html?id=6758 >

As they can’t access the RTIR interface this is also causing confusion.

Is this generated from a template, or where do I go to change this

and can I set up the Blocks queue to just have the Network team
as a standard To: / correspondent and not BCC or CC?

All of these emails that RT sends are controlled by Scrips and
generate content from a Template.

I suspect you want to go to
Tools → Configuration → Queues → Blocks
Scrips
Look at what is configured on that QUeue
Templates
Look at the content of the templates

You may want a Queue Level Admin Correspondence template on this
Queue, or you could just make the Netops folks Queue Ccs instead of
AdminCcs, especially since they’re never logging in to RT.

If they’re going to stay AdminCcs and really can’t deal with an empty
To line, you may want to look into
http://bestpractical.com/docs/rt/latest/RT_Config.html#UseFriendlyToLine

-kevin

Kevin_Falcone · November 25, 2013, 8:11pm

I’ve been through the same thing. I originally had our network team
configured as admincc watchers on the blocks queue. This made
sending block requests very easy as we didn’t have to put anything
in the correspondents field when creating the block.

However, the status of tickets in the blocks queue can be
automatically updated by correspondence. So I create a block in
‘Activation pending’ state. Message goes off to network team who
then reply. This changes the state to ‘Activated’. Similar thing
happens on removal.

This does not work when the network team is configured as watchers
rather than specified as correspondents. This is because the state
change only gets done if the incoming e-mail is from one of the
requesters of the ticket.

So we took off the watchers and we now specify the network team
explicitly every time we create a block. We have to specify the
members of the team explicitly, we cannot even use their group
mailing list address.

This surprises me - default RTIR scrips use
On Correspond - RTIR Set Status of Block

That On Correspond condition is a literal “Any Correspondence by
anybody” not “On correspondence from Requestors”.

I suspect a local mod or a non standard scrip configuration.

-kevin

Tony_Arnold · November 25, 2013, 11:03pm

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kevin,On 25/11/13 20:11, Kevin Falcone wrote:

On Sat, Nov 23, 2013 at 11:52:09AM +0000, Tony Arnold wrote:

I’ve been through the same thing. I originally had our network
team configured as admincc watchers on the blocks queue. This
made sending block requests very easy as we didn’t have to put
anything in the correspondents field when creating the block.

However, the status of tickets in the blocks queue can be
automatically updated by correspondence. So I create a block in
‘Activation pending’ state. Message goes off to network team who
then reply. This changes the state to ‘Activated’. Similar thing
happens on removal.

This does not work when the network team is configured as
watchers rather than specified as correspondents. This is because
the state change only gets done if the incoming e-mail is from
one of the requesters of the ticket.

So we took off the watchers and we now specify the network team
explicitly every time we create a block. We have to specify the
members of the team explicitly, we cannot even use their group
mailing list address.

This surprises me - default RTIR scrips use On Correspond - RTIR
Set Status of Block

That On Correspond condition is a literal “Any Correspondence by
anybody” not “On correspondence from Requestors”.

I think the scrip SetRTIRstate, condition ‘RTIR Require State Change’,
Action is ‘RTIR Set Block State’ is the relevant one here. It’s how it
came out of the box, no local mods.

Regards,
Tony.

Tony Arnold, Tel: +44 (0) 161 275 6093
Head of IT Security, Fax: +44 (0) 705 344 3082
University of Manchester, Mob: +44 (0) 773 330 0039
Manchester M13 9PL. Email: tony.arnold@manchester.ac.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKT1yQACgkQIsyKE/d21hm3BACfZUxogcu5PEfNBW7PcQscYpz5
71IAoLGbl7FC3vFEtcYWsRpQ0FmmF2ad
=phoJ
-----END PGP SIGNATURE-----

Kevin_Falcone · November 26, 2013, 5:13pm

I think the scrip SetRTIRstate, condition ‘RTIR Require State Change’,
Action is ‘RTIR Set Block State’ is the relevant one here. It’s how it
came out of the box, no local mods.

Came out of the box on what version?

3.0.0 ships the scrip I described.

github.com

bestpractical/rtir/blob/3.0-trunk/etc/initialdata#L301


      
              },
          );
          
          @Scrips = (
              {  Description       => "SetHowReported",
                 Queue             => 'Incident Reports',
                 ScripCondition    => 'On Create',
                 ScripAction       => 'RTIR Set How Reported',
                 Template          => 'Blank' },
          
              {  Description       => "On Correspond Change Status of the Block",
                 Queue             => 'Blocks',
                 ScripCondition    => 'On Correspond',
                 ScripAction       => 'RTIR Set Block Status',
                 Template          => 'Blank', },
              {  Description       => "On Linking To Incident Activate Report",
                 Queue             => 'Incident Reports',
                 ScripCondition    => 'RTIR Linking To Incident',
                 ScripAction       => 'RTIR Activate Ticket',
                 Template          => 'Blank' },
              {  Description       => "On Correspond (not every) Activate Report",

It sounds like you’re running 1.0, 2.4 or 2.6.
I see that the 3.0 upgrade scripts add the scrip I mentioned.

-kevin

Tony_Arnold · November 26, 2013, 5:55pm

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kevin,On 26/11/13 17:13, Kevin Falcone wrote:

On Mon, Nov 25, 2013 at 11:03:00PM +0000, Tony Arnold wrote:

I think the scrip SetRTIRstate, condition ‘RTIR Require State
Change’, Action is ‘RTIR Set Block State’ is the relevant one
here. It’s how it came out of the box, no local mods.

Came out of the box on what version?

3.0.0 ships the scrip I described.

rtir/etc/initialdata at 3.0-trunk · bestpractical/rtir · GitHub

It sounds like you’re running 1.0, 2.4 or 2.6. I see that the 3.0
upgrade scripts add the scrip I mentioned.

Ah, yes, I’m not on 3.0.0 yet. I think it’s 2.6.

The new scrip in 3.0.0 will make our lives much easier. Good news!

Regards,
Tony.

Tony Arnold, Tel: +44 (0) 161 275 6093
Head of IT Security, Fax: +44 (0) 705 344 3082
University of Manchester, Mob: +44 (0) 773 330 0039
Manchester M13 9PL. Email: tony.arnold@manchester.ac.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKU4JUACgkQIsyKE/d21hkd/wCgjvbvkoFtY5gDI7T0DKbFXal5
z0YAoOVDKf4towdjagUJ1cqZYfrcOsNU
=P/b3
-----END PGP SIGNATURE-----