Outbound TCP and UDP suggestion for block list.
-
I'm creating an alias of ports, TCP and UDP, with all ports that should never go to the Internet.
I'm doing this because I found one laptop trying to reach an IP, that was in a blacklist, on UDP port 137.
Some could say, allow just what you need, this would be a good approach but not for this network that has a lot of apps that uses high ports and they are so random..
TCP ports:
20 FTP command control
21 FTP transfer data
22 TELNET
23 SSH
25 SMTP
110 POP3
135 MS RPC
137 Name service
138 Datagram distribution service
139 Session service
389 LDAP
445 SMB
8080 Alternative port for HTTP traffic
3389 RDPUDP ports:
69 Trivial File Transfer Protocol (TFTP) UDP
135 MS RPC
137 Name service
138 Datagram distribution service
514 SYSLOG
389 LDAP
3389 RDPAny thoughts about the list above, or any other suggestions ?
Thanks. -
@mcury said in Outbound TCP and UDP suggestion for block list.:
8080 Alternative port for HTTP traffic
If you allow the webports, you could allow this one too. I think speedtest.net will not run without this port if I remember correct.
-
-
@mcury said in Outbound TCP and UDP suggestion for block list.:
Any thoughts about the list above
you have your telnet and ssh reversed ;)
many of those ports don't work across the public internet anyway - 135-139 are block by many an isp, and 445 almost everywhere. My isp doesn't allow 25 outbound as another example.
I ssh to stuff on the internet all the time, sure not going to block that.. And yeah ftp now and then..
You might be better off just logging the traffic for a bit to see if your using any of it, but nothing wrong with blocking unwanted ports - I personally don't do it.. But hey more power too ya.
-
Nice, lots of good stuff here, thanks !!
@johnpoz the laptop I mentioned got some malware and I found some kind of DNS poisoning.. I'm positively sure it isn't miss configuration or something else.
ipconfig /displaydns and wireshark pointed that out.
Weird thing is that hosts.txt was empty, still don't know where this thing came from.It was a Windows machine, so ran the Windows Defender full scan and also offline scan, database updated, nothing found.
I'm now formatting and will perform a clean Windows installation.
If it wasn't for my pfBlockerNG blocklist, it would probably reach some server on UDP 137 and consequently on TCP 445 (SMB).
Also, it is not just outbound connections from that same IP I can see, I see unbound on port 80, surely being blocked by the firewall.After installation, I'll nuke Netbios from everything, it is not in use and I'll tune this outbound filter.. Here, we don't use FTP or SSH to the Internet, so that won't be a problem for us..
Edit: I'm logging everything
@Bob-Dig said in Outbound TCP and UDP suggestion for block list.:
If you allow the webports, you could allow this one too. I think speedtest.net will not run without this port if I remember correct.
Oh, speed test I'll probably allow for one computer only, mine.
@tinfoilmatt said in Outbound TCP and UDP suggestion for block list.:
Helpful documentation on the subject of egress/outbound filtering.
Nice read!! So, what I'm doing is indeed a good practice.
-
@mcury said in Outbound TCP and UDP suggestion for block list.:
what I'm doing is indeed a good practice.
For an enterprise or work place it is done all the time.. In my home on my secure network its a hassle for really zero benefit.
The only rule I have blocking outbound is rfc1918.. because I am a good netizen, and zero point for throwing noise out on the net.. My laptop loves to look for work IPs when its disconnected from the vpn, and those rfc1918 are not on my home network - so they would get routed out to the internet and go nowhere ;)
Oh and I block going to dot and doh IPs - I hate apps that or devices that think its ok for them to bypass my local filtering dns.
-
@johnpoz said in Outbound TCP and UDP suggestion for block list.:
Oh and I block going to dot and doh IPs - I hate apps that or devices that think its ok for them to bypass my local filtering dns.
Hopefully you're forwarding to your stub resolver and otherwise filtering all outbound UDP/53 and TCP/853 to account for any external resolvers not on your blocklists. One can never know what apps/devices are hardcoded to do these days...