상황에 따라, 환경에 따라 여러가지 형태의 path 존재할  있다.

C:\Windows\System32
/usr/bin
https://www.naver.com

여러 형태의 path  유독 윈도우만 디렉토리 구분자로 백슬래시(backslashs, ‘\’) 사용하고   다른 모든 환경에서는 슬래시(forward slashs, ‘/‘) 사용한다.  Windows에서만 백슬래시를 사용하는 것일까.

 

Windows에서 백슬래시를 사용하게  배경

1970년경, Unix 슬래시를 디렉토리 구분자로 소개했다.  슬래시를 선택했는지는 모른다.

그리고 1981, Windows MS-DOS 1.0 발표하였다. MS-DOS 1.0 나도 경험한 적이 없기에  모르지만 놀랍게도 디렉토리 개념이 없었다고 한다. 그리고 슬래시를 옵션값 설정용으로 사용을 했다. 이러한 기능은 현재도 유효하다. CMD에서 dir/w 입력하면 가로 목록 형식으로 출력되는 것을 확인할  있다.('help dir'을 입력하면 슬래시를 이용한 여러 옵션 값들을 확인할 수 있다.)

도스에서 '/'의 기능

이후 MS-DOS 2.0에서 디렉토리를 지원하기 시작하였고, 디렉토리 구분자가 필요하게 되었다. 그러나 Unix에서와 같이 슬래시를 디렉토리 구분자로 사용하면 MS-DOS 1.0 옵션 구분자와 충돌이 발생하여 사용할  없었다. 그때라도 옵션 구분자를 다른 문자로 변경했다면 문제가 없었겠지만 MS 디렉토리 구분자를 다른 문자로 바꾸어 사용하기 시작했다. 그  변경한 디렉토리 구분자가 백슬래시이다.

 

OS 따라 디렉토리 구분자를 정확히 써야만 하는가?

최근의 많은 소프트웨어들은  가지 모두를 호환하고 있다. 

Windows 탐색기에서 C:/Windows/System32 입력하면 슬래시가 백슬래시로 변경되어 검색된다.

Chrome 브라우저에서 백슬래시로 URL 입력해도 슬래시로 변경되어 검색된다.

이렇듯 많은 소프트웨어가 디렉토리 구분자로 슬래시와 백슬래시를 모두 지원하고 있다. (테스트 결과 Unix계열에서는 백슬래시를 호환하지 않았다.)

 

하지만 정확한 디렉토리 구분자를 쓰는 것을 권장한다.

많은 소프트웨어가  가지 모두를 호환하지만 그렇지 않는 프로그램도 많기 때문이다. 상황에 맞게 경로를 입력하는 것이 바람직하다.

 

주의 - 보안적 이슈

시스템 API 또한 슬래시와 백슬래시를 모두 지원하는 경우가 있다. 예를 들어 win32 api의 CopyFile 함수의 파라메터에 슬래시가 포함 된 경로를 입력할 경우 백슬래시로 변경하여 인식하게 된다. 이 때문에 사용자로부터 경로를 입력받아 처리하는 경우, 입력 값에 슬래시가 포함되어 있는 상황을 고려해야 한다. 

예를 들어 사용자로부터 입력받은 경로가 C:\Windows\System32  경우 에러가 발생하도록 프로그램을 개발한다고 가정해보자.

입력받은 파라메터를 “C:\Windows\System32” 단순비교 한다면, 사용자가 경로를 “C:/Windows/System32” 입력 할 경우 이를 찾아내지 못할 것이다. 하지만 시스템 API “C:/Windows/System32”에도 정상 동작하므로 프로그램은 해당 경로로 접근할 것이다.

그렇기에 경로를 입력받을  디렉토리 구분자를 통일시키는 작업을 선행하는 것이 바람직하다.

 

[참고]

https://www.howtogeek.com/181774/why-windows-uses-backslashes-and-everything-else-uses-forward-slashes/

3개의 노드로 구성된 쿠버네티스 클러스터에서 replica가 2인 pod를 배포하고 NodePort로 서비스를 등록했더니 접근했던 노드에서 실행 중인 pod만 응답을 하는 현상이 발생했다.

 

정상적인 상황이라면 어떤 노드로 접근을 하던지 서비스는 실행중인 pod 중 하나로 연결을 해줘야 하는데, 접근을 시도했던 IP의 노드에서 동작중인 pod에만 접근이 가능하였다. 3개 노드 중 pod가 떠있지 않은 노드로 연결을 시도하면 pod에 연결되지 못해 응답을 받지 못했다.

 

이를 해결하기 위해 두 가지 설정을 체크해야 한다.

 

1. Forward 방화벽 설정

노드로 접근한 트래픽을 다른 노드로 Forward 하기 위해 노드들에서 방화벽을 허용해야 한다.

# iptables -P FORWARD ACCEPT

 

2. CNI CIDR 설정

나의 경우에는 CNI로 Calico를 사용했다. Calico 설치 시 pod의 네트워크 CIDR를 설정하는데 이 값을 kubernetes의 CIDR와 매칭 시켜야 한다.

...
  - name: CALICO_IPV4POOL_CIDR
    value: 10.5.0.0/16
....

 

Known DLL이란 Windows 운영체제가 아주 특별하게 취급하는 몇몇의 DLL을 말한다.

 

Known DLL에 속한 DLL은 시스템 부팅 시 미리 캐시로 로드가 되고, 이후 해당 DLL을 호출할 때 시스템에서 DLL들을 검색하지 않고 미리 캐시 된 DLL을 사용하게 된다.

Known DLL 목록은 아래 레지스트리를 통해 확인이 가능하다.

레지스트리: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\KnownDLLs

레지스트리를 보면 아래와 같이 DLL 정보가 입력되어 있는 것을 확인할 수 있다.

Known-dll 정보

 

애플리케이션이 LoadLibrary나 LoadLibraryEx 함수로 DLL을 호출할 때, DLL 이름에 .dll 확장자가 포함되어 있으면 확장자를 제거한 이름을 위의 레지스트리에서 찾아 그 값에 입력되어 있는 DLL을 호출한다.

만약 DLL 이름에 .dll 확장자를 넣지 않으면 일반적인 DLL 검색 순서에 따라 검색을 진행한다.

 

원래는 애플리케이션의 로딩 속도 개선이 목적이었으나 보안적인 측면에서도 의미가 있다.

애플리케이션이 DLL 검색 순서에 따라 DLL을 찾을 때, 공격자가 우선순위가 높은 곳에 악성 DLL을 심어 놓으면 애프리케이션은 악성 DLL을 로드하게 되고 애플리케이션의 권한을 탈취할 수 있게 된다.

하지만 Known DLL을 사용할 때에는 시스템에서 DLL을 검색하지 않고 캐시 된 DLL을 사용하므로 이러한 공격을 회피하는데 도움을 준다.

+ Recent posts