그누보드 설치 후 퍼미션 조정 정보
일반 그누보드 설치 후 퍼미션 조정본문
설치 후 그누보드 경로의 퍼미션을 705 또는 701로 변경해 주셔야 그나마 조금이라도 안전(?!)합니다.
질문/답변 내용중에서 '완두콩'님께서 언급 하셨듯이 그누보드 설치 후에는 해당 경로의 퍼미션을
적절히 조정해 주셔야 합니다.
퍼미션 조정에 들어가기에 앞서 각각의 퍼미션에 따른 간략한 설명을 기재합니다.
r-w-x
r : read (읽기,접근,수행) ===> 4
w : write(쓰기,삭제) ===> 2
x : excutive(실행,접근권한,execution) ===> 1
1. 웹문서루트(www 또는 public_html --- 호스팅 업체마다 다름)에 그누보드를 설치하셨다면,
설치후에는 웹문서루트의 퍼미션을 705 또는 701로 변경.
2. 웹문서루트 이하에 그누보드가 설치되어 있을 경우에는,
/웹문서루트/gnu3 ---> gnu3 경로의 퍼미션을 705 또는 701로 변경.
3. 상기한 1. 2.의 과정을 수행하는 이유는 다음과 같습니다.
퍼미션을 705로 조정하는 경우는 가장 일반적인(?!) 형태의 조정입니다만,
퍼미션을 701로 조정하는 경우는 동일 서버의 그룹사용자 또는 일반 사용자의 접근을 막는 효과도
포함됩니다.
즉, 내 계정의 디렉토리 구조를 훤히 알고 있는 상태가 아니라면,
원천적으로 내 계정에 접근할 수 없다는 의미지요.
물론, 이 부분은 해당 호스팅 업체에서 root를 제외하고는 각각의 사용자 계정에 접근할 수 없도록 설정되어
있습니다. 혹시라도 이렇게 설정되지 않아서 특정 유저의 계정공간에 접근할 수 있는 호스팅 업체가 있다면,
당장 시정을 요구하십시오.
만약 시정이 안된다면???
호스팅 업체 바꾸십시오!!!
<그누보드 설치 후 특정 경로 이하의 퍼미션 조정>
//gnu3
-. 경로 : 705 또는 701
설치 후 gnu3경로의 퍼미션은 705 또는 701로 조정.
단, 705가 아닌 701로 설정했을 경우의 문제점은 다음과 같다.
그누보드 설치 경로 이하에 존재하는 전체적인 계정 공간을 웹페이지에서 확인할 수 없음.
그누보드 설치경로(//gnu3/)에 대해서만 701로 조정한다면, 상기된 전체 사용량에 대한 부분에
관해서는 정상적으로 사용할 수 없으나, 실제 그누보드가 구동되는 것에는 전혀 문제가 없음.
만약 자신이 사용하는 홈페이지에서 계정사용량(HDD)를 구현하고 있지 않다면,
웹문서루트(www 또는 public_html)나 그누보드의 설치경로의 퍼미션은 701로 조정하시는 것이
그나마 자신의 계정으로 접근하는 것을 방지할 수 있음.
-. 만약 호스팅 업체의 root가 뚫려 버린다면??? 음냐... 방법 없음.
-. 많이 다뤄진 내용이지만, root의 권한은 막강 그 자체이기 때문에...
-. 파일 : 604
/bbs/
-. 경로 : 705
-. 파일 : 604
/bbs/skin/ 및 이하의 경로
-. 경로 : 705
해당경로 및 그 이하의 board, outlogin, member 등의 퍼미션이 701로 설정되어 있는 경우는,
최고관리자 모드에서 특정 스킨의 목록이 표시되지 않으며, 선택 또한 할 수 없음.
팁텍 또는 스킨자료실, 자작프로그램에 공개되어 있는 각종 유틸리티(?!)를 효율적으로 활용할 수 없음.
계정사용공간(HDD)에 대한 실제 사용용량이 다르게(적게) 출력됨.
그러나, DB 사용용량은 정상적으로 출력됨.
-. 파일 : 604
/lib/
-. 경로 : 705 (만약 경로의 퍼미션이 701로 설정되어 있다면, 오류메시지가 출력됨)
why? include된 파일이 존재하는 경우, 해당 경로의 퍼미션이 701로 지정되어 있을 경우,
실제 include되는 목적(target)파일을 인식하지 못함.
간혹 /lib/ 경로의 퍼미션을 701로 설정해도 오류메시지없이 정상 인식한다는 분들이 계시는데,
/lib 경로를 701로 조정했을 경우 inlucde되는 파일이 해당 경로 이하에 존재할 경우, 정상적으로 인식할 수 없음.
(관련 오류 : open failed 어쩌고...)
-. 파일 : 604
<참조사항 1.>
Q. 파일의 퍼미션이 하나같이 604인 이유는?
A. 웹으로 구현되는 각각의 페이지(html,php,asp,jsp ...)들은 서버측에서 읽혀지는 것으로
사용자의 웹브라우저에서 정상적으로 구현됩니다.
만약 특정 파일의 퍼미션이 601로 지정되어 있을 경우, 정상적인 서버 환경에서는 해당 웹페이지에
접근할 수 없다는 메시지가 출력되거나 수행(?!)할 수 없다는 오류메시지가 출력됩니다.
그러나, 서버 환경에서 해당 퍼미션 미만일 경우 환경설정이 적절치 못한 경우라면,
php를 비롯한 서버스크립트 언어(asp,jsp...)의 소스코드가 그대로 웹브라우저상에 노출될 위험이 있습니다.
물론, 이러한 경우는 지극히 이례적이며, 대부분 개인이 테스트를 위해 서버를 설치하고 서버 환경설정에
문제가 있을 경우에 발생하는 경우이며, 만약 호스팅 업체를 이용하고 있을 경우에 이러한 현상이 자주(?!)
발생한다면 당장 호스팅 업체를 변경하시기 바랍니다.(사실 자주 이런 문제가 발생하는 호스팅 업체는 없음.)
<참조사항 2.>
Q. 그누보드 설치 후 파일이나 특정경로(디렉토리)를 생성하는데 왜 하필 644, 755와 같은 형태로 생성되나요?
A. 서버 및 root 관리자의 편의(?!)를 제공하기 위해서가 아닐지...(이거 무쟈게 무식한 발언이네요. 에구~*)
가장 간단한 답변은, unix 계열을 프로그래밍할때 프로그래머의 맘대로 설정된 부분이라고
답변하는 것이 가장 적절(?!)한 답변인 듯 합니다.
일례로 리눅스 계열에서 y*로 시작되는 명령(어)은 없습니다.
뭐 어거지로 만든다면 있다고 봐도 반문하셔도 할말은 없지만...
제가 개인적으로 즐겨하는 철자의 시작이 y*라서 ~*^^*
여러분께서도 이미 알고 계시듯이 root 관리자는 특정 개개인의 사용자(계정)에 관해서만 관리를 하지 않습니다.
일종의 분류의 개념인 그룹(group)을 생성하고 그에 따른 개인계정의 집합체를 만들고 적절한 관리를 수행합니다.
따라서 umask 값이 022인 이유를 추론할 수 있는 부분입니다.
서버의 root(최고관리자)일 경우만 변경 가능.
일반적으로 /etc/profile에 umask 022 과 같이 umask로 지정되어 있는 부분이 있습니다.
이것은 파일 및 디렉토리를 생성할 경우, 퍼미션의 최대치(?!)인 777에서 umsak된 값 만큼 변경 후
최종적으로 파일이나 경로(디렉토리) 생성시 적용된다고 보시면 됩니다.
-추신-
정리해서 간략히 올려야 하는데...
팁텍이라고 하기도 뭐 하지만...
가끔씩 얘기되는 내용이라 생각되어 올려 봅니다.
질문/답변 내용중에서 '완두콩'님께서 언급 하셨듯이 그누보드 설치 후에는 해당 경로의 퍼미션을
적절히 조정해 주셔야 합니다.
퍼미션 조정에 들어가기에 앞서 각각의 퍼미션에 따른 간략한 설명을 기재합니다.
r-w-x
r : read (읽기,접근,수행) ===> 4
w : write(쓰기,삭제) ===> 2
x : excutive(실행,접근권한,execution) ===> 1
1. 웹문서루트(www 또는 public_html --- 호스팅 업체마다 다름)에 그누보드를 설치하셨다면,
설치후에는 웹문서루트의 퍼미션을 705 또는 701로 변경.
2. 웹문서루트 이하에 그누보드가 설치되어 있을 경우에는,
/웹문서루트/gnu3 ---> gnu3 경로의 퍼미션을 705 또는 701로 변경.
3. 상기한 1. 2.의 과정을 수행하는 이유는 다음과 같습니다.
퍼미션을 705로 조정하는 경우는 가장 일반적인(?!) 형태의 조정입니다만,
퍼미션을 701로 조정하는 경우는 동일 서버의 그룹사용자 또는 일반 사용자의 접근을 막는 효과도
포함됩니다.
즉, 내 계정의 디렉토리 구조를 훤히 알고 있는 상태가 아니라면,
원천적으로 내 계정에 접근할 수 없다는 의미지요.
물론, 이 부분은 해당 호스팅 업체에서 root를 제외하고는 각각의 사용자 계정에 접근할 수 없도록 설정되어
있습니다. 혹시라도 이렇게 설정되지 않아서 특정 유저의 계정공간에 접근할 수 있는 호스팅 업체가 있다면,
당장 시정을 요구하십시오.
만약 시정이 안된다면???
호스팅 업체 바꾸십시오!!!
<그누보드 설치 후 특정 경로 이하의 퍼미션 조정>
//gnu3
-. 경로 : 705 또는 701
설치 후 gnu3경로의 퍼미션은 705 또는 701로 조정.
단, 705가 아닌 701로 설정했을 경우의 문제점은 다음과 같다.
그누보드 설치 경로 이하에 존재하는 전체적인 계정 공간을 웹페이지에서 확인할 수 없음.
그누보드 설치경로(//gnu3/)에 대해서만 701로 조정한다면, 상기된 전체 사용량에 대한 부분에
관해서는 정상적으로 사용할 수 없으나, 실제 그누보드가 구동되는 것에는 전혀 문제가 없음.
만약 자신이 사용하는 홈페이지에서 계정사용량(HDD)를 구현하고 있지 않다면,
웹문서루트(www 또는 public_html)나 그누보드의 설치경로의 퍼미션은 701로 조정하시는 것이
그나마 자신의 계정으로 접근하는 것을 방지할 수 있음.
-. 만약 호스팅 업체의 root가 뚫려 버린다면??? 음냐... 방법 없음.
-. 많이 다뤄진 내용이지만, root의 권한은 막강 그 자체이기 때문에...
-. 파일 : 604
/bbs/
-. 경로 : 705
-. 파일 : 604
/bbs/skin/ 및 이하의 경로
-. 경로 : 705
해당경로 및 그 이하의 board, outlogin, member 등의 퍼미션이 701로 설정되어 있는 경우는,
최고관리자 모드에서 특정 스킨의 목록이 표시되지 않으며, 선택 또한 할 수 없음.
팁텍 또는 스킨자료실, 자작프로그램에 공개되어 있는 각종 유틸리티(?!)를 효율적으로 활용할 수 없음.
계정사용공간(HDD)에 대한 실제 사용용량이 다르게(적게) 출력됨.
그러나, DB 사용용량은 정상적으로 출력됨.
-. 파일 : 604
/lib/
-. 경로 : 705 (만약 경로의 퍼미션이 701로 설정되어 있다면, 오류메시지가 출력됨)
why? include된 파일이 존재하는 경우, 해당 경로의 퍼미션이 701로 지정되어 있을 경우,
실제 include되는 목적(target)파일을 인식하지 못함.
간혹 /lib/ 경로의 퍼미션을 701로 설정해도 오류메시지없이 정상 인식한다는 분들이 계시는데,
/lib 경로를 701로 조정했을 경우 inlucde되는 파일이 해당 경로 이하에 존재할 경우, 정상적으로 인식할 수 없음.
(관련 오류 : open failed 어쩌고...)
-. 파일 : 604
<참조사항 1.>
Q. 파일의 퍼미션이 하나같이 604인 이유는?
A. 웹으로 구현되는 각각의 페이지(html,php,asp,jsp ...)들은 서버측에서 읽혀지는 것으로
사용자의 웹브라우저에서 정상적으로 구현됩니다.
만약 특정 파일의 퍼미션이 601로 지정되어 있을 경우, 정상적인 서버 환경에서는 해당 웹페이지에
접근할 수 없다는 메시지가 출력되거나 수행(?!)할 수 없다는 오류메시지가 출력됩니다.
그러나, 서버 환경에서 해당 퍼미션 미만일 경우 환경설정이 적절치 못한 경우라면,
php를 비롯한 서버스크립트 언어(asp,jsp...)의 소스코드가 그대로 웹브라우저상에 노출될 위험이 있습니다.
물론, 이러한 경우는 지극히 이례적이며, 대부분 개인이 테스트를 위해 서버를 설치하고 서버 환경설정에
문제가 있을 경우에 발생하는 경우이며, 만약 호스팅 업체를 이용하고 있을 경우에 이러한 현상이 자주(?!)
발생한다면 당장 호스팅 업체를 변경하시기 바랍니다.(사실 자주 이런 문제가 발생하는 호스팅 업체는 없음.)
<참조사항 2.>
Q. 그누보드 설치 후 파일이나 특정경로(디렉토리)를 생성하는데 왜 하필 644, 755와 같은 형태로 생성되나요?
A. 서버 및 root 관리자의 편의(?!)를 제공하기 위해서가 아닐지...(이거 무쟈게 무식한 발언이네요. 에구~*)
가장 간단한 답변은, unix 계열을 프로그래밍할때 프로그래머의 맘대로 설정된 부분이라고
답변하는 것이 가장 적절(?!)한 답변인 듯 합니다.
일례로 리눅스 계열에서 y*로 시작되는 명령(어)은 없습니다.
뭐 어거지로 만든다면 있다고 봐도 반문하셔도 할말은 없지만...
제가 개인적으로 즐겨하는 철자의 시작이 y*라서 ~*^^*
여러분께서도 이미 알고 계시듯이 root 관리자는 특정 개개인의 사용자(계정)에 관해서만 관리를 하지 않습니다.
일종의 분류의 개념인 그룹(group)을 생성하고 그에 따른 개인계정의 집합체를 만들고 적절한 관리를 수행합니다.
따라서 umask 값이 022인 이유를 추론할 수 있는 부분입니다.
서버의 root(최고관리자)일 경우만 변경 가능.
일반적으로 /etc/profile에 umask 022 과 같이 umask로 지정되어 있는 부분이 있습니다.
이것은 파일 및 디렉토리를 생성할 경우, 퍼미션의 최대치(?!)인 777에서 umsak된 값 만큼 변경 후
최종적으로 파일이나 경로(디렉토리) 생성시 적용된다고 보시면 됩니다.
-추신-
정리해서 간략히 올려야 하는데...
팁텍이라고 하기도 뭐 하지만...
가끔씩 얘기되는 내용이라 생각되어 올려 봅니다.
추천
0
0
댓글 전체
늦게 봤네요...
제가 써놓고도.. 어디에 무슨 이야길 써 놓았는지 모르는 경우가 허다합니다.
하루에 인터넷 검색중 돌아다니는 싸이트가.. 상상을 초월해서요..
나쁜말로하면.. 찌질이적인 성향의 글을 많이 유표한다는 뜻이겠죠?
어째꺼나.. 제가 적은 글중에.. 잘못된점은.. 사용자측면이 아닌 관리자 측면을 강조한것이고..
적으신 내용의 원론을 이야기하려 한것 같아 죄송합니다..
말씀대로.. 팁텍은 사용하기 편하게 알려주는 정보인데 말이죠 :)
아마 보안과 편리함은.. 어느정도 조율하기가 상당히 까다로울꺼 같습니다.
저처럼. 보안에 민감한 사람도 있는반면..
아무렇지않게 그냥.. 잘되면 되지 무슨 보안이냐는 사람들도 있을껍니다.
소 잃고 외양간 고치는 것과, 구더기 무서워 장 못 담근다의 속담이 적절한지 모르겠네요.. :)
MC이야기는 제가 그것을 써보지 않아서 잘은 모르나 아마도 퍼미션을 넘나드는것이라면..
Suid 가 설정된거 같네요
로컬어택시 해커가 가장 노리는 것들중 하나가 Suid 파일을 찾는것입니다 :)
제가 써놓고도.. 어디에 무슨 이야길 써 놓았는지 모르는 경우가 허다합니다.
하루에 인터넷 검색중 돌아다니는 싸이트가.. 상상을 초월해서요..
나쁜말로하면.. 찌질이적인 성향의 글을 많이 유표한다는 뜻이겠죠?
어째꺼나.. 제가 적은 글중에.. 잘못된점은.. 사용자측면이 아닌 관리자 측면을 강조한것이고..
적으신 내용의 원론을 이야기하려 한것 같아 죄송합니다..
말씀대로.. 팁텍은 사용하기 편하게 알려주는 정보인데 말이죠 :)
아마 보안과 편리함은.. 어느정도 조율하기가 상당히 까다로울꺼 같습니다.
저처럼. 보안에 민감한 사람도 있는반면..
아무렇지않게 그냥.. 잘되면 되지 무슨 보안이냐는 사람들도 있을껍니다.
소 잃고 외양간 고치는 것과, 구더기 무서워 장 못 담근다의 속담이 적절한지 모르겠네요.. :)
MC이야기는 제가 그것을 써보지 않아서 잘은 모르나 아마도 퍼미션을 넘나드는것이라면..
Suid 가 설정된거 같네요
로컬어택시 해커가 가장 노리는 것들중 하나가 Suid 파일을 찾는것입니다 :)
'prosper'님 말씀마따나 단순히 팁/텍에 올릴만한 내용이 아니군요.
그러나 게시물 어디를 살펴보나 '퍼미션'과 '소유권한'을 동일시한 내용은 없어 보입니다만...
게시물 상단부에 기재한 부분은 단순히 777~444(실제 의미가 있는 부분 정도...)에 대한 의미가
어떻게 r(ead)-w(rite)-(e)x(cutive)와 연관이 되느냐를 정말 간략하게 기재하기 위한 방편이었습니다.
물론 편의상 그러한 뉘앙스를 풍기는 단락이 존재할 수도 있습니다.
오해의 소지를 남길 것 같아서 몇 글자 덧붙입니다.
퍼미션 : 한마디로 줄여서 '접근권한'이라고 정의할 수 있습니다.
소유권한 : 말 그대로 파일, 특정경로(일반적으로 디렉토리로 부름)를 조정할 수 있는 실제 소유자.
여기서 서버환경을 총체적으로 제어하는 root는 논외로 하겠습니다.
팁/텍은 원론부터 펼쳐가는 강좌게시판이 아니라는 점입니다.
사용에 필요한 부분, 경험에 의해 해결중이거나 해결했던 부분에 대해 기록을 남기고,
여러 사용자들이 간혹 맞딱뜨리게 될 문제점을 미리 언급할 수 있는 부분이라고 봅니다.
그리고, 기재하신 내용중에서 '소유권한'과 '그룹지정'에 관련된 부분은 일반 사용자에게는 해당되지 않는 내용입니다.
그 부분을 게시물 도입부분에 한번 더 언급을 하셨어야 여러 유저들께서 '혼동의 여지가 그만큼 줄어들지 않았을까'
라는 생각을 해 봅니다.
자세한 설명 감사드리고, 차후로도 'prosper'님의 역량을 기대해 봅니다.
아 참... 깜빡한 부분이 있네요.
'리눅스'라는 녀석을 만질때 root의 막강함과 세세함이 정말 살 떨리게 제 자신을 흥분시키고,
각종 유틸리티의 막강함과 그 막강함 뒤에 숨겨진 문제점들을 발견하게 됐습니다.
많은 분들께서 사용해 보셨던 ms-dos를 사용하던 시절의 m-dir과 그 형태가 사뭇 유사한(?!)
mc(midnight command)를 들어 보겠습니다.
이 녀석은 엄청난 편리함을 안겨 줍니다.
root는 물론이거니와 개개의 계정 사용자에게도 말이죠.
그런데, 이 녀석의 가장 큰 맹점이 무엇이냐?!
퍼미션(접근권한)이 설정된 영역도 넘나든다는 점입니다.
당연히 root는 가능하고, 일반 계정 사용자들도 접근할 수 있다는 부분이 강력한 문제점이었지요.
물론, 특정 경로(디렉토리)나 파일들에 대한 읽기/쓰기(수정,삭제,생성)의 권한이 없다면,
직전에 기재된 작업은 할 수 없겠지만, 단지 해당 경로에 접근하거나 파일을 열람하는 것만으로도
엄청난 문제점을 야기할 수 있지요.(예를 들어 db설정 파일 또는 패스워드 관련 파일들...)
그런데 이러한 문제점을 안고 있는 유틸리티들을 호스팅 업체에서 제공을 할까요?
물론 사용자 입장에서야 엄청난 편리함을 안겨주니 제공해 주면 좋다고 하겠지요.
그런데... 막상 기재된 실상을 꿰뚫어 보고, 그 문제점들을 파악하는 상황이 된다면?!
얘기가 이상하게 흘러가 버렸군요.
맞습니다. 편리함과 보안은 때로는 상충될 수도, 말씀하셨듯이 반비례할 수도 있습니다.
(물론, 현재까지는 반비례하는 경우가 비교할 수 없을 정도로 많지만...)
너무 보안에만 치중하다 보면, 실제 그것을 이용하는(빈번하게 적절한 수정을 해야 할 필요가 있는...) 유저들의
입장에서는 정말 답답하고 분통(?!) 터지는 상황을 연출할 수 있습니다.
얘기가 계속 길어져서 죄송합니다만 참고로 현재 제가 테스트겸 계정을 이용하는 호스팅 업체가 있습니다.
요 근래 대두된 php관련 보안버그 등을 이유로, 각각의 연구단체에서 추천하는 방법을 따른다고,
일반적인 ftp 프로그램(알ftp, alive-ftp 등등)을 사용해서 접근하지 못합니다.
돌겠더군요. 답답해서...
홈페이지 관련 자료 파일(흔히 생각하는 계정 파일관련 자료 제외)은 기껏 10Mb 이하라 할지라도 상당히 큰
분량이 됩니다. 이러한 자료를 서버에 올리려면 어떤 방법을 사용하고 있는 줄 아십니까?
...
'prosper'님께서 언급하셨듯이 보안에 신경은 쓰되, 너무 한쪽(보안)에만 치중해서,
일반 사용자를 답답하게 만들고, 번거롭게 만들고, 사용자의 권한을 대폭 축소하는 것은 결코
바람직한 방향은 아니라고 봅니다.
일정 부분을 제어하더라도 최소한 사용자의 편의성을 거의 묵살하는 수준까지 축소해서는 안된다는 점입니다.
두서 없는 장문에 관심 주셔서 감사드립니다.
그러나 게시물 어디를 살펴보나 '퍼미션'과 '소유권한'을 동일시한 내용은 없어 보입니다만...
게시물 상단부에 기재한 부분은 단순히 777~444(실제 의미가 있는 부분 정도...)에 대한 의미가
어떻게 r(ead)-w(rite)-(e)x(cutive)와 연관이 되느냐를 정말 간략하게 기재하기 위한 방편이었습니다.
물론 편의상 그러한 뉘앙스를 풍기는 단락이 존재할 수도 있습니다.
오해의 소지를 남길 것 같아서 몇 글자 덧붙입니다.
퍼미션 : 한마디로 줄여서 '접근권한'이라고 정의할 수 있습니다.
소유권한 : 말 그대로 파일, 특정경로(일반적으로 디렉토리로 부름)를 조정할 수 있는 실제 소유자.
여기서 서버환경을 총체적으로 제어하는 root는 논외로 하겠습니다.
팁/텍은 원론부터 펼쳐가는 강좌게시판이 아니라는 점입니다.
사용에 필요한 부분, 경험에 의해 해결중이거나 해결했던 부분에 대해 기록을 남기고,
여러 사용자들이 간혹 맞딱뜨리게 될 문제점을 미리 언급할 수 있는 부분이라고 봅니다.
그리고, 기재하신 내용중에서 '소유권한'과 '그룹지정'에 관련된 부분은 일반 사용자에게는 해당되지 않는 내용입니다.
그 부분을 게시물 도입부분에 한번 더 언급을 하셨어야 여러 유저들께서 '혼동의 여지가 그만큼 줄어들지 않았을까'
라는 생각을 해 봅니다.
자세한 설명 감사드리고, 차후로도 'prosper'님의 역량을 기대해 봅니다.
아 참... 깜빡한 부분이 있네요.
'리눅스'라는 녀석을 만질때 root의 막강함과 세세함이 정말 살 떨리게 제 자신을 흥분시키고,
각종 유틸리티의 막강함과 그 막강함 뒤에 숨겨진 문제점들을 발견하게 됐습니다.
많은 분들께서 사용해 보셨던 ms-dos를 사용하던 시절의 m-dir과 그 형태가 사뭇 유사한(?!)
mc(midnight command)를 들어 보겠습니다.
이 녀석은 엄청난 편리함을 안겨 줍니다.
root는 물론이거니와 개개의 계정 사용자에게도 말이죠.
그런데, 이 녀석의 가장 큰 맹점이 무엇이냐?!
퍼미션(접근권한)이 설정된 영역도 넘나든다는 점입니다.
당연히 root는 가능하고, 일반 계정 사용자들도 접근할 수 있다는 부분이 강력한 문제점이었지요.
물론, 특정 경로(디렉토리)나 파일들에 대한 읽기/쓰기(수정,삭제,생성)의 권한이 없다면,
직전에 기재된 작업은 할 수 없겠지만, 단지 해당 경로에 접근하거나 파일을 열람하는 것만으로도
엄청난 문제점을 야기할 수 있지요.(예를 들어 db설정 파일 또는 패스워드 관련 파일들...)
그런데 이러한 문제점을 안고 있는 유틸리티들을 호스팅 업체에서 제공을 할까요?
물론 사용자 입장에서야 엄청난 편리함을 안겨주니 제공해 주면 좋다고 하겠지요.
그런데... 막상 기재된 실상을 꿰뚫어 보고, 그 문제점들을 파악하는 상황이 된다면?!
얘기가 이상하게 흘러가 버렸군요.
맞습니다. 편리함과 보안은 때로는 상충될 수도, 말씀하셨듯이 반비례할 수도 있습니다.
(물론, 현재까지는 반비례하는 경우가 비교할 수 없을 정도로 많지만...)
너무 보안에만 치중하다 보면, 실제 그것을 이용하는(빈번하게 적절한 수정을 해야 할 필요가 있는...) 유저들의
입장에서는 정말 답답하고 분통(?!) 터지는 상황을 연출할 수 있습니다.
얘기가 계속 길어져서 죄송합니다만 참고로 현재 제가 테스트겸 계정을 이용하는 호스팅 업체가 있습니다.
요 근래 대두된 php관련 보안버그 등을 이유로, 각각의 연구단체에서 추천하는 방법을 따른다고,
일반적인 ftp 프로그램(알ftp, alive-ftp 등등)을 사용해서 접근하지 못합니다.
돌겠더군요. 답답해서...
홈페이지 관련 자료 파일(흔히 생각하는 계정 파일관련 자료 제외)은 기껏 10Mb 이하라 할지라도 상당히 큰
분량이 됩니다. 이러한 자료를 서버에 올리려면 어떤 방법을 사용하고 있는 줄 아십니까?
...
'prosper'님께서 언급하셨듯이 보안에 신경은 쓰되, 너무 한쪽(보안)에만 치중해서,
일반 사용자를 답답하게 만들고, 번거롭게 만들고, 사용자의 권한을 대폭 축소하는 것은 결코
바람직한 방향은 아니라고 봅니다.
일정 부분을 제어하더라도 최소한 사용자의 편의성을 거의 묵살하는 수준까지 축소해서는 안된다는 점입니다.
두서 없는 장문에 관심 주셔서 감사드립니다.
이주제는 아마도 토론란이나 포럼에서 다루어야 할 내용인듯 싶네요..
한마디만 하자면 보안과 편리함은 반비례한다는것입니다.
심지어
" 웹서버에는 GCC와 기타 유틸리티는 없어야 안전하다"
는 내용까지 있었고..
"최고의 보안은 컴퓨터를 켜지 않는 것 "
이라는 이야기도 있었습니다 :D
저의 경우 최대한 보안에 신경을 써서 작업을 하게 됩니다.
퍼미션을 nobody로 주는것이 아니라 특정한 그룹을 따로 만들어 줍니다.
물론 어느 그룹이나 유저가 속해있지 않는 그룹 (물론 nobody도 그렇지만 nobody는 그룹과 유저가 같으므로)
여기에서는 nogroup라는 그룹을 만들고, 웹에서만 접근 가능하도록 만듭니다.
ssh,ftp,telnet,rlogin등 80포트를 제외한 모든 접근을 차단!
그리고 각각 해당의 유저의 public_html 또는 html또는 www의 디렉토리를 루트로 생성
(이러면 지우거나 수정을 못함)
퍼미션은 750
소유권은 user:nogroup
또한 웹권한으로 디렉토리나 파일을 생성해야될 일이 있는 gnu/data디렉토리경우만
퍼미션 770
소유권 user:nogroup
로 만들어줍니다.
물론 처음에 777로 해놓고 설치후 퍼미션을 조정해도 상관없습니다.
이럴경우 웹권한 자체가 틀려서 웹으로 접근은 가능하나..
콘솔로써 접근은 금지 됩니다.
콘솔 접근 금지에 대한 이야기는 회피하겠습니다.
현재 호스팅의 대부분이 이것에 취약하기 때문에 ㅠㅠ;
아무튼 자신이 서버를 관리한다면..
아파치의 그룹을 노바디가 아닌 다른 그룹으로 만들고
소유권을 명확하게 함으로 많은 사용자가 쓰고있는 웹호스팅에서의 취약점을 없애고
좀더 보안을 높일수있게 됩니다.
그것 보다 더 좋은 방법은 가급적 웹에서 파일또는 디렉토리를 생성시키는것을 자제 하는것입니다.
만일 만들더라도 나름대로 보안절차를 만들어 까다롭게 만들어야 최소한 해킹에 피해를 줄일수 있을 겁니다.
한가지더!
퍼미션과 소유권은 엄연히 틀립니다.
d / rwx / rwx / rwx
유저 / 그룹 / 그외모두
여기에서 아파치에서 쓰이는 그룹은 일반적으로 nobody 또는 httpd, apache (예전 버전 일부는 이렇게 쓰였음) 였습니다.
이것을 자신만의 웹그룹으로 변경 시키고, ( nobody 유저에 대한 그룹을 포함시켜야됩니다.)
이것을 웹폴더에만 적용시킴으로 웹외에 접근을 회피함.
그외모두의 another는 개나소나 다보는것입니다 ㅠㅠ;
한마디만 하자면 보안과 편리함은 반비례한다는것입니다.
심지어
" 웹서버에는 GCC와 기타 유틸리티는 없어야 안전하다"
는 내용까지 있었고..
"최고의 보안은 컴퓨터를 켜지 않는 것 "
이라는 이야기도 있었습니다 :D
저의 경우 최대한 보안에 신경을 써서 작업을 하게 됩니다.
퍼미션을 nobody로 주는것이 아니라 특정한 그룹을 따로 만들어 줍니다.
물론 어느 그룹이나 유저가 속해있지 않는 그룹 (물론 nobody도 그렇지만 nobody는 그룹과 유저가 같으므로)
여기에서는 nogroup라는 그룹을 만들고, 웹에서만 접근 가능하도록 만듭니다.
ssh,ftp,telnet,rlogin등 80포트를 제외한 모든 접근을 차단!
그리고 각각 해당의 유저의 public_html 또는 html또는 www의 디렉토리를 루트로 생성
(이러면 지우거나 수정을 못함)
퍼미션은 750
소유권은 user:nogroup
또한 웹권한으로 디렉토리나 파일을 생성해야될 일이 있는 gnu/data디렉토리경우만
퍼미션 770
소유권 user:nogroup
로 만들어줍니다.
물론 처음에 777로 해놓고 설치후 퍼미션을 조정해도 상관없습니다.
이럴경우 웹권한 자체가 틀려서 웹으로 접근은 가능하나..
콘솔로써 접근은 금지 됩니다.
콘솔 접근 금지에 대한 이야기는 회피하겠습니다.
현재 호스팅의 대부분이 이것에 취약하기 때문에 ㅠㅠ;
아무튼 자신이 서버를 관리한다면..
아파치의 그룹을 노바디가 아닌 다른 그룹으로 만들고
소유권을 명확하게 함으로 많은 사용자가 쓰고있는 웹호스팅에서의 취약점을 없애고
좀더 보안을 높일수있게 됩니다.
그것 보다 더 좋은 방법은 가급적 웹에서 파일또는 디렉토리를 생성시키는것을 자제 하는것입니다.
만일 만들더라도 나름대로 보안절차를 만들어 까다롭게 만들어야 최소한 해킹에 피해를 줄일수 있을 겁니다.
한가지더!
퍼미션과 소유권은 엄연히 틀립니다.
d / rwx / rwx / rwx
유저 / 그룹 / 그외모두
여기에서 아파치에서 쓰이는 그룹은 일반적으로 nobody 또는 httpd, apache (예전 버전 일부는 이렇게 쓰였음) 였습니다.
이것을 자신만의 웹그룹으로 변경 시키고, ( nobody 유저에 대한 그룹을 포함시켜야됩니다.)
이것을 웹폴더에만 적용시킴으로 웹외에 접근을 회피함.
그외모두의 another는 개나소나 다보는것입니다 ㅠㅠ;
요것도 스크랩을...
