폴 그린과 나는 그가 작업 중인 새로운 명령어인 check_module_security에 대해 논의하고 있었다. 로그인 프롬프트에서 불필요하게 제공되는 명령어에 대한 이야기가 나왔다. 트랜잭션 디자인의 존 슈미트는 '문 닫기(Locking the Barn Door)'에 관한 글에서 권고한다.
내부 명령어:
display_current_module (prelogin)
list_modules (prelogin) display_date_time (prelogin)
list_systems (prelogin)
display_line (prelogin)
login (prelogin)
If there are other commands shown, remove them.
나는 명령어 같은 것들에 대해 생각하게 되었는데 list_modules 그리고 list_systems; 설령 여러분이 자신의 모듈이나 시스템을 보호하기 위해 애를 썼더라도, 이러한 명령어들은 해커에게 다른 모듈/시스템에 대한 힌트를 제공할 수 있습니다. 해당 모듈/시스템은 보안이 취약할 수 있으며, 이를 악용할 수 있습니다. login -module그래서 우리는 로그인 전 단계에서 이들의 사용을 차단하는 방법을 고민했습니다. 제가 찾은 한 가지 방법은 다음과 같습니다:
액세스 목록 이름으로 사용할 고유한 이름의 파일을 생성합니다. 이 경우, 저는 prelogin_no_access 특정 사용자의 접근을 금지하려는 명령어에 첨부됩니다. 파일 자체의 내용은 무의미하며, 중요한 것은 파일에 첨부된 접근 제어 목록입니다. 이 파일은 특별한 위치에 저장됩니다: (master_disk)>system>acl 디렉터리. 제한하려는 사용자는 PreLogin.System로그인 프롬프트를 실행하는 사용자입니다. 다른 사용자에게도 (로그인 후) 접근 권한을 부여하는 것을 잊지 마십시오. 귀하는 특권 사용자여야 하며 SysAdmin 대부분의 사이트에서 이러한 작업을 수행하는 그룹.
change_current_dir (master_disk)>system>acl
create_file prelogin_no_access
give_access null prelogin_no_access -user PreLogin.System
give_access write prelogin_no_access -user *.*
제한하려는 명령어가 해당 액세스 목록을 사용하도록 internal_commands.tin에 구성되었는지 확인하십시오…
%phx_vos#m14_mas>system.14.7>configuration>internal_commands.tin 07-10-02 12:14
/ =name display_current_module
=access_list_name prelogin_no_access
=audit 0
/ =name list_modules
=access_list_name prelogin_no_access
=audit 0
변경이 필요하다면, 그 변경 사항을 적용해야 합니다.
create_table internal_commands.ti
broadcast_file internal_commands.table (master_disk)>system
configure_commands
이제 로그인 시 금지된 명령어를 사용해 볼 수 있습니다
VOS Release 15.3.0ai, Module %phx_vos#m15
Please login 12:13:19
help
Internal Commands:
change_password (prelogin) help (prelogin)
display_current_module (prelogin) list_modules (prelogin)
display_date_time (prelogin) list_systems (prelogin)
display_line (prelogin) login (prelogin)
VOS Release 15.3.0ai, Module %phx_vos#m15
Please login 12:13:23
list_modules
command_processor: Not enough access to perform operation. list_modules.
모든 내부 명령어를 제한하지는 않았습니다; 따라서 영향을 받지 않는 명령어들은 여전히 사용할 수 있습니다.
VOS Release 15.3.0ai, Module %phx_vos#m15
Please login 12:13:29
list_systems
phx_osn . . . . . . online (local)
phx_test . . . . . . online (local)
phx_vos . . . . . . online (current system)
그러니 중요하다고 생각하는 것들은 제한하는 것을 잊지 마세요.
VOS Release 15.3.0ai, Module %phx_vos#m15
Please login 12:13:39
display_current_module
command_processor: Not enough access to perform operation.
display_current_module.
VOS Release 15.3.0ai, Module %phx_vos#m15
Please login 12:13:53
보너스가 있습니다: 보안 로깅이 활성화되어 있다면, 누군가가 해당 명령어 중 하나를 사용하려 시도했다는 사실을 알려주는 보안 로그 항목이 생성됩니다.
1: 07-10-02 12:16:20 mst PreLogin.System %phx_vos#tli_log.m15_65
Target: list_modules
Text: Not enough access to perform operation. Validating object access.
모든 것을 다 다루었나요? 전혀 그렇지 않습니다. 이 간단한 튜토리얼의 부족한 점 몇 가지를 정리해 보겠습니다:
– list_modules 및 display_current_module 명령어가 비활성화되었음에도 로그인 배너에는 여전히 모듈명이 표시됩니다.
– 로그인 배너가 릴리스 이름을 표시할 때 여전히 VOS 시스템임을 암시하는 단서를 제공합니다.
– list_systems 명령어가 여전히 작동합니다(이 예시를 위해 의도적으로 허용되었으나, 이 역시 금지되어야 합니다).
추가 포인트는 다른 방법이 무엇인지 알아내는 분께 드립니다. 힌트: 명령어 기능은 여전히 작동합니다.
-댄 단즈, VOS 서비스 기술 컨설턴트
폴 그린과 나는 그가 작업 중인 새로운 명령어인 check_module_security에 대해 논의하고 있었다. 로그인 프롬프트에서 불필요하게 제공되는 명령어에 대한 이야기가 나왔다. 트랜잭션 디자인의 존 슈미트는 '문 닫기(Locking the Barn Door)'에 관한 글에서 권고한다.
내부 명령어:
display_current_module (prelogin)
list_modules (prelogin) display_date_time (prelogin)
list_systems (prelogin)
display_line (prelogin)
login (prelogin)
If there are other commands shown, remove them.
나는 명령어 같은 것들에 대해 생각하게 되었는데 list_modules 그리고 list_systems; 설령 여러분이 자신의 모듈이나 시스템을 보호하기 위해 애를 썼더라도, 이러한 명령어들은 해커에게 다른 모듈/시스템에 대한 힌트를 제공할 수 있습니다. 해당 모듈/시스템은 보안이 취약할 수 있으며, 이를 악용할 수 있습니다. login -module그래서 우리는 로그인 전 단계에서 이들의 사용을 차단하는 방법을 고민했습니다. 제가 찾은 한 가지 방법은 다음과 같습니다:
액세스 목록 이름으로 사용할 고유한 이름의 파일을 생성합니다. 이 경우, 저는 prelogin_no_access 특정 사용자의 접근을 금지하려는 명령어에 첨부됩니다. 파일 자체의 내용은 무의미하며, 중요한 것은 파일에 첨부된 접근 제어 목록입니다. 이 파일은 특별한 위치에 저장됩니다: (master_disk)>system>acl 디렉터리. 제한하려는 사용자는 PreLogin.System로그인 프롬프트를 실행하는 사용자입니다. 다른 사용자에게도 (로그인 후) 접근 권한을 부여하는 것을 잊지 마십시오. 귀하는 특권 사용자여야 하며 SysAdmin 대부분의 사이트에서 이러한 작업을 수행하는 그룹.
change_current_dir (master_disk)>system>acl
create_file prelogin_no_access
give_access null prelogin_no_access -user PreLogin.System
give_access write prelogin_no_access -user *.*
제한하려는 명령어가 해당 액세스 목록을 사용하도록 internal_commands.tin에 구성되었는지 확인하십시오…
%phx_vos#m14_mas>system.14.7>configuration>internal_commands.tin 07-10-02 12:14
/ =name display_current_module
=access_list_name prelogin_no_access
=audit 0
/ =name list_modules
=access_list_name prelogin_no_access
=audit 0
변경이 필요하다면, 그 변경 사항을 적용해야 합니다.
create_table internal_commands.ti
broadcast_file internal_commands.table (master_disk)>system
configure_commands
이제 로그인 시 금지된 명령어를 사용해 볼 수 있습니다
VOS Release 15.3.0ai, Module %phx_vos#m15
Please login 12:13:19
help
Internal Commands:
change_password (prelogin) help (prelogin)
display_current_module (prelogin) list_modules (prelogin)
display_date_time (prelogin) list_systems (prelogin)
display_line (prelogin) login (prelogin)
VOS Release 15.3.0ai, Module %phx_vos#m15
Please login 12:13:23
list_modules
command_processor: Not enough access to perform operation. list_modules.
모든 내부 명령어를 제한하지는 않았습니다; 따라서 영향을 받지 않는 명령어들은 여전히 사용할 수 있습니다.
VOS Release 15.3.0ai, Module %phx_vos#m15
Please login 12:13:29
list_systems
phx_osn . . . . . . online (local)
phx_test . . . . . . online (local)
phx_vos . . . . . . online (current system)
그러니 중요하다고 생각하는 것들은 제한하는 것을 잊지 마세요.
VOS Release 15.3.0ai, Module %phx_vos#m15
Please login 12:13:39
display_current_module
command_processor: Not enough access to perform operation.
display_current_module.
VOS Release 15.3.0ai, Module %phx_vos#m15
Please login 12:13:53
보너스가 있습니다: 보안 로깅이 활성화되어 있다면, 누군가가 해당 명령어 중 하나를 사용하려 시도했다는 사실을 알려주는 보안 로그 항목이 생성됩니다.
1: 07-10-02 12:16:20 mst PreLogin.System %phx_vos#tli_log.m15_65
Target: list_modules
Text: Not enough access to perform operation. Validating object access.
모든 것을 다 다루었나요? 전혀 그렇지 않습니다. 이 간단한 튜토리얼의 부족한 점 몇 가지를 정리해 보겠습니다:
– list_modules 및 display_current_module 명령어가 비활성화되었음에도 로그인 배너에는 여전히 모듈명이 표시됩니다.
– 로그인 배너가 릴리스 이름을 표시할 때 여전히 VOS 시스템임을 암시하는 단서를 제공합니다.
– list_systems 명령어가 여전히 작동합니다(이 예시를 위해 의도적으로 허용되었으나, 이 역시 금지되어야 합니다).
추가 포인트는 다른 방법이 무엇인지 알아내는 분께 드립니다. 힌트: 명령어 기능은 여전히 작동합니다.