Hello Joseph,

Alert 1124 is documented as: "Alert 1124 is sent when a user ID with the SPECIAL, AUDITOR, OPERATIONS, or ROAUDIT attribute logs on to TSO from an IP address that is not allowed."

In the documentation for alert 1124 at the bottom it shows:

"You can configure the alert for your site. When selecting the alert, you are prompted with a panel. You can enter up to 10 IP addresses or network prefixes that specify from where the user ID is allowed to logon. See Allowed IP address (alerts 1124 and 2124) configuration."

and that link shows you the panel you will see where allowed IP addresses/subnets are specified during the configuration of alert 1124.

Alert 1124 is triggered by SMF record types 30 subtype 1 or type 80 for the actual logon, and uses the information from previous type 118 or 119 subtype 20 records from TN3270 to determine the source IP address that the logon from the terminal relates to.

I would therefore not expect this alert to trigger for an SSH logon and would need to see what SMF records are seen when these different logons occur to understand what you see.

Please feel free to open a case with support to dig deeper.

Thank you Joseph for that link - was a mystery to me what these various alerts do!  Would you know what the content of the alert is when sent thru the SIEM adaptor in zSecure to a SPLUNK or QRADAR or ? type of server?  I've asked our network server admins to tell me what he's seeing over on their side but he seems not to know how to 'spot' these alerts as there sent over there.  

Hello Joseph,

Alert 1124 is documented as: "Alert 1124 is sent when a user ID with the SPECIAL, AUDITOR, OPERATIONS, or ROAUDIT attribute logs on to TSO from an IP address that is not allowed."

In the documentation for alert 1124 at the bottom it shows:

"You can configure the alert for your site. When selecting the alert, you are prompted with a panel. You can enter up to 10 IP addresses or network prefixes that specify from where the user ID is allowed to logon. See Allowed IP address (alerts 1124 and 2124) configuration."

and that link shows you the panel you will see where allowed IP addresses/subnets are specified during the configuration of alert 1124.

Alert 1124 is triggered by SMF record types 30 subtype 1 or type 80 for the actual logon, and uses the information from previous type 118 or 119 subtype 20 records from TN3270 to determine the source IP address that the logon from the terminal relates to.

I would therefore not expect this alert to trigger for an SSH logon and would need to see what SMF records are seen when these different logons occur to understand what you see.

Please feel free to open a case with support to dig deeper.

Hi Lynn,

If you can read (or run) CARLa, you can see the formats in the skeleton members in SCKRSLIB.

RACF alerts are in members with C2PSnnnn as the name, with nnnn being the alert number.
Sometimes they also handle ACF2 alerts (which start with a 2 instead of a 1). 

The QRadar formats are in the sections headed with

)CM QRadar Unix syslog sortlist   

For example,

VIEW       CRMA.D.GKR320.$BASE.SCKRSLIB(C2PS1124) - 01.35  Columns 00001 00072 
Command ===> ________________________________________________ Scroll ===> CSR  
000169 )CM QRadar Unix syslog sortlist                                         
000170 )SEL &C2PERCTP = SYSL                                                   
000171  option header=rfc5424                                                  
000172  sortlist,                                                              
000173   recno(nd) '<&C2PEPRIO.>' | _hdr_datetime _hdr_hostname 'C2P&c2pemem.',
000174   '[C2P&C2PEMEM.',                                                      
000175   userid('whoUSERID'),                                                  
000176   user:name('whoNAME'),                                                 
000177   'whatACTION="&C2PXNAME"'(norepl),                                     
000178 )SEL &C2PESECP = RACF                                                   
000179   desc('whatDESC',0,explode,hor),                                       
000180 )ENDSEL                                                                 
000181   jobname('whatJOBNAME'),                                               
000182   jobid('whatJOBID'),                                                   
000183   system('whereSYSTEM'),                                                
000184 )SEL &C2PESECP = RACF                                                   
000185   terminal('fromWhereTERMINAL'),                                        
000186   terminalip('fromWhereSRCIP',cond),                                    
000187 )ENDSEL                                            
000188 )SEL &C2PESECP = ACF2                                                   
000189   acf2_source('fromWhereTERMINAL'),                                     
000190   acf2_sourceip('fromWhereSRCIP',cond),                                 
000191 )ENDSEL                                                                 
000192   srcip('fromWhereSRCIP',cond),                                         
000193 )SEL &C2PESECP = RACF                                                   
000194   utoken_source_userid('fromWhereUSER'),                                
000195   utoken_source_system('fromWhereSYSTEM'),                              
000196 )ENDSEL                                                                 
000197   | ']',                                                                
000198 )IM C2PSFMSG                                                                                

where the lines starting with a closing bracket are skeleton directives as to what to generate,
and there are some variables &C2Psomething that get substituted, such as the &C2PEMEM being the alert number,
while the HEADER=RFC5424 instructs the program to use a format for the individual fields like whoUSERID="userid",
and some of the CARLa fields are defined in the C2PSGLOB global member:
VIEW       CRMA.D.GKR320.$BASE.SCKRSLIB(C2PSGLOB) - 18.99  Columns 00001 00072 
Command ===> ________________________________________________ Scroll ===> CSR  
000094 )CM Message header fields for recipient SYSL (RFC5424) and CEF          
000095 )CM all other newlist types must define these locally in the skeleton.  
000096  define type=SMF _hdr_datetime(cef_dt,15,noprefix,noquote) as datetime  
000097  define type=SMF _hdr_hostname(0,noprefix,noquote) as system            

Here is an example payload:
<117>May 20 10:34:54 ZS45 C2P1124 [C2P1124 whoUSERID="CRMBRT1" whoNAME="TESTACTION" whatACTION="Logon_From_NotAllowed" whatDESC="Success" whatJOBNAME="CRMBRT1" whatJOBID="TSU02430" whereSYSTEM="ZS45" fromWhereTERMINAL="STCP0001" fromWhereSRCIP="::FFFF:9.83.61.17"]Alert: Authorized user CRMBRT1 logged on from ::FFFF:9.83.61.17 - Logon by a userid from a not allowed IP address

I hope this begins to help.

Regards,

Thank you Joseph for that link - was a mystery to me what these various alerts do!  Would you know what the content of the alert is when sent thru the SIEM adaptor in zSecure to a SPLUNK or QRADAR or ? type of server?  I've asked our network server admins to tell me what he's seeing over on their side but he seems not to know how to 'spot' these alerts as there sent over there.  

Hello Joseph,

Alert 1124 is documented as: "Alert 1124 is sent when a user ID with the SPECIAL, AUDITOR, OPERATIONS, or ROAUDIT attribute logs on to TSO from an IP address that is not allowed."

In the documentation for alert 1124 at the bottom it shows:

"You can configure the alert for your site. When selecting the alert, you are prompted with a panel. You can enter up to 10 IP addresses or network prefixes that specify from where the user ID is allowed to logon. See Allowed IP address (alerts 1124 and 2124) configuration."

and that link shows you the panel you will see where allowed IP addresses/subnets are specified during the configuration of alert 1124.

Alert 1124 is triggered by SMF record types 30 subtype 1 or type 80 for the actual logon, and uses the information from previous type 118 or 119 subtype 20 records from TN3270 to determine the source IP address that the logon from the terminal relates to.

I would therefore not expect this alert to trigger for an SSH logon and would need to see what SMF records are seen when these different logons occur to understand what you see.

Please feel free to open a case with support to dig deeper.

Hi Lynn,

If you can read (or run) CARLa, you can see the formats in the skeleton members in SCKRSLIB.

RACF alerts are in members with C2PSnnnn as the name, with nnnn being the alert number.
Sometimes they also handle ACF2 alerts (which start with a 2 instead of a 1). 

The QRadar formats are in the sections headed with

)CM QRadar Unix syslog sortlist   

For example,

VIEW       CRMA.D.GKR320.$BASE.SCKRSLIB(C2PS1124) - 01.35  Columns 00001 00072 
Command ===> ________________________________________________ Scroll ===> CSR  
000169 )CM QRadar Unix syslog sortlist                                         
000170 )SEL &C2PERCTP = SYSL                                                   
000171  option header=rfc5424                                                  
000172  sortlist,                                                              
000173   recno(nd) '<&C2PEPRIO.>' | _hdr_datetime _hdr_hostname 'C2P&c2pemem.',
000174   '[C2P&C2PEMEM.',                                                      
000175   userid('whoUSERID'),                                                  
000176   user:name('whoNAME'),                                                 
000177   'whatACTION="&C2PXNAME"'(norepl),                                     
000178 )SEL &C2PESECP = RACF                                                   
000179   desc('whatDESC',0,explode,hor),                                       
000180 )ENDSEL                                                                 
000181   jobname('whatJOBNAME'),                                               
000182   jobid('whatJOBID'),                                                   
000183   system('whereSYSTEM'),                                                
000184 )SEL &C2PESECP = RACF                                                   
000185   terminal('fromWhereTERMINAL'),                                        
000186   terminalip('fromWhereSRCIP',cond),                                    
000187 )ENDSEL                                            
000188 )SEL &C2PESECP = ACF2                                                   
000189   acf2_source('fromWhereTERMINAL'),                                     
000190   acf2_sourceip('fromWhereSRCIP',cond),                                 
000191 )ENDSEL                                                                 
000192   srcip('fromWhereSRCIP',cond),                                         
000193 )SEL &C2PESECP = RACF                                                   
000194   utoken_source_userid('fromWhereUSER'),                                
000195   utoken_source_system('fromWhereSYSTEM'),                              
000196 )ENDSEL                                                                 
000197   | ']',                                                                
000198 )IM C2PSFMSG                                                                                

where the lines starting with a closing bracket are skeleton directives as to what to generate,
and there are some variables &C2Psomething that get substituted, such as the &C2PEMEM being the alert number,
while the HEADER=RFC5424 instructs the program to use a format for the individual fields like whoUSERID="userid",
and some of the CARLa fields are defined in the C2PSGLOB global member:
VIEW       CRMA.D.GKR320.$BASE.SCKRSLIB(C2PSGLOB) - 18.99  Columns 00001 00072 
Command ===> ________________________________________________ Scroll ===> CSR  
000094 )CM Message header fields for recipient SYSL (RFC5424) and CEF          
000095 )CM all other newlist types must define these locally in the skeleton.  
000096  define type=SMF _hdr_datetime(cef_dt,15,noprefix,noquote) as datetime  
000097  define type=SMF _hdr_hostname(0,noprefix,noquote) as system            

Here is an example payload:
<117>May 20 10:34:54 ZS45 C2P1124 [C2P1124 whoUSERID="CRMBRT1" whoNAME="TESTACTION" whatACTION="Logon_From_NotAllowed" whatDESC="Success" whatJOBNAME="CRMBRT1" whatJOBID="TSU02430" whereSYSTEM="ZS45" fromWhereTERMINAL="STCP0001" fromWhereSRCIP="::FFFF:9.83.61.17"]Alert: Authorized user CRMBRT1 logged on from ::FFFF:9.83.61.17 - Logon by a userid from a not allowed IP address

I hope this begins to help.

Regards,

Thank you Joseph for that link - was a mystery to me what these various alerts do!  Would you know what the content of the alert is when sent thru the SIEM adaptor in zSecure to a SPLUNK or QRADAR or ? type of server?  I've asked our network server admins to tell me what he's seeing over on their side but he seems not to know how to 'spot' these alerts as there sent over there.  

Hello Joseph,

Alert 1124 is documented as: "Alert 1124 is sent when a user ID with the SPECIAL, AUDITOR, OPERATIONS, or ROAUDIT attribute logs on to TSO from an IP address that is not allowed."

In the documentation for alert 1124 at the bottom it shows:

"You can configure the alert for your site. When selecting the alert, you are prompted with a panel. You can enter up to 10 IP addresses or network prefixes that specify from where the user ID is allowed to logon. See Allowed IP address (alerts 1124 and 2124) configuration."

and that link shows you the panel you will see where allowed IP addresses/subnets are specified during the configuration of alert 1124.

Alert 1124 is triggered by SMF record types 30 subtype 1 or type 80 for the actual logon, and uses the information from previous type 118 or 119 subtype 20 records from TN3270 to determine the source IP address that the logon from the terminal relates to.

I would therefore not expect this alert to trigger for an SSH logon and would need to see what SMF records are seen when these different logons occur to understand what you see.

Please feel free to open a case with support to dig deeper.

Hello Joseph,

Alert 1124 is documented as: "Alert 1124 is sent when a user ID with the SPECIAL, AUDITOR, OPERATIONS, or ROAUDIT attribute logs on to TSO from an IP address that is not allowed."

In the documentation for alert 1124 at the bottom it shows:

"You can configure the alert for your site. When selecting the alert, you are prompted with a panel. You can enter up to 10 IP addresses or network prefixes that specify from where the user ID is allowed to logon. See Allowed IP address (alerts 1124 and 2124) configuration."

and that link shows you the panel you will see where allowed IP addresses/subnets are specified during the configuration of alert 1124.

Alert 1124 is triggered by SMF record types 30 subtype 1 or type 80 for the actual logon, and uses the information from previous type 118 or 119 subtype 20 records from TN3270 to determine the source IP address that the logon from the terminal relates to.

I would need to see what SMF records are seen when these different logons occur to understand what you see.

Please feel free to open a case with support to dig deeper.

------------------------------
Mike Riches
------------------------------

Hi Mike,

Thank you for the info!

By chance, do you know what qualifies or does not qualify as an unauthorized IP address? It is strange that only 1 logon action causes this Alert to trigger.

Hello Joseph,

Alert 1124 is documented as: "Alert 1124 is sent when a user ID with the SPECIAL, AUDITOR, OPERATIONS, or ROAUDIT attribute logs on to TSO from an IP address that is not allowed."

In the documentation for alert 1124 at the bottom it shows:

"You can configure the alert for your site. When selecting the alert, you are prompted with a panel. You can enter up to 10 IP addresses or network prefixes that specify from where the user ID is allowed to logon. See Allowed IP address (alerts 1124 and 2124) configuration."

and that link shows you the panel you will see where allowed IP addresses/subnets are specified during the configuration of alert 1124.

Alert 1124 is triggered by SMF record types 30 subtype 1 or type 80 for the actual logon, and uses the information from previous type 118 or 119 subtype 20 records from TN3270 to determine the source IP address that the logon from the terminal relates to.

I would need to see what SMF records are seen when these different logons occur to understand what you see.

Please feel free to open a case with support to dig deeper.

------------------------------
Mike Riches

Hi Mike,

Thank you for the info!

By chance, do you know what qualifies or does not qualify as an unauthorized IP address? It is strange that only 1 logon action causes this Alert to trigger.