主页 / user-250204

anx's questions

Martin Hope
anx
Asked: 2019-02-09 19:52:53 +0800 CST
  • 6

我需要覆盖systemd模板的ExecStart参数。我已确认单元文件存在并通过验证。添加unique-name@.service.d/override.conf文件在某些​​机器上效果很好：

user@prod-west-1604$ systemctl --version | head -1
systemd 229
user@prod-west-1604$ file -b /etc/systemd/system/unique-name@.service
symbolic link to /lib/systemd/system/nginx.service

user@prod-west-1604$ sudo systemctl edit unique-name@.service
# (opens editor as expected)

但是，在运行较新 systemd 版本的机器上，操作会失败：

user@prod-east-1810$ systemctl --version | head -1
systemd 239
user@prod-east-1810$ file -b /etc/systemd/system/unique-name@.service
symbolic link to /lib/systemd/system/nginx.service

user@prod-east-1810$ sudo systemctl edit unique-name@.service
Failed to get the load state of unique-name@.service: Unit name unique-name@.service is neither a valid invocation ID nor unit name.

为什么？

systemd
Martin Hope
anx
Asked: 2017-01-02 08:10:07 +0800 CST
  • 1

我的（linux）服务器有一些相当简单的 iptables 规则。

iptables -A INPUT -p icmp -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -m tcp -p tcp --dport ssh -j ACCEPT
iptables -A INPUT -m tcp -p tcp --dport https -j ACCEPT
iptables -A INPUT -j LOG
iptables -A INPUT -j NFLOG
iptables -A INPUT -j DROP

ICMP 未过滤，但不允许其他不必要的连接。NFLOG 规则只是将数据包存储到数据包捕获文件 (pcap) 中。因为系统日志非常垃圾，我查看了数据包的详细信息。

tshark -V -a filesize:1 -r /scooby/doo.pcap（IP 和端口[replaced]）

Frame 1: 52 bytes on wire (416 bits), 52 bytes captured (416 bits)
    Encapsulation type: Raw IP (7)
    [Protocols in frame: raw:ip:gre:ip:udp:data]
Internet Protocol Version 4, Src: [incoming IP] ([incoming IP]), Dst: [my server IP] ([my server IP])
    Version: 4
    Header length: 20 bytes
    Total Length: 52
    Identification: 0x0000 (0)
    Flags: 0x02 (Don't Fragment)
    Time to live: 52
    Protocol: GRE (47)
Generic Routing Encapsulation (IP)
    Flags and Version: 0x0000
    Protocol Type: IP (0x0800)
Internet Protocol Version 4, Src: [not my IP1] ([not my IP1]), Dst: [not my IP2] ([not my IP2])
    Version: 4
    Header length: 20 bytes
    Total Length: 28
    Time to live: 64
    Protocol: UDP (17)
User Datagram Protocol, Src Port: [random port1] ([random port1]), Dst Port: [random port2] ([random port2])
    Length: 8

主动提供的数据包主要是 ip:gre:ip:udp 数据包。GRE 数据包的数量（通常每分钟多个）大大超过了其他未经请求的数据包（漏洞扫描器/垃圾邮件发送者/端口扫描器）。GRE 封装内的所有 IP 对我来说都没有任何特殊意义，只是属于（专门）美国公司的各种常规 IP（因此，不是完全随机的地址）。

为什么有人会发送那些 GRE 数据包？

是否存在与 GRE 数据包相关的已知 DoS 漏洞？这是试图欺骗配置错误的路由器/服务器将封装的数据包转发到它们明显的目的地吗？发件人是否尝试收集有关我可能已设置的潜在 GRE 隧道性质的信息？

奖励：最合理的反应真的是“-j DROP”吗？

iptables gre
Martin Hope
anx
Asked: 2015-08-10 10:49:54 +0800 CST
  • 1

我维护的一个网站由多个本地应用程序组成，所有应用程序都由同一个nginx实例代理。每个应用程序都在其自己的用户下运行，并公开一个可由 web 服务器组写入的unix 套接字www-data。

所有应用程序用户都是该www-data组的一部分，因此他们可以chown他们的套接字。如何改进我的设置，以便不再使用一个应用程序中的漏洞通过直接连接到其他套接字来尝试进一步提升权限？

我以前的解决方案：为每个用户创建一个新组并将 Web 服务器添加到所有这些用户。此解决方案不太可取，因为它使添加/删除应用程序变得复杂，并且需要硬重启 Web 服务器来更新组。

nginx
Martin Hope
anx
Asked: 2014-10-22 11:51:44 +0800 CST
  • 2

一个 postfix 实例通过 LANsub.example.com推送邮件example.com，它既是邮件服务器又是路由器：

Internet
|
|
203.0.113.1 
<example.com> (127.0.1.1 in /etc/hosts)
192.168.1.1
|
|
192.168.1.99
<sub.example.com>

每次收到 LAN 邮件时，都会记录一条警告消息：

postfix/smtpd[1337]：警告：主机名 example.com 无法解析为地址 203.0.113.1

但是，域确实解析到地址，只有一条 A 记录（但没有 rdns）：

# dig example.com
example.com.          3600   IN   A    203.0.113.1
# dig -x 203.0.113.1
..                       1   IN   PTR  new-customer.isp.example

虽然反向 DNS 不正确，但这不是警告所说的，也没有解释为什么它只由 LAN 邮件触发。正如通过 tcpdump 确认的那样，LAN 邮件服务器EHLO带有sub.example.com- 后缀服务器称为 192.168.1.99。

是什么触发了警告？

domain-name-system