Windows Packet Monitoring by SmartSniff (smsniff)

이미지
가끔 Windows PC나 서버를 운영하다 보면, 장애나 이슈로 Network Packet Monitoring을 해야 할 때가 있다. 보통 Wireshark를 설치하여 Packet Dump 및 분석을 진행하는데, 고객의 PC나 서버의 경우 Wireshark 및 Capture용 Driver를 설치하는 것이 부담스러울 때가 있다. 바로 이 때, NirSoft 사의 SmartSniff라는 제품을 사용하면 좋을 것 이다. http://www.nirsoft.net/utils/smsniff.html 이 프로그램의 장점은 위 사이트에서 무료로 다운로드 받을 수 있으며, 문제의 장비에서 별도의 설치 과정 없이 실행이 가능하다는 것이다. 일단 실행하면 아래와 같은 매우 심플한 창이 뜬다. 여기서 바로 좌상단의 삼각형 재생 버튼을 클릭하면 바로 Packet Capture 작업이 시작된다. 실제로 사용자 PC에서 Capture한 화면이다. Column 3~4는 실제 IP가 찍히고, 어떤 Protocol로 통신했는지까지 확인이 가능하다. 12번 통신 내역은 MS-SQL서버로 로그인하는 Packet을 잡은 것이다. 해당 패킷을 우클릭하여 HTML로 보면 아래와 같이 HTML형대로 자료가 정리된다. 실제로 해당 Packet의 분석 과정에서 암호화 되지 않은 Query문에서 SQL Server로 로그인 하는 계정과 패스워드까지 확인 할 수 있었다. 따로, HEX Dump 분석 없이도 오른 쪽 열에 ASCII 문자를 보여줄 정도입니다. 사전에 장애나 이슈에 대한 정보가 있었다면, Capture Filter를 적용하여 보다 정확하게 문제에 접근 하는 것도 가능하다. 항상 PC나 관리 서버에 올려두고 유용하게 사용하기 좋은 툴로 보인다. 물론 관리자의 약간의 경험과 툴에 대한 이해가 장애같이 급박한 상황에서는 툴과 함께 더 빛을 바랄 것이라고 생각된다.

linux stat command

Linux 서버를 운영하면서 가끔 파일의 상태를 보고자 할 때가 있다. 마지막으로 접속한 시간이나, 변경한 시간, 파일의 Permission 등이 궁금할 때가 있는데, 이 때 사용할 수 있는 명령어가 바로 stat이다. [root@test log]# stat messages   File: `messages'   Size: 635             Blocks: 8          IO Block: 4096   일반 파일 Device: 6802h/26626d    Inode: 6816140     Links: 1 Access: (0600/-rw-------)  Uid: (    0/    root)   Gid: (    0/    root) Access: 2016-02-01 12:31:01.526079662 +0900 Modify: 2016-02-01 14:01:46.134250103 +0900 Change: 2016-02-01 14:01:46.134250103 +0900 사용법은 매우 간단한데, stat 명령어 뒤에 바로 파일 명 또는 디렉토리 명을 적어주면 된다. 그 결과 값은 위와 같이 나오는데, 여기서 몇 가지 눈여겨 봐야 할 항목이 있다. 권한이나 사용자/그룹에 대한 내용은 ls명령어를 통해 활용 충분히 확인이 가능한데, 파일의 Access나 Modify, Change 시각에 대한 확인도 가능하다. Access - 파일에 마지막으로 접근 했던시각 Modify - 파일의 Contents를 마지막으로 수정 했던 시각 Change - 파일의 Permission을 마지막으로 수정했던 시각 [root@test]$ stat -f /app/   File: "/app/"     ID: 0        Namelen: 255     Type: nfs Block size: 1048576    Fundamental block size: 1048576 Blocks: Total: 1996800    Free:

Installing IPMI Tool for Linux Server

IPMI은 (Intelligent Platform Management Interface)의 약자이며, Intel이 리드하고, HP, DELL 등 다수의 x86 Platform 서버 제조사가 지원하는 사실상의 H/W 관리 프로토콜이다. 따라서, 각 제조사 및 지원 OS의 기능을 볼 수 도 있지만, 가장 근본인 Intel의 자료를 한 번 보는 것이 의미 있을 것 같다. http://www.intel.com/content/www/us/en/servers/ipmi/ipmi-animation.html 기본적으로 서버의 온도나, Power, Fan, H/W Inventory 등의 정보를 수집하고 그 정보를 OS나 관리 콘솔 등으로 전달해 주는 Interface이다. HP는 이를 활용하여 ILO라는 관리 콘솔을 만들어 사용자의 서버 관리를 편하게 해 주었으며, 최근에는 Network를 통해 원격지의 서버로 IPMI기능을 사용하여 서버의 On/Off 부터 각종 H/W 항목을 모니터링 관리할 수 있게 개발되고 있다. [root@test ~]# yum install ipmitool Loaded plugins: aliases, changelog, downloadonly, kabi, presto, product-id, refresh-packagekit, security, subscription-manager, tmprepo, verify, versionlock This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register. Loading support for Red Hat kernel ABI LOCAL                                                                                                                                

Starting Xperf by Windows Performance Tools (WPT)

이미지
Windows Server의 성능 이슈 중, 서버 내 상세한 항목을 보기 위한 방법으로 Windows Performance Tools을 활용 할 수 있다. 물론, Perfmon은 Windows Server 및 MS사의 Product에 대한 다양한 성능 API를 제공하고, 사용자가 손쉽게 데이터를 뽑아낼 수 있지만, 특정 시점에 발생하는 성능 이슈에 대해서는 xperf를 활용한 성능 정보 수집 및 분석이 매우 용이할 수 있다. 먼저 Windows Server 설치 상태에선 xperf를 바로 활용 할 수 없기 때문에, Windows ADK 설치를 통해 Windows Performance Toolkit 을 설치해야 한다. https://www.microsoft.com/en-us/download/confirmation.aspx?id=39982 Windows Server 2012 버전 용 ADK 설치 파일 설치 파일을 서버에 올려 실행하면 설치 Kit 중 Windows Performance Tools를 선택하여 설치 할 수 있다. 운영 서버의 경우 다행인 점은 설치 중간에 서버의 재기동은 없다. 설치 후, CMD 또는 Powershell 화면에서 바로 xperf라고 명령어를 실행시켜 보면 설치가 정상적으로 됐는지 확인 가능하다. 일단, 설치가 완료됐으면 가장 기본적인 사용법으로 성능 정보 수집을 진행할 수 있다. xperf에는 기본적으로 다양한 성능 정보 항목 및 취합 그룹을 갖고 있다. xperf -help providers 라고 명령어를 수행 해 보면 다수의 성능 정보 취합 항목(또는 그룹)을 확인 할 수 있다. 이 중 많이 취합하는 항목으로는 KG(Kernel Group)인데 그 내용은 아래와 같다. 성능 이슈로 보여지는 상황에 맞는 Kernel 의 모니터링 항목을 잘 모아 놓은 KG를 선택하여 성능 정보를 취합할 수 있다. 예를 들어 File I/O에 이슈가 있는 것으로 보일 때는 FileIO 그룹을 택하면 되

Linux SSH Login without Password

이미지
Linux 서버를 운용하다 보면, SSH 로그인을 패스워드 없이 구성해야 하는 경우가 종종 있다. Oracle RAC 구성을 위해 Node 서버 간 Oracle 운영 계정에 대해 패스워드 없이 접속 가능하도록 구현하거나, 특정 XML을 서버에 올리고 내리는 작업을 자동화 하기 위해 패스워드 인증 단계 없이 구성하는 경우가 있다. 이 경우, 정확한 구성 방법과 원리를 이해한다면 기계적으로 구성하면서 놓치는 부분이나, 실수를 줄일 수 있을 것으로 생각된다. 그 전에, 간단히 역사 공부를 하자면, 1976년 Whitfield Diffe와 Martin Hellman은 공개 키 암호 알고리즘을 만들었다. 그 후, Linux 서버 및 전자 상거래 인증서 등에 많이 사용되는 RSA키는 1978년 로널드 라이베스트(Ron Rivest), 아디 샤미르(Adi Shamir), 레너드 애들먼(Leonard Adleman)의 연구에 의해 체계화되었으며, RSA라는 이름은 이들 3명의 이름 앞글자를 딴 것이다. 이들은 다수의 시도와 여러 알고리즘을 테스트 한 끝에  Scientific American 1978년 8월호에 그 결과를 내놓게 된다. 공개키와 개인키를 이용한 암호화 작동원리는 다음과 같다. 기본적으로 공개키는 누구나 가질 수 있는 키이고, 개인키(혹인 비밀키)는 자기 자신이 갖고 있는 키이다. A라는 사람이 B라는 사람의 공개키로 메시지를 암호화하여 B에게 보내면, B만 가지고있는 개인키로 이를 복호화 할 수 있다. 이 과정에서 A라는 사람이 자신의 개인키로 서명을 한다면, B가 메시지를 받았을 때, A라는 사람의 공개키로 그 서명도 같이 확인 할 수 있는 원리이다.  수학적으로는 매우 큰 정수를 소인수 분해하기 어렵다는 접근에서 계산 원리가 만들어졌다. 이 때문인지 아주 큰 소수(1과 자기 자신으로 밖에 나누어지지 않는 수)를 구할 수 있다면 돈이 되는 얘기도 있었다. SSH로그인 과정에서는 이러한 공개키 방식을 이용하여 별도의 패스워드 없이 키 인증만으로

EFI GPT and BIOS MBR

이미지
이 이야기는 FileSystem 도 아니고, Storage에서 작업해서 서버에 할당 해 주는 LUN에 대한 내용도 아니다. 사실 OS를 설치 운영한다면 많지 않은 시간 지나치는 설정 항목인 Patition에 대한 내용이다. 최근 PC및 서버에서 EFI 환경으로 OS를 설치하는 경우가 많아졌다. 기본적으로 EFI는 그래픽 인터페이스를 제공하여 사용자의 편의성을 제공하고, 대용량 디스크와 다수의 파티션을 사용할 수 있는 장점이 있다. Windows 8.1을 설치한 PC에서 DISKPART 명령어로 확인 해 본 결과 디스크는 GPT형식으로 잡혀있으며, 다수의 300MB와 128MB라는 내 컴퓨터에서는 보이지 않는 파티션이 잡혀있는 것을 확인할 수 있다. 이는 ESP(EFI(Extensible Firmware Interface) 시스템 파티션), MSR(Microsoft® Reserved) 파티션이다. https://technet.microsoft.com/ko-kr/library/dd744301(v=ws.10).aspx 평상시에는 느끼지 못 하지만, BIOS(MBR)과 EFI(GPT)의 경우 서버의 부팅환경에서 큰 차이를 보인다. System Board의 Firmware에서 부팅을 위해 MBR또는 EFI를 찾게되고, 바로 이곳부터 OS의 부팅이 시작되게 때문이다. 마찬가지로 UEFI환경에 설치된 OS를 Veritas 사의 SSR 등의 Third Party Tool 등으로 Restore를 진행할 때에는 보이지 않는 볼륨을(MBR구성에 비교해 설치 과정에서 추가했던 볼륨) 모두 받아야 하고, 복구 CD로 부팅 후, 미리 EFI/MSR 볼륨을 만들어 준 후 복원을 해야한다. 이 때, 복구 CD(대부분 Windows PE버전일 것이다)의 CMD(DISKPARK명령어)를 활용하여 아래와 같이 불륨을 미리 잡아 줄 수 있다. select disk 0 clean convert gpt create partition efi size=100 forma