Hi guys!
Recently I scanned my ClearOS router for open ports and discovered many of them being open. Below is the corresponding output:
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.
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
SFs,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.
Share this post:
Responses (12)
-
Accepted Answer
-
Accepted Answer
-
Accepted Answer
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:
to the end of the [Service] section so it reads:ExecStopPost=-/etc/miniupnpd/iptables_removeall.sh
Then run the command:[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
Now stopping miniupnpd will clear the firewall rules.systemctl daemon-reload
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:
and you should pull down version 2.1-4.yum update miniupnpd --enable-repo=clearos-contribs-testing
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. -
Accepted Answer
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
. At the end, removed /var/lib/miniupnpd/upnp.leases.systemctl daemon-reload
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" -
Accepted Answer
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. -
Accepted Answer
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. -
Accepted Answer
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) -
Accepted Answer
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? -
Accepted Answer
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. -
Accepted Answer
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? -
Accepted Answer
Please login to post a reply
You will need to be logged in to be able to post a reply. Login using the form on the right or register an account if you are new here.
Register Here »