작은 행복을 위한 시

Hello Everyone,

I searched through my entire quarantine folder and grep'd for files named in this format msg-12341-1.txt. 
I scanned them with file and file -i. The following are the results.
I entered them into my filetype.conf.rules and it seems to work.

allow   ASCII English text, with escape sequences       text/plain; charset=us-ascii    -       -
allow   ASCII text      text/plain; charset=us-ascii    -       -
allow   DOS executable  text/plain; charset=iso-8859-1  -       -
allow   DOS executable  text/plain; charset=unknown     -       -
allow   DOS executable  text/plain; charset=utf-8       -       -
allow   DOS executable  text/x-mail; charset=unknown    -       -
allow   DOS executable  text/x-mail; charset=utf-8      -       -
allow   HTML document text      text/html       -       -
allow   UTF-8 Unicode English text      text/plain; charset=utf-8       -       -

I tested that I'm not inadvertently letting DOS executables through, and it they remain blocked. 
It appears that when both 2/5 and 3/5 are true, they are a match and thus allowed through. 
If someone could verify that would be nice.

In the time when I didn't have a solution, 
I changed the /usr/bin/file to /usr/bin/file -i just to alleviate the problem. 
But I think this one solves it, but I don't know whether this is the right way to do it.

I have prepended to my filetype.rules.conf.

p

http://lists.mailscanner.info/pipermail/mailscanner/2010-July/096257.html

모델: HP DL360

갑자기 서버에서 팬소음이 크게 나서 확인해 보니 
LED 알람에서 내부 오류를 알리는 LED가 빨간색으로 깜빡이고 있었다.
서버에 로그인하여 확인해 보니 특별한 메세지는 없었고

[root@xxx log]# tail -f /var/log/messages
Dec 30 19:34:37 xxx kernel: sd 0:0:0:0: [sda] CDB: Write(10): 2a 00 10 da 8d f0 00 00 08 00
Dec 30 19:34:37 xxx kernel: end_request: I/O error, dev sda, sector 282758640
Dec 30 19:34:37 xxx kernel: sd 0:0:0:0: rejecting I/O to offline device
Dec 30 19:34:37 xxx kernel: sd 0:0:0:0: [sda] killing request
Dec 30 19:34:37 xxx kernel: sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
Dec 30 19:34:37 xxx kernel: sd 0:0:0:0: [sda] CDB: Write(10): 2a 00 14 1a de c0 00 00 08 00
Dec 30 19:34:37 xxx kernel: end_request: I/O error, dev sda, sector 337305280
Dec 30 19:34:37 xxx kernel: Buffer I/O error on device dm-0, logical block 41983448
Dec 30 19:34:37 xxx kernel: lost page write due to I/O error on dm-0
Dec 30 19:34:37 xxx kernel: sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK

와 같이 디스크 관련 오류가 확인되었다.
해당 메세지 이후 모든 로그 기록 작동은 멈추었다.
하지만 웹서비스나 DB서비스는 문제가 없었다.

서버를 재부팅 하려고 했으나

[root@xxx log]# reboot
Bus error (core dumped)

재부팅이 되지 않았다.

아래와 같은 방법으로 재부팅할 수 있었다.

[root@xxx log]# reboot –fn

서버를 재부팅할 때 확인해 보니 BIOS 정보에서 RAID 컨트롤러에 문제가 있었음을 확인할 수 있었다.

재부팅 후 서버 동작에는 문제가 없었다.

이러한 증상이 나타난 이유는 다음과 같다.

RAID 컨트롤러 오류 또는 하드 디스크 오류로 인해 디스크 하위 시스템을 사용할 수 없는 경우 이러한 종류의 문제가 발생할 수 있다. 메모리/디스크 캐시에 있는 바이너리 및 라이브러리는 계속 실행할 수 있지만 다른 바이너리는 IO 오류 또는 기타 치명적인 오류로 실패한다. 
만약 reboot 바이너리가 여전히 실행 가능하다면 
reboot -fn
이 시스템의 즉각적인 재부팅을 강제 할 것이다.
하드웨어가 여전히 작동하는 경우 약 5-10분 후에 다시 켜져야 한다.
그렇지 않으면 누군가 물리적으로 하드웨어를 껐다 켜야 한다.

참고사이트 : https://serverfault.com/questions/57920/bus-error-when-trying-to-reboot-linux/57928

#linux #buserror #raidcontroller #HP #H240ar #버스에러 #레이드컨트롤러

리눅스 소프트웨어 레이드 디스크 교체 (mdadm: software raid)

1. 제거
mdadm --manage /dev/md0 --fail /dev/sdb1
mdadm --namage /dev/md0 --remove /dev/sdb1
   (결과출력=>mdadm: hot remove /dev/sdb1)

2. 종료 후 재부팅
shutdown -h now

3. 디스크 복사
sfdisk -d /dev/sda | sfdisk /dev/sdb

fdisk -l
로 파티션 확인

4. 추가
mdadm --manage /dev/md0 --add /dev/sdb1
   (결과출력=> mdadm: re-added /dev/sdb1)

5. 디스크 동기화 확인
cat /proc/mdstat

#mdadm #소프트레이드디스크교체

Qnap Nas 디스크 검사 (콘솔/ssh)

/etc/init.d/services.sh stop
/etc/init.d/opentftp.sh stop
/etc/init.d/Qthttpd.sh stop
/etc/init.d/rsnap.sh stop

umount /dev/md0

e2fsck -f -v -C 0 /dev/md0

#qnap #Nas #Raid #디스크검사

/AnhLab/ Log4j (로그4j) 취약점, 이렇게 대응하세요! 

4. 취약점 대응 방안

로그4j 취약점을 악용한 위협들에 노출되지 않기 위해 보안 업데이트를 적용해야 한다. 로그4j 취약점은 크게 두 가지 방법으로 대응할 수 있다.

1) 2021년 12월 14일 업데이트를 통해 다음과 같이 취약점 패치

  ■ Log4j 2.16.0 이상 최신버전으로 업데이트 (Java8 이상) : https://logging.apache.org/log4j/2.x/download.html

  ■​ Log4j 2.12.2 버전 (Java 7) : 제공 예정​

2) Log4j 패치가 어려운 경우 취약점 완화 적용 (ATIP 보안권고문 참조)

​  ■ ​​버전 : Log4j 2.0-beta9 이상 2.15.0 이하 버전 (Log4j 2.12.2 버전 제외)

  JndiLookup 클래스를 다음과 같이 제거

  # zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

​  ■ ​​버전 : Log4j 1.x 버전

  Log4j 1.x에서 JMSAppender 사용 여부 확인 후 해당 기능을 중지​

https://www.ahnlab.com/kr/site/securityinfo/secunews/secuNewsView.do?seq=31086&utm_source=CM&utm_medium=eDM&utm_campaign=SL%5FtypeF&utm_content=899 

#Log4j #로그4j #취약점

아웃룩 OutLook 메일 검색 오류
이미지 출처 : https://alpa-manbo.tistory.com/13

아웃룩 2010 이상 버전에서 검색/찾기가 제대로 작동하지 않는 오류가 계속 있어왔다.
어제 2019 버전을 사용하는 분이 또 문의가 와서 다시 확인해 보았다.

해결 방법을 찾았다.
윈도우10 색인옵션 -> 수정 -> Microsoft Outlook 체크 해제 -> 재부팅

적용하신 분의 확인 결과 검색이 잘 된다고 한다.

참고사이트 - https://alpa-manbo.tistory.com/13

알파만보의 행복한 일상

#아웃룩 #아웃룩검색오류