iBug's questions

I see that almost all registered domains have at least two authoritative name servers configured (and for most of them, exactly two), and that using two servers provides redundancy against any kind of server failure. Technically there's no restriction on number of auth NS servers, so a single NS also works.

However, for some zones, there are already multiple addresses for one server configured, like ns1.qq.com (4 IPv4 addresses, auth NS for qq.com.). And for some other zones, the name servers are distributed using techniques like anycast, like ns3.cloudflare.com (one anycast IPv4 and one anycast IPv6).

In those cases, why would one still configure multiple authoritative name servers for a zone, when one NS entry can already provide redundancy against physical server failure?

I have a server A running as gateway for some intranet connected on eth0. A is connected to multiple "relay nodes" like B, C, D... via WireGuard.

Assume here's the IP setup:

A routes some traffic through WG. Here's a part of A's routing table:

...
172.16.0.0/16 via 10.0.0.2 dev wg0
172.17.0.0/16 via 10.0.0.3 dev wg0
...

I would like to allow all traffic routed through B (10.0.0.2), while blocking traffic routed through C. With pseudo-code, this is what I'm thinking:

-A FORWARD -o wg0 --via 10.0.0.2 -j ACCEPT
-A FORWARD -o wg0 --via 10.0.0.3 -j DROP
#                 ^^^^^^^^^^^^^^

There are a lot of items in the routing table that I don't want to repeat in iptables rules. Another problem is there's no MAC (or L2 in general) inside WG.

Is there any way to make this work?

I want to filter traffic coming into my Linux box so ports appears like closed instead of "filtered".

Using iptables, except for ports I intended to open (-j ACCEPT), I have done the following on INPUT traffic (IPv4):

• For established or related connections (using -m conntrack), ignore and accept
• For TCP, -j REJECT --reject-with tcp-reset, which should send a TCP RST packet back
• For UDP, reject with icmp-port-unreachable
• For ICMP, accept echo request (so it can be pinged), and respond with icmp-proto-unreachable
• For everything else (protocols except 1, 6 and 17), respond with icmp-proto-unreachable

For IPv6, everythinge except TCP is rejected with icmp6-port-unreachable. I haven't filtered any OUTPUT traffic.

Should I take any extra actions or is the setup comprehensive enough?

We have a cluster of Proxmox VE servers with shared SAN storage. The storage server provides a big LUN through iSCSI. We use iscsiadm on the PVE hosts to load the storage. Per our workload, we setup one VG backed by one PV on the SAN. For some reasons the iSCSI disk doesn't load properly on startup (/dev/sdb not showing up), and we had to iscsiadm --login manually. The problem is, all LVs on the VG on that disk load as "active", with lvs showing -wi-a----- as flags. This is undesirable for a cluster setup, as Proxmox expect volumes associated with powered-off VMs and CTs be "freed" (i.e. lvchange -an). I have to manually run vgchange -an every time the iSCSI drive is mounted.

Is there a way to stop LVM from activating all logical volumes upon attachment of a new VG (or this particular VG, or the iSCSI disk)? I need the solution on Debian.

I want to replace iptables(8) with IPVS for a TCP reverse proxy which involved dual-way NAT.

My current setup using iptables is functionally equivalent to a userspace forwarder (like socat(1)). It has the following setup:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8000 -j DNAT --to-destination 172.31.1.1:80
# iptables -P FORWARD ACCEPT
iptables -t nat -A POSTROUTING -o eth1 -d 172.31.1.1 -p tcp --dport 80 -j MASQUERADE

The machine has 10.0.0.2 on eth0 and 172.31.0.2 on eth1. It also has the following routes:

default via 10.0.0.1 dev eth0
172.31.0.0/24 dev eth1
172.31.1.0/24 via 172.31.0.1 dev eth1

I say this is "functionally equivalent" to a userspace proxy because all traffic coming to TCP address 10.0.0.2:8000 is forwarded to the intranet host 172.31.1.1, while on the target host the traffic appears to come from 172.31.0.2 instead of the real host. Neither side sees the actual address of the opposite, only this reverse proxy server.

I'm trying to learn IPVS by replacing this iptables-based setup with Linux Virtual Server. I started with this:

ipvsadm -A -t 10.0.0.2:8000
ipvsadm -a -t 10.0.0.2:8000 -r 172.31.1.1:80 -m

The critical point is, it's frequent that neither the source host nor the target host is reachable on the same link as one of the interfaces. Traffic may need to be sent to a gateway on both sides.

I couldn't figure out why curl http://10.0.0.2:8000/ on this host gives the expected result, while the same command doesn't even establish a TCP connection when run on a host outside of the network (10.0.0.2 / eth0 is public-facing).

Using tcpdump, I can see a SYN packet to the backend, a SYNACK packet returned, but no ACK afterwards (the 3rd step of TCP 3-way handshake).

I know that a VPN or just tunneling can solve this problem, but I want to do this without either of them.

In case it's relevant, this reverse proxy is running CentOS 7.7 with both SELinux and firewalld disabled.

I am running radvd (2.17-2, Debian Buster) on a local network to provide IPv6 access. I would like to make radvd advertise the static IP of the interface (e.g. 2001::1/64) as the gateway IP instead of the link-local address (like fe80::something/64). I have tried AdvRASrcAddress but it seems to be only effective for LL addresses so I can't specify 2001::1/64 there.

How to make radvd advertise the static IP as gateway instead of the LL address?

If radvd isn't up to this task, I'm open to other solutions.

I found the following lines in a firewall script on one of our Linux servers (kernel 5.x)

ip6tables -A INPUT -p icmp -j ACCEPT
ip6tables -A INPUT -p ipv6-icmp -j ACCEPT

The two commands both run without error, but I'm confused about it. I can only figure out that ipv6-icmp is a synonym for icmpv6, but what is icmp in the context of IPv6 iptables (or ip6tables(8))?

Our server cluster has remote root access enabled for rescue purposes, and we generally set PermitRootLogin prohibit-password in /etc/ssh/sshd_config because LDAP users can still login using password.

Recently we added an extra server with very strict access control, and we have PasswordAuthentication set to no so only specific users with SSH keys can login. However, a default setting of PermitRootLogin yes remained for some time unnoticed. (It wasn't a real issue since we also have the password of the root user deleted so no one could log in unless directly at the KVM console.)

My question is, with PasswordAuthentication no set, does PermitRootLogin yes behave identically to prohibit-password?

I'm seeing walls of logs like this in /var/log/auth.log. Every 2 minutes ten lines of the same message appears. I would like to know the remote IP that generated these messages.

I'm running on Ubuntu 19.10 (it's my remote workstation, just doing regular security checkups)

61094 Jan 25 22:44:01 localhost sshd[10390]: error: kex_exchange_identification: Connection closed by remote host
61095 Jan 25 22:44:02 localhost sshd[10408]: error: kex_exchange_identification: Connection closed by remote host
61096 Jan 25 22:44:02 localhost sshd[10433]: error: kex_exchange_identification: Connection closed by remote host
61097 Jan 25 22:44:02 localhost sshd[10437]: error: kex_exchange_identification: Connection closed by remote host
61098 Jan 25 22:44:02 localhost sshd[10441]: error: kex_exchange_identification: Connection closed by remote host
61099 Jan 25 22:44:02 localhost sshd[10446]: error: kex_exchange_identification: Connection closed by remote host
61100 Jan 25 22:44:02 localhost sshd[10450]: error: kex_exchange_identification: Connection closed by remote host
61101 Jan 25 22:44:02 localhost sshd[10454]: error: kex_exchange_identification: Connection closed by remote host
61102 Jan 25 22:44:02 localhost sshd[10462]: error: kex_exchange_identification: Connection closed by remote host
61103 Jan 25 22:44:02 localhost sshd[10466]: error: kex_exchange_identification: Connection closed by remote host
61104 Jan 25 22:46:01 localhost sshd[12501]: error: kex_exchange_identification: Connection closed by remote host
61105 Jan 25 22:46:01 localhost sshd[12528]: error: kex_exchange_identification: Connection closed by remote host
61106 Jan 25 22:46:01 localhost sshd[12538]: error: kex_exchange_identification: Connection closed by remote host
61107 Jan 25 22:46:01 localhost sshd[12542]: error: kex_exchange_identification: Connection closed by remote host
61108 Jan 25 22:46:01 localhost sshd[12546]: error: kex_exchange_identification: Connection closed by remote host
61109 Jan 25 22:46:01 localhost sshd[12551]: error: kex_exchange_identification: Connection closed by remote host
61110 Jan 25 22:46:01 localhost sshd[12555]: error: kex_exchange_identification: Connection closed by remote host
61111 Jan 25 22:46:01 localhost sshd[12560]: error: kex_exchange_identification: Connection closed by remote host
61112 Jan 25 22:46:01 localhost sshd[12564]: error: kex_exchange_identification: Connection closed by remote host
61113 Jan 25 22:46:01 localhost sshd[12568]: error: kex_exchange_identification: Connection closed by remote host
61114 Jan 25 22:48:01 localhost sshd[14371]: error: kex_exchange_identification: Connection closed by remote host
61115 Jan 25 22:48:01 localhost sshd[14390]: error: kex_exchange_identification: Connection closed by remote host
61116 Jan 25 22:48:01 localhost sshd[14414]: error: kex_exchange_identification: Connection closed by remote host
61117 Jan 25 22:48:01 localhost sshd[14418]: error: kex_exchange_identification: Connection closed by remote host
61118 Jan 25 22:48:01 localhost sshd[14422]: error: kex_exchange_identification: Connection closed by remote host
61119 Jan 25 22:48:01 localhost sshd[14427]: error: kex_exchange_identification: Connection closed by remote host
61120 Jan 25 22:48:01 localhost sshd[14431]: error: kex_exchange_identification: Connection closed by remote host
61121 Jan 25 22:48:01 localhost sshd[14435]: error: kex_exchange_identification: Connection closed by remote host
61122 Jan 25 22:48:01 localhost sshd[14439]: error: kex_exchange_identification: Connection closed by remote host
61123 Jan 25 22:48:01 localhost sshd[14443]: error: kex_exchange_identification: Connection closed by remote host
61124 Jan 25 22:50:01 localhost sshd[16489]: error: kex_exchange_identification: Connection closed by remote host
61125 Jan 25 22:50:01 localhost sshd[16512]: error: kex_exchange_identification: Connection closed by remote host
61126 Jan 25 22:50:01 localhost sshd[16530]: error: kex_exchange_identification: Connection closed by remote host
61127 Jan 25 22:50:01 localhost sshd[16535]: error: kex_exchange_identification: Connection closed by remote host
61128 Jan 25 22:50:01 localhost sshd[16539]: error: kex_exchange_identification: Connection closed by remote host
61129 Jan 25 22:50:01 localhost sshd[16544]: error: kex_exchange_identification: Connection closed by remote host
61130 Jan 25 22:50:01 localhost sshd[16548]: error: kex_exchange_identification: Connection closed by remote host
61131 Jan 25 22:50:01 localhost sshd[16552]: error: kex_exchange_identification: Connection closed by remote host
61132 Jan 25 22:50:01 localhost sshd[16556]: error: kex_exchange_identification: Connection closed by remote host
61133 Jan 25 22:50:01 localhost sshd[16561]: error: kex_exchange_identification: Connection closed by remote host
61134 Jan 25 22:52:01 localhost sshd[18480]: error: kex_exchange_identification: Connection closed by remote host
61135 Jan 25 22:52:01 localhost sshd[18491]: error: kex_exchange_identification: Connection closed by remote host
61136 Jan 25 22:52:01 localhost sshd[18518]: error: kex_exchange_identification: Connection closed by remote host
61137 Jan 25 22:52:01 localhost sshd[18523]: error: kex_exchange_identification: Connection closed by remote host
61138 Jan 25 22:52:01 localhost sshd[18527]: error: kex_exchange_identification: Connection closed by remote host
61139 Jan 25 22:52:01 localhost sshd[18532]: error: kex_exchange_identification: Connection closed by remote host
61140 Jan 25 22:52:01 localhost sshd[18536]: error: kex_exchange_identification: Connection closed by remote host
auth.log-20200126-1579968001                                                                   61140,1        99%

One of our Git servers recently went down and we have no way to get it back up soon, so we've redirected the DNS to a dummy (placeholder) host, which when accessed via HTTP / HTTPS, sends users to our notice board with 302. I want to configure this server so any user with or without an SSH key can log in to the git user, with commands limited to a preset one that writes a message (e.g. command="echo 'a message here'",restrict).

I haven't figured out how to allow arbitrary login. (Restricting commands is easy) Any ideas? (OpenSSH 7.9p1, Debian Buster)

I have a desktop computer (Ubuntu 19.10) running containers and VMs. Its ethernet enp2s0 is bridged with systemd-networkd:

[Match]
Name=enp2s0

[Network]
Bridge=bridge
LinkLocalAddressing=no

The bridge interface is named exactly bridge and has IP addresses when shown with ip a, for example, 192.168.1.2/24. It also has a wireless interface wlp3s0 with IP address 192.168.5.2/24 and an OpenVPN interface ovpn at 10.0.1.2/24.

My containers and VMs are running under an internal bridge virbr0 where the host has the address 172.17.0.1/16. The strange thing is, no container or VM can reach the network outside host interface bridge, but all of them can reach anything from host interfaces wlp3s0 (e.g. 192.168.5.1) and ovpn (e.g. 10.0.1.1).

I tried pinging different locations from a VM and watching packets on the host.

root@iBug-Server:~# tcpdump -leni bridge icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bridge, link-type EN10MB (Ethernet), capture size 262144 bytes
00:05:36.068658 86:80:93:9a:83:87 > d8:67:d9:70:e9:41, ethertype IPv4 (0x0800), length 98: 192.168.1.2 > 192.168.1.1: ICMP echo request, id 6227, seq 1, length 64
00:05:36.068902 d8:67:d9:70:e9:41 > 86:80:93:9a:83:87, ethertype IPv4 (0x0800), length 98: 192.168.1.1 > 192.168.1.2: ICMP echo reply, id 6227, seq 1, length 64
00:05:36.068930 86:80:93:9a:83:87 > d8:67:d9:70:e9:41, ethertype IPv4 (0x0800), length 98: 192.168.1.1 > 172.17.2.120: ICMP echo reply, id 6227, seq 1, length 64
^C
3 packets captured
3 packets received by filter
0 packets dropped by kernel
root@iBug-Server:~# tcpdump -leni wlp3s0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlp3s0, link-type EN10MB (Ethernet), capture size 262144 bytes
00:06:29.306316 12:04:21:2d:39:18 > 74:f8:db:6a:3e:d1, ethertype IPv4 (0x0800), length 98: 192.168.5.2 > 192.168.5.1: ICMP echo request, id 6231, seq 1, length 64
00:06:29.317283 74:f8:db:6a:3e:d1 > 12:04:21:2d:39:18, ethertype IPv4 (0x0800), length 98: 192.168.5.1 > 192.168.5.2: ICMP echo reply, id 6231, seq 1, length 64
^C
2 packets captured
2 packets received by filter
0 packets dropped by kernel
root@iBug-Server:~# tcpdump -leni enp2s0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp2s0, link-type EN10MB (Ethernet), capture size 262144 bytes
00:09:12.098863 86:80:93:9a:83:87 > d8:67:d9:70:e9:41, ethertype IPv4 (0x0800), length 98: 192.168.1.2 > 192.168.1.1: ICMP echo request, id 6232, seq 1, length 64
00:09:12.099100 d8:67:d9:70:e9:41 > 86:80:93:9a:83:87, ethertype IPv4 (0x0800), length 98: 192.168.1.1 > 192.168.1.2: ICMP echo reply, id 6232, seq 1, length 64
00:09:12.099145 86:80:93:9a:83:87 > d8:67:d9:70:e9:41, ethertype IPv4 (0x0800), length 98: 192.168.1.1 > 172.17.2.120: ICMP echo reply, id 6232, seq 1, length 64
^C
3 packets captured
3 packets received by filter
0 packets dropped by kernel

As can be seen above, the 3rd packet from bridge or enp2s0 appears to be going to the wrong place (it should have been to virbr0) and also having wrong MAC addresses. Here are the results from virbr0. Note how the ICMP reply didn't appear when pinging 192.168.1.1 (gateway of host's bridge interface).

root@iBug-Server:~# tcpdump -leni virbr0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on virbr0, link-type EN10MB (Ethernet), capture size 262144 bytes
00:21:49.815124 00:16:3e:03:1a:f8 > 52:b4:4b:3f:45:e2, ethertype IPv4 (0x0800), length 98: 172.17.2.120 > 192.168.1.1: ICMP echo request, id 6238, seq 1, length 64
^C
1 packet captured
1 packet received by filter
0 packets dropped by kernel
root@iBug-Server:~# tcpdump -leni virbr0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on virbr0, link-type EN10MB (Ethernet), capture size 262144 bytes
00:21:59.268210 00:16:3e:03:1a:f8 > 52:b4:4b:3f:45:e2, ethertype IPv4 (0x0800), length 98: 172.17.2.120 > 192.168.5.1: ICMP echo request, id 6239, seq 1, length 64
00:21:59.277884 52:b4:4b:3f:45:e2 > 00:16:3e:03:1a:f8, ethertype IPv4 (0x0800), length 98: 192.168.5.1 > 172.17.2.120: ICMP echo reply, id 6239, seq 1, length 64
^C
2 packets captured
2 packets received by filter
0 packets dropped by kernel

My iptables has an empty FORWARD chain with policy ACCEPT, and I didn't touch the nat table after setting up KVM (with libvirt). What's going wrong here and how do I fix it?

My server connects to some strange resources via OpenVPN, and every time the OpenVPN client starts up, an ovpn interface is brought up.

I want to expose only selected ports (say, MySQL) to this interface, so I have this rule in my iptables:

iptables -A INPUT -i ovpn -p tcp --dport 3306 -j ACCEPT

However, because the OpenVPN client can disconnect and reconnect without intervention, the link ID (as shown by ip link show ovpn) can change.

Will the above iptables rule continue to work after the link disappears and appears again (with a different ID)?

I have a custom-managed domain when inside my corporate's intranet it resolves to an internal gateway machine, and when outside the intranet it resolves to Cloudflare. There's a website we want to provide access to both the intranet and the internet, so I have configured Nginx on the gateway as follows:

server {
    listen 443 ssl http2;
    server_name example.com;

    location / {
        proxy_pass https://example.com.cloudflare.net;
        proxy_set_header Host "example.com";
    }
}

The problem is, now I want Nginx to verify the SSL certificate for example.com.cloudflare.net against example.com (instead of the resolved domain). How should I do so?

Note that example.com resolves to the intranet IP address of this gateway machine (it's in the intranet, too).

I have a storage server providing downloading services in an intranet. Recently I've added a reverse proxy on a gateway so the download services are accessible from the internet. However because bandwidth costs and paired with other reasons, I would like to restrict the maximum file size for a single request, say one MiB.

I have currently two ideas

1. Configure Nginx on the origin server to deny access to files exceeding the threshold
2. Configure Nginx on the gateway to respond with some 4xx code once the proxy backend responds with a big value in Content-Length header.

I still haven't Googled out how to do either (any one of the ideas suffices).

In case it helps: The origin server runs stock Nginx from Debian APT repository, while the gateway runs OpenResty (Nginx with LUA). I however am not familiar with LUA.

I have a private SSH CA that manages my servers (well I have quite a few of them). All my servers are configured to trust this CA in this way:

TrustedUserCAKeys /etc/ssh/iBug-CA.pub

These servers run a variety of OS's and have different usernames (like root, ubuntu, debian, admin, ibug etc.). I have a "central" server that I'd like to grant access to an arbitrary username on an arbitrary server, so I signed its user key with this command.

ssh-keygen -s ibug_ca.pem -I iBug-Central -n \* id_rsa.pub

But the signed certificate (id_rsa-cert.pub) can't log in any server, so I had to sign another certificate like this

ssh-keygen -s ibug_ca.pem -I iBug-Central -n root,ubuntu,debian,ibug,admin id_rsa.pub

The new id_rsa-cert.pub can log in to any server with one of the listed usernames, but it can't log in with an unlisted username (e.g. adm).

Is there a way to sign a certificate for a catch-all name? I tried omitting the -n option of ssh-keygen and it didn't work, either.

I have something like this in ~/.ssh/known_hosts on my Linux machine:

@cert-authority * ssh-rsa pubkeypubkeypubkey

And any server with a signed host key is automatically trusted by the OpenSSH client.

I regularly use PuTTY on my Windows PC. How do I achieve something similar?