Modify

Opened 23 months ago

Last modified 22 months ago

#22111 new defect

dropbear listens on public ipv6 connection after process restart = remote SSH access (vulnerability mitigation included)

Reported by: Aditza Owned by: developers
Priority: high Milestone:
Component: packages Version: Chaos Calmer 15.05
Keywords: dropbear, remote ssh Cc:

Description

note:i posted this on github too since i don't know exactly which issue tracking system is used for OpenWRT's dropbear

https://github.com/openwrt/packages/issues/2562

using Chaos Calmer 15.05.1 r49053 / LuCI for-15.05 branch (git-16.081.39589-0207cb7)

What do i have to do so that dropbear listens ONLY on ipv4 connections?

in the allowed parameters description i did not find this
https://wiki.openwrt.org/doc/uci/dropbear

when my router starts up, dropbear runs like this

 4732 root      1220 S    /usr/sbin/dropbear -F -P /var/run/dropbear.1.pid -p 192.168.0.1:22 -p fd41:_ETC_ipv6_:22 -K 300

and after the IPv6 PPPoE connection starts up, if i run the command

/etc/init.d/dropbear restart

then dropbear starts to listen on the public-accessible IPv6 address

7598 root      1152 S    /usr/sbin/dropbear -F -P /var/run/dropbear.1.pid -p 192.168.0.1:22 -p 2a02:2f0d:_ETC_ipv6_:22 -p fd41:_ETC_ipv6_:22 -K 300

netstat info:

tcp        0      0 192.168.0.1:22          0.0.0.0:*               LISTEN      7598/dropbear
tcp        0      0 fd41:_ETC_ipv6_:22    :::*                    LISTEN      7598/dropbear
tcp        0      0 2a02:2f0d:_ETC_ipv6_:22 :::*                    LISTEN      7598/dropbear


since i did not find how to prevent dropbear from listening on the public IPv6 address, i created firewall rules to block anything incoming to destination port 22, both on INPUT and on the FORWARD chains

block_incoming_ssh - Any TCP, UDP - From any host in wan To any router IP at port 22 on this device
Discard input

block_incoming_ssh_fw - Any TCP, UDP - From any host in wan To any host, port 22 in any zone
Discard forward

root@MyRouter-v2:/etc/config# iptables-save | grep 22
[...]

-A zone_wan_forward -p tcp -m tcp --dport 22 -m comment --comment block_incoming_ssh_fw -j DROP
-A zone_wan_forward -p udp -m udp --dport 22 -m comment --comment block_incoming_ssh_fw -j DROP
-A zone_wan_input -p tcp -m tcp --dport 22 -m comment --comment block_incoming_ssh -j DROP
-A zone_wan_input -p udp -m udp --dport 22 -m comment --comment block_incoming_ssh -j DROP

root@MyRouter-v2:/etc/config# ip6tables-save | grep 22
[...]

-A zone_wan_forward -p tcp -m tcp --dport 22 -m comment --comment block_incoming_ssh_fw -j DROP
-A zone_wan_forward -p udp -m udp --dport 22 -m comment --comment block_incoming_ssh_fw -j DROP
-A zone_wan_input -p tcp -m tcp --dport 22 -m comment --comment block_incoming_ssh -j DROP
-A zone_wan_input -p udp -m udp --dport 22 -m comment --comment block_incoming_ssh -j DROP

my network and dropbear configuration:

/etc/dropbear/config

config dropbear
        option PasswordAuth 'on'
        option Port '22'
        option Interface 'lan'

and relevant bits of /etc/config/network

config interface 'lan'
        option ifname 'eth1'
        option force_link '1'
        option type 'bridge'
        option proto 'static'
        option netmask '255.255.255.0'
        option stp '1'
        option ipaddr '192.168.0.1'
        option ip6assign '64'

config interface 'wan'
        option ifname 'eth0'
        option _orig_ifname 'eth0'
        option _orig_bridge 'false'
        option proto 'pppoe'
        option username '_my_pppoe_username_here'
        option password '__my_pppoe_pw_here'
        option peerdns '0'
        option dns '_my_ipv4_dns_servers_here _my_ipv6_dns_servers_here'
        option ipv6 'auto'
        option reqprefix 'auto'
        option reqaddress 'force'

ifconfig info:
NOTE: dropbear is listening on the IPv6 address from br-lan... but that one is still public-accessible due to how IPv6 works (scope: global and no NAT for IPv6)

root@MyRouter-v2:~# ifconfig
br-lan    Link encap:Ethernet  HWaddr xxxxxxxxxxxxxxxxxxxxx
          inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::_ETC_ipv6_/64 Scope:Link
          inet6 addr: fd41:_ETC_ipv6_::1/64 Scope:Global
          inet6 addr: 2a02:2f0d:_ETC_ipv6_/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:234667 errors:0 dropped:0 overruns:0 frame:0
          TX packets:153136 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:287862887 (274.5 MiB)  TX bytes:26678071 (25.4 MiB)

[...]
pppoe-wan Link encap:Point-to-Point Protocol
          inet addr:xxxxxxxxxxxxxxx  P-t-P:10.0.0.1  Mask:255.255.255.255
          inet6 addr: fe80::_ETC_ipv6_/10 Scope:Link
          inet6 addr: 2a02:2f0d:_ETC_ipv6_/128 Scope:Global
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:146565 errors:0 dropped:0 overruns:0 frame:0
          TX packets:223867 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:20771573 (19.8 MiB)  TX bytes:286770435 (273.4 MiB)

[...]

Attachments (0)

Change History (9)

comment:1 Changed 23 months ago by anonymous

The address is public / globally routable, but OpenWrt's default firewall rules block any incoming connections from the WAN interface.

comment:2 follow-up: Changed 23 months ago by Aditza

the security of critical system services, such as telnet/ssh and luci web admin, should not rely imho on the default firewall rules... they should have explicit DROP rules for wan.

I think that those default rules should be considered more of a safety net for cases of "oh, shit! why is this open?" instead of the main line of defense.

comment:3 Changed 23 months ago by Aditza

P.S. for "default firewall rules" i mean the default rule policy for rule cases not otherwise specified by the firewall.

comment:4 in reply to: ↑ 2 Changed 22 months ago by anonymous

Replying to Aditza:

the security of critical system services, such as telnet/ssh and luci web admin, should not rely imho on the default firewall rules... they should have explicit DROP rules for wan.

I think that those default rules should be considered more of a safety net for cases of "oh, shit! why is this open?" instead of the main line of defense.

I agree with you this should not be open just like it's not for IPv4.

comment:5 Changed 22 months ago by Donk

Hello,
Recently, I upgraded from Barrier Breaker to Chaos Calmer and I have the same issue.

Does anyone know, with odhcpd, how to send router advertisement with a public routable prefix on the lan without having a public ipv6 on the br-lan interface.

comment:6 Changed 22 months ago by anonymous

You want your router to advertise a prefix that it can't actually route to/from?

comment:7 Changed 22 months ago by Donk

The router can route the public prefix through the private ipv6 of his br-lan interface.

Under Barrier Breaker I used radvd, but I do not know if this is possible with odhcpd.

comment:8 Changed 22 months ago by anonymous

I see now. I didn't realize that Linux (on the router) would be able to route to the public prefix on its LAN interface even if the LAN interface didn't have an address with that prefix. It also seems like the router wouldn't be able to originate traffic destined to the public addresses of machines on the LAN (because it would have no source address to use). Maybe that's ok though?

comment:9 Changed 22 months ago by anonymous

Also, I'm not sure but I don't think this is possible with odhcpd--it seems like it simply looks at the addresses assigned to the interfaces on the router.

Add Comment

Modify Ticket

Action
as new .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.