네른

본 글에서는 JUnit, Jacoco, Jmeter, SiteSpeed.io를 gitlab-ci.yml에 작성하는 틀을 적어두고자함. JUnit JUnit은 우선 Gradle 환경을 기반으로 설명하고자 함. JUnit은 자바의 유닛 테스트 도구로, gradle에서 해당 플러그인을 지원하고 있음 - build.gradle 파일에 다음과 같은 내용 추가 버전이 달라 작성하는 내용에 약간의 차이가 있을 수 있음 implementation ("junit:junit:{junit버전}") testImplementation ("junit:junit:{junit버전}") 이후, Java Testcase를 직접 작성하고 package test; import static org.junit.Assert.*; import o..

해당 업무를 진행하면서 조사하고 적용한 내용중 잊어먹지 않으면 좋을만한 것을 정리하고자 함. GitLab은 자체적으로 제공하는 GitLab Runner를 통해 CI/CD를 자동화하는 기능을 제공하고 있음 이를 설정하면서 겪은 크가지 두 주의점을 기록해두고자 함 1) Gitlab-Gitlab Runner 연동 시 주의할 점 2) DIND 대신 socket을 이용해 runner 동작시키는 법 GitLab은 해당 레포지토리에 commit이 push될 때 CI를 동작하도록 하며 해당 브랜치가 master 브랜치에 머지될 때 마다 CD 작업을 수행하도록 설정할 수 있음. 일련의 과정들은 앞서 언급된 GitLab Runner를 통해 수행됨 GitLab Runner는 쉽게 말해 GitLab에서 지시한 일을 수행하고 ..

테스트했던 것 중에 가장 마지막이었던 JMeter. JMeter는 백엔드 테스팅 도구로, API테스트를 진행하거나 부하 테스트를 진행하는 등의 동작을 수행할 수 있음. 사용자는 JMeter 프로그램을 이용하여 테스트케이스를 작성할 수 있고, 이를 jmx 라는 형태의 파일로 추출할 수 있음. 여기서는 이 jmx 파일을 사용해야하기에, 테스트케이스를 별도로 생성해주어야 함 jmeter는 다행스럽게도 공식 도커 이미지를 제공함 jmeter: stage: after_sitespeed // jmeter는 제공된 공식 이미지를 사용하고, entrypoint를 초기화하여 사용. // 해당 이미지는 docker run 을 이용하여 테스트를 바로 진행할 수 있도록 설계되어있기에 entrypoint를 덮어씌워야 함 ima..

사실, Gitlab의 경우에는 Premium 버전을 구매해서 사용하게 되면 다양한 플러그인을 제공한다. 그 중 하나가 SiteSpeed.io이지만, 여기서는 무료버전에서 해당 기능을 사용하고자 하는 것이므로 이와 관련된 내용을 적고자 한다. SiteSpeed.io는 특정 사이트에 대해 프론트엔드의 부하테스트(load test)를 수행할 수 있는 툴. gitlab-ci.yml은 다음과 같이 작성할 수 있다. 여기서는 제공되는 플러그인이 아닌, NPM에 등록되어있는 sitespeed.io 패키지를 사용한다 주의할 점은 실제 실행되고 있는 서버가 있어야 한다는 점 sitespeed: stage: after_test // NPM에 등록된 SiteSpeed.io 패키지를 사용하고자 함 image: node:16-..

사내에서 JAVA를 이용한 웹 프로젝트가 많아서 관련된 테스팅 도구를 조사한 적이 있다. 조사의 목적은 GitLab CI/CD에 얹어 사용할 수 있는 자동화 테스팅 도구를 찾기 위함이었다. 그 중에서 괜찮다고 생각됐던 것들이나, 실제 사용했던 것들을 간략하게 정리하고자 함 주요 조건에 무료 도구여야함이 있었기에 오픈소스/무료인 도구들만 정리되어있음 1. Jenkins - CI 도구이며 각종 플러그인을 사용해 테스팅도 진행할 수 있음. - 주로 빌드 테스트를 위해 사용되며 다양한 플러그인을 지원함 2. Jmeter - 서버 부하 테스트나 API 테스트를 위해 사용 - HTTP/S, REST, TCP, JDBC 등 다양한 테스트가 진행 가능함 - 직접 테스트 스크립트를 작성하고 프로그램을 실행할 수 있음 -..

지난 업무들에서 주로 사용한 명령어와 자잘하지만 자꾸 까먹을 수 있는 내용들을 좀 정리하고자 한다. [ 많이 사용했던 명령어들] 사실 이미 잘 정리된게 많기도 많고 필요한건 그때그때 쓰면 되긴하지만 1. docker pull 레포명/이미지명:태그 docker build --tag 레포명/이미지명:태그 경로 docker push 레포명/이미지명:태그 - 이미지 받아오기 - 이미지 빌드하기. 경로는 빌드할 곳의 루트 디렉토리. 보통 . 을 이용해서 현재 경로에서 시작함 - 이미지를 레포지토리에 올리기. - 만약 push하는 곳이 공개된 docker hub인 경우에는 계정명/이미지명:태그 로 빌드하고 push하면 된다 2. docker image ls (docker images) - 받아와 로컬에 설치된 이미..

1. RTL - NX를 우회하는 대표적인 기법. - 라이브러리에는 system, execve등 공격에 용이한 다양한 함수들이 있음 - NX로 인해서 코드를 실행할 수 없으니, "실행 권한이 있는" 코드 영역으로 Return address를 덮자. // Name: rtl.c // Compile: gcc -o rtl rtl.c -fno-PIE -no-pie #include #include const char* binsh = "/bin/sh"; int main() { char buf[0x30]; setvbuf(stdin, 0, _IONBF, 0); setvbuf(stdout, 0, _IONBF, 0); // Add system function to plt's entry system("echo 'system@p..

1. 라이브러리? - 함수, 변수 등을 공유해서 사용할 수 있도록 자주 사용하는 함수들의 정의를 묶어 하나의 라이브러리로 만들어 제공 - libc라는 C의 표준 라이브러리는 어디에나 탑재되는 편 2. 링크? - 컴파일의 마지막 단계 - 프로그램에서 라이브러리의 함수를 사용하는 경우, 함수와 실제 라이브러리의 함수를 연결해줌! - 심볼과 관련된 정보를 찾아서 실행 파일에 링크(연결)해 줌! - 리눅스의 경우 다음과 같은 표준 라이브러리들이 gcc 빌드시에 항상 들어가게 됨. - 이 표준 라이브러리들은 컴파일될때 모두 탐색됨!! $ ld --verbose | grep SEARCH_DIR | tr -s ' ;' '\n' SEARCH_DIR("=/usr/local/lib/x86_64-linux-gnu") SEA..

NX : No-Execute의 약자로, 메모리 영역의 실행 권한을 제거 ASLR : Address Space Layout Randomization의 약자로, 바이너리가 실행될 때 마다 스택, 힙, 라이브러리등을 "임의의 주소"에 배치시키는 것 1. ASLR ASLR을 사용하면 앞에서 배웠던 기법중에 buffer의 주소같은것을 알 수가 없게 된다. 그래서 이 buffer의 주소를 출력하는 공격이 선행되어야 한다. - ASLR은 커널단에서 지원하는 보안 기법! - cat /proc/sys/kernel/randomize_va_space 를 통해 확인할 수 있으며 0인경우 꺼져있는 것 그러나 ASLR이 완전 랜덤화는 아니라는 점 $ ./addr buf_stack addr: 0x7ffcd3fcffc0 buf_he..

보호되어 있는 글입니다.