It turns out that Eggdrop does not check to see if the DNS is spoofed when
accepting a telnet session.
Telnet connection: barkerjr.ircd/56705
Denied telnet: barkerjr@barkerjr.ircd, No Access
Now, this would be fine if the host was actually valid for forward resolving.
However...
Dns resolved 69.50.185.193 to barkerjr.ircd
Dns unable to resolve barkerjr.ircd
Since it's not verifying the forward DNS, this could be a problem. Reverse DNS
is specified by the net-block administrator, so it can easily be invalid, by
mistake or intentionally.
So, this could be a problem, as any net-block admin can spoof hostnames and
telnet to your bot as a known user's hostname, rendering protect-telnet ineffective.
It turns out that Eggdrop does not check to see if the DNS is spoofed when accepting a telnet session.
Telnet connection: barkerjr.ircd/56705 Denied telnet: barkerjr@barkerjr.ircd, No Access
Now, this would be fine if the host was actually valid for forward resolving. However...
Since it's not verifying the forward DNS, this could be a problem. Reverse DNS is specified by the net-block administrator, so it can easily be invalid, by mistake or intentionally.
So, this could be a problem, as any net-block admin can spoof hostnames and telnet to your bot as a known user's hostname, rendering protect-telnet ineffective.