- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Strange intrusion behaviour
Operating System - OpenVMS
1752805
Members
5373
Online
108789
Solutions
Forums
Categories
Company
Local Language
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-24-2005 11:58 PM
10-24-2005 11:58 PM
Strange intrusion behaviour
I have a program that tries to connect to a non-existing server, which is a decnet object.
Of course it fails but I get in operator log :
%%%%%%%%%%% OPCOM 23-OCT-2005 13:36:23.27 %%%%%%%%%%%
Message from user SYSTEM on SPVMX2
Event: Access Control Violation from: Node LOCAL:.SPVMX2 Session Control,
at: 2005-10-23-13:36:23.273+02:00Iinf
NSAP Address=49::00-14:AA-00-04-00-02-50:20,
Source=UIC = [0,0]GIS_MAINT,
Destination=name = FOE_FMI_SRV,
Destination User="",
Destination Account="",
Node Name=LOCAL:.SPVMX2
eventUid 008FD160-43CA-11DA-860F-AA0004000250
entityUid 10953BB1-43B8-11DA-8372-AA0004000250
streamUid 1FAE48D0-43B8-11DA-8501-AA0004000250
In audit I get :
Security audit (SECURITY) on SPVMX2, system id: 20482
Auditable event: Network login failure
Event time: 23-OCT-2005 13:36:23.27
PID: 2160021D
Process name: NET$ACP
Username: *DECNET_TASK*
Remote node id: 490014AA000400025020
Remote node fullname: LOCAL:.SPVMX2
Remote username: GIS_MAINT
Status: %LOGIN-F-NOSUCHUSER, no such user
The LGI params :
LGI_BRK_TERM 0 1 0 1 Boolean D
LGI_BRK_DISUSER 0 0 0 1 Boolean D
LGI_PWD_TMO 30 30 0 255 Seconds D
LGI_RETRY_LIM 3 3 0 255 Tries D
LGI_RETRY_TMO 20 20 2 255 Seconds D
LGI_BRK_LIM 6 5 1 255 Failures D
LGI_BRK_TMO 600 300 0 5184000 Seconds D
LGI_HID_TIM 60 300 0 1261440000 Seconds D
LGI_CALLOUTS 0 0 0 255 Count D
The violation is repeated a lot of times and when I do show intrus I got a suspect intrusion with more than 120 violations in 1 hour (uptime). This while I was expecting an real intruder.
1) Why no intruder ?
2) Why is a non-existing ncl object leading to intrusion (if I do the same with type x::77=yyy" I don't get a violation but simply network object unknown) ?
2) Is it possible that a suspect intruder blocks something ?
Wim
Wim
Of course it fails but I get in operator log :
%%%%%%%%%%% OPCOM 23-OCT-2005 13:36:23.27 %%%%%%%%%%%
Message from user SYSTEM on SPVMX2
Event: Access Control Violation from: Node LOCAL:.SPVMX2 Session Control,
at: 2005-10-23-13:36:23.273+02:00Iinf
NSAP Address=49::00-14:AA-00-04-00-02-50:20,
Source=UIC = [0,0]GIS_MAINT,
Destination=name = FOE_FMI_SRV,
Destination User="",
Destination Account="",
Node Name=LOCAL:.SPVMX2
eventUid 008FD160-43CA-11DA-860F-AA0004000250
entityUid 10953BB1-43B8-11DA-8372-AA0004000250
streamUid 1FAE48D0-43B8-11DA-8501-AA0004000250
In audit I get :
Security audit (SECURITY) on SPVMX2, system id: 20482
Auditable event: Network login failure
Event time: 23-OCT-2005 13:36:23.27
PID: 2160021D
Process name: NET$ACP
Username: *DECNET_TASK*
Remote node id: 490014AA000400025020
Remote node fullname: LOCAL:.SPVMX2
Remote username: GIS_MAINT
Status: %LOGIN-F-NOSUCHUSER, no such user
The LGI params :
LGI_BRK_TERM 0 1 0 1 Boolean D
LGI_BRK_DISUSER 0 0 0 1 Boolean D
LGI_PWD_TMO 30 30 0 255 Seconds D
LGI_RETRY_LIM 3 3 0 255 Tries D
LGI_RETRY_TMO 20 20 2 255 Seconds D
LGI_BRK_LIM 6 5 1 255 Failures D
LGI_BRK_TMO 600 300 0 5184000 Seconds D
LGI_HID_TIM 60 300 0 1261440000 Seconds D
LGI_CALLOUTS 0 0 0 255 Count D
The violation is repeated a lot of times and when I do show intrus I got a suspect intrusion with more than 120 violations in 1 hour (uptime). This while I was expecting an real intruder.
1) Why no intruder ?
2) Why is a non-existing ncl object leading to intrusion (if I do the same with type x::77=yyy" I don't get a violation but simply network object unknown) ?
2) Is it possible that a suspect intruder blocks something ?
Wim
Wim
Wim
1 REPLY 1
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-25-2005 10:11 PM
10-25-2005 10:11 PM
Re: Strange intrusion behaviour
Hi,
1)As I understand it, LGI_HID_TIM gives the period for the Intruder state. So after the 60 seconds are reached the system probably returns the value 'suspect' to intrusion record. Try to watch it. You should see Intruder state some times. Or encrease LGI_HID_TIM.
2) There is for sure an logging sequence happening under the username *DECNET_TASK*. The connect request to a server as you've written (not to an object) probably causes it.
3)Suspect state shouldn't block nothing. It's defined by LGI_BRK_TMO and it specifies the length of the failure monitoring
period. This time increment is added to the suspect's expiration
time each time a login failure occurs. Once the expiration period
passes, prior failures are discarded, and the suspect is given a
clean slate.
Mike
1)As I understand it, LGI_HID_TIM gives the period for the Intruder state. So after the 60 seconds are reached the system probably returns the value 'suspect' to intrusion record. Try to watch it. You should see Intruder state some times. Or encrease LGI_HID_TIM.
2) There is for sure an logging sequence happening under the username *DECNET_TASK*. The connect request to a server as you've written (not to an object) probably causes it.
3)Suspect state shouldn't block nothing. It's defined by LGI_BRK_TMO and it specifies the length of the failure monitoring
period. This time increment is added to the suspect's expiration
time each time a login failure occurs. Once the expiration period
passes, prior failures are discarded, and the suspect is given a
clean slate.
Mike
...and I think to myself, what a wonderful world ;o)
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP