Kali Purple Greenbone Setup
-
@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.
-
@bmeeks said in Kali Purple Greenbone Setup:
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.
@bmeeks said in Kali Purple Greenbone Setup:
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.
There's the ahhh haaa moment!! I have saved this entire comment in my notes!!
-
@Technolust:
There are settings in the SYSTEM > ADVANCED > Firewall and NAT menu that let you customize the stateful reply timeout value. Normally this should be left at the default. But there may some older app or software on some IoT device that needs a longer state timeout. Luckily these days that is very rare.You can always see the active states on the firewall under DIAGNOSTICS. There are a few menu choices there for viewing and/or clearing the state table.
Most states are closed automatically as part of the TCP session teardown. The only time this might not happen is if one side of the conversation just disappears and never sends any further traffic. That will result in the state eventually timing out and being closed. As long as the two sides of the session continue to send packets to each other, the state will remain "open".
One more thing, just to be clear. States apply specifically to just the two IP addresses that caused them to open. Just because there is a stateful reply session in place for
rsyncconnections, that does not mean any other IP can hop onto or hijack the session. It is locked to just the two specific hosts (your internal LAN host and the specific external host IP your internal host started the converstation with). -
@Technolust are you running squid proxy?
Greenbone is the application with the dinosaur 🦖 we used that in cyber security class.
-
@JonathanLee no I haven’t setup squid proxy yet. Something I’m looking to do but I don’t know enough about it. Gotta figure out Kali Purple…
Yeah Greenbone (dinosaur) is the application I’m trying to configure. It’s one of the first tools to setup in Kali Purple.
