728x90
반응형

 

Linux lsyncd log 파일 초기화

1. : > 연산자 사용 (내용만 비우고 파일 유지)

: > /var/log/lsyncd/lsyncd.log
  • 파일 내용만 모두 지우고, 파일 자체는 그대로 유지
  • touch와 달리 변경시간은 갱신됨
  • 프로세스가 계속해서 이 파일을 로그로 쓰는 경우에도 안전하게 사용 가능

2. truncate 명령 사용

truncate -s 0 /var/log/lsyncd/lsyncd.log
  • 파일의 사이즈를 0으로 줄여 초기화
  • 동일하게 내용만 삭제, 권한/소유자/경로 그대로 유지

3. echo 명령 사용

echo "" > /var/log/lsyncd/lsyncd.log
  • 빈 문자열을 덮어씌워 내용 삭제

주의사항

  • 로그 파일을 삭제(rm)하고 새로 만드는 것은 서비스나 데몬이 파일 핸들 유지 중일 경우 로그 기록이 끊기는 문제가 발생할 수 있습니다.
  • 따라서 파일 삭제보다는 내용만 비우는 방법이 안전합니다.

 

 

리눅스에서 각 파일의 line 수를 확인하는 방법

1. 단일 파일의 라인 수 확인

wc -l filename.txt
  • 출력 예시:
    123 filename.txt → 총 123줄

2. 현재 디렉토리의 모든 파일에 대한 라인 수 확인

wc -l *
  • 각 파일의 라인 수와 파일명이 나열되고, 마지막에 전체 합계가 나옵니다.
  • 디렉토리 포함시 에러 발생 가능성이 있으므로 텍스트 파일만 지정하려면:
     
wc -l *.txt

3. 하위 디렉토리 포함 모든 파일 라인 수 확인 (재귀적)

find . -type f -exec wc -l {} +
  • .: 현재 디렉토리부터
  • -type f: 파일만 검색
  • -exec wc -l {}: 각 파일에 대해 wc -l 실행

4. 결과를 정렬하여 출력 (라인 수 기준 내림차순)

find . -type f -exec wc -l {} + | sort -nr

 

5. 특정 확장자만 필터링 (예: .py)

find . -name "*.py" -type f -exec wc -l {} + | sort -nr

🔍 참고: 라인 수만 합산하려면

find . -type f -name "*.java" -exec cat {} + | wc -l
  • 모든 .java 파일의 라인을 합쳐서 총 라인 수만 출력합니다.
find . -name "*.tpl.html" -type f -exec wc -l {} + | sort -nr
find . -name "*.tpl.html" -exec wc -l {} + | sort -nr

라인수만계산
find . -type f -name "*.tpl.html" -exec cat {} + | wc -l
find . -type f -name "*.tpl.html" -exec wc -l {} + | sort -nr

 

 

linux csv파일 상위 10개 라인만 조회하는 명령어

 

리눅스에서 **CSV 파일의 상위 10개 라인(행)**만 조회하려면, 일반적으로 head 명령어를 사용합니다.

기본 명령어

head -n 10 yourfile.csv
  • yourfile.csv 파일의 앞 10줄을 출력합니다.
  • -n 뒤에 원하는 숫자를 지정하면 해당 줄 수만큼 출력됩니다.

예시

head -n 10 customers.csv

→ customers.csv 파일의 1행(헤더 포함)부터 10행까지 보여줍니다.

✅ 헤더 제외 상위 10개 데이터만 보고 싶을 때

tail -n +2 yourfile.csv | head -n 10
  • tail -n +2: 2번째 줄부터 끝까지 출력 (즉, 헤더 제외)
  • 그 후 head -n 10으로 상위 10줄을 자릅니다.

CSV 파일의 상위 10개 라인만 추출해서 새로운 파일로 저장

head 명령어 + 리디렉션 사용

bash
복사편집
head -n 10 original.csv > top10.csv
  • original.csv의 앞 10줄을 읽어서
  • top10.csv라는 새 파일에 저장합니다.
  • 기존 파일이 있을 경우 덮어씌워집니다.

헤더 제외하고 상위 10개 데이터만 저장하려면

head -n 10 original.csv > top10.csv
  • 2번째 줄부터 읽은 뒤 상위 10줄만 추출하여 저장
  • 보통 데이터만 필요할 때 사용

헤더 포함 + 상위 10개 데이터 저장 (즉, 11줄: 헤더 + 10줄)

(head -n 1 original.csv && tail -n +2 original.csv | head -n 10) > top10_with_header.csv
  • head -n 1: 헤더 1줄 추출
  • tail -n +2 | head -n 10: 데이터 10줄 추출
  • 전체를 ()로 묶고 >로 새로운 파일에 저장

 

728x90
반응형
728x90
반응형

GCash는 필리핀 최대 모바일 지갑 서비스로, Globe Fintech Innovations, Inc. (브랜드명 Mynt)에 속해 있으며, 운영은 자회사인 G‑Xchange, Inc. (GXI)가 담당하고 있습니다 tribune.net.ph+15en.wikipedia.org+15new.gcash.com+15.

GCash: 회사 개요

소유주 및 주요 주주 구조

GCash의 모회사 MyntGlobe Telecom 계열의 917Ventures가 설립하고, Ant Group(Alibaba 그룹 계열사), Ayala Corporation, 그리고 Globe Telecom이 공동 투자한 합작법인(JV) 구조입니다 growjo.com+15en.wikipedia.org+15reuters.com+15.

결론적으로 현재 주요 주주는 Globe Telecom (via 917Ventures), Ant Group, Ayala, 그리고 MUFG입니다.

요약 정리

회사명 Globe Fintech Innovations, Inc. (브랜드명: Mynt)
운영 서비스 G-Xchange, Inc. (GCash 서비스)
서비스 시작 2004년 10월
주요 주주 Globe Telecom (through 917Ventures), Ant Group, Ayala Corporation (~13%), MUFG (~8%)
Valuation 약 50억 달러 (2024)
 
 
 
728x90
반응형

'Cloud > Alibaba' 카테고리의 다른 글

Alibaba Cloud Linux 3 에서 timedatectl RTC time 동기화  (0) 2024.03.20
728x90
반응형

1. 인증서 형식 오류 (PEM 형식 아님)

  • 인증서 파일은 반드시 **PEM 형식 (Base64 인코딩)**이어야 하며, 다음과 같은 헤더가 포함되어야 합니다:
-----BEGIN CERTIFICATE-----
... (Base64 encoded content)
-----END CERTIFICATE-----
  • 형식이 맞지 않으면 무시됩니다.

확인 방법:

cat /etc/pki/ca-trust/source/anchors/your-cert.crt.pem

 

2. 잘못된 경로에 파일을 넣음

  • 유효한 경로는 다음 중 하나입니다:
    • /etc/pki/ca-trust/source/anchors/ ✅ (권장)
    • /etc/pki/ca-trust/source/blacklist/ ❌ (차단 리스트)
    • /usr/share/pki/ca-trust-source/ (시스템 전역)
  • anchors 폴더 외 경로에 넣으면 적용되지 않습니다.

3. 파일 확장자가 .crt 또는 .pem이 아님

  • 파일 확장자는 반드시 .crt, .pem, .cer 중 하나여야 하며, 그렇지 않으면 무시됩니다.

✔️ 권장 예:

your-cert.crt

 

4. 인증서 내용이 실제로 CA 인증서가 아님

  • 개인 인증서(Client Cert)나 중간 인증서가 아닌 Root 또는 Intermediate CA 인증서여야 합니다.
  • openssl x509 -in cert.pem -text -noout 명령어로 Basic Constraints: CA:TRUE 여부를 확인하세요.

5. extract 실행 후 시스템에 적용 안 됨

  • update-ca-trust extract는 시스템 내 /etc/ssl/certs/ca-bundle.crt 등을 갱신하지만,
    • 이를 사용하는 앱(OpenSSL, curl 등)만 영향을 받음
    • Java는 전혀 영향을 받지 않습니다. (cacerts 별도 관리)

빠르게 점검하는 체크리스트

항목점검
.crt 파일이 PEM 형식인가요?
파일에 -----BEGIN CERTIFICATE----- 헤더가 있나요?
anchors 폴더에 위치했나요? (/etc/pki/ca-trust/source/anchors/)
update-ca-trust extract를 실행했나요?
openssl verify로 테스트해 봤나요?
적용 여부 테스트
openssl verify -CAfile /etc/ssl/certs/ca-bundle.crt your-target-cert.pem​

이 명령어로 시스템에 반영되었는지 테스트할 수 있습니다.

 

/etc/pki/ca-trust/extracted/java/cacerts 에 update-ca-trust extract로 your-cert.cer를 등록하는 방법
 
/etc/pki/ca-trust/extracted/java/cacerts 경로에 인증서를 등록하려는 경우, 이는 Java용 Trust Store에 해당하는 시스템 CA 통합 결과 파일입니다. 이 파일은 직접 수정하는 것이 아니라, update-ca-trust extract 명령으로 자동 생성되며, 다음 절차에 따라야 등록이 성공합니다.

 

목적:

update-ca-trust extract 실행 시 **/etc/pki/ca-trust/extracted/java/cacerts**에
your-cert.cer 인증서가 포함되도록 만드는 절차

등록 절차 요약

1. 인증서를 PEM 형식으로 준비

# 확인: PEM 형식인지 체크
grep "BEGIN CERTIFICATE" your-cert.cer

2. anchors 폴더에 복사

sudo cp your-cert.cer /etc/pki/ca-trust/source/anchors/​

⚠️ 반드시 .cer, .crt, .pem 확장자 중 하나여야 하고, PEM 형식이어야 합니다.

3. Trust Store 갱신

sudo update-ca-trust extract​

이 명령은 /etc/ssl/certs/ca-bundle.crt와 함께 /etc/pki/ca-trust/extracted/java/cacerts도 함께 갱신합니다.

4. 등록 성공 여부 확인

grep -A 1 "BEGIN CERTIFICATE" /etc/pki/ca-trust/extracted/java/cacerts | less​

또는, 파일 내부에 인증서 정보가 포함됐는지 openssl로 확인:

openssl x509 -in /etc/pki/ca-trust/extracted/java/cacerts -text -noout

(위 명령은 일부 시스템에서 오류 발생 가능 — 이 경우 단순 문자열 검색이 더 유효함)

인증서가 포함되지 않는 경우 주요 원인

원인설명
인증서 형식이 DER openssl x509 -inform der로 확인 및 PEM 변환 필요
인증서에 CA:TRUE가 없음 루트 또는 중간 CA 인증서가 아닌 경우 무시됨
파일 위치 또는 확장자 오류 /anchors/가 아닌 위치거나 확장자가 비표준일 경우 무시됨
필요시 PEM 변환
openssl x509 -in your-cert.cer -inform der -out your-cert.pem -outform pem
sudo cp your-cert.pem /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust extract

결론

/etc/pki/ca-trust/extracted/java/cacerts는 수동 수정 대상이 아니며,
PEM 인증서를 anchors/에 넣고 update-ca-trust extract를 실행해야 반영됩니다.

728x90
반응형
728x90
반응형

1. 개인 금융(Personal Banking)에서 DeFi란 무엇인가요?

DeFi(탈중앙화 금융)는 개인에게 자신의 자산에 대한 직접적인 통제권 허가 없이 이용할 수 있는 금융 서비스를 제공합니다.

개인은 다음과 같은 방식으로 DeFi를 활용할 수 있습니다:

  • DEX(탈중앙화 거래소)를 통한 비(非)수탁형 거래
    • 중개기관 없이 직접 암호화폐를 거래할 수 있습니다.
  • 대출 및 차입 프로토콜 참여로 수익 창출 및 담보 대출 이용
    • 암호화폐를 예치해 이자를 얻거나, 담보를 제공하고 대출을 받을 수 있습니다.
  • 스테이블코인 활용
    • 결제 수단으로 사용하거나, 암호화폐 시장의 높은 변동성에 대비하기 위한 헤지(위험 회피) 수단으로 활용할 수 있습니다.

2. DeFi 은행의 예시는 무엇인가요?

DeFi 은행은 전통적인 의미의 은행은 아니지만, Aave, Compound, MakerDAO와 같은 DeFi 프로토콜들이 은행과 유사한 금융 서비스를 제공합니다.

이러한 프로토콜은 오픈소스와 비(非)수탁형(non-custodial) 플랫폼으로 운영되며, 스마트 계약에 의해 관리됩니다.

주요 제공 서비스는 다음과 같습니다:

  • 대출 (Lending)
  • 차입 (Borrowing)
  • 스테이블코인 발행 (Stablecoin Issuance)

전통적인 금융기관 없이도 사용자가 직접 자산을 빌려주고 빌릴 수 있으며, 스테이블코인과 같은 디지털 자산을 발행하고 활용할 수 있도록 지원합니다.

3. 거래 은행(Transaction Banking)에서 DeFi란 무엇인가요?

DeFi(탈중앙화 금융)는 거래 은행 분야에서도 큰 변화를 일으키고 있습니다.

주요 변화 내용:

  • 국경 간 결제의 간소화
    • 복잡한 절차 없이 빠르고 효율적인 해외 송금이 가능합니다.
  • 중개기관 의존도 감소
    • 기존 은행, 결제 네트워크 등의 중개자가 필요하지 않으므로 비용과 시간이 절감됩니다.
  • 스테이블코인 기반 결제 채널 활용
    • USDC, USDT와 같은 스테이블코인을 사용해 가치 변동 위험 없이 결제할 수 있습니다.
  • Layer-2 확장 솔루션 활용 (예: Lightning Network)
    • 비트코인 네트워크의 라이트닝 네트워크와 같은 Layer-2 솔루션을 사용하여 더 빠르고 저렴한 거래 처리가 가능합니다.
  • 탈중앙화 결제 게이트웨이 도입
    • 기업들은 탈중앙화된 결제 게이트웨이를 통해 암호화폐 결제를 직접 수락할 수 있으며, 이를 통해 결제 처리 비용을 절감하고 글로벌 고객에게 더 쉽게 접근할 수 있습니다.

DeFi는 거래 은행 분야에서 더 빠르고, 저렴하며, 투명한 결제 및 정산 환경을 제공함으로써, 기존 금융 인프라를 대체하거나 보완하는 역할을 하고 있습니다.

 

4. DeFi 뱅킹(DeFi Banking)이란 무엇이며, 전통적인 은행과 어떻게 다른가요?

DeFi 뱅킹은 중앙집중화되고 중개 기관에 의존하는 기존 금융 시스템에서 벗어나, 탈중앙화된 개인 간(Peer-to-Peer) 금융 모델로 전환하는 패러다임 변화를 의미합니다.

DeFi 뱅킹의 주요 특징:

  • 블록체인 기술과 스마트 계약 활용
    • 자동화된 계약으로 중개자 없이 거래가 이루어집니다.
  • 중개 기관 불필요
    • 은행, 결제 네트워크, 브로커 등의 역할을 스마트 계약과 프로토콜이 대신합니다.
  • 투명성 향상
    • 모든 거래 기록은 블록체인에 저장되어 누구나 검증할 수 있습니다.
  • 접근성 확대
    • 전통 금융 서비스에 접근하기 어려운 사람들도 인터넷과 암호화폐 지갑만 있으면 금융 서비스를 이용할 수 있습니다.
  • 사용자 주도적 자산 관리
    • 개인이 자신의 자산에 대한 완전한 통제권을 가집니다.

전통적인 은행과의 주요 차이점 비교

구분전통적인 은행DeFi 뱅킹
운영 주체 중앙 기관 (은행) 탈중앙화 네트워크
중개자 존재 있음 (필수) 없음 (스마트 계약)
투명성 제한적 완전한 공개
접근성 제한적 (계좌 필요) 누구나 참여 가능
자산 통제 은행이 관리 사용자가 직접 관리
비용 구조 수수료 및 서비스 요금 상대적으로 저렴
 

DeFi 뱅킹은 기존 금융 시스템의 복잡함과 비효율성을 제거하고, 사용자에게 더 많은 자율성과 투명성, 그리고 비용 절감 혜택을 제공하는 혁신적인 금융 모델입니다.

 

5. DeFi 은행을 전통 은행보다 사용하는 장점은 무엇인가요?

DeFi(탈중앙화 금융)는 사용자에게 다음과 같은 여러 가지 이점을 제공합니다:

1. 허가 없는 접근 (Permissionless Access)

  • 별도의 계좌 개설, 신용 조회 등의 절차 없이 누구나 DeFi 서비스를 이용할 수 있습니다.
  • 전 세계 어디에서나 인터넷과 암호화폐 지갑만 있으면 금융 서비스 이용이 가능합니다.

2. 높은 투명성과 감사 가능성 (Transparency and Auditability)

  • 모든 거래 내역은 퍼블릭 블록체인에 기록되며, 누구나 이를 실시간으로 확인하고 검증할 수 있습니다.
  • 금융 거래의 불투명성과 조작 가능성을 크게 줄일 수 있습니다.

3. 조합성과 상호운용성 (Composability and Interoperability)

  • 서로 다른 DeFi 프로토콜 간에 연동이 가능하여,
    새로운 금융 상품과 서비스를 자유롭게 조합하고 개발할 수 있습니다.
  • 예: Aave에서 대출받고, Curve Finance로 유동성 제공, Compound로 이자 수익 창출.

4. 프로그래밍 가능성과 자동화 (Programmability and Automation)

  • 스마트 계약을 통해 금융 계약을 자동으로 실행할 수 있어,
    수동 개입 없이 효율적으로 거래가 처리됩니다.
  • 예: 정해진 조건에 따라 자동 상환, 이자 지급 등이 가능.

5. 상대적으로 높은 수익률 (Potentially Higher Returns)

  • DeFi 대출 및 투자 프로토콜은 전통적인 예금 상품이나 투자 상품보다 더 높은 이자율과 수익률을 제공하는 경우가 많습니다.
  • 이는 중개 기관이 없어, 수익이 직접 사용자에게 돌아가기 때문입니다.

DeFi 은행은 사용자가 더 쉽게 금융 서비스에 접근하고, 더 높은 수익을 얻으며, 거래의 투명성과 자산 통제력을 직접 확보할 수 있게 해주는 혁신적인 대안 금융 시스템입니다.

 

6. DeFi 뱅킹은 어떻게 작동하며, 어떤 기술이 사용되나요?

DeFi(탈중앙화 금융) 뱅킹은 다음과 같은 핵심 기술을 활용하여 운영됩니다:

1. 블록체인 (Blockchain)

  • 블록체인은 분산 원장 기술로, 모든 거래 내역을 안전하고 투명하게 기록합니다.
  • 데이터를 중앙 서버가 아닌 네트워크 참여자들이 공동으로 관리하며, 변경이나 위조가 어렵습니다.
  • 주요 블록체인 플랫폼: 이더리움(Ethereum), Solana, Polygon 

2. 스마트 계약 (Smart Contracts)

  • 스마트 계약은 자동으로 실행되는 디지털 계약입니다.
  • 계약 조건이 충족되면 사람이 개입하지 않아도 자동으로 거래나 금융 계약이 실행됩니다.
  • 이를 통해 중개 기관 없이 금융 서비스 제공이 가능하고, 운영 효율성을 높일 수 있습니다.
  • 예시:
    • 자동 대출 실행
    • 이자 지급
    • 담보 청산

3. 탈중앙화 거버넌스 (Decentralized Governance)

  • DeFi 생태계에서는 **DAO(Decentralized Autonomous Organization)**와 같은 거버넌스 메커니즘을 활용하여,
    커뮤니티가 직접 프로토콜 개선과 정책 결정을 주도합니다.
  • 거버넌스 토큰을 가진 사용자가 제안 및 투표를 통해 시스템 업그레이드나 주요 의사결정에 참여합니다.
  • 예시 플랫폼: Uniswap DAO, MakerDAO, Aave Governance

DeFi 뱅킹은 블록체인과 스마트 계약을 기반으로, 탈중앙화된 방식으로 금융 서비스를 제공하며,
프로토콜의 운영과 개선은 커뮤니티 중심의 거버넌스 시스템을 통해 이루어집니다.

728x90
반응형

'블록체인' 카테고리의 다른 글

Banking에서 DeFi란 무엇인가?  (0) 2025.02.11
728x90
반응형
Linux 시스템의 cacerts 파일은 Java 신뢰할 수 있는 인증서 저장소 (Java TrustStore) 입니다. 오래된 인증서를 제거하고 최신 인증서를 관리하는 것은 보안상 매우 중요합니다.

 

인증서 제거 절차

1. keytool 명령어 확인

Java TrustStore는 keytool로 관리합니다.
우선 keytool 경로와 Java 환경을 확인합니다.

which keytool
java -version

예시 TrustStore 경로:
/etc/alternatives/java_sdk/jre/lib/security/cacerts

2. 현재 저장된 인증서 목록 확인

sudo keytool -list -keystore /etc/alternatives/java_sdk/jre/lib/security/cacerts -storepass changeit
  • 기본 패스워드: changeit (변경했으면 해당 패스워드 사용)
  • 주요 정보:
    • 별칭 (Alias)
    • 만료일
    • 인증기관 정보

3. 제거할 인증서 결정

  • 예전 인증서를 별칭(Alias) 기준으로 제거합니다.
  • 목록에서 예전 인증서를 찾고 별칭을 메모해 두세요.

4. 인증서 삭제 명령어

sudo keytool -delete -alias <alias_name> -keystore /etc/alternatives/java_sdk/jre/lib/security/cacerts -storepass changeit
  • <alias_name>: 삭제할 인증서의 별칭
  • 예시:
sudo keytool -delete -alias old_cert -keystore /etc/alternatives/java_sdk/jre/lib/security/cacerts -storepass changeit

5. 삭제 후 확인

sudo keytool -list -keystore /etc/alternatives/java_sdk/jre/lib/security/cacerts -storepass changeit

삭제된 인증서가 목록에서 사라졌는지 반드시 확인하세요.

📌 주의 사항

  • cacerts는 시스템 전역 Java 인증서 저장소입니다. 삭제 전 반드시 백업 하시기 바랍니다.
sudo cp /etc/alternatives/java_sdk/jre/lib/security/cacerts /etc/alternatives/java_sdk/jre/lib/security/cacerts.bak​
  • 패스워드를 변경했을 경우, changeit 대신 새 패스워드를 사용 하시기 바랍니다.
  • 일부 시스템에서는 경로가 다를 수 있습니다. 확인 후 정확한 경로 사용 필요.
728x90
반응형
728x90
반응형

 

START_DT START_TIME END_DT END_TIME
20250427 001003 20250427 001238
20250427 001003 20250427 001120
20250427 001003 20250427 001145
20250427 001500 20250427 005432

 

값중에서 START_TIME과 END_TIME의 차이를 초로 계산하는 방법

 

START_DT START_TIME END_DT END_TIME 차이 (초)
20250427 001003 20250427 001238 155
20250427 001003 20250427 001120 77
20250427 001003 20250427 001145 102
20250427 001500 20250427 005432 2372

 

Excel 함수로 변환 공식

만약 A1 셀에 021320처럼 숫자 형태로 입력되어 있다고 가정할 때, 이를 초(second)로 변환하는 공식은 다음과 같습니다:

=INT(A1/10000)*3600 + INT(MOD(A1,10000)/100)*60 + MOD(A1,100)

설명

부분의미
INT(A1/10000) 시(hour) 추출
MOD(A1,10000)/100 분(minute) 추출
MOD(A1,100) 초(second) 추출
각각 시는 ×3600, 분은 ×60을 해서 모두 초로 변환 후 합산  

두 값의 초 차이 구하는 공식

예를 들어,

  • A1 = 021320
  • B1 = 021428
    이렇게 두 값이 있다고 하면, 두 값의 초 차이를 구하는 공식은:
=(INT(B1/10000)*3600 + INT(MOD(B1,10000)/100)*60 + MOD(B1,100)) 
- (INT(A1/10000)*3600 + INT(MOD(A1,10000)/100)*60 + MOD(A1,100))

결과

  • 위 수식을 입력하면,
  • B1 - A1의 초 단위 차이가 바로 계산됩니다.

추가 팁

  • 결과를 분:초 형식으로 보고 싶으면 =TEXT(초값/86400,"[mm]:ss") 형식으로 변환할 수도 있습니다.
  • 예를 들어 위 공식 결과가 68초라면,
    =TEXT(68/86400,"[mm]:ss") 로 01:08처럼 표시할 수 있습니다.

결과를 시:분:초 (hh:mm:ss) 형식으로 변환

엑셀에서는 시간 = 초 / 86400 을 하면 시간 형식으로 바꿀 수 있습니다.
(하루 = 24시간 × 60분 × 60초 = 86400초)

=TEXT(
   ((INT(B1/10000)*3600 + INT(MOD(B1,10000)/100)*60 + MOD(B1,100)) 
   - (INT(A1/10000)*3600 + INT(MOD(A1,10000)/100)*60 + MOD(A1,100))) / 86400,
   "hh:mm:ss"
)

결과 예시

위 식을 적용하면 668초 → 00:11:08 로 출력됩니다.

추가 팁

  • TEXT(..., "hh:mm:ss")로 표시 형식을 지정하지 않으면 엑셀이 소수로 인식할 수 있으므로 반드시 TEXT로 감싸거나, 셀 서식을 **사용자 지정 → hh:mm:ss**로 설정하세요.
728x90
반응형
728x90
반응형

HTTP Request Smuggling (요청 스머글링)이란?

**HTTP 요청 스머글링(HTTP Request Smuggling, HRS)**이란,
**프론트엔드 서버(리버스 프록시, 로드 밸런서 등)**와 백엔드 서버(애플리케이션 서버)
HTTP 요청 해석 차이점을 악용하여 요청을 변조하거나 몰래 끼워 넣는 공격 기법을 의미합니다.

간단히 말하면,

"앞단 서버는 하나의 요청이라 생각했지만, 뒷단 서버는 두 개 이상의 요청으로 인식하여
공격자가 숨겨둔 악의적 요청이 몰래 처리되는 것"
이라고 할 수 있습니다.

어떻게 발생하는가?

HTTP 요청 본문의 길이를 명시하는 Content-Length 헤더와
요청을 여러 개로 구분하는 Transfer-Encoding: chunked 헤더의 해석 차이를 이용합니다.

  • 프론트 서버와 백엔드 서버가 서로 다르게 이 두 헤더를 해석하면,
  • 공격자가 숨긴 두 번째 요청이 정상 요청에 끼워 넣어져 처리될 수 있습니다.

예시 흐름

POST / HTTP/1.1
Host: example.com
Content-Length: 50
Transfer-Encoding: chunked

0

GET /admin HTTP/1.1
Host: example.com
 
  • 프론트 서버는 Content-Length를 기준으로 해석하여 요청 완료라 판단하지만,
  • 백엔드 서버는 Transfer-Encoding을 기준으로 해석하여 뒤의 숨은 GET 요청을 별개로 처리할 수 있습니다.

주요 공격 결과

공격 효과설명
요청 가로채기 다른 사용자의 요청을 탈취할 수 있습니다.
세션 하이재킹 세션 토큰 탈취 가능.
캐시 포이즈닝 잘못된 응답을 캐시하여 불특정 다수에게 악성 응답을 제공할 수 있습니다.
비인가 요청 전송 관리자 페이지 접근, CSRF 보조 공격 등.

방어 및 대응 방법

대응 방법세부 설명
단일 길이 기준 강제화 Content-Length 또는 Transfer-Encoding 중 하나만 허용.
HTTP 요청 일관성 검사 서버 간 동일한 해석 기준 유지 (엄격한 RFC 준수).
최신 웹서버/프록시 업데이트 nginx, Apache, HAProxy 등의 보안 패치 적용.
WAF 규칙 강화 WAF(Web Application Firewall)에서 의심 요청 차단.
input validation 강화 HTTP 요청 헤더와 바디를 철저히 검증.

덧붙여

HTTP Request Smuggling은 2005년에 처음 발견되었으나,
2020년대 이후 클라우드 환경, API Gateway, Reverse Proxy 사용 증가로 인해 다시 부각되었습니다.
특히 Android 앱에서도 백엔드와 통신할 때 리버스 프록시를 거치는 경우, 서버 측 대응이 매우 중요합니다.

 

추가로

Android App 관점에서 HTTP Request Smuggling 대응 가이드

1. 앱 내부 네트워크 통신 라이브러리 설정 강화

Android 앱은 보통 OkHttp, Retrofit, HttpURLConnection 등을 통하여 서버와 통신합니다.
이를 사용하는 경우, 기본 설정만으로는 일부 우회 시도가 가능할 수도 있으므로, 아래를 꼭 지켜야 합니다.

OkHttp / Retrofit 대응

  • HTTP/1.1 또는 HTTP/2 명시적 사용 (HTTP/0.9, HTTP/1.0은 지원 차단)
  • Transfer-Encoding: chunked 사용 최소화
  • Content-Length 헤더의 일관성 확보 (명시적 지정 권장)
val client = OkHttpClient.Builder()
    .protocols(listOf(Protocol.HTTP_1_1, Protocol.HTTP_2))
    .build()
  • Interceptor 추가로 비정상 요청 방어
class HeaderValidationInterceptor : Interceptor {
    override fun intercept(chain: Interceptor.Chain): Response {
        val request = chain.request()
        val headers = request.headers

        // 의심스러운 헤더 검증
        if (headers.names().any { it.equals("Transfer-Encoding", ignoreCase = true) }
            && headers.names().any { it.equals("Content-Length", ignoreCase = true) }) {
            throw IOException("Invalid HTTP headers detected: Smuggling risk.")
        }

        return chain.proceed(request)
    }
}

// 적용 예시
val safeClient = OkHttpClient.Builder()
    .addInterceptor(HeaderValidationInterceptor())
    .build()

 

2. 서버와 통신 시 HTTPS 강제 사용

  • 반드시 HTTPS 통신만 허용할 것.
  • 앱의 network_security_config.xml을 설정하여 **Cleartext Traffic(HTTP)**을 차단할 것.
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="false">
        <trust-anchors>
            <certificates src="system" />
        </trust-anchors>
    </base-config>
</network-security-config>
  • AndroidManifest.xml에도 반영
<application
    android:networkSecurityConfig="@xml/network_security_config"
    android:usesCleartextTraffic="false">
 

3. 서버 측 검증 동시 강화

비록 앱에서 요청을 조심하더라도,
**서버(백엔드)**가 최종적으로 요청을 검증하고 해석하므로 서버단에서도 반드시 다음을 해야 합니다 :

서버 측 조치설명
Proxy, LB 업데이트 nginx, HAProxy 등을 최신 버전으로 유지.
Content-Length/Transfer-Encoding 혼용 차단 둘 중 하나만 허용하거나, 둘 모두 존재할 경우 요청 거부.
Request size 제한 요청 본문 크기에 상한 설정 (예: 8KB 제한).
경계 테스트 수행 BurpSuite, OWASP ZAP 등으로 Smuggling 테스트.

4. 취약점 대응 주기적 점검

  • 앱과 서버 모두 대상으로 OWASP ASVS 4.0 기준을 활용하여 정기 점검을 수행할 것.
  • OWASP HTTP Request Smuggling Cheat Sheet를 참조하여 공격 패턴 업데이트 및 방어할 것.

HTTP Request Smuggling Cheat Sheet (OWASP)

맺음말

"애초에 요청이 올바르게 구성되도록 하고, 서버가 의심스러운 요청을 철벽같이 막아내는 것이
HTTP Request Smuggling을 완전히 차단하는 길"입니다.

 

Android 앱에서도 '안전한 요청 생성'은 매우 중요하니,
앱 단에서부터 안전한 통신을 기본으로 삼고, 서버와의 협력 체계를 단단히 다지는 것이 필수라 할수 있습니다.

728x90
반응형
728x90
반응형

jQuery 1.4에서 jQuery 3.5(또는 3.x 최신 버전)로 업그레이드하는 데 소요되는 시간은 웹 애플리케이션의 규모, jQuery 의존도, 사용자 정의 코드의 복잡도에 따라 달라집니다. 다음은 일반적인 상황에서의 추정과 주요 고려사항입니다.

예상 소요 시간

업무 범위작업 항목예상 소요 시간
사전 분석 및 계획 사용 중인 jQuery 기능 목록화, 호환성 확인 0.5 ~ 1일
라이브러리 교체 및 기본 테스트 jQuery 3.5로 교체, Migrate 플러그인 적용 0.5일
기능 점검 및 수정 비호환 API, deprecated 기능 수정 (예: .bind(), .size(), .live() 등) 1 ~ 3일
UI/UX 테스트 주요 브라우저 및 기기 호환성 점검 1 ~ 2일
최종 배포 및 리그레션 테스트 CI/CD 배포 및 회귀 테스트 0.5 ~ 1일

총 예상 기간: 약 3 ~ 7일 (기준: 중간 규모 단일 SPA 또는 jQuery 위주의 레거시 웹사이트 기준)


주요 고려사항

1. jQuery Migrate 플러그인 도입

  • jquery-migrate-3.4.1.js를 먼저 삽입하여 deprecated 기능을 경고로 확인
  • 콘솔 로그에서 호환성 경고를 통해 수정 대상 API 파악 가능

2. 대체 API 매핑

제거된 기능대체 방법
.size() .length
.bind() / .unbind() .on() / .off()
.live() .on() (동적 요소에 대한 이벤트 바인딩 시 주의)
.toggle() (2개 이상의 함수 인자) 커스텀 함수로 대체 필요

3. jQuery 플러그인 호환성

  • 사용하는 타사 플러그인이 jQuery 3.x와 호환되는지 확인
  • 오래된 플러그인은 최신 버전이나 다른 대안으로 교체 필요

  • 가능한 경우 jQuery 제거를 고려해도 좋습니다 (예: Vue, React, vanilla JS 대체).
  • 다수의 페이지에 공통으로 로딩되는 경우, 점진적 전환(모듈 단위)보다는 전면 교체가 효율적일 수 있습니다.
  • 레거시 시스템에서는 jQuery 1.x 코드 스타일이 많이 섞여 있어 예상보다 수정량이 많을 수 있습니다.
728x90
반응형
728x90
반응형

리눅스에서 지정한 날짜 이전에 변경된 파일을 찾으려면 find 명령어를 -newermt 옵션과 조합하여 사용할 수 있습니다.

예시: 2023년 12월 31일 이전에 변경된 파일 찾기

find /path/to/search -type f ! -newermt "2024-01-01"

이 명령어는 2024-01-01 보다 이전에 마지막으로 수정된 파일들을 찾습니다.
! -newermt는 지정한 날짜 이전이라는 의미입니다.

설명

  • /path/to/search: 검색할 디렉토리 (예: . 현재 디렉토리)
  • -type f: 파일만 찾음 (디렉토리는 제외)
  • -newermt "YYYY-MM-DD": 해당 날짜 이후 수정된 파일
  • ! -newermt "YYYY-MM-DD": 해당 날짜 이전 수정된 파일

예시 사용

# 현재 디렉토리에서 2024년 1월 1일 이전에 수정된 파일 찾기 
find . -type f ! -newermt "2024-01-01"​

날짜와 시간까지 지정하고 싶다면?

find . -type f ! -newermt "2024-01-01 15:00"​

 

필요하다면 특정 확장자나 이름 패턴도 추가할 수 있어요:

# .log 파일 중에서 2024년 1월 1일 이전에 수정된 것 
find . -type f -name "*.log" ! -newermt "2024-01-01"​
728x90
반응형
728x90
반응형

https://sunlo.quora.com/The-famous-Italian-diver-Enzo-Maiorca-was-diving-in-the-sea-near-Syracuse-and-talking-to-his-daughter-Rossana-who-wa?ch=17&oid=218259986&share=9a887a56&srid=MGMA&target_type=post

 

The famous Italian diver, Enzo Maiorca, was diving in the sea near Syracuse and talking to his daughter, Rossana, who was on the

The famous Italian diver, Enzo Maiorca, was diving in the sea near Syracuse and talking to his daughter, Rossana, who was on the boat. As he was getting ready to dive, he felt something gently tap his back. When he turned around, he saw it was a dolphin. A

sunlo.quora.com

 

 

The famous Italian diver, Enzo Maiorca, was diving in the sea near Syracuse and talking to his daughter, Rossana, who was on the boat. As he was getting ready to dive, he felt something gently tap his back. When he turned around, he saw it was a dolphin. At first, he thought the dolphin just wanted to play, but then he realized the dolphin was trying to tell him something.

 

이탈리아의 유명한 잠수부 엔초 마이오르카는 시라쿠사 근처 바다에서 잠수를 준비하며 딸 로사나와 배 위에서 이야기를 나누고 있었습니다. 그때, 누군가가 그의 등을 부드럽게 건드리는 느낌이 들었습니다. 돌아보니, 그것은 돌고래였습니다.

처음에 그는 돌고래가 장난을 치고 싶어 하는 줄 알았지만, 곧 돌고래가 무언가를 전하려고 한다는 것을 깨달았습니다.



The dolphin dived under the water, and Enzo followed it. About 12 meters deep, they found another dolphin trapped in an old fishing net. Enzo quickly asked his daughter to grab the diving knives. Together, they managed to cut the net and free the dolphin. After the dolphin was freed, it let out a sound that Enzo described as "almost human." Dolphins can only stay underwater for about 10 minutes before they drown.

 

돌고래는 바닷속으로 잠수했고, 엔초는 그 뒤를 따랐습니다. 수심 약 12미터쯤 되는 곳에서, 그들은 오래된 어망에 걸려 꼼짝 못 하는 또 다른 돌고래를 발견했습니다. 엔초는 딸에게 다이빙용 칼을 가져오라고 빠르게 요청했고, 둘은 함께 그물을 잘라 돌고래를 구출할 수 있었습니다. 돌고래가 풀려난 후, 그것은 마치 "사람처럼" 들리는 소리를 냈다고 엔초는 말했습니다. 돌고래는 약 10분 정도만 물속에 있을 수 있으며, 그 이상 머무르면 익사할 수 있습니다.


Once freed, the dolphin was helped to the surface by Enzo, Rossana, and the other dolphin. Then, something amazing happened. The dolphin they saved was pregnant! The male dolphin circled them, then swam up to Enzo, gently touched his cheek as if giving him a kiss, and swam away with the female.

 

구조된 돌고래는 엔초와 로사나, 그리고 그 돌고래의 동료로 보이는 다른 한 마리의 도움을 받아 수면 위로 올라왔습니다. 그리고 놀라운 일이 벌어졌습니다. 구출된 돌고래가 임신 중이었던 것입니다! 수컷 돌고래는 그들 주위를 한 바퀴 돌더니, 엔초에게 다가와 볼을 살며시 터치하며 마치 "키스"를 하는 듯한 행동을 보이고, 암컷과 함께 헤엄쳐 떠났습니다.

Enzo Maiorca ended the story by saying, "Until man learns to respect and communicate with the animal world, he will never truly understand his place on Earth."

 

엔초 마이오르카는 이 이야기를 다음과 같은 말로 마무리했습니다.
"인간이 동물 세계를 존중하고 소통하는 법을 배우기 전에는, 지구에서 자신의 진정한 자리를 결코 이해하지 못할 것이다."

728x90
반응형

+ Recent posts