Community Forum

Resolved
0 votes
Hi guys!

Recently I scanned my ClearOS router for open ports and discovered many of them being open. Below is the corresponding output:


NSE: Loaded 148 scripts for scanning.

NSE: Script Pre-scanning.

Initiating NSE at 13:52

Completed NSE at 13:52, 0.00s elapsed

Initiating NSE at 13:52

Completed NSE at 13:52, 0.00s elapsed

Initiating Ping Scan at 13:52

Scanning [4 ports]

Completed Ping Scan at 13:52, 0.30s elapsed (1 total hosts)

Initiating Parallel DNS resolution of 1 host. at 13:52

Completed Parallel DNS resolution of 1 host. at 13:52, 5.50s elapsed

Initiating SYN Stealth Scan at 13:52

Scanning () [65535 ports]

SYN Stealth Scan Timing: About 9.38% done; ETC: 13:58 (0:04:59 remaining)

Discovered open port 1194/tcp on

SYN Stealth Scan Timing: About 43.96% done; ETC: 13:55 (0:01:18 remaining)

Discovered open port 8008/tcp on

Discovered open port 8020/tcp on

Discovered open port 5060/tcp on

Discovered open port 2000/tcp on

Discovered open port 58656/tcp on

Discovered open port 9091/tcp on

Completed SYN Stealth Scan at 13:54, 98.44s elapsed (65535 total ports)

Initiating Service scan at 13:54

Scanning 7 services on ()

Service scan Timing: About 71.43% done; ETC: 13:58 (0:01:00 remaining)

Completed Service scan at 13:57, 156.04s elapsed (7 services on 1 host)

Initiating OS detection (try #1) against

Retrying OS detection (try #2) against

Initiating Traceroute at 13:57

Completed Traceroute at 13:57, 0.01s elapsed

NSE: Script scanning .

Initiating NSE at 13:57

Completed NSE at 13:57, 15.92s elapsed

Initiating NSE at 13:57

Completed NSE at 13:57, 1.03s elapsed

Nmap scan report for

Host is up (0.0057s latency).

Not shown: 65526 filtered ports

PORT STATE SERVICE VERSION

113/tcp closed ident

1194/tcp open openvpn OpenVPN

2000/tcp open cisco-sccp?

5060/tcp open sip?

8008/tcp open http Fortinet FortiGuard block page

| http-methods:

|_ Supported Methods: GET HEAD POST OPTIONS

|_http-title: Did not follow redirect to

8010/tcp closed xmpp

8020/tcp open http-proxy FortiGate Web Filtering Service

| http-methods:

|_ Supported Methods: GET HEAD POST OPTIONS

| http-open-proxy: Potentially OPEN proxy.

|_Methods supported:CONNECTION

|_http-title: Web Filter Block Override

9091/tcp open http Transmission BitTorrent management httpd (unauthorized)

| http-auth:

| HTTP/1.1 401 Unauthorized\x0D

|_ Basic realm=Transmission

| http-methods:

|_ Supported Methods: GET HEAD POST

|_http-server-header: Transmission

|_http-title: Site doesn't have a title (text/html; charset=ISO-8859-1).

58656/tcp open unknown

| fingerprint-strings:

| Kerberos:

| m6fq

| D)O4(M

| 'G)B

| z#@#

| L-j$

| oqRY

| t+CV

| TLSSessionReq:

| P\xa0!

| Wmm~7

| :vYR

| Y0u>

| \xea

| \x81w

|_ Ei}o

1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service :

SF-Port58656-TCP:V=7.70%I=7%D=5/29%Time=5B0D31A8%P=i686-pc-windows-windows

SF:%r(TLSSessionReq,257,"Y>\x97\x99\xc2\rQ\)\xd4V\xe8\$\xf8\x201jx\xa9R\x9

SF:8\xdfP\\\xa0!\x81\xb8\xacK\xab8I\xfa\x1c\xc3\)\x83%\nV\x01t\xd3\xf4Wmm~

SF:7\n\xce\xad%\x12\x13\xaf\xeb4\x96\xb9f\x15l\x9dn\xfe\xf4;\x96\x01\xec\n

SF:\xb3\^\x96E9\xcdoh\x84:vYR\xda\$\xf6\xb5\x948\xe0\xd5\xd3\xd1k\xe7\[\[\

SF:x17E%\xd5\xb3\x97Jf\x017\xbb\xab\xee\xb4\x01T4\(\xa9i\xd4E>\x08\xf7\x81

SF:\x82\x99\x03\xa2\xf9\x08\x17\xd2l\xe8>Y\xd9\x03}\x95jl\x01\xa1\xd8\x8e\

SF:xdd\^\x11\xa0Y0u>\xd2e\xf8\xb6\xb2\xc8\x16\xf7\xa0,\x84\xc7\x81\xc79X\x

SF:12\xc4\xc5\xc3\xfd\x15\\\xea\xe6\xf3\x8a\x88C\x0en\xfed\x96\x0b\xc8E4c\

SF:x14\xd9M\nNU\xad\x95\$\xf3\x1f\xf1Z-\x9fd\xc6\xa6\x12H\[\x14\xf7\x19\+~

SF:\xb40\x92\xbc\xeb\xb0v\xb1\xce\xf1/w\xbby\xee\xc82%\xfc\xd5P0\x84\x9f\x

SF:c1\xa2\xc95\x82\xa2l\xcc\x9c\xc0`H\x83\xce\xf2N;\x81\x88\xd2\xe7\xbaxA\

SF:x1a\x05\xd9\xee\xa77\xadh\xd4I\xab\xde\xc0\xde\xed\x9c\xf5\x94\x7f\x91\

SF:x01\xe8\xe5\xdeQ\x1c\xcd\xd7_L\+\x1c\x0bK\xdc\xf0\x08\xc0\x10\x9c\x91F\

SF:xb7\x93l\xef\xdb\\\x81w\xcb\x10\xf2\xc3l\x12\x9eK\xb9\xc6\xb2-'/\x9e\xb

SF:5\xcf\xda\xd1\xeaC\xd2\x1a\xd3<\xfe\xd4\x18\xeb\xa0\xae\x1beyM\xe3\x84\

SF:x04Za\r\xb3\x81\xae\xa6\$\xf1\xce\xaaQ\xbf\xb6x\xdff\n\xdb\x95\x10\xaa9

SF:\xe8\xf3i,<\xab\xdc\xeb\xec\0M\xe2\xa8\xdeHg\.\x8f\xdb9\xaf\xa3\xcb\xeb

SF:\x0e\x17\x9a7\x0e\xf7\x1e\xcc\x99\x1dA\xdf\x81S\xd4\xee\xdf\?\xb0\|=\xf

SF:9}\xf8\x0cj\x95\xc8{\$\r\x04;k\xdcQW}\xf7\xf9Z\xc5BC\xae2\xf0\xa5&\xd9\

SF:xfb\x19\[\x11\x1d\x12\x1dUM'\xfd\x0f3\x98J\x84\x93Q\x84\xd7Fp\xa2Z\xbei

SF:\x93\x14}\x15\xa4\xb7\xcd\xd3\|\xdf\x0f8\x83\xfa\xfe\xec\x90&\n,D\x9d\)

SF:S\x8cv\(\x8d\xa1`Pd\x0e\xaa\x17x\x17t\xd8\xb0\x1a\xb7\xea\x9f5\ts\xe4\x

SF:f3\xe0\x9d\?\x8c\xee\)\xfd\x83\x0f%\x98\x99o\x11\xb1\xcf\?\xf3\xca!\x1d

SF:Ay\x1c\xb4B\xe9\x9b\xdb8\x9a\x9fz\x07\xe4\xf3\xe1\x08\x99Ei}o\xe1\x8d!\

SF:]w\xf4\x01\x1e\xab=\x90\xabU\|\xef\x10'i\x94\.ZF\xf6_\x15CgI")%r(Kerber

SF:os,14E,"8\x1d\xe1\xaf\x1dmwU\xec\x9a\xcf8E\xab\"\xa7U\x9e\xaf\x8d\xcf\x

SF:d0y\xf4\x9a<\x0c\xe7\xf3\xf5\xac\xb3\xa9\xaaL\|S\xc8\x08c\xb7\xf6r\xe1\

SF:xc1\xb9\xd2\x85s\xad\x08m6fq\x8e\x19\xea}\x20\xbdL\xfb\x15\x9ao\x1b\x0e

SF:\x1a\x10\xd1\xe2\xb7\xa0\x84m\xeb\xf9\xd33\x8a\x10\xec>\xd7\x7f\xac\xc3

SF:\xd3\xdeEP\xc7W\x0c\xd5\xd0!\xf9\x95\xb3\xf1B\x1e:\xcd\x19\xfe\x91<b9\x

SF:e1\x8a\x02\xa6\x0b\rD\)O4\(M\xe8\x15\x9d\xeb\x86p\xe46\x18\"\x03\xb7H\x

SF:b0\xd9\xb1\xf5\xfc\x86\x8a\x06\x8e-\x05\x82c\x9b\xc6Q\xdd\x80\x07\xf4\*

SF:c\x17\"\xa3\xaa\xc2~\x85\x9fM\xb2\xbdz-\xb6'G\)B\xf7}H\xa2a\xbc\x93\xa4

SF:\x13\xbc\x05\x93S\x9a\xdf\xd1\x08\x8a3\xd3~3\xd1xX6\x03\xdb\x0b\$\xa0\x

SF:a4\xa1!\xdf\xc1\xb3\xd8z#@#\xe12\x04\x91\xd5yE\xdf\xdf\x88\xde\x91\xf7\

SF:?\x80_/!\x85\xd7\x19\xce\xdb\x9fI\xc3\x7fL-j\$\xc9\x10\xea\x99\x0b\tY\x

SF:eb\xe8oqRY\xd3\xc4\xda\xb9\xc0\x85\x15\xf7k\xb1V\x20\x03\x15\xb4\^\xd5\

SF:xcb\xa3\xd7\xa9\x1f\xc5\xff\xd9\x0fc\x08\?\xc1b\xf9\xd3\x8c\xf5\xc7\x04

SF:\xfa\x0e\x15t\+CV\x96\xc2<A\xca\x9e\xc1\xfc5W\xe3\xfe\xbe\x17\xda\x90\x

SF:d6\xdeA\xcc\x9caC1\x1fuq");

Device type: general purpose

Running (JUST GUESSING): Linux 4.X|3.X|2.6.X (99%)

OS CPE: cpe:/o:linux:linux_kernel:4.4 cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:2.6.32

Aggressive OS guesses: Linux 4.4 (99%), Linux 4.0 (96%), Linux 3.11 - 4.1 (94%), Linux 2.6.32 (93%), Linux 2.6.32 or 3.10 (93%), Linux 3.13 (93%), Linux 3.10 - 3.12 (92%), Linux 2.6.32 - 2.6.35 (91%), Linux 4.9 (91%), Linux 2.6.32 - 2.6.39 (91%)

No exact OS matches for host (test conditions non-ideal).

Uptime guess: 4.579 days (since Fri May 25 00:03:41 2018)

Network Distance: 1 hop

TCP Sequence Prediction: Difficulty=260 (Good luck!)

IP ID Sequence Generation: All zeros

Service Info: Device: security-misc



TRACEROUTE (using port 113/tcp)

HOP RTT ADDRESS

1 1.00 ms



NSE: Script Post-scanning.

Initiating NSE at 13:57

Completed NSE at 13:57, 0.00s elapsed

Initiating NSE at 13:57

Completed NSE at 13:57, 0.00s elapsed

Read data files from: C:\Program Files (x86)\Nmap

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .

Nmap done: 1 IP address (1 host up) scanned in 283.95 seconds

Raw packets sent: 131215 (5.777MB) | Rcvd: 143 (7.040KB)


By default, all my ports are closed except the one for VPN (1194) configured in Allowed Incoming Connections. Behind my router, I have a QNAP NAS. When I disconnected it nmap reported that the host seems to be down, hence my network became not accessible from the outside. Obviously, all scans are done from outside of my network (from work and my Android phone connected to a celullar network). I was thinking that it was due to the MiniUpnp daemon which forward ports on demand, but after I turned it off and restarted networking service (I think I also tried to restart the router completely) nothing has changed in nmap output. Still, those ports remain open.
FYI ports 9091 and 58656 are forwarded in ClearOS.

If any of you has any idea why it is happening you are welcome to help.
Friday, June 01 2018, 09:00 PM
Share this post:
Responses (12)
  • Accepted Answer

    Friday, June 15 2018, 12:44 PM - #Permalink
    Resolved
    0 votes
    It always makes sense not to open ports you don't need. All you have specifically open is OpenVPN with UDP which you use and need so that is fine. The same goes for forwarded ports. Only forward the ones you need.
    The reply is currently minimized Show
  • Accepted Answer

    Friday, June 15 2018, 12:24 PM - #Permalink
    Resolved
    0 votes
    In iptables I didn't find anything interesting:


    [root@gateway ~]# iptables -nvL INPUT
    Chain INPUT (policy DROP 160K packets, 13M bytes)
    pkts bytes target prot opt in out source destination
    9478 673K DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
    0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x12/0x12 state NEW reject-with tcp-reset
    1401 951K DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:!0x17/0x02 state NEW
    0 0 DROP all -- enp3s0 * 127.0.0.0/8 0.0.0.0/0
    0 0 DROP all -- enp3s0 * 169.254.0.0/16 0.0.0.0/0
    4138 359K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
    0 0 ACCEPT all -- pptp+ * 0.0.0.0/0 0.0.0.0/0
    0 0 ACCEPT all -- tun+ * 0.0.0.0/0 0.0.0.0/0
    47026 3991K ACCEPT all -- enp4s0 * 0.0.0.0/0 0.0.0.0/0
    0 0 ACCEPT all -- wlp2s0 * 0.0.0.0/0 0.0.0.0/0
    2527 74543 ACCEPT icmp -- enp3s0 * 0.0.0.0/0 0.0.0.0/0 icmptype 0
    1 56 ACCEPT icmp -- enp3s0 * 0.0.0.0/0 0.0.0.0/0 icmptype 3
    701 58462 ACCEPT icmp -- enp3s0 * 0.0.0.0/0 0.0.0.0/0 icmptype 8
    0 0 ACCEPT icmp -- enp3s0 * 0.0.0.0/0 0.0.0.0/0 icmptype 11
    20442 7393K ACCEPT udp -- enp3s0 * 0.0.0.0/0 0.0.0.0/0 udp spt:67 dpt:68
    0 0 ACCEPT tcp -- enp3s0 * 0.0.0.0/0 0.0.0.0/0 tcp spt:67 dpt:68
    4 168 ACCEPT udp -- * * 0.0.0.0/0 udp dpt:1194
    24604 3387K ACCEPT udp -- enp3s0 * 0.0.0.0/0 0.0.0.0/0 udp dpts:1024:65535 state RELATED,ESTABLISHED
    49 35694 ACCEPT tcp -- enp3s0 * 0.0.0.0/0 0.0.0.0/0 tcp dpts:1024:65535 state RELATED,ESTABLISHED


    Shields Up! reported:
    "THE EQUIPMENT AT THE TARGET IP ADDRESS
    DID NOT RESPOND TO OUR UPnP PROBES!"

    I believe I've made my router much more difficult to hack from outside by closing all unnecessary ports.

    What do you think? What can be improved further?
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, June 12 2018, 08:51 PM - #Permalink
    Resolved
    0 votes
    To look for open ports in the firewall, you also need to do an "iptables -nvL INPUT" at a basic level. It gets more complicates if you have DNAT rules in the PREROUTING chain which switch ports.

    Are you doing TCP or UDP port scans or both? You can try the Shields Up! testing at grc.com, but ignore some of his scaremongering about invisibility.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, June 12 2018, 06:35 PM - #Permalink
    Resolved
    0 votes
    UPD. Here is the output from pentest tool:

    http://i68.tinypic.com/d4soy.jpg
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, June 12 2018, 06:22 PM - #Permalink
    Resolved
    0 votes
    Sorry for the late response. Was on a business trip.

    Yesterday had an opportunity to run nmap from work and found a few differences. Windows version of nmap gives more open ports compare to the version for Android. Here is the output for intense, no ping scan:


    NSE: Loaded 148 scripts for scanning.

    NSE: Script Pre-scanning.

    Initiating NSE at 14:36

    Completed NSE at 14:36, 0.00s elapsed

    Initiating NSE at 14:36

    Completed NSE at 14:36, 0.00s elapsed

    Initiating Parallel DNS resolution of 1 host. at 14:36

    Completed Parallel DNS resolution of 1 host. at 14:36, 5.53s elapsed

    Initiating SYN Stealth Scan at 14:36

    Scanning [1000 ports]

    Discovered open port 9091/tcp on

    Discovered open port 5060/tcp on

    Discovered open port 2000/tcp on

    Discovered open port 8008/tcp on

    Completed SYN Stealth Scan at 14:36, 4.38s elapsed (1000 total ports)

    Initiating Service scan at 14:36

    Scanning 4 services on

    Service scan Timing: About 75.00% done; ETC: 14:40 (0:00:50 remaining)

    Completed Service scan at 14:39, 156.09s elapsed (4 services on 1 host)

    Initiating OS detection (try #1) against
    Retrying OS detection (try #2) against

    Initiating Traceroute at 14:39

    Completed Traceroute at 14:39, 0.01s elapsed

    NSE: Script scanning

    Initiating NSE at 14:39

    Completed NSE at 14:39, 15.02s elapsed

    Initiating NSE at 14:39

    Completed NSE at 14:39, 1.03s elapsed

    Nmap scan report for

    Host is up (0.0068s latency).

    Not shown: 994 filtered ports

    PORT STATE SERVICE VERSION

    113/tcp closed ident

    2000/tcp open cisco-sccp?

    5060/tcp open sip?

    8008/tcp open http Fortinet FortiGuard block page

    | http-methods:

    |_ Supported Methods: GET HEAD POST OPTIONS

    |_http-title: Did not follow redirect to

    8010/tcp closed xmpp

    9091/tcp open http Transmission BitTorrent management httpd (unauthorized)

    | http-auth:

    | HTTP/1.1 401 Unauthorized\x0D

    |_ Basic realm=Transmission

    | http-methods:

    |_ Supported Methods: GET HEAD POST

    |_http-server-header: Transmission

    |_http-title: Site doesn't have a title (text/html; charset=ISO-8859-1).

    Device type: firewall|WAP|general purpose

    Running (JUST GUESSING): Fortinet embedded (99%), Linux 2.4.X|2.6.X (90%)

    OS CPE: cpe:/h:fortinet:fortigate_100d cpe:/o:linux:linux_kernel:2.4.36 cpe:/o:linux:linux_kernel:2.6

    Aggressive OS guesses: Fortinet FortiGate 100D firewall (99%), Fortinet FortiGate-60B or -100A firewall (96%), DD-WRT v23 (Linux 2.4.36) (90%), Fortinet FortiGate-50B or 310B firewall (90%), Linux 2.6.18 - 2.6.22 (90%)

    No exact OS matches for host (test conditions non-ideal).

    Uptime guess: 171.824 days (since Wed Dec 20 17:52:50 2017)

    Network Distance: 1 hop

    Service Info: Device: security-misc



    TRACEROUTE (using port 113/tcp)

    HOP RTT ADDRESS

    1 0.00 ms


    NSE: Script Post-scanning.

    Initiating NSE at 14:39

    Completed NSE at 14:39, 0.00s elapsed

    Initiating NSE at 14:39

    Completed NSE at 14:39, 0.00s elapsed

    Read data files from: C:\Program Files (x86)\Nmap

    OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/.

    Nmap done: 1 IP address (1 host up) scanned in 191.18 seconds

    Raw packets sent: 2079 (95.136KB) | Rcvd: 38 (2.260KB)


    "iptables -nvL -t nat" shows only two ports 58656 and 9091 which are forwarded in ClearOS for the QNAP Transmission client. I closed the tcp port for OpenVPN connections.

    CanYouSeeMe.org reports only about those forwarded ports. Others are closed. Can it be simply a mistake of nmap for Windows?
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, June 03 2018, 07:39 AM - #Permalink
    Resolved
    0 votes
    What does a port scan give now? I think you've said it is OK.

    If you're using ClearOS as your OpenVPN server and the .ovpn file downloaded from ClearOS then you only need the udp port 1194 open. If you've changed your .ovpn file to use tcp, then you need the tcp port open. You will only be using tcp if you've done some manual configuring somewhere along the line (e.g. a Mikrotik router only has a built in client which can use tcp)
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, June 02 2018, 09:47 PM - #Permalink
    Resolved
    0 votes
    Here is the output of


    [root@gateway ~]# iptables -nvL -t nat
    Chain PREROUTING (policy ACCEPT 74193 packets, 7846K bytes)
    pkts bytes target prot opt in out source destination
    3490 199K DNAT tcp -- * * 0.0.0.0/0 tcp dpt:58656 to:192.168.10.124
    15914 1916K DNAT udp -- * * 0.0.0.0/0 udp dpt:58656 to:192.168.10.124
    21 1092 DNAT tcp -- * * 0.0.0.0/0 tcp dpt:9091 to:192.168.10.124
    15420 1144K MINIUPNPD all -- enp3s0 * 0.0.0.0/0 0.0.0.0/0

    Chain INPUT (policy ACCEPT 3814 packets, 335K bytes)
    pkts bytes target prot opt in out source destination

    Chain OUTPUT (policy ACCEPT 2135 packets, 135K bytes)
    pkts bytes target prot opt in out source destination

    Chain POSTROUTING (policy ACCEPT 19245 packets, 2106K bytes)
    pkts bytes target prot opt in out source destination
    0 0 ACCEPT all -- * tun+ 0.0.0.0/0 0.0.0.0/0
    39001 3687K SNAT all -- * * 192.168.10.124 0.0.0.0/0 to:
    4 208 SNAT tcp -- * * 192.168.10.0/25 192.168.10.124 tcp dpt:58656 to:192.168.10.1
    0 0 SNAT tcp -- * * 192.168.20.0/26 192.168.10.124 tcp dpt:58656 to:192.168.20.1
    0 0 SNAT udp -- * * 192.168.10.0/25 192.168.10.124 udp dpt:58656 to:192.168.10.1
    0 0 SNAT udp -- * * 192.168.20.0/26 192.168.10.124 udp dpt:58656 to:192.168.20.1
    21 1092 SNAT tcp -- * * 192.168.10.0/25 192.168.10.124 tcp dpt:9091 to:192.168.10.1
    0 0 SNAT tcp -- * * 192.168.20.0/26 192.168.10.124 tcp dpt:9091 to:192.168.20.1
    10927 1225K MASQUERADE all -- * enp3s0 0.0.0.0/0 0.0.0.0/0
    0 0 MASQUERADE all -- * ibvpn 0.0.0.0/0 0.0.0.0/0

    Chain MINIUPNPD (1 references)
    pkts bytes target prot opt in out source destination


    Port 58656 is less important, I believe, since it is an incoming port for the Transmission client. I don't think that someone can do any harm using this port.

    The other one, 9091, is for remote access to my Transmission client. Even if someone finds out my login credentials to this client, I don't know if it helps to make any damage to my network.

    The main reason why I've started this conversation is the security of my network. I know that passwords can't be simple and easily cracked. Moreover, having many ports open is not secure as well, I believe. I am not a security expert, but I would like to keep my network as secure as possible. So any comments in this direction are welcomed.

    BTW, I keep port 1194 open only for one reason: I would like to have access to my local network via VPN connection. I assume that otherwise, I wouldn't be able to connect to my router. Please correct me if I'm wrong.
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, June 02 2018, 08:20 PM - #Permalink
    Resolved
    0 votes
    The point of updating miniupnpd was that on Thursday the underlying app, miniupnpd was updated to 2.1-3 and I failed to notice a particular change (I am the packager for the app in ClearOS) so the update introduced a bug where shutting the app down did not remove the port-forwards that miniupnpd had set up. This meant your test with miniupnpd shut down was effectively the same as the one with it running, so it was bad (or, at least, the ClearOS firewall was in an unintended state when testing)

    With your iptables listings now, your only open ports should be udp:1194 and tcp:1194 (which you probably don't need unless you have manual OpenVPN configs) and your port forwards. Unfortunately I gave you the wrong command for the port forwards - it should have been "iptables -nvL -t nat" and not "iptables -nvL INPUT", but your port forwards are tcp:80,443,9091,58656 and udp:58656. All should show open if the machine at 192.168.10.124 has them open when you test.
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, June 02 2018, 07:28 PM - #Permalink
    Resolved
    0 votes
    Here is the ClearOS version installed on my router:


    [root@gateway myksok]# cat /etc/redhat-release
    ClearOS release 7.4.0 (Final)


    Updated miniupnpd service to miniupnpd-2.1-3.v7 in the ClearOS dashboard (stil don't know what was the point since I'd shut the service down before). Added the line in /usr/lib/systemd/system/miniupnpd.service according to Nick's advice and reloaded daemon using
    systemctl daemon-reload
    . At the end, removed /var/lib/miniupnpd/upnp.leases.

    Now I can only scan my network using the flag -no ping (other parameters give "host seems down"). The output is only 9091 which is dedicated to the Transmission web client on my NAS.

    Here is the output of


    iptables -nvL

    Chain INPUT (policy DROP 15812 packets, 957K bytes)
    pkts bytes target prot opt in out source destination
    19752 1626K DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
    0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x12/0x12 state NEW reject-with tcp-reset
    1936 1174K DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:!0x17/0x02 state NEW
    0 0 DROP all -- enp3s0 * 127.0.0.0/8 0.0.0.0/0
    0 0 DROP all -- enp3s0 * 169.254.0.0/16 0.0.0.0/0
    7893 687K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
    0 0 ACCEPT all -- pptp+ * 0.0.0.0/0 0.0.0.0/0
    0 0 ACCEPT all -- tun+ * 0.0.0.0/0 0.0.0.0/0
    123K 10M ACCEPT all -- enp4s0 * 0.0.0.0/0 0.0.0.0/0
    1 52 ACCEPT all -- wlp2s0 * 0.0.0.0/0 0.0.0.0/0
    5053 147K ACCEPT icmp -- enp3s0 * 0.0.0.0/0 0.0.0.0/0 icmptype 0
    5 280 ACCEPT icmp -- enp3s0 * 0.0.0.0/0 0.0.0.0/0 icmptype 3
    1188 97980 ACCEPT icmp -- enp3s0 * 0.0.0.0/0 0.0.0.0/0 icmptype 8
    0 0 ACCEPT icmp -- enp3s0 * 0.0.0.0/0 0.0.0.0/0 icmptype 11
    70037 25M ACCEPT udp -- enp3s0 * 0.0.0.0/0 0.0.0.0/0 udp spt:67 dpt:68
    0 0 ACCEPT tcp -- enp3s0 * 0.0.0.0/0 0.0.0.0/0 tcp spt:67 dpt:68
    2 92 ACCEPT tcp -- * * 0.0.0.0/0 tcp dpt:1194
    4 168 ACCEPT udp -- * * 0.0.0.0/0 udp dpt:1194
    57349 8104K ACCEPT udp -- enp3s0 * 0.0.0.0/0 0.0.0.0/0 udp dpts:1024:65535 state RELATED,ESTABLISHED
    13486 27M ACCEPT tcp -- enp3s0 * 0.0.0.0/0 0.0.0.0/0 tcp dpts:1024:65535 state RELATED,ESTABLISHED

    Chain FORWARD (policy DROP 0 packets, 0 bytes)
    pkts bytes target prot opt in out source destination
    0 0 ACCEPT icmp -- enp3s0 * 0.0.0.0/0 192.168.10.124 icmptype 0
    271K 30M ACCEPT icmp -- enp3s0 * 0.0.0.0/0 192.168.10.124 icmptype 3
    0 0 ACCEPT icmp -- enp3s0 * 0.0.0.0/0 192.168.10.124 icmptype 8
    8827 854K ACCEPT icmp -- enp3s0 * 0.0.0.0/0 192.168.10.124 icmptype 11
    0 0 DROP icmp -- enp3s0 * 0.0.0.0/0 192.168.10.124
    30M 41G ACCEPT tcp -- enp3s0 * 0.0.0.0/0 192.168.10.124 tcp dpt:58656
    26M 4914M ACCEPT udp -- enp3s0 * 0.0.0.0/0 192.168.10.124 udp dpt:58656
    751 74527 ACCEPT tcp -- enp3s0 * 0.0.0.0/0 192.168.10.124 tcp dpt:9091
    0 0 ACCEPT tcp -- enp3s0 * 0.0.0.0/0 192.168.10.124 tcp dpt:80
    0 0 ACCEPT tcp -- enp3s0 * 0.0.0.0/0 192.168.10.124 tcp dpt:443
    100M 90G ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
    0 0 ACCEPT all -- pptp+ * 0.0.0.0/0 0.0.0.0/0
    0 0 ACCEPT all -- tun+ * 0.0.0.0/0 0.0.0.0/0
    3444K 283M ACCEPT all -- enp4s0 * 0.0.0.0/0 0.0.0.0/0
    0 0 ACCEPT all -- wlp2s0 * 0.0.0.0/0 0.0.0.0/0

    Chain OUTPUT (policy DROP 0 packets, 0 bytes)
    pkts bytes target prot opt in out source destination
    8406 724K ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
    0 0 ACCEPT all -- * pptp+ 0.0.0.0/0 0.0.0.0/0
    0 0 ACCEPT all -- * tun+ 0.0.0.0/0 0.0.0.0/0
    88526 17M ACCEPT all -- * enp4s0 0.0.0.0/0 0.0.0.0/0
    38 14295 ACCEPT all -- * wlp2s0 0.0.0.0/0 0.0.0.0/0
    190K 32M ACCEPT icmp -- * enp3s0 0.0.0.0/0 0.0.0.0/0
    1 328 ACCEPT udp -- * enp3s0 0.0.0.0/0 0.0.0.0/0 udp spt:68 dpt:67
    0 0 ACCEPT tcp -- * enp3s0 0.0.0.0/0 0.0.0.0/0 tcp spt:68 dpt:67
    10 412 ACCEPT tcp -- * enp3s0 0.0.0.0/0 tcp spt:1194
    20 888 ACCEPT udp -- * enp3s0 0.0.0.0/0 udp spt:1194
    72343 4658K ACCEPT all -- * enp3s0 0.0.0.0/0 0.0.0.0/0

    Chain DROP-lan (0 references)
    pkts bytes target prot opt in out source destination
    0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0


    and



    iptables -nvL INPUT

    pkts bytes target prot opt in out source destination
    19763 1628K DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
    0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x12/0x12 state NEW reject-with tcp-reset
    1936 1174K DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:!0x17/0x02 state NEW
    0 0 DROP all -- enp3s0 * 127.0.0.0/8 0.0.0.0/0
    0 0 DROP all -- enp3s0 * 169.254.0.0/16 0.0.0.0/0
    7950 694K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
    0 0 ACCEPT all -- pptp+ * 0.0.0.0/0 0.0.0.0/0
    0 0 ACCEPT all -- tun+ * 0.0.0.0/0 0.0.0.0/0
    123K 10M ACCEPT all -- enp4s0 * 0.0.0.0/0 0.0.0.0/0
    1 52 ACCEPT all -- wlp2s0 * 0.0.0.0/0 0.0.0.0/0
    5055 147K ACCEPT icmp -- enp3s0 * 0.0.0.0/0 0.0.0.0/0 icmptype 0
    5 280 ACCEPT icmp -- enp3s0 * 0.0.0.0/0 0.0.0.0/0 icmptype 3
    1188 97980 ACCEPT icmp -- enp3s0 * 0.0.0.0/0 0.0.0.0/0 icmptype 8
    0 0 ACCEPT icmp -- enp3s0 * 0.0.0.0/0 0.0.0.0/0 icmptype 11
    70067 25M ACCEPT udp -- enp3s0 * 0.0.0.0/0 0.0.0.0/0 udp spt:67 dpt:68
    0 0 ACCEPT tcp -- enp3s0 * 0.0.0.0/0 0.0.0.0/0 tcp spt:67 dpt:68
    2 92 ACCEPT tcp -- * * 0.0.0.0/0 tcp dpt:1194
    4 168 ACCEPT udp -- * * 0.0.0.0/0 udp dpt:1194
    57389 8109K ACCEPT udp -- enp3s0 * 0.0.0.0/0 0.0.0.0/0 udp dpts:1024:65535 state RELATED,ESTABLISHED
    13486 27M ACCEPT tcp -- enp3s0 * 0.0.0.0/0 0.0.0.0/0 tcp dpts:1024:65535 state RELATED,ESTABLISHED


    I erased my real IP in a few places. 192.168.10.124 is the IP of my NAS

    Can't find anything interesting in "netstat -nlp" :(
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, June 02 2018, 01:02 PM - #Permalink
    Resolved
    0 votes
    miniupnpd may have been updated in the last couple of days to v2.1-3 (it should have been pushed on Thursday). A big change was made upstream to the firewalling and I've missed one change they made. The net result is that stopping miniupnpd does not clean the firewall rules. Please can you make the following change to /usr/lib/systemd/system/miniupnpd.service:

    Add the line:
    ExecStopPost=-/etc/miniupnpd/iptables_removeall.sh
    to the end of the [Service] section so it reads:
    [Service]
    Type=forking
    ExecStartPre=-/etc/miniupnpd/iptables_init.sh
    ExecStartPre=-/etc/miniupnpd/init_clearos.sh
    ExecStart=/usr/sbin/miniupnpd -f /etc/miniupnpd/miniupnpd.conf $MINIUPNPD_START_OPTIONS
    ExecStartPost=-/usr/bin/systemctl unset-environment MINIUPNPD_START_OPTIONS
    ExecStopPost=-/etc/miniupnpd/iptables_removeall.sh
    Then run the command:
    systemctl daemon-reload
    Now stopping miniupnpd will clear the firewall rules.

    Alternatively, I've just pushed an updated build into the test repos and it should be sync'ing in the next couple of hours. Once sync'd, you should be able to install it with:
    yum update miniupnpd --enable-repo=clearos-contribs-testing
    and you should pull down version 2.1-4.

    Miniupnpd maintains a state file in /var/lib/miniupnpd/upnp.leases but it does not start clearing it down until you reach the number of leases in clean_ruleset_threshold in /etc/miniupnpd/miniupnpd.conf. Any lines in the lease file automatically get re-added to the firewall when miniupnpd starts. You can reduce the parameter value, or, with miniupnpd stopped, just clear down the lease file.
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, June 02 2018, 07:35 AM - #Permalink
    Resolved
    0 votes
    Can you give the output of:
    iptables -nvL
    iptables -nvL INPUT
    If there weren't too many of them, miniupnpd remembers the last ports forwarded and every time it restarts, it re-activates the port forwards. Also what version of ClearOS are you running?
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, June 02 2018, 03:24 AM - #Permalink
    Resolved
    0 votes
    Use "netstat -nlp" on your ClearOS system to see what is listening on those ports...
    Anything of interest in your logs...
    The reply is currently minimized Show
Your Reply