Topic
  • 14 replies
  • Latest Post - ‏2013-07-22T14:09:22Z by gpy
gpy
gpy
23 Posts

Pinned topic local traffic for sysda only

‏2013-07-17T14:34:38Z |

Dears,

i'm running guard-stap-9.0.0_r48064_v90_1-rhel-5-linux-i686 on RedHat and monitor an Oracle 11.2.0.2.0.

I can see Network traffic.

I can see local traffic, but only for users logged as sysdba. The reports show me BEQUEATH traffic for this user.

When i run a sqlplus query as "normal" user, i can't see it in the reports.

I see more or less the same information sent by the S-TAP to the collector (tcpdump when NO-TLS).

Collector is running version 9, patch1, 2 and 50.

Any suggestions ?

Regards

 

  • John_Haldeman
    John_Haldeman
    28 Posts

    Re: local traffic for sysda only

    ‏2013-07-17T15:01:17Z  

    Interesting problem. When you say you can't see local traffic for those users, what report are you using to determine that? If you create a new report with the main entity of SESSION and only include fields from SESSION and CLIENT/SERVER are you able to see the session information?

    If you can, but you can't see the local connection in another report that say has FULL SQL or SQL or COMMAND as the main entity, it's probably an issue with your policy not logging traffic for the sessions you're interested in.

  • gpy
    gpy
    23 Posts

    Re: local traffic for sysda only

    ‏2013-07-17T15:15:40Z  

    Interesting problem. When you say you can't see local traffic for those users, what report are you using to determine that? If you create a new report with the main entity of SESSION and only include fields from SESSION and CLIENT/SERVER are you able to see the session information?

    If you can, but you can't see the local connection in another report that say has FULL SQL or SQL or COMMAND as the main entity, it's probably an issue with your policy not logging traffic for the sessions you're interested in.

    Hi,

    i don't see any session activity for normal users and by the way any sql verb or object.

    I have one policy with no restrictions and LOG FULL DETAILS.

    It's a test system and i'm the only one generating traffic.

     Is that possible that sqlplus does use a different protocol for normal users as for sysdba ?

     

    Updated on 2013-07-17T15:17:28Z at 2013-07-17T15:17:28Z by gpy
  • John_Haldeman
    John_Haldeman
    28 Posts

    Re: local traffic for sysda only

    ‏2013-07-17T17:36:56Z  
    • gpy
    • ‏2013-07-17T15:15:40Z

    Hi,

    i don't see any session activity for normal users and by the way any sql verb or object.

    I have one policy with no restrictions and LOG FULL DETAILS.

    It's a test system and i'm the only one generating traffic.

     Is that possible that sqlplus does use a different protocol for normal users as for sysdba ?

     

    Sounds like you've got the right policy configuration in place to track everything in your test environment. I ran a little test with oracle 11.2 on RHEL with the same STAP version and the BEQUEATH traffic comes through for both SYS AS SYSDBA logins and normal logins. See attached. The normal login I used in the screenshot is called "GUARD".

    So, for me at least, I can't replicate.

     

    So, we know the following:

    1) Based on the tcpdumps you collected, the STAP seems to be reporting on the traffic

    2) You are sure that the Policy you are using tracks everything and is freshly installed (you might want to confirm that it's freshly installed)

    3) I can't replicate with a similar environment

     

    Maybe the problem is with your reports. Consider running the "Sessions List" built in report that comes standard with Guardium. That's the report I ran in the attached screenshot. It would help you confirm that Guardium picked up the sessions at least and it does not apply any filters in it's query. That report should show you something regardless of policy configuration.

     

    Attachments

  • 1XWY_TS_Teh
    1XWY_TS_Teh
    222 Posts

    Re: local traffic for sysda only

    ‏2013-07-19T14:04:15Z  

    Sounds like you've got the right policy configuration in place to track everything in your test environment. I ran a little test with oracle 11.2 on RHEL with the same STAP version and the BEQUEATH traffic comes through for both SYS AS SYSDBA logins and normal logins. See attached. The normal login I used in the screenshot is called "GUARD".

    So, for me at least, I can't replicate.

     

    So, we know the following:

    1) Based on the tcpdumps you collected, the STAP seems to be reporting on the traffic

    2) You are sure that the Policy you are using tracks everything and is freshly installed (you might want to confirm that it's freshly installed)

    3) I can't replicate with a similar environment

     

    Maybe the problem is with your reports. Consider running the "Sessions List" built in report that comes standard with Guardium. That's the report I ran in the attached screenshot. It would help you confirm that Guardium picked up the sessions at least and it does not apply any filters in it's query. That report should show you something regardless of policy configuration.

     

    Hi, it seem that you have upgraded to p50 which is 64-bit. And, I believe there are all new STAP for p50 - InfoSphere_Guardium_S-TAP_Red_Hat_9.0_r52864. You may want to download it from Fix Central and give it a try.

  • John_Haldeman
    John_Haldeman
    28 Posts

    Re: local traffic for sysda only

    ‏2013-07-19T14:11:52Z  

    Hi, it seem that you have upgraded to p50 which is 64-bit. And, I believe there are all new STAP for p50 - InfoSphere_Guardium_S-TAP_Red_Hat_9.0_r52864. You may want to download it from Fix Central and give it a try.

    TS has a good point. I tried to replicate with V9 p2, not p50. That being said, the old V9 STAP should be compatible with V9 p50. I hope at least that that is the case.

    TS, just a heads up that apparently p50 is only 64-bit if it's reimaged from scratch. So, if you had a 32-bit V9 appliance and ran the p50 upgrade scripts, you end up with a 32-bit V9p50 appliance. If you reimaged to V9p50 from scratch, you end up with a 64-bit V9p50 instance. At least that's how I understand it.

     

  • 1XWY_TS_Teh
    1XWY_TS_Teh
    222 Posts

    Re: local traffic for sysda only

    ‏2013-07-19T14:20:29Z  

    TS has a good point. I tried to replicate with V9 p2, not p50. That being said, the old V9 STAP should be compatible with V9 p50. I hope at least that that is the case.

    TS, just a heads up that apparently p50 is only 64-bit if it's reimaged from scratch. So, if you had a 32-bit V9 appliance and ran the p50 upgrade scripts, you end up with a 32-bit V9p50 appliance. If you reimaged to V9p50 from scratch, you end up with a 64-bit V9p50 instance. At least that's how I understand it.

     

    Hi John, so what you mean if apply the p50 on existing 32-bit appliance, it is still 32-bit and not upgraded to 64-bit unless we download the 64-bit image which has not available yet and perform fresh installation? But, if I read through the release note it sound like it will upgrade to 64-bit. 

  • John_Haldeman
    John_Haldeman
    28 Posts

    Re: local traffic for sysda only

    ‏2013-07-19T14:28:45Z  

    Hi John, so what you mean if apply the p50 on existing 32-bit appliance, it is still 32-bit and not upgraded to 64-bit unless we download the 64-bit image which has not available yet and perform fresh installation? But, if I read through the release note it sound like it will upgrade to 64-bit. 

    Hi TS,

    We're hijacking gpy's thread here a little but I see what you mean on the release notes. It sort of implies you have an option, but I think that only applies to new installs. What I've heard from the Guardium team at IBM is that if you upgrade a V9p2 instance to V9p50, your result is going to be 32-bit.

    But, it may be worth confirming ourselves. I've been meaning to run the patch and I suppose there's no time like the present. I'll let you know what it turns up.

    Cheers,

    John

  • 1XWY_TS_Teh
    1XWY_TS_Teh
    222 Posts

    Re: local traffic for sysda only

    ‏2013-07-19T14:33:32Z  

    Hi TS,

    We're hijacking gpy's thread here a little but I see what you mean on the release notes. It sort of implies you have an option, but I think that only applies to new installs. What I've heard from the Guardium team at IBM is that if you upgrade a V9p2 instance to V9p50, your result is going to be 32-bit.

    But, it may be worth confirming ourselves. I've been meaning to run the patch and I suppose there's no time like the present. I'll let you know what it turns up.

    Cheers,

    John

    Hi John, I have upgraded one of my VM to p50 and after the upgrade, when I login into GUI as admin, it will prompt the message for minimum of 8GB memory requirement. Does it indicate it has upgraded to 64-bit? If it is still 32-bit, it should not prompt me for the memory upgrade, right?

  • John_Haldeman
    John_Haldeman
    28 Posts

    Re: local traffic for sysda only

    ‏2013-07-19T17:12:37Z  

    Hi John, I have upgraded one of my VM to p50 and after the upgrade, when I login into GUI as admin, it will prompt the message for minimum of 8GB memory requirement. Does it indicate it has upgraded to 64-bit? If it is still 32-bit, it should not prompt me for the memory upgrade, right?

    Hi TS,

    Good point, but it is not always the case that a 32-bit operating system cannot access memory address space higher than 4GB. There's something called Physical Address Extension (PAE) that allows a linux OS with the right kernel to address more than 4GB:

    http://en.wikipedia.org/wiki/Physical_Address_Extension


    The trick is you need a PAE enabled linux kernel. I just updated my V9 sandbox to V9p50 and took a quick look at the kernel version:
        2.6.18-348.3.1.el5PAE #1 SMP Tue Mar 5 13:23:57 EST 2013 i686 i686 i386 GNU/Linux
    i386 there indicates it's a 32-bit OS and PAE indicates that it is enabled to use Physical Address Extension.

     

    Updated on 2013-07-19T17:13:11Z at 2013-07-19T17:13:11Z by John_Haldeman
  • 1XWY_TS_Teh
    1XWY_TS_Teh
    222 Posts

    Re: local traffic for sysda only

    ‏2013-07-20T01:15:24Z  

    Hi TS,

    Good point, but it is not always the case that a 32-bit operating system cannot access memory address space higher than 4GB. There's something called Physical Address Extension (PAE) that allows a linux OS with the right kernel to address more than 4GB:

    http://en.wikipedia.org/wiki/Physical_Address_Extension


    The trick is you need a PAE enabled linux kernel. I just updated my V9 sandbox to V9p50 and took a quick look at the kernel version:
        2.6.18-348.3.1.el5PAE #1 SMP Tue Mar 5 13:23:57 EST 2013 i686 i686 i386 GNU/Linux
    i386 there indicates it's a 32-bit OS and PAE indicates that it is enabled to use Physical Address Extension.

     

    Hi John, thanks. So, mean if we want to have 64-bit OS and MySQL, we will need to perform fresh installation for all the appliances. Well, this is crazy. 

    With PAE mean we can not utilise memory larger than 16GB, right? 

  • gpy
    gpy
    23 Posts

    Re: local traffic for sysda only

    ‏2013-07-22T11:57:27Z  

    Hi, it seem that you have upgraded to p50 which is 64-bit. And, I believe there are all new STAP for p50 - InfoSphere_Guardium_S-TAP_Red_Hat_9.0_r52864. You may want to download it from Fix Central and give it a try.

    Dear,

    I'm not realy convinced by this approach, but it works.

    I've uninstalled the version r48064, reboot the machine and instaledl the S-TAP r52864.

    Now i can see the all user accessing the DB localy.

    Thanks for all answers.

  • 1XWY_TS_Teh
    1XWY_TS_Teh
    222 Posts

    Re: local traffic for sysda only

    ‏2013-07-22T12:31:14Z  
    • gpy
    • ‏2013-07-22T11:57:27Z

    Dear,

    I'm not realy convinced by this approach, but it works.

    I've uninstalled the version r48064, reboot the machine and instaledl the S-TAP r52864.

    Now i can see the all user accessing the DB localy.

    Thanks for all answers.

    Hi, glad to heard that and thanks for the update. 

  • John_Haldeman
    John_Haldeman
    28 Posts

    Re: local traffic for sysda only

    ‏2013-07-22T13:09:46Z  
    • gpy
    • ‏2013-07-22T11:57:27Z

    Dear,

    I'm not realy convinced by this approach, but it works.

    I've uninstalled the version r48064, reboot the machine and instaledl the S-TAP r52864.

    Now i can see the all user accessing the DB localy.

    Thanks for all answers.

    Strange. I failed to replicate your error with r48064 and V9p50. So, your original situation worked for me.

  • gpy
    gpy
    23 Posts

    Re: local traffic for sysda only

    ‏2013-07-22T14:09:22Z  

    Strange. I failed to replicate your error with r48064 and V9p50. So, your original situation worked for me.

    i agree. By having re (re ... re) installed the same version has may be solved my problem too.