반응형
< 출처 : http://www.idg.co.kr/newscenter/common/newCommonView.do?newsId=57714 >

 현재 미국에서 K 모사 일을 하고 있지만, 우리나라만의 새로운 운영체제를 발표한다는 소식을 듣고 관련 동영상과 문서를 보면서 필자도 모르게 아쉬운 마음을 감출 수 없었다. 특히, 많은이들이 공감하듯이 개발자의 이혼이야기며, 건강이야기를 자랑스럽게 이야기하는 부분에서 흥분하지 않을 수 없었다. 과연 이것은 회사의 경영진의 문제일까? 아니면, 개발자 자신의 문제일까? 필자는 무엇보다도 개발자의 자발적인 자기관리가 중요하다고 생각한다.

개발자가 반드시 관리를 해야 하는 부분을 안과 밖으로 나누어 설명할 수 있는데, 안이라고 하면 정신적인 것과 관련된 이야기이며 밖은 육체적인 것과 관련된 이야기다. 이 둘의 조화가 얼마나 중요한지 짚고 넘어가야 한다. 한번이라도 개발을 해보았던 사람들이라면 누구나 공감을 할 것이다. 아래와 같은 상황을 가정하고, 결과를 한번 상상해보자.

술김에 프로그램을 만들어 본 기억이 있는가?

어느 프로젝트에서 일이 너무도 힘들어서 홧김에 술을 마시고 코딩을 했다면, 그 당시에는 이것이 얼마나 잘못된 일인지 알지 못한다. 멀쩡한 정신에 프로그램을 만들어도 자신이 어디서 실수를 했는지 찾기는 그렇게 만만치 않은데, 하물며 술을 마시고 프로그램을 만들었다면 이건 진짜 대박이라고 하는 표현이 맞을 것이다. 술의 힘을 빌어 프로그램을 만들게 되면 당사자도 놀라울 정도로 척척 코딩이 이루어진다. 하지만 술이 깬 다음 날 자신이 만든 프로그램을 보게 되면 도무지 이해가 되지 않는 부분들을 발견하게 된다. 어디까지 만들고 어디까지 수정을 했는지 알 수가 없게 된다. 그러니 더더욱 혼자서 만드는 소스가 아닐 때에는 오히려 찾아서 원상복귀 시키는 것조차 어렵게 된다. 이런 얘기를 해서는 안 되겠지만 필자 역시도 경험이 있기에 그게 얼마나 위험한 상태인지 알기에 얘기를 하는 것이다.

아픈 상태에서 프로그램을 만들어본 기억이 있는가?

깊이 생각할 일도 아닌 것 같다. 가벼운 감기,몸살만 걸려도 정신이 몽롱하고 집중이 안 되어 도저히 프로그램 개발이 안되는 경우를 경력이 좀 되는 개발자라면 누구나 경험해 보았을 것이다. 일반적인 프로젝트에서는 그런 사람이 옆에 있으면 오히려 기존 프로그램마저 망칠까 봐 일찍 귀가를 시키는 경우를 종종 볼 수가 있다. 몽롱한 상태에서 아무리 개발을 해봐야 그건 그냥 시간 잡아먹기에 불과하며 상황을 오히려 악화시키는 불완전한 요소가 될 뿐이다.

그렇다면, 개발자 중에 개발 때문에 이혼까지 하고 자신이 아픈 줄도 모르고 개발을 한 사람이 있다는 사실은 결코 자랑해서는 안 되는 부분이지 않을까. 이혼까지 갔다면 도중에 맨정신으로 개발이 가능 했을까? 아픈 줄도 모르고 개발을 했다면 제대로 된 코딩이 가능 했을까? 잠도 못자고 개발을 했다면 새로운 영역의 개발인데 정말 제대로 된 프로그램이 만들어 졌을까? 하는 의문만 남게 만들었다. 어떤 의미로 얘기를 했는지는 이해는 되지만 결코 자랑할 부분이 아니라는 생각이 들며 진짜 너무 고생, 고생하며 개발한 개발자들을 한꺼번에 바보로 만들었다는 생각이 들었다.

개발자가 하나의 프로젝트를 끝까지 무사히 끝내고 싶다면 체력은 반드시 갖추고 있어야 한다. 보약을 먹든지 아니면 운동을 하든지 끝나는 그 순간까지 견딜 힘의 원천이 필요한 것이다. 정신적인 것도 역시 마찬가지라고 생각한다. 일주일 내내 오직 일에만 전념한다면 정말 중요한 시점에서 모든 것이 고갈되고 말 것이다. 주말에 휴식하는 것도 다음 일주일을 위한 배려이다. 하루 이틀 바짝 밤샘하며 일을 하는 것과는 다른 얘기이다. 장기 프로젝트 경우 개발자들 중에 보약을 먹으며 체력을 쌓거나, 운동을 하고 정신적인 스트레스를 운동으로 푸는 등, 자기만의 비법으로 장기전에 대비하는 경우를 쉽게 볼 수가 있다. 필자 역시도 체력적, 정신적인 면의 해결을 위해서 이젠 약보다는 운동에 힘쓰고 있다. 운동을 하면 살도 빠지고 맑은 정신을 오래 유지할 수 있도록 해주는 숙면도 제공하기에 적극 추천한다. ‘건강한 신체에 참신한 아이디어가 깃든다’는 상투적인 표현을 굳이 부연 설명할 필요는 없을 것이다. 육체적인 면만 강조하는 우를 범하지 말아야 한다. 모든 것은 조화에서 비롯된다.

그리고 이 말도 해주고 싶다. 하루 이틀 밤샘으로 끝날 일이 아니라면 무작정 자신을 혹사시키며 일한 것이 결코 자랑은 아니라는 것이다. 행복한 개발자가 되고 싶다면 자기관리는 스스로 해야만 한다. 제삼자가 해주는 것이 아니다. 개발자에게 균형있는 자기관리는 현재, 그리고 미래를 위한, 어쩌면 가장 중요한 투자이기 때문이다. cess98@paran.com


임철우님의 컬럼이 또 올라왔길래 읽다가 퍼오게 되었다.
국내 기업중 모기업에서 운영체제 개발 과정에 대한 에피소드 소개시에 나온 이야기를 나도 들었었다.
그 기업에서는 힘든 프로젝트이고 모든 팀원들이 모두 열심히 노력했다는 취지이겠지만
개발자들의 일은 단순히 작업시간에 비례하여 그 성과가 나오는 것은 아니라고 생각하기 때문이다.
위에서 언급한 것과 같이 아프거나 다른데 신경쓸일이 있거나 술에 취하거나 하는 경우는
일의 특성상 좋은 프로그램을 만들어 내는 것이 어려운 것이다.
기계적으로 처리할수 있는 단순공정이 아니기 때문이다.
개발은 근본적인 문제를 해결하는 활동이고 문제를 해결하려면 창의력이 필요하다고 한다.
소프트웨어 문제를 해결하는 활동은 어떤 활동보다도 아주 복잡한 과정임을 인정해야 한다.
관라자 측면에서는 이러한 특성에 대한 이해가 필요하리라 생각한다.
사람은 기계가 아니며 소프트웨어 개발은 기계가 할수 있는 단순 작업공정이 아님을 인지하고
소프트웨어 개발에 대한 특성을 고려하여 이에 대한 환경을 조성하고 관리해야 할것이다.
요즘 읽고 있는 "소프트웨어 크리에이티비티 2.0"  내용을 조금 인용하였다.
반응형
출처: http://www.idg.co.kr/newscenter/common/newCommonView.do?newsId=52482

임철우님의 컬럼입니다. 전에도 스크랩해서 다른 글을 포스팅한적이 있습니다.

시간을 내서 다시 찾아서 못읽었던 다른 컬럼을 읽고 또 포스팅 합니다.

요즘은 거의다 스크랩해서 올리게 되는거 같군요. 임철우님의 컬럼 시간내서 읽어보시길..

정말 좋은 글들이 많이 있습니다.  가슴에 와닿는 글들도 많고..

 

AP76F8.JPG해마다 이맘때면 시내 한복판에서 쉽게 구세군들을 만날 수가 있다. 그들이 왜 추운 거리에서 자그마한 정성을 모아 불우한 이웃을 돕자고 열심히 종을 치며 사랑의 모금을 하는지 생각해 볼 필요가 있다. 무엇인가 나눌 것이 있다는 것은 참 행복한 것이다. 어쩌면 손해를 본다는 생각이 들겠지만 조금만 다른 시각에서 바라보면 전혀 다른 행복이 보이기 시작할 것이다.

  

개발자라면 꾸준히 새로운 지식을 익힐 필요성을 느끼게 될 것이다. 필자가 처음 개발자로 입문을 했을 당시에는 지금처럼 인터넷이 활성화가 안 되어 있던 시절이었고 개발을 하다 막히는 부분이 있으면 하루고 이틀이고 밤을 새워가며 해결하기 위해 끊임없이 원인을 찾기 위해 노력을 해야만 했다.

 

한번은 문제가 해결될 기미도 안보이고 거의 포기 상태까지 이르렀을 때 같이 일하던 A선배가 비슷한 경험이 있다며 힌트를 주었고, 그로 말미암아 다른 관점에서 접근을 하게 되어 일을 기한에 맞추어 끝냈던 기억이 난다.

 

반면, 당시 실력은 월등히 좋았지만 옆에서 힘들어 하는 걸 뻔히 보면서도 도움을 주지 않았던 B라는 선배도 있었다. 그 이후에도 A선배는 뛰어난 실력은 아니어도 자신이 알고 있는 것을 정리해서 가끔 필자에게 알려 주었고, 덕분에 다양한 개발 팁을 배우게 되는 등 회사 생활을 하는데 많은 도움을 받았다. B선배의 경우는 어려운 일을 혼자서 다 처리했기에 역시 회사 생활을 하는데 도움을 받은 것은 사실이다.

 

하지만 A, B선배와는 서로 다른 회사로 옮기면서 확실하게 차이가 벌어지게 되었다. A선배와는 계속 연락하며 지내지만, B선배와는 연락을 하는 일이 전혀 없어진 것이다. A선배와는 왠지 모르는 인간적인 유대가 생겼고 B선배와는 그저 일 때문에 만난 사람이기에 더 이상 관계가 발전되기 힘들기 때문이다. 직장에서 만난 사람들과 오랫동안 서로 알고 지내는 일은 솔직히 좀처럼 쉽지 않다.

  

실력이 우선시 되는 사회인 것만은 사실이다. 하지만 독불장군처럼 알고 있고 기술을 나눌 줄 모르는 사람이라면 아마도 개발자로서 오랫동안 생활하기에는 어려움이 있을 것이다. 모든 지식을 혼자서 다 익힐 수는 없기 때문이다. 그리고 자기만 알고 있다고 생각하는 신기술 또한 알고 있는 사람이 있기에 자신도 알고 있는 것이고 그렇다면 언젠가는 다른 사람들 또한 알게 될 것이다. 어떤 사람이 그 기술을 공유하려고 할 때 "나도 알고 있는데…" 이런 말을 하게 된다면 한다면 오히려 욕을 먹을지도 모른다.

  

현재 거의 모든 프로젝트는 여러 사람이 톱니바퀴처럼 딱딱 맞아야 비로소 성공적인 프로젝트로 갈 수 있다. 내가 알고 상대가 모른다면 지식을 공유해야 하는 것이 개발자의 예의라고 생각한다. 기술의 공유에 있어서 지위가 높고 낮음은 없으며, 새로운 지식을 습득하게 되면 다른 사람들과의 공유는 필수이며, 알려주려고 하는 사람을 오히려 잘난 척 한다고 생각하는 사람이 있다면 그 사람은 남보다 발전이 늦을 것이며 그 사람은 왜 쉽게 갈 수 있는 길을 어렵게 돌아가려 하는지 생각해봐야 한다. 사전 정보를 가지고 시작하는 것과 모르고 시작하는 것은 천지차이다.

  

신기술이나 팁을 공유함으로써 자신에 돌아오는 것이 무엇인가? 그것은 사람이다. 바로 이것이 나누면 행복해지는 이유이다. 나를 인정해주고 어려움이 닥쳐도 함께 해줄 동료가 한 명이라도 있다면 개발자로서 성공한 거라고 생각한다. 이 글을 통해 내가 지금 힘들 때 정말 나를 도와줄 개발자가 몇이나 되고 연락 가능한 사람이 몇이나 되는지 돌아보는 계기가 되었으면 좋겠다.



반응형
출처: http://www.hauri.co.kr/customer/security/colum_view.html?intSeq=89&page=1&keyfield=&key=

악성코드 짜잉나는 놈 내 손으로 제거해 주마!!! ㅎㅎ

악성코드 관련 컬럼이 있어 퍼왔습니다. 눈에 익은 툴들이 몇개 보이네요....ㅎ

 

1. 악성코드의 형태


악성코드는 대부분 스스로 실행 가능한 .exe 형태이거나, 다른 프로세스에 인젝션 되어 실행되는 .dll형태로 존재한다. 이번 칼럼에서는 간단하게 .exe형태의 악성코드를 제거해보도록 하겠다. 왜냐하면 .exe형태의 프로세스가 .dll형태의 악성코드보다 인지하는게 수월하기 때문이다.


2. 유용한 확인/제거 툴


ㄱ. Process Explorer 작업관리자로도 .exe형태의 파일을 볼 수는 있지만, 프로세스명만 나오기 때문에 많이 부족하다.이를 보완해줄수 있는 툴이 Process Explorer이다. 이 툴은 간단하게는 이미지(파일) 경로와 프로세스명, User Name등을 알 수 있으며, 프로세스의 실행, 일시정지, 재실행, 종료등 여러가지 기능을 가지고 있다.


ㄴ. Autoruns 레지스트리를 확인할 수 있는 툴로 부팅시 자동실행되는 파일이나 서비스를 보여준다. 이것을 이용해서 재부팅시 실행되는 악성코드도 확인 할 수 있다.


ㄷ. IceSword / Gmer 루트킷 탐지와 숨겨진 프로세스, 파일 등을 종료시키거나 제거할 때 사용한다.


ㄹ. File Monitor / Registry Monitor 파일이나 레지스트리의 IO를 사람의 눈으로 확인하기가 힘들기 때문에, IO에 대한 로그를 보고IO를 확인하는데 사용한다.


ㅁ. taskkill 하나 이상의 프로세스를 종료하는데 사용하며 여러가지 조건을 줄 수 있다.


3. 악성코드에 감염된 PC를 찾아라


악성코드를 제거하기 위해서는 감염된 PC가 필요한데 실PC가 감염되면 좋을게 하나도 없다. 이럴때 필요한 것이 가상머신인데 VmWare, VirtualPC, VirtualBox등 여러가지가 있다. 자신에게 맞는 가상머신을 설치하고 OS도 설치하여 필요한 툴도 넣고, 마지막으로 스냅샷 등의 복원지점도 설정해놓아야 편안하게 감염 테스트를 할 수 있다.


ㄱ. 필자는 VirtualBox를 이용해 보았으며 툴도 넣어두었고, 복원지점을 위해 스냅샷도 찍어 두었다. 숨길건 없지만, 안개효과를 내주는 Blur 필터를 추가하니 이미지가 멋있어졌다.



 

ㄴ. 가상머신에 공유폴더를 이용하여 악성코드와 툴을 넣고 File Monitor를 실행해두고, 악성코드인 TEST_MAL.vir.exe를 실행시켰다. 악성코드가 C:\lsass.exe를 생성시키는 것을 알수 있었다.


(설정변경 : 메뉴의 Help밑에 보이는 깔때기 아이콘 실행 -> Highlite에 Write;Delete 추가)



ㄷ. 이제 악성코드는 TEST_MAL.vir.exe와 C:\lsass.exe 두 마리다.


실행중인 악성코드를 보기위해 Process Explorer을 실행시켜 악성코드를 지켜보니 처음에 실행한 악성코드 TEST_MAL.vir.exe와 계속해서 실행/종료를 반복하고 있는 C:\lsass.exe를 확인할 수 있다.


(빨간색 줄은 종료되는 프로세스를, 녹색줄은 이제 막 실행되고 있는 프로세스를, 보라색은 압축되어 있는 프로세스를 나타낸다.)



 

4. 악성코드 제거하기


이제 감염된 PC가 생겼으니 제거해보자. 원래 쉬운것부터 해나가야 실력이 늘것이고, 주유소 습격사건의 유오성처럼 한 놈만 잡으면 다른것도 응용해서 할 수 있을꺼라 생각한다. 대부분의 악성코드를 직접 감염시켜보는게 아니기 때문에 어떤 프로세스를 종료시켜야 할 지 난감할 것이다. 이 많은 프로세스중에 어떤게 악성코드일까?


ㄱ. 악성코드 의심 대상을 좁혀라.


(Services로 실행되는 악성코드는 예외) Process Explorer가 트리구조로 보여주는 것을 감안하여 Shell로 동작하는 explorer.exe의 자식노드(우측으로 치우친)로 보여지거나, (모니터를 기준으로) explorer.exe의 아래쪽에 존재하는 프로세스들을 자세히 들여다 보자. 이는 우리가 PC에 로그인하여 실행하는 프로그램들은 쉘에서 실행되기 때문이며, 예외적으로 쉘에서 실행된 것중 자식프로세스를 생성하고 죽을경우 Process Explorer는 해당 자식 프로세스를 쉘과 동등한 레벨로 보여주기 때문이다.


(이것은 마치 SI로 추정되는 사람을 특정국가에서 귀국한 사람들로 범위를 좁혀가는 것과 같은 것이다. 하지만 사람은 악성코드가 아니다.)


ㄴ. 하나씩 제외시키면 악성코드가 보인다. 평소에 자신이 많이 보았거나 확실하게 아는 프로세스를 제외해보면 몇 개 안남을 것이다. 지금 같은 경우는 TEST_MAL.vir.exe와 실행/종료를 반복하는 lsass.exe만 눈에 띄게 이상하다. ㄷ. 의심되는 프로세스를 찾았다. 정말 악성코드일까?


- 백신업체에 해당 파일을 압축암호와 함께 압축하여 신고


=> 악성코드의 신고접수는 자신뿐 아니라 많은 백신 이용자들이 PC를 쾌적하고 안전하게 사용할 수 있게 해준다. 많은분들이 계속해서 신고해준다면 더 좋아지지 않을까?


- 각 백신업체의 홈페이지에서 무료로 검사해 볼 수 있다.


- 여러 백신업체의 스캐너로 악성코드를 무료로 검사해준다.


=> http://www.virustotal.com/ko


=> http://virscan.org


ㄹ. 확신이 섰다면 악성코드를 종료하자. 실행중인 악성코드를 종료하기 위해 Process Explorer에서 해당 악성코드를 선택하여 마우스 우측버튼을 누르면 나오는 메뉴중 [Kill Process] 를 선택하면 해당 프로세스가 종료되고, [Kill Process Tree]를 선택하면 해당 프로세스 및 해당 프로세스의 자식 프로세스까지 같이 종료된다. - TEST_MAL.vir.exe, lsass.exe -> 마우스 우측버튼 -> Kill Process/Kill Process Tree



 

ㅁ. 어라.. 아직 남았네.


Process Explorer로 TEST_MAL.vir.exe는 종료되었지만, 실행/종료를 반복중인 lsass.exe는 끄떡도 안한다. 일반적인 바이러스의 경우 Process Explorer, IceSword, Gmer, 추가적으로 Autoruns면 끝을 보는데 실행/종료를 반복하는 악성코드의 경우는 이것들로 해결이 되지 않을 수 있다.


[시도-1] IceSword로 Process를 종료해보자.


(생성/종료를 반복하기 때문에 안보일때도 있음) 왼쪽메뉴 Function/Registry/File중 Function을 선택한 뒤 Process를 선택하면 실행중인 프로세스의 PathName과 ImageName를 확인할 수 있다. 마우스 우측버튼으로 선택해서 Terminate Process를 누르면 종료해보자. 종료된 것 처럼 보였지만, 여전히 프로세스 생성/종료를 반복하고 있다. 실패!!



[시도-2] 실패했다. 그러면 IceSword로 파일을 지워보자.


왼쪽메뉴 Function/Registry/File중 File을 선택하여 C드라이브를 선택하면 lsass.exe가 보이므로 해당 악성코드를 선택하여 [Delete]/[force delete]해보자. 지워진것 처럼 보이지만 Process Explorer에서는 여전히 실행/종료를 반복하고 있다. 실패!!



[시도-3] Gmer로 프로세스를 종료해보자.


(생성/종료를 반복하기 때문에 선택안됨) Gmer를 실행시키고 맨위의 메뉴 [Rootkit/Malware]/[>>>>]중 >>>>를 선택하면 아래와 같은 메뉴가 나온다. 그중 첫번째에 있는 Process를 선택하여 [Kill Process]하려 하였으나 선택이 안된다. 실패!!



[시도-4] Gmer로 파일을 파일을 지워보자.


메뉴중 [File]를 선택하여 C드라이브에 존재하는 lsass.exe를 선택하여 [Delete]를 누르면 제거되지만 다른 폴더를 억세스후 다시 확인해보면 그대로다. 실패!! [File]메뉴에도 [Kill]이 존재하여 종료해보니 성공 반!! 실패 반!! 이었다.



ㅂ. 왜 안되는지 문제점을 파악하자.


Process Explorer, IceSword의 문제는 실행/종료가 반복되는 해당 프로세스에 대한 종료를 하려 하면 이미 해당 프로세스의 ID(=PID)는 이미 사라지고 다른 PID가 생성되면서 딜레이가 발생해서 인것으로 추정되었다. 즉 툴이 보여주는 프로세스와 현재 실행중인 프로세스에 차이가 발생해서 종료가 불가능 했던 것이며, Gmer의 경우 성공 반!! / 실패 반!! 이 가능했던 이유는 변하지 않는 않는 파일쪽에서 [Kill]명령을 내려서 인것으로 추정되었다. 한 두번 하면 성공!!


ㅅ. 위의 방법만으로만 해결이 가능한 것일까? 좀더 쉬운 방법은 없을까?


여러가지 조건을 걸어줄 수 있는 Taskkill이 가능 했었다. 아래의 Process Explorer을 보면 정상 lsass.exe와 악성 lsass.exe의 차이를 찾아서 조건부 Kill을 하면 되는 것이었다. Process Explorer의 숨겨진 컬럼을 추가하여 보자.


a. View -> Select Columns선택



b. Process Image에서 User Name, command Line를 체크해준다.



c. 아래의 컬럼이 추가된 Process Explorer을 보면 User Name이 다른 것을 알수 있다.

Taskkill을 이용하여 종료시켜보자. 프로세스가 종료되는 순간이 있기 때문에 프로세스를 찾지 못하는 경우도 있으니, 한두번 더 해주면 성공할 것이다.

<<사용된 명령어>> Taskkill /f /fi “username eq pcname” /im lsass.exe




휴.. 해결되었다.. 처음엔 쉬운걸 선택한줄 알았는데, 의외로 까다로운 악성코드였다. 이번 악성코드는 좀 방황했지만, 대부분 Process Explorer에서 프로세스를 종료하고 IceSword나 Gmer로 파일을 지우면 대부분 해결된다. 이제 악성코드라고 멀리하지 말고 가끔은 자신의 힘으로 악성코드를 제거해보는건 어떨까 한다. 물론 가끔이다.


(주)하우리 기술연구소 바이러스팀 연구원 이새별


+ Recent posts