송시의 적절한 정보공유

유닉스 / 리눅스 환경에서 계정의 비밀번호는 hash 로 암호화 된다. hash 로 저장된 값은 /etc/shadow 에 저장된다. 과거 리눅스 시스템은 md5 로 hash 된 값을 기본으로 사용하였는데, md5 자체의 취약성과 더 높은 보안성을 위해 sha512 를 기본으로 사요하고 있다. 같은 길이의 평문을 sha512, sha256, md5 로 암호화 한다면 길이가 다르다. [root@~]# echo 'passw0rd' | sha512sum b8290cb0fe43d4e274787e39af74df240c2cd180b9b6db04d2ccce13c200333d3504a79eeea3d21a1b850aba8bb03068c959eba5f227f97724c55d86debdab14 - [root@~]# echo ..

UNIX/LINUX 에서 root 권한을 갖고 있다는 의미는 그 시스템에서 할 수 있는 모든 것이 가능하다는 의미이기도 하다. 대부분 별로 관심없겠지만, 원격에서 여러 형태의 무차별대입 공격이 많이 있고, 그 중 비밀번호를 무차별로 대입하여 공격하는 형태의 자동화 공격이 시도 때도 없이 존재 한다. 보안측면에서 본다면 방화벽, SSL VPN 이나 NAT를 사용하는 것이 최고지만 모든 환경에서 SSL VPN 을 사용할 수 있는 것은 아니다.(도입 비용 및 유지보수 등이 이 최고의 것을 선택할 수 없는 이유일 수도) 어쨌든 저런 것이 없는 상태라고 가정하고 시스템에서만 할 수 있는 최고의 방법은 원격에 대한 접근을 적절하게 차단하는 것이 아닐까. 그중 가장 많이 사용하는 sshd 로만 본다면 /etc/ssh..

결국엔 머리가 나쁜 것에 대한 핑계지만 지난 번 RHCA를 따겠다는 마음을 돌린 이유를 조금 설명하고 싶다 그땐 나에게 매우 저렴하게 RHCA를 취득 할 수 있는 기회가 있었고 한창 ansible을 공부하며 공부 뿜이 뿜뿜 일고 있었다 그런데 그 기회가 결국 주어지진 않았고 회사를 옮기며 더더욱 그 기회와 멀어졌다. 게다가 막상 보니 RHCA가 있다고 내 가게에 특별히 영향을 주는 것 같지 않은 느낌도 들었다 결국 레드햇 뱃지를 받는다는 자기만족 이외에 그리 큰 장점을 찾기 어려워 보였다. 오픈스택 자격증으로 클라우드 자격증을 디미는 것 보다 aws,azure,gcp 를 디미는게 더 가치 있는 것 같고 openshift 자격증으로 콘테이너 자격증을 디미는 것 보다 CKA 자격증으로 디미는 것이 더 가게에..

그냥 누가 물어봐서 기록으로 남겨봄 find . -type f -mtime -1 2> /dev/null -exec scp {} root@192.168.128.52:/root \; 하루 동안 발생한 db data를 scp 를 통해 원격지로 보내는 방법 물론 authorized_keys 는 선행되어야함

gluster 를 처음 보았을때 GPFS(Spectrum scale) 이 생각나더라. 리눅스와 오픈소스의 힘을 입어 더 다양하게 사용될 수 있다는 부분에서 gluster 가 조금 더 유리한 면이 있는 것같다. 몇 가지 gluster 만의 장점을 살펴 본다면 메타데이터를 중앙에서 관리하지 않기에 병목이 발생하는 것을 효과적으로 줄일 수 있다. 스토리지의 스케일 업/아웃을 소프트웨어적으로 구성할 수 있기에 확장성이 좋고, POSIX 규격에 맞추어 호환성이 높다. infiniband 를 지원하기에 network 보다 더 빠른 속도를 제공받을 수 있다. cluster 의 개념이기에 고가용성이 있고, 데이터를 저장하는 알고리즘 방식에 따라 RAID1, RAID5,6 과같은 효과를 낼 수 있어 데이터를 보다 안전하..

사실 별로 그럴일은 없지만, 예전에 고객사의 리눅스가 해킹당한적이 있었다. 그걸 어떻게 알았냐하면, 뭔가 리눅스가 이상해서 재부팅을 수행했는데, GRUB 에서 부팅을 하지 못하는 것이였다. 부팅하지 못하는 리눅스에서 GRUB 를 복구하려던 내 노력에서 GRUB 상태가 매우 비정상이라는 것을 알게 되었고, 그것이 해킹과 관련되었던 것을 알게되었다. 어쨌든 사실 드문일이지만 GRUB 가 문제가 생기거나, MBR 영역이 손상되는 일이 종종 있다. MBR 의 어떤 영역까지가 (offset DEC 446) 손상되었느냐에 따라 복구 방법이 다소 다른데 MBR 의 모든 영역 (DEC 512)이 손상되었다는 가정하에 복구를 해보고자 한다. ** 이 복구 방법에는 치명적인 단점이 있는데 파티션의 크기를 이미 알고 있어야..

protective MBR 영역에 장애가 발생했다고 가정하자 # dd if=/dev/zero of=/dev/sda bs=512 count=1 # reboot 우선 부팅 영역을 찾지 못한다. CD 를 통해 rescue 부팅을 한다. 일반적인 rescue 와 다르게 any linux partitions 라는 내용이 확인이 된다. # chroot /mnt/sysimage 에서 실패한다. chroot: failed to run command '/bin/bash': No such file or directory # cat /proc/partitions 에서 sda 에 대한 파티션이 없는것이 확인된다. 8 0 20971520 sda gdisk 를 통해 GPT 정보를 다시 재작성 한다. protective MBR 영..

MBR과 GPT 는 잘 보여주는 구조와 차이는 아래 그림으로 대체 해보련다. GPT 의 Protective MBR 은 GPT 영역을 보호하기 위함으로 사용되는데 쉽게 말하면 MBR 영역을 읽고 처리하였던 툴이나 방식들이 GPT 영역인지 인식하지 못하고 다른 행동을 할까봐 형식적으로 남겨분 부분이다. 그래서 그런지 MBR 의 영역 512 bytes 에 가득했던 정보들이 GPT 에서는 데이터가 없다. MBR DOS partition table 의 시작은 DEC 446, HEX 1BE 에서 시작되는데 partition type 을 가르키는 offset 5byte (DEC 450, HEX 1C2) 위치에서는 'EE' 라는 형태를 갖는다. 'EE' 는 Indication that this legacy MBR is..

[root@trouble policy]# sestatus SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Max kernel policy version: 31 [root@trouble policy]# getenforce Enforcing [root@trouble policy]# setenforce 0 [root@trouble..

리눅스에서는 SELinux 라는 좀더 고오급진 보안 정책이 있다. 그런데 이것이 고오급지기도 하고 귀찮기도해서 그냥 스리슬적 넘기는게 일상 다반사다. 그런데 trouble shooting 에서 selinux에 대한 이해가 있어야지만 문제를 알아낼 수 있는 부분들이 있기에 SELinux 를 오늘 한번 짚고 넘어가 볼까한다. SELinux 를 쉽게 생각하면 ACL(접근제어) 로 괜찮을 것 같다. /etc/selinux/config 의 내용을 살펴 본다. # This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is..