일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 | 31 |
- Shift + ESC
- Mac
- Chrome 작업관리자
- Kublet
- decap
- ip forwarding
- 강의
- 무선채널
- OpenID Connect
- 계정 탈취
- 대학원
- Container
- recon-ng
- 패시브스캐닝
- davtest
- airdecap-ng
- NMAP
- 공격그래프
- SecurityMetric
- Mimikatz
- cgroups
- 넷크래프트
- dnsenum
- AttackGraph
- 보안
- 프로젝트
- 화이트해커
- Social Network in Game
- 액티브스캐닝
- OIDC
- Today
- Total
네른
로그 로테이션. 말 그대로 로그를 회전시키는 것. 로그 파일의 크기가 너무 커지는 것을 방지하기 위해, 로그 파일을 분산/갱신 하는 과정을 의미한다. Spring과같은 다양한 애플리케이션들은 기본적으로 로그 로테이션 방법을 내부적으로 지니고 있다. 그런데 만약 없다면?? 예를들어 database들 그런 것들을 위해 사용되는거이 리눅스의 기본 패키지 중 하나인 logrotate이다. logrotate는 cron을 기반으로 돌아간다고 생각하면 되는데, 당연하게도 주기적으로 로그를 갱신해야되므로 필요하다. 간단하게 구조를 보면 cron의 동작을 기술하는 부분 중, cron.daily 폴더 내부를 보면 logrotate파일이 있는 것을 볼 수 있다. 그리고, 해당 파일의 내부에는 /etc/logrotate.d ..

약간 번외 느낌인데, Elasticsearch를 사용하다가 쌓인 데이터를 어떻게 처리할까? 에 대해 고민하다가 찾아봤다. 디스크가 터질 것 같았기 때문. ILM(Index Lifecycle Management)인데, 말그대로 elasticsearch index들의 수명을 어떻게 처리할지이다. 주로 Hot, warm, cold, delete 페이즈를 지정해서 일정 기간이 지나도록 접근이 없거나 접근 횟수가 낮으면 중요도를 점점 낮추다가 삭제하는 방식. - 기본적으로 hot-warm-cold 방식을 기반으로 동작 - 자주 접근되는 인덱스는 hot, 일정 기간 이상 접근되지 않으면 warm -> cold 순으로 내려감 - cold 상태에서도 일정 기간 이상 접근되지 않으면(데이터 조회나 추가가 없으면) del..
지난번에 작성한 Fluentd 내용을 토대로, 실제 EFK 스택을 kube에 올릴 때 사용한 yaml을 정리하고자 한다. 해당 yaml들은 helm chart를 기반으로 작성되어있어 일부 변수가 포함되어있다. 실제로는 해당 부분을 직접 채워넣어 사용해도 되니까 우선은 helm chart 내용을 토대로 정리한다! 우선, 각 애플리케이션별 구성은 크게 다음과 같다. Fluentd - Deployment (HTTP 로그 수집용 / Side-car 형태의 로그 수집용) - ConfigMap - Service (HTTP 로그 수집용 Pod를 위한 서비스) - Ingress Elasticsearch - Deployment - Service - Ingress Kibana - Deployment - Service - ..