今天意外發現自己 1GB 內存的 Rocky Linux 9.2 機子三台全部 OOM 並需要強制重啟…經過監控之後發現 dnf-makecache 在主機死亡前出現在了 htop,馬上鎖定原因並禁用。準備 ASAP 更換成 Debian。
Dnf-makecache.timer is a major liability
https://forums.rockylinux.org/t/dnf-makecache-timer-is-a-major-liability/15371
白翼的服務器運維博客
今天意外發現自己 1GB 內存的 Rocky Linux 9.2 機子三台全部 OOM 並需要強制重啟…經過監控之後發現 dnf-makecache 在主機死亡前出現在了 htop,馬上鎖定原因並禁用。準備 ASAP 更換成 Debian。
Dnf-makecache.timer is a major liability
https://forums.rockylinux.org/t/dnf-makecache-timer-is-a-major-liability/15371
~# dig @119.29.29.29 www.dnssec-failed.org. A
; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> @119.29.29.29 www.dnssec-failed.org. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10361
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 400176fcef655802 (echoed)
;; QUESTION SECTION:
;www.dnssec-failed.org. IN A
;; ANSWER SECTION:
www.dnssec-failed.org. 3600 IN A 68.87.109.242
www.dnssec-failed.org. 3600 IN A 69.252.193.191
~# dig @8.8.8.8 www.dnssec-failed.org. A
; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> @8.8.8.8 www.dnssec-failed.org. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 16567
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; EDE: 9 (DNSKEY Missing): (No DNSKEY matches DS RRs of dnssec-failed.org)
;; QUESTION SECTION:
;www.dnssec-failed.org. IN A
説明:如果 www.dnssec-failed.org 能夠返回 A 記錄,則代表遞歸 DNS 沒有對 DNSSEC 簽名進行檢驗。
其他還測試了 114.114.114.114,以及 223.5.5.5,均不支持 DNSSEC 校驗。雖然 DNSPod 支持了 DNSSEC 功能,但在國内依然是沒有什麽用處。
Email spoofers are trying to up their game. By spending efforts to set up a domain for header_from
SPF spoofing.
The technique involves configuring a valid SPF record for the envelope_from
domain while using a spoofed domain in the header_from
field, hoping that the email server does not perform thorough checks. So far domains like club-sphere-web.com
, ar-realestate.com
, chainyuu.com
are observed for such activities.
To protect your domains, make sure to deploy strong DMARC policies (p=reject). SPF record alone is not designed to check SPF alignments between header_from
and envelope_from
.
Check your email: https://checkcybersecurity.service.ncsc.gov.uk/email-security-check/form
And possibly the best article to educate yourself on SPF, DKIM, DMARC – https://simonandrews.ca/articles/how-to-set-up-spf-dkim-dmarc (The only thing I disagree would be the use of -all instead of ~all, see Mailhardener’s reasoning on this – https://www.mailhardener.com/kb/spf#fail-vs-soft-fail)
<record>
<row>
<source_ip>156.242.10.176</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>reject</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
<reason>
<type/>
<comment/>
</reason>
</policy_evaluated>
</row>
<identifiers>
<envelope_to>ezweb.ne.jp</envelope_to>
<envelope_from>chainyuu.com</envelope_from>
<header_from>[domains they do not control]</header_from>
</identifiers>
<auth_results>
<dkim>
<domain/>
<selector/>
<result>none</result>
<human_result>no signature data</human_result>
</dkim>
<spf>
<domain>chainyuu.com</domain>
<scope>mfrom</scope>
<result>pass</result>
</spf>
</auth_results>
</record>
I alwasys had fail2ban rules configured on my host server, came across this service today which provides bad acting IPs caught by honeypots and can be fed into fail2ban directly. This is some great stuff.
https://apiban.org/2024.html