공부

ssh 접속한 사람 잡기

야끼 소바 — Mon, 1 Jun 2026 17:36:42 +0900

auditctl -w /usr/bin/ssh -p x -k ssh_exec

/usr/bin/ssh 를 감시

실행되는 경우

ssh_exec 라는 태그 적용

ausearch -k ssh_exec -i

ssh_exec 라는 태그가 붙은 로그 출력

Kroki 미적용 해결 - diagram proxy 미지원 문제

야끼 소바 — Mon, 1 Jun 2026 17:13:18 +0900

https://gitlab-docs.infograb.net/17.9/ee/administration/integration/kroki.html

GitLab 공식 기술 문서 한글판 by 인포그랩 | 인포그랩 | GitLab 기반 DevSecOps 구축,컨설팅,교육,CICD Pipe

GitLab의 Selected 파트너 인포그랩에서 OpenAI 기술 기반으로 자체 개발한 자동화 번역 프로그램을 통해 GitLab 공식 기술 문서의 한글판을 국내 최초로 제공합니다.

gitlab-docs.infograb.net

위의 문서를 접속하면 kroki 설정을 확인할 수 있다.

그런데 kroki 로 작성한 diagram이 출력이 안되는 문제 발생

mermaid는 작동하나 다른 다이어그램이 출력이 안되는 상황

curl도 제대로 나오고

svg도 서버에서 제대로 지원함

연결 문제라고 해서 확인해보니

현재 깃랩 버전에서는 diagram proxy를 지원을 안한다

그전에 kroki는 마크다운 문법으로 작성한 다이어그램을 랜더링해주는 랜더링 서버이다

gitlab -> kroki -> mermaid 엔진 -> SVG/PNG 생성 -> GitLab 화면 표시

gitlab과 kroki간 통신도 확인했고 curl 을 이용하여 svg, png 도 잘 생성되는 것을 확인했다.

diagram proxy는 gitlab이 kroki 서버에서 직접 이미지를 가져와 사용자에게 보여주는 방식이다.

이것이 지원되지 않는 경우 사용자가 직접 kroki 서버에 접근할 수 있어야 이미지를 볼 수 있다.

방화벽 설정으로 자체 kroki 서버에 접근 허용하고 확인해보니

아래와 같이 출력이 잘 되었다.

Failed to load API definition

야끼 소바 — Tue, 31 Mar 2026 15:11:04 +0900

swagger에서 아래와 같은 에러 발생

컨테이너에서 확인해 보니 아래와 같은 로그를 발견했다.

Caused by: java.lang.NoSuchMethodError: 'java.lang.String io.swagger.v3.oas.annotations.media.Schema.$dynamicRef()'

annotation과 core의 버전 불일치 문제라고 한다.

jar에 있는 파일 목록을 살펴보았다.

root:  /# jar tf ./app.jar | grep -E "swagger|springdoc" 
BOOT-INF/lib/springdoc-openapi-starter-common-2.8.16.jar 
BOOT-INF/lib/springdoc-openapi-starter-webmvc-api-2.8.16.jar 
BOOT-INF/lib/springdoc-openapi-starter-webmvc-ui-2.8.16.jar 
BOOT-INF/lib/swagger-annotations-2.2.21.jar 
BOOT-INF/lib/swagger-annotations-jakarta-2.2.43.jar 
BOOT-INF/lib/swagger-core-jakarta-2.2.43.jar 
BOOT-INF/lib/swagger-models-jakarta-2.2.43.jar 
BOOT-INF/lib/swagger-ui-5.32.0.jar

swagger-annotation과 annotaion-jakarta 의 버전이 맞지 않았다.

2.2.21에는 $dynamicRef() 메서드가 없어서 발생한 사건으로 보인다.

2.2.21이 너무 낮은 버전이어서 2.2.43 으로 build.gradle에 추가

dependencyManagement {

dependencies {

dependency 'io.swagger.core.v3:swagger-annotations:2.2.43'

}

Signoz 에러 Key not found

야끼 소바 — Thu, 18 Dec 2025 10:45:01 +0900

Signoz 에서 로그 확인 시 필터링 에서 이슈가 발생했다.

필터를 걸어주지 않으면 로그가 출력되지만

필터를 걸어주면 key not found 라고 하면서 로그가 출력되지 않았다.

docker exec -it signoz-clickhouse clickhouse-client

SELECT DISTINCT arrayJoin(mapKeys(resources_string)) AS resource_key
FROM signoz_logs.distributed_logs_v2
ORDER BY resource_key ASC

Query id: 472d571d-1224-40ed-a66f-7a6f72afa1dd

┌─resource_key────────────────┐
│ container.id                │
│ deployment.environment      │
│ deployment.environment.name │
│ host.arch                   │
│ host.name                   │
│ os.description              │
│ os.name                     │
│ os.type                     │
│ os.version                  │
│ process.command             │
│ process.command_args        │
│ process.executable.path     │
│ process.owner               │
│ process.pid                 │
│ process.runtime.description │
│ process.runtime.name        │
│ process.runtime.version     │
│ service.instance.id         │
│ service.name                │
│ service.version             │
│ telemetry.distro.name       │
│ telemetry.distro.version    │
│ telemetry.sdk.language      │
│ telemetry.sdk.name          │
│ telemetry.sdk.version       │
└─────────────────────────────┘

실제 데이터는 잘 들어오는 것을 확인했다.

에러가 없는 다른 signoz 서버와 비교했을때

데이터가 똑같은 resource_key 컬럼으로 들어오고 있었다.

이 때문에 필터를 걸어주지 않았을때 정상적으로 데이터가 출력되었다.

그러다가 필터에 관련된 테이블을 발견했다.

signoz_logs.distributed_logs_resource_keys

이 테이블에 위 테이블의 column 값들이 없어서 발생한 현상이었다.

실제로 아래와 같은 명령어로 resource_key를 확인해보니

에러가 없는 필터 key 값이 들어있었다.

SELECT DISTINCT name,datatype
FROM signoz_logs.distributed_logs_resource_keys

Query id: af9ba0d2-7e72-4246-b8d5-0592c4159b2d
┌─name────────────────────────┬─datatype─┐
│ container.id │ string │
│ process.command │ string │
│ process.command_args │ string │
│ process.runtime.description │ string │
│ service.instance.id │ string │
│ service.version │ string │
└─────────────────────────────┴───────┘

INSERT INTO signoz_logs.distributed_logs_resource_keys (name, datatype)
VALUES ('os.name', 'string');

위와 같은 쿼리를 날려 데이터를 넣어

signoz_logs.distributed_logs_v2 테이블의 resource_keys와

signoz_logs.distributed_logs_resource_keys 테이블의 데이터를 맞춰주니 필터가 정상적으로 동작하는 것을 확인했다.

깃랩 공식 변수

야끼 소바 — Wed, 10 Dec 2025 13:24:27 +0900

https://docs.gitlab.com/ci/variables/predefined_variables/

Predefined CI/CD variables reference | GitLab Docs

Predefined CI/CD variables reference Tier: Free, Premium, UltimateOffering: GitLab.com, GitLab Self-Managed, GitLab Dedicated Predefined CI/CD variables are available in every GitLab CI/CD pipeline. Avoid overriding predefined variables, as it can cause th

docs.gitlab.com

if: '($CI_PIPELINE_SOURCE == "merge_request_event" && $CI_MERGE_REQUEST_TARGET_BRANCH_NAME != "master")'

gitlab-ci 에서 이와 같은 방식으로 실행하기 위험

랜섬웨어

야끼 소바 — Mon, 13 Oct 2025 11:29:54 +0900

0.011 BTC = 1810334.87 원 이란다....

내가 해커라면 며칠 기다려서 181만원 받을바에

40만원으로 하루에 3탕을 치겠다

ulimit -a

야끼 소바 — Thu, 11 Sep 2025 11:05:27 +0900

- cor

core file size	프로그램이 크래시 했을 때 생성되는 core dump 파일의 최대 크기
data seq size	프로세스의 데이터 세그먼트(힙 메모리) 크기 제한
scheduling priority	프로세스의 우선순위 값
file size	생성가능한 단일 파일의 최대 크기
pending signals	해당 사용자가 동시에 보낼 수 있는 보류 중인 시그널 수
max locked memory	mlock()등을 통해 RAM에 고정 할 수 있는 메모리 크기
max memory size	프로세스가 사용할 수 있는 최대 메모리 크기
open files	한 프로세스가 동시에 열 수 있는 파일 디스크립터 개수
pipe size	파이프(IPC)의 버퍼 크기 512바이트 * 숫자
POSIX message queues	POSIX 메시지 큐에서 사용할 수 있는 최대 크기
real-time priority	실시간 스케줄링 우선순위
stack size	스택 메모리 크기 제한
cpu time	프로세스가 사용할 수 있는 cpu 시간 제한
max user processes	한 사용자가 동시에 실행할 수 있는 프로세스 개수
virtual memory	가상 메모리 크기 제한
file locks	파일에 걸 수 있는 lock의 개수

그누보드 - 라이센스(License) 내용에 동의하셔야 설치를 계속하실 수 있습니다

야끼 소바 — Mon, 11 Aug 2025 18:32:02 +0900

php.ini 에서 에러 출력 활성화를 하고 확인해보면

이런 에러를 볼 수 있다.

POST 값을 임시로 저장할 곳을 찾지 못해 생기는 일이다.

사용자의 tmp 폴더의 권한을 777로 설정하면

아래와 같이 넘어간다.

이 부분을 넘어갈 수 있는 방법은 많지만 tmp 디렉토리로의 접근 문제로 인한 다른 에러를 방지하기 위해

체크하고 넘어가는게 좋을 듯 하다

차단 IP 조회 쉘 스크립트

야끼 소바 — Mon, 11 Aug 2025 11:33:46 +0900

IP 차단 여부를 자주 체크해서 전달해야 하는 일이 있는데,

굳이 우리팀에서 확인해서 알려주지 않아도 되도록 스크립트를 작성했다.

OliveTin에서 실행결과를 출력해주기 때문에

다른팀에서 터미널 접속할 필요없이 OliveTin만 실행해서 결과확인이 가능하게 되었다.

구성요소는

디렉토리 2개

ip_list - 전체 차단 된 ip 목록
diff - 이전에 있던 전체 차단 된 ip 목록의 변경사항

쉘 스크립트 1개

denied_ip.sh - 실행 스크립트

텍스트 및 기타로그파일 1개

target_list.txt - 차단 된 ip 목록 파일의 경로가 적힌 파일

이렇게 구성되어있다.

우선

전체 차단 ip 목록을 생성

이후 전체 차단 ip목록 파일을 diff로 비교하여 차이점 발생 시 diff 폴더에 저장

이후 오래된 전체 차단 ip 목록 삭제

diff 파일 확인하여 최근 차단된 ip로 표시하여 출력

diff에는 있으나 전체 차단 ip 목록에 없는 경우 차단해제 표시하여 출력

#!/bin/bash
cd /root/denied_ip
DATE=$(date '+%Y%m%d_%H:%M:%S')
LOG_DIR="ip_list"
DIFF_DIR="diff"
TMP_DIFF="$DIFF_DIR/tmp_diff.log"

mkdir -p "$LOG_DIR" "$DIFF_DIR"
LOGFILE="denied_ip_$(date '+%Y%m%d_%H%M%S').log"
FULL_PATH="$LOG_DIR/$LOGFILE"

DIFF_FILE="diff_$(date '+%Y%m%d_%H%M%S').log"
DIFF_PATH="$DIFF_DIR/$DIFF_FILE"

target_list="target_list.txt"

# all denied ip listi
echo "###" > "$FULL_PATH"
echo "### iptables" >> "$FULL_PATH"
echo "###" >> "$FULL_PATH"

sudo iptables -L INPUT -n -v | awk 'NR>2 && $1 ~ /^[0-9]+$/ {print $8}' >> "$FULL_PATH"
echo -e "\n\n" >> "$FULL_PATH"

while IFS= read -r SRC
do
  # 빈 줄이나 #로 시작하는 줄 스킵
  case "$SRC" in
    ''|\#*) continue ;;
  esac
  echo "###" >> "$FULL_PATH"
  echo "### $(basename "$SRC")" >> "$FULL_PATH"
  echo "###" >> "$FULL_PATH"
  awk '$1 ~ /^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$/ { print $1 }' "$SRC" >> "$FULL_PATH"
  echo -e "\n\n" >> "$FULL_PATH"
done < "$target_list"
# compare all denied ip lists
log_files=($(ls -1t "$LOG_DIR"/denied_ip_*.log 2>/dev/null))

if [ ${#log_files[@]} -ge 2 ]; then
    NEW_FILE="${log_files[0]}"
    OLD_FILE="${log_files[1]}"

    diff "$OLD_FILE" "$NEW_FILE" \
      | grep '^>' \
      | grep -v '#' \
      | sed "s/^> \(.*\)/\1 $DATE/" > "$TMP_DIFF"

    # ip diff save
    if grep -qE '([0-9]{1,3}\.){3}[0-9]{1,3}' "$TMP_DIFF"; then
        mv "$TMP_DIFF" "$DIFF_PATH"
    else
        rm -f "$TMP_DIFF"
    fi

    # old diff file remove
    ls -t "$DIFF_DIR"/diff*.log 2>/dev/null | tail -n +7 | xargs -r rm -f
    rm -f "$OLD_FILE"
fi


############################## result
echo "#######################"
echo "### 최근 차단된 IP  ###"
echo "#######################"
diff_files=($(ls -1t "$DIFF_DIR"/diff*.log 2>/dev/null))

if [ ${#diff_files[@]} -gt 0 ]; then
    for file in "${diff_files[@]}"; do
        while read -r ip; do
            # IP 형식만 추출 (예: "pass 1.2.3.4" 또는 "1.2.3.4 YYYYMMDD_HH:MM:SS")
            target_ip=$(echo "$ip" | awk '{print $1}')
            [[ "$target_ip" =~ ^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+(/[0-9]+)?$ ]] || continue

            if grep -qwF "$target_ip" "$FULL_PATH"; then

                echo "차    단$ip"
            else
                echo "차단해제$target_ip"
            fi
        done < "$file"
    done
 #   echo $DIFF_DIR'/'*
else
    echo "there is no file"
fi
echo ""
echo "######################"
echo "### 모든 차단된 IP ###"
echo "######################"
echo ""
cat "$FULL_PATH"
#echo "$(date '+%H:%M:%S.%3N') - $ip"
sleep 0.5s
exit 0

서비스 프록시

야끼 소바 — Sun, 10 Aug 2025 21:04:45 +0900

쿠버네티스의 서비스가 트래픽을 올바른 파드(Pod)로 전달하도록 중간에서 라우팅·포워딩을 해주는 구성 요소

요청으로 온 cluster IP를 실제 Pod IP와 연결해준다.

대표적으로 kube-proxy가 있으며 3가지 방식으로 움직인다.

iptables - 서비스의 가상 IP와 포트를 커널레벨의 iptables 규칙으로 등록 후 패킷을 해당 서비스의 파드로 NAT

IPVS - 리눅스 커널의 IPVS 모듈을 이용 - 대규모 작업에 효과적

userspace - kube-proxy 프로세스가 직접 소켓을 포워딩하는 형식(현재는 거의 안쓰임)

iptables 방식

# ClusterIP로 들어온 패킷을 서비스 체인으로 이동
-A KUBE-SERVICES -d 10.96.0.1/32 -p tcp --dport 80 \
  -j KUBE-SVC-XXXXXXX

# 서비스 체인 → 엔드포인트 체인 (라운드 로빈)
-A KUBE-SVC-XXXXXXX -m statistic --mode random --probability 0.333333 \
  -j KUBE-SEP-AAAAAAA
-A KUBE-SVC-XXXXXXX -j KUBE-SEP-BBBBBBB
...

# 엔드포인트 체인에서 DNAT 수행
-A KUBE-SEP-AAAAAAA -j DNAT --to-destination 10.244.1.5:80

커널수준에서 처리하기에 빠른 편이고, 의존성이 적다는 장점이 있다.
서비스나 파드수가 늘어날수록 규칙이 더 복잡해지기 때문에 업그레이드 시 성능저하의 위험이 있다.

IPVS 방식

원리: Linux 커널의 IPVS (IP Virtual Server) 모듈을 사용
IPVS는 iptables보다 더 전문적인 L4 로드밸런싱 엔진
kube-proxy가 ipvsadm 명령을 통해 서비스와 엔드포인트를 커널에 등록
커널 내부에서 해시 테이블로 매핑 → 검색과 라우팅 속도가 훨씬 빠름

TCP  10.96.0.1:80 rr
  -> 10.244.1.5:80  Masq    1  0  0
  -> 10.244.2.8:80  Masq    1  0  0
  -> 10.244.3.12:80 Masq    1  0  0

커널 레벨 해시 기반 → 규칙이 많아져도 빠름
다양한 LB 알고리즘 지원 (rr, lc, sh 등)
iptables보다 업데이트 시 부하 적음

IPVS 모듈이 커널에 로드되어 있어야 함 (추가 설정 필요할 수도 있음)