Kali Purple Greenbone Setup
-
How do I create a rule to allow port 873 (RSYNC) from and external site (Greenbone) to a single host (Kali Purple) on the LAN?
-
You do not need any rules on your LAN providing you have not deleted the default pfSense rules that were there when you installed out-of-the-box. The default pfSense LAN rules allow any LAN host to initiate outbound traffic to the Internet. In return, the stateful inspection logic of the firewall will allow the return traffic for that connection. In pfSense, rules go on the interface the traffic is entering from. So, for LAN hosts communicating outside the rules go on the LAN. But for WAN hosts needing to talk to something on your LAN, the rule would go on the WAN interface.
However, some setups will require that the firewall accept an unsolicited inbound connection on the WAN. That's what your Rsync is going to need. For that you would configure an appropriate port forward. This thread from 2021 has some info: https://forum.netgate.com/topic/164623/rsync-issue-cant-do-a-rsync-to-a-external-nas. The third post in that thread has your likely answer.
Be aware that opening such a pinhole in your firewall is generally not a good idea. Any non-encrypted open port on your WAN is sure to be discovered and abused. If at all possible, lock down that WAN rule so that only a single IP address, or a tiny handful of addresses, are allowed to start an unsolicited inbound connection.
-
@bmeeks Thank you for the response, I created the NAT rule per the link you provided and still not able to get to the site..
I can however, run the port test and it works successfully. The idea is to have port 873 open to only 1 device (Kali Purple Host) on the LAN.Now I could have made the NAT policy incorrectly because I only understand the basics of NAT not really how it affects traffic other than providing address translation.
Here is the results of a port test I ran in diagnostics. Even if I leave the source port blank it is successful.
However, when I try to run traceroute the traffic doesn't leave the firewall.
┌──(purple㉿kali-purple)-[~] └─$ sudo traceroute -T -O info 45.135.106.143 -p 873 traceroute to 45.135.106.143 (45.135.106.143), 30 hops max, 60 byte packets 1 * * * 2 * * * 3 * * *If I try to run the greenbone feed update it fails to connect to the rsync:
└─$ sudo greenbone-feed-sync --type nvt Running as root. Switching to user '_gvm' and group '_gvm'. Trying to acquire lock on /var/lib/openvas/feed-update.lock Acquired lock on /var/lib/openvas/feed-update.lock ⠦ Downloading Notus files from rsync://feed.community.greenbone.net/community/vulnerability-feed/22.04/vt-data/notus/ to /var/lib/notus rsync: [Receiver] failed to connect to feed.community.greenbone.net (45.135.106.143): Connection timed out (110) rsync: [Receiver] failed to connect to feed.community.greenbone.net (2a0e:6b40:20:106:20c:29ff:fe7f:d2ae): Network is unreachable (101) rsync error: error in socket IO (code 10) at clientserver.c(139) [Receiver=3.2.7]I see in the logs the default deny policy rule is denying the traffic.
I'm just not sure how to allow the traffic through to the single host from outside.
Thoughts?
-
What rules do you have on your LAN? You should not have changed anything there from the pfSense defaults. Post a picture of your LAN rules.
That firewall log snippet you posted clearly shows your LAN's default DENY rule is blocking the traffic. That default rule should really never be hit in most scenarios.
The default pfSense LAN rules configuration has only two rules. One allows connection to ports 80 and 443 on the firewall from any IP and any port for admin. The other allows any IP from any port to go anywhere (meaning usually to the Internet through the WAN).
Have you read the official documentation from here: https://docs.netgate.com/pfsense/en/latest/firewall/index.html?
And here is a link to the official documentation that shows the default rules for WAN and LAN out of the box: https://docs.netgate.com/pfsense/en/latest/firewall/rule-list-intro.html#introduction-to-the-firewall-rules-screen. Your LAN rules should initially look like these until you get things working. Then you can tighten things up if desired.
Your
tracerttraffic is never even getting past your LAN probably due to your rules defined there. -
@bmeeks Thanks for the response again. I did notice something which is weird... When I create the NAT rule using Alias's the traceroute to the port fails. However, when I create the NAT rule using numbers for IP and ports the Traceroute works.
Here is the LAN Rules: Hope it's ok to list these here...
-
@Technolust said in Kali Purple Greenbone Setup:
When I create the NAT rule using Alias's the traceroute to the port fails
That's an indication that DNS resolution is failing for that Alias. Go to DIAGNOSTICS > TABLES, find that alias table, and see if it shows the correctly resolved IP address for the SOC host. If that is not correct, then the alias will not work when used in a firewall rule because the IP address is wrong (or likely empty).
When you hover your mouse over the "SOC" alias entry on the LAN firewall rules tab, does a tooltip window pop up showing the correct IP address?
-
@bmeeks That was it, I had the fist octet wrong in the SOC host. I didn't know about the TABLES... However, did my Rules Table look ok? Now I'm able to use Alias's and traceroute works but when i actually try to run the rsync fetch on the SOC host itself it still fails..
─$ sudo greenbone-feed-sync Running as root. Switching to user '_gvm' and group '_gvm'. Trying to acquire lock on /var/lib/openvas/feed-update.lock Acquired lock on /var/lib/openvas/feed-update.lock ⠋ Downloading Notus files from rsync://feed.community.greenbone.net/community/vulnerability-feed/22.04/vt-data/notus/ to /var/lib/notus rsync: [Receiver] failed to connect to feed.community.greenbone.net (45.135.106.143): Connection refused (111) rsync: [Receiver] failed to connect to feed.community.greenbone.net (2a0e:6b40:20:106:20c:29ff:fe7f:d2ae): Network is unreachable (101) rsync error: error in socket IO (code 10) at clientserver.c(139) [Receiver=3.2.7] ⠋ Downloading NASL files from rsync://feed.community.greenbone.net/community/vulnerability-feed/22.04/vt-data/nasl/ to /var/lib/openvas/plugins rsync: [Receiver] failed to connect to feed.community.greenbone.net (45.135.106.143): Connection refused (111) rsync: [Receiver] failed to connect to feed.community.greenbone.net (2a0e:6b40:20:106:20c:29ff:fe7f:d2ae): Network is unreachable (101) rsync error: error in socket IO (code 10) at clientserver.c(139) [Receiver=3.2.7] Releasing lock on /var/lib/openvas/feed-update.lock Trying to acquire lock on /var/lib/gvm/feed-update.lock Acquired lock on /var/lib/gvm/feed-update.lock ⠋ Downloading SCAP data from rsync://feed.community.greenbone.net/community/vulnerability-feed/22.04/scap-data/ to /var/lib/gvm/scap-data rsync: [Receiver] failed to connect to feed.community.greenbone.net (45.135.106.143): Connection refused (111) rsync: [Receiver] failed to connect to feed.community.greenbone.net (2a0e:6b40:20:106:20c:29ff:fe7f:d2ae): Network is unreachable (101) rsync error: error in socket IO (code 10) at clientserver.c(139) [Receiver=3.2.7] ⠋ Downloading CERT-Bund data from rsync://feed.community.greenbone.net/community/vulnerability-feed/22.04/cert-data/ to /var/lib/gvm/cert-data rsync: [Receiver] failed to connect to feed.community.greenbone.net (45.135.106.143): Connection refused (111) rsync: [Receiver] failed to connect to feed.community.greenbone.net (2a0e:6b40:20:106:20c:29ff:fe7f:d2ae): Network is unreachable (101) rsync error: error in socket IO (code 10) at clientserver.c(139) [Receiver=3.2.7] ⠋ Downloading gvmd data from rsync://feed.community.greenbone.net/community/data-feed/22.04/ to /var/lib/gvm/data-objects/gvmd/22.04 rsync: [Receiver] failed to connect to feed.community.greenbone.net (45.135.106.143): Connection refused (111) rsync: [Receiver] failed to connect to feed.community.greenbone.net (2a0e:6b40:20:106:20c:29ff:fe7f:d2ae): Network is unreachable (101) rsync error: error in socket IO (code 10) at clientserver.c(139) [Receiver=3.2.7] Releasing lock on /var/lib/gvm/feed-update.lockHere is the successful tracetroute with the new NAT rule.
└─$ sudo traceroute -T -O info 45.135.106.143 -p 873 traceroute to 45.135.106.143 (45.135.106.143), 30 hops max, 60 byte packets 1 45.135.106.143 (45.135.106.143) 0.340 ms 0.307 ms 0.292 ms 2 45.135.106.143 (45.135.106.143) <rst,ack> 0.488 ms 0.475 ms 0.503 ms -
@bmeeks I do see this in the states table:
-
@Technolust said in Kali Purple Greenbone Setup:
rsync: [Receiver] failed to connect to feed.community.greenbone.net (45.135.106.143): Connection refused (111)
rsync: [Receiver] failed to connect to feed.community.greenbone.net (2a0e:6b40:20:106:20c:29ff:fe7f:d2ae): Network is unreachable (101)Looking at your screen shot of the connection attempt, it appears the remote end refused your connection. Look at these lines from your connection log:
rsync: [Receiver] failed to connect to feed.community.greenbone.net (45.135.106.143): Connection refused (111) rsync: [Receiver] failed to connect to feed.community.greenbone.net (2a0e:6b40:20:106:20c:29ff:fe7f:d2ae): Network is unreachable (101)I assume that 45.135.106.143 is the remote host you are trying to
rsyncwith. That host refused your connection attempt. That could mean wrong password/user ID or it is blocking your ISP's IP address range. Your box first tried an IPv4 connection, and when that failed it tried to switch over to IPv6. That appears to not be configured on your firewall, so that connection attempt also failed.As for your rules, they are okay, but I think a bit needlessly restrictive. You can very well find yourself troubleshooting "issues" frequently due to the restrictive rules. For home networks, it's generally better to just open them up for outbound traffic. If you have host devices on your LAN that you don't trust so much, then move those to their own VLAN and restrict their access there.
-
@Technolust said in Kali Purple Greenbone Setup:
@bmeeks I do see this in the states table:
That's the normal state created by stateful inspection in the firewall. It shows your local host's attempt to establish a connection to the remote IP (45.135.106.143), so it will remember that destination IP and let any return packets from that remote host back in through your WAN. But in your case the packets seem to have gotten to the remote host, but the remote host said "I don't want to talk to you!". That's what the "connection refused" reply means.
-
@bmeeks said in Kali Purple Greenbone Setup:
As for your rules, they are okay, but I think a bit needlessly restrictive. You can very well find yourself troubleshooting "issues" frequently due to the restrictive rules. For home networks, it's generally better to just open them up for outbound traffic. If you have host devices on your LAN that you don't trust so much, then move those to their own VLAN and restrict their access there.
Thanks again for your help.. I'm fairly new to Pfsense and firewalling in general. It's the reason I built one; to learn... However, I don't fully know how to accomplish "open up for outbound traffic." I have been taught (right or wrong) "deny all explicitly allow."
It's not so much that I don't trust devices on my network, it the outside world I don't trust coming into the network. I have run into weird issues especially like this I try to reslove. It def takes a lot of time though.
-
@Technolust said in Kali Purple Greenbone Setup:
It's not so much that I don't trust devices on my network, it the outside world I don't trust coming into the network.
Just to be clear that you understand -- it's the WAN rules that determine what comes into your network, not so much the LAN rules.
The LAN rules limit what your internal hosts can initiate to outside connections. And that is where overly restrictive rules can be a pain. Lots of applications do different things with various ports and destination IPs, and if you don't account for that in your LAN rules, then some things in an application may not work. For example, the app may execute but not be able to fetch critical updates if execution uses one set of ports and IP addresses but updates use something different.
The default WAN setup on pfSense when you install it (and before you change anything) is for all unsolicited inbound traffic to be dropped. That means nothing external can connect to your firewall at all. The only way traffic can come in is if there is a state table entry created by first an internal host initiating the connection to the remote host.
-
One other point, since you said you are new to firewall administration.
Your NAT Port Forward rule is designed to let an external host initiate an unsolicited connection. Because the source Address for your Port Forward is "*", any host on the Internet can start an
rsyncconnection to your internal Greebone host because that NAT forward rule will forward all unbound TCP port 873 requests straight on to the 10.69.0.221 host on your LAN. That may not be what you want. You might want to limit the Source Address for the NAT Port Forward to only certain addresses or netblocks. -
@bmeeks Thank you for this wealth of information. I did understand that the WAN rules allow what is coming in. I just didn't know if the LAN rules set by the firewall allowed all the traffic to be denied unless I create rules or everything is allowed until I create the rules.. For whatever reason this is a mental block in my head I need to figure out in my own way (so to speak)...
With the initial pfSense install (change nothing on the WAN) and allow all on the LAN, wouldn't this be initiating unsolicited traffic? This is the other major confusion I've yet to figure out in my brain...
-
@Technolust said in Kali Purple Greenbone Setup:
With the initial pfSense install (change nothing on the WAN) and allow all on the LAN, wouldn't this be initiating unsolicited traffic? This is the other major confusion I've yet to figure out in my brain...
It allows only your LAN hosts to initiate outbound traffic. LAN rules have nothing at all to do with what the WAN allows in (neglecting stateful replies for the moment).
Unsolicited inbound traffic is usually accepted to mean any random host out on the Internet can open a connection to your firewall and be accepted WITHOUT having an internal host (on the LAN) first ask for the connection.
Using your
rsyncport forward rule as an example, it currently allows anybody on the Internet to attempt a connection with your internal LANrsynchost (your SOC host). If you did not have that inbound Port Forward rule, then the only timersyncwill work is when your internal SOC host first asks the external box to sync. The external box then replies to that request and the WAN stateful inspection rule would let that reply come back to your LAN host. But otherwise, without the Port Forward rule, the 873rsyncport would be closed to external connection attempts.I thought you wanted a situation where that external host was the one that opened the
rsyncconnection. If that's not true, then you do not need the NAT Port Forward rule. Your original problem was the mistyped IP octet. I initially misread your post as saying you wanted the external host to initiate thersyncjob. -
@bmeeks I did end up changing the RSYNC port to only allow the grennbone ip address and the host on my network. I submitted a request on the greenbone forum to see why the feed community is blocking my host's request.
-
@bmeeks said in Kali Purple Greenbone Setup:
If you did not have that inbound Port Forward rule, then the only time rsync will work is when your internal SOC host first asks the external box to sync. The external box then replies to that request and the WAN stateful inspection rule would let that reply come back to your LAN host.
Now that I have this rule, it means the external box can initiate the RSYNC traffic? If want to only allow the SOC to initiate the traffic then once I initiate the traffic from the host, the external can communicate back without any LAN or WAN rules?
That is correct, I'm looking for the SOC host to initiate the traffic only and not allow the external box to initiate the traffic.
I'll test by disabling the NAT rule.
-
@Technolust said in Kali Purple Greenbone Setup:
Now that I have this rule, it means the external box can initiate the RSYNC traffic? If want to only allow the SOC to initiate the traffic then once I initiate the traffic from the host, the external can communicate back without any LAN or WAN rules?
Yes, the above is correct with one caveat. Because you have chosen to be somewhat restrictive with your LAN rules with regards to where you allow internal hosts to connect, then without your SOC rule on the LAN allowing that host to communicate with the external Greenbone IP, then your internal host could never communicate with Greenbone at all.
But having that LAN rule has nothing to do with whether or not the Greenbone external host can start an unsolicited converstation with you. For controlling that end, you put rules on the WAN. Hence the original Port Forward rule.
The out-of-the-box LAN rules for pfSense let LAN hosts (meaning boxes on your internal network) communicate anywhere they wish without restriction. But that does NOT mean anywhere outside can just start its own unsolicited conversation. WAN rules determine if that is allowed, and the default WAN rule is "deny all inbound". That means deny all traffic that is not a "stateful reply" to a session already established by a LAN host.
Perhaps you need to read up on and understand how stateful inspection firewalls work. Here are some tutorials:
From Fortinet: https://www.fortinet.com/resources/cyberglossary/stateful-firewall
This link differentiates between the three firewall types available: https://www.router-switch.com/faq/differences-between-packet-firewall-stateful-firewall-and-applicatio-firewall.html.
Note that almost nobody uses a simple packet filtering firewall these days (meaning one without stateful inspection replies).
-
@bmeeks Now it makes sense... However, I still don't know why I needed the NAT rule. I think I could have got away with creating a single LAN rule to allow the traffic from the SOC host now that I fixed the fist octet (like you mentioned earlier). I'm going to try this when I get home.
I need to buy you a round or two of icy tasty bevy's for all of your knowledge and assistance!! Hopefully someone else will read this thread and learn as I have!!
Can't thank you enough!
-
@Technolust said in Kali Purple Greenbone Setup:
However, I still don't know why I needed the NAT rule.
Because I initially thought you wanted either the external host OR your internal host to be able to start an
rsyncsession. The only way the external host could ever start a session is with the NAT Port Forward. The external host can "respond" to a session initiated by your internal host all day long due to stateful replies being allowed. But the external host can't just start a session on his own anytime he wishes UNLESS there is a NAT Port Forward rule in place on the WAN.But if you only wanted just the internal host to start all sessions, then the NAT Port Forward was not required.
Stateful inspection replies will always automatically be allowed by the firewall. But these "states" have a timeout, and after that timeout expires any traffic coming from the external host is again dropped. States are also automatically cleaned up and closed when the established session is closed. The timeout only comes into play when the connection is just interrrupted without the two sides properly saying "goodbye" to each other.
