sshfail2banFedora 23 Server 버전을 설치했고, , 사용자 설정 외에 samba관리적인 작업은 거의 하지 않았습니다.
어느 날 시스템이 완전히 잠겨 있었는데 ssh_exchange_identification: read: Connection reset by peer인터넷 검색을 하다가 메시지를 발견했습니다.ssh_exchange_identification: 읽기: 피어에 의한 연결 재설정
그래서 나는 fail2ban금지와 관련이 있다고 가정하고 있습니다. 큰 문제는 아닙니다. 그냥 "물리적으로" 머신에 로그인하고 재설정하면 됩니다. 이것을 시도한 후에 내 콘솔이물에 잠기다로그 메시지가 포함됩니다("systemd.service 뭔가 읽기만 가능함"이라는 기억이 나지 않음). 이 홍수로 인해 로그인이 불가능해졌습니다. 자격 증명을 입력하기 시작하면 로그 메시지가 인쇄되고 자격 증명이 재설정되면서 손상됩니다.
강제로 재부팅을 해야 했습니다. 재설정 버튼을 누르거나 기기의 전원 버튼을 길게 누르세요.
문제의 근본 원인을 파악하고 무엇이 잘못되었는지 파악하고 싶었을 때 로그 파기를 했습니다. 하지만 이유를 찾을 수 없는 것 같습니다.
이렇게 하면 journalctl --since 2016-04-10다음과 같은 결과를 얻습니다.
Apr 10 12:19:32 Server smartd[620]: Device: /dev/sdc [SAT], 47 Currently unreadable (pending) sectors
-- Reboot --
Apr 11 20:27:53 Server systemd-journal[148]: Runtime journal is using 8.0M (max allowed 81.0M, trying to leave 121.5M free of 802.5M available → current limit 81.0M).
문제가 시작되었다고 가정하고 하드 재부팅을 수행할 때까지 모든 로그를 삭제했습니다. ( /dev/sdc드라이브를 받은 이후로 드라이브에서 이 오류가 발생했습니다.)
나도 계속해서 읽고 있다https://freedesktop.org/wiki/Software/systemd/Debugging//var/log/messages로그를 확인해야 합니다 .
내가 볼 수있는 관련 부분은
Mar 6 18:52:49 Server audit: USER_AUTH pid=3435 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=? acct="root" exe="/usr/sbin/sshd" hostname=183.3.202.108 addr=183.3.202.108 terminal=ssh res=failed'
Apr 11 20:28:46 Server rsyslogd-2177: imjournal: begin to drop messages due to rate-limiting
Apr 11 20:39:15 Server rsyslogd-2177: imjournal: 91404 messages lost due to rate-limiting
Apr 11 20:39:15 Server dnf: repo: using cache for: rpmfusion-free
이는 91404개의 로그 메시지가 있음을 알려줍니다. 그러나 나는 그들 중 어느 것도 찾을 수 없었습니다.모두내가 아는 한, 그것은 버려졌다.
내 시스템이 정확히 "파손"된 것이 무엇인지 알고 싶으면 로그를 저장할 수 있는 다른 곳에 있나요? 아니면 같은 문제가 다시 발생하지 않도록 별에게 기도해야 합니까?
답변1
참고: 내 의심을 확인할 추가 증거는 없습니다. 이는 단지 가설적인 추측일 뿐입니다.
"읽기 전용"에 대한 내용이 있다고 언급하셨습니다. 시스템이 디스크(또는 케이블이나 SATA 인터페이스 등)에서 복구할 수 없는 손상이나 하드웨어 오류를 경험했을 수 있으며 추가 손상/손상을 방지하기 위해 루트 파일 시스템을 읽기 전용으로 다시 마운트하십시오.
가능한 한 빨리 수행해야 하는 가장 중요한 일은 1. 백업이 최신인지 확인합니다. 2. 디스크를 철저히 테스트합니다(예: 테스트 통과 smartctl). 그렇지 않으면 실패할 수 있습니다.
그러나 로깅 문제로 돌아가서:
루트 파일 시스템(또는 /var/log)이 읽기 전용이면 디스크에 로그가 기록되지 않습니다.
로그 메시지를 전달할 수 있는 다른 시스템이 있는 경우 로컬 파일과 원격 시스템 모두에 로그하도록 rsyslog를 구성하는 것이 좋습니다. 이 시스템은 원격 시스템에도 동일한 서비스를 제공할 수 있습니다.
ganesh예를 들어 내 시스템( 및 ) 모두에 kali다음이 있습니다 /etc/rsyslog.d/00remote.conf.
$ModLoad imudp # provides UDP syslog reception
$UDPServerAddress 0.0.0.0
$UDPServerRun 514
if $fromhost-ip == '127.0.0.1' and $syslogfacility-text == 'kern' then @kali
위의 파일입니다 ganesh. on 으로 대체된 kali것을 @kali제외하면 동일합니다 @ganesh.
그러면 kern로컬 호스트에서 발생한 모든 시설 로그 항목이 원격 로깅 호스트로 전달됩니다. IP 주소 확인은 원격 로깅 루프 충돌을 방지합니다.
대신 기반 로깅을 rsyslog포함하여 원격 로깅을 구성하는 데 사용할 수 있는 다른 방법이 있습니다 . 이것은 몇 년 전에 필요할 때 시도한 첫 번째 방법일 뿐입니다. 작동하고 간단하며 변경할 필요가 없었습니다. 아직은요. tcpudp이 사이트 검색다른 방법과 자세한 내용을 알아보세요.
그런데, 방화벽이 UDP 포트 514로 들어오는 트래픽을 차단하는지 확인하세요.