New User to pfSense - some doubts
-
@HansSolo said in New User to pfSense - some doubts:
Whoa!
I just ran into this on my pfSense machine.
I had changed ALL those rules and then a bit later when I went back it had reset them ALL to ANY ANY.
Anyone know what's going on? Is it SUPPOSED to re-write them back to ANY ANY ????Again, Click on the Blue Infoblock Icon for the "Action" setting, and its all detail there.
"Auto type" rules are always controlled by the Package and the settings that you configured. Every cron run will move the rules as per the defined settings that you configured in the package.
If you want to manually create your own Firewall Rules and use a pfBlockerNG IP Aliastable, select any of the "Alias" type Action settings. Be sure to prefix the Firewall rule description with "pfb_" so that the Alerts tab and the Widget find these rules accordingly. -
@johnpoz said in New User to pfSense - some doubts:
Yeah this is a HORRIBLE implementation... Just freaking HORRIBLE!!
That should be limited to wan address on specific PORTS, unless the user changes it... Then that would be on them.. But I can see how new users might just open wide their wan... Arrrgghhh!!
Or anything behind pfsense if they had a routed netblock, etc. etc.
paging @BBcan177 again, I don't see how such a thing would be ok... Ultimately its on the admin of the firewall to understand what they are doing, and what is set... But pfsense does try and keep the users from shooting themselves in the foot.. This is not doing that at all..Anyone is more than welcome to create a PR, I am obviously not capable.
-
An ANY rule is horrible dude... You open up all services listening on the wan to the the internet, or atleast the sources they pick from the list, like North America. In the case of ipv6 or a routed subnet the whole network behind pfsense even.
If your going to do an allow for sources it needs to be limited to the ports they have forwarded.
At min there needs to be a HUGE warning... I mean HUGE these users love to shoot themselves in the foot.. If not their heads..
Blocking specific sources before the port forwards is fine with an any dest.. But an allow with any as destination is disaster waiting to happen.. User doesn't change their default admin password, and now their gui is exposed is low on the list, if routed or ipv6 it exposes everything.. This really needs to be addressed!!!!
edit: A safer approach would be for pfblocker not to create any rules on the wan, let the user just use the aliases pfblocker creates in their own rules and or port forwards.. If you want to create the rule on the lan to block access out to back stuff, or ads that fine... But creating a rule on the wan that can open up the whole network is not worth the risk, even if the user confirms they understand the implications... Which they prob don't in many cases.
-
Decided to check the original file I downloaded
SHA256 (pfSense-CE-2.4.4-RELEASE-p1-amd64.iso.gz) = a5ca11eab11e2cddc33a11ded4df69eab7ae48399004588562f5f305ae3c0246
C:\Users\HansSolo\Downloads>certutil -hashfile pfSense-CE-2.4.4-RELEASE-p1-amd64.iso.gz MD5
MD5 hash of pfSense-CE-2.4.4-RELEASE-p1-amd64.iso.gz:
e7f248f20c24a190641f1d2577aab0d7
CertUtil: -hashfile command completed successfully.Houston, we have a problem? (other than me being stupid too early in the AM)
-
comment on what?
you can not compare a 256 sha hash and md5 hash = no shit they will not match ;)
-
@johnpoz said in New User to pfSense - some doubts:
comment on what?
you can not compare a 256 sha hash and md5 hash = no shit they will not match ;)
lol
yeah....maybe a cup of coffee and wake up before I try this crap
thanks -
heheh - they match ;)
-
Yeah,
when I go total stupid...I do it right hahaMuch better!
Your way is even 'MORE gooder' :-)C:\Users\HansSolo\Downloads>certutil -hashfile pfSense-CE-2.4.4-RELEASE-p1-amd64.iso.gz SHA256
SHA256 hash of pfSense-CE-2.4.4-RELEASE-p1-amd64.iso.gz:
a5ca11eab11e2cddc33a11ded4df69eab7ae48399004588562f5f305ae3c0246
CertUtil: -hashfile command completed successfully. -
So, I'm on what?....day 5 or 6 with pfsense now.
Some doubts have been eliminated. Some new ones surfaced.But at this point it's working and doing the job I need done (albeit a bit more tedious than with other hardware firewalls).
Considering the current pricing for the Community Version, it's a hands down Winner.
My only two complaints at this point would be the difficulty in blocking Outbound traffic and the lack of native auto-blocking.....such as for port probes or other potentially nefarious activity.
Oh, and I need to find a way to at least see some blinking lights that represent active traffic across the Interfaces.
I see no reason this could not have been done on the Console and viewed onscreen same as with pftop etc.
I don't like the options of adding additional cards just to get blinking activity LEDsSomething as simple as this would be terrific ....Maybe I'll write something like this in C++ for my own use.
Heck, it could probably be written in BASIC for that matter.
-
@HansSolo said in New User to pfSense - some doubts:
My only two complaints at this point would be the difficulty in blocking Outbound traffic
What it takes like 2 freaking seconds to block anything you need to block outbound - like .2 seconds.
native auto-blocking.....such as for port probes or other potentially nefarious activity.
What? Dude out of the box all inbound unsolicited traffic is dropped anyway.. So your worried that you have port 80 forwarded, and you want to block IP xyz that starts checking ports at 1 and moves up 2,3,4 before he gets to your 80.. That doesn't stop just bot that hits you direct 80 without other ports being checked first... Its NONSENSE smoke and mirror security magic that does nothing.. Your service you open to the public is either secure or its not, trying to "hide" is not security!!
I don't like the options of adding additional cards just to get blinking activity LEDs
Again WHAT??
-
@johnpoz said in New User to pfSense - some doubts:
I don't like the options of adding additional cards just to get blinking activity LEDs
Again WHAT??
I'm thinking he's looking for visual confirmation that his firewall is actually working and moving traffic.
Jeff
-
Doesn't seem like a terrible idea to me. I have no idea what it would take to implement that at the console though.
Open a new feature request at https://redmine.pfsense.org/Steve
-
@akuma1x said in New User to pfSense - some doubts:
I'm thinking he's looking for visual confirmation that his firewall is actually working and moving traffic.
your on the console - hit #9 (pftop)
Can you not just use the BlinkLED package? If you want something to be blinking at you ;)
-
@HansSolo said in New User to pfSense - some doubts:
My only two complaints at this point would be the difficulty in blocking Outbound traffic and the lack of native auto-blocking.....such as for port probes or other potentially nefarious activity.
Outbound traffic is managed just as easily as inbound. You can even copy rules and change one drop-down to apply that rule to outbound traffic.
If you want pfSense to respond to malicious or suspicious activity, it's really easy to do. Download Snort to start with. If you're anything like me, your pfSense installation will block your computer from the entire network when you start testing to see if Snort works. And then you'll have to go over to another computer to get Snort to unblock your testing computer. I had Snort block every device on the network once. With great power comes great responsibility. Works great, just don't set it too aggressively to begin with.
Oh, and I need to find a way to at least see some blinking lights that represent active traffic across the Interfaces.
I see no reason this could not have been done on the Console and viewed onscreen same as with pftop etc.
I don't like the options of adding additional cards just to get blinking activity LEDsWhat about the bandwidth graphs? I use those all the time to monitor traffic. It's usually "good enough". There are other ways to check on traffic activity down to the port if need be.
-
@tim-mcmanus said in New User to pfSense - some doubts:
@HansSolo said in New User to pfSense - some doubts:
My only two complaints at this point would be the difficulty in blocking Outbound traffic and the lack of native auto-blocking.....such as for port probes or other potentially nefarious activity.
Outbound traffic is managed just as easily as inbound. You can even copy rules and change one drop-down to apply that rule to outbound traffic.
If you want pfSense to respond to malicious or suspicious activity, it's really easy to do. Download Snort to start with. If you're anything like me, your pfSense installation will block your computer from the entire network when you start testing to see if Snort works. And then you'll have to go over to another computer to get Snort to unblock your testing computer. I had Snort block every device on the network once. With great power comes great responsibility. Works great, just don't set it too aggressively to begin with.
Oh, and I need to find a way to at least see some blinking lights that represent active traffic across the Interfaces.
I see no reason this could not have been done on the Console and viewed onscreen same as with pftop etc.
I don't like the options of adding additional cards just to get blinking activity LEDsWhat about the bandwidth graphs? I use those all the time to monitor traffic. It's usually "good enough". There are other ways to check on traffic activity down to the port if need be.
Yeah, there are "ways" to do it..but my complaint is that it shouldn't be a process.
-
@johnpoz said in New User to pfSense - some doubts:
@akuma1x said in New User to pfSense - some doubts:
I'm thinking he's looking for visual confirmation that his firewall is actually working and moving traffic.
your on the console - hit #9 (pftop)
Can you not just use the BlinkLED package? If you want something to be blinking at you ;)
Not what I'm looking for. The BlinkLED package requires an add on card. I just want to be able to look over and see Activity lights blinking when traffic is moving through the Interfaces. This could EASILY be done via the console. I may have to write my own code to do it.
JohnPoz understands
-
@HansSolo said in New User to pfSense - some doubts:
@tim-mcmanus said in New User to pfSense - some doubts:
@HansSolo said in New User to pfSense - some doubts:
My only two complaints at this point would be the difficulty in blocking Outbound traffic and the lack of native auto-blocking.....such as for port probes or other potentially nefarious activity.
Outbound traffic is managed just as easily as inbound. You can even copy rules and change one drop-down to apply that rule to outbound traffic.
If you want pfSense to respond to malicious or suspicious activity, it's really easy to do. Download Snort to start with. If you're anything like me, your pfSense installation will block your computer from the entire network when you start testing to see if Snort works. And then you'll have to go over to another computer to get Snort to unblock your testing computer. I had Snort block every device on the network once. With great power comes great responsibility. Works great, just don't set it too aggressively to begin with.
Oh, and I need to find a way to at least see some blinking lights that represent active traffic across the Interfaces.
I see no reason this could not have been done on the Console and viewed onscreen same as with pftop etc.
I don't like the options of adding additional cards just to get blinking activity LEDsWhat about the bandwidth graphs? I use those all the time to monitor traffic. It's usually "good enough". There are other ways to check on traffic activity down to the port if need be.
Yeah, there are "ways" to do it..but my complaint is that it shouldn't be a process.
Which part?
It's actually better that it is a process. You have very acute control over nearly every aspect of pfSense, and many of the packages take advantage of the extensibility of the platform to bring significant enhancements to it.
pfSense can be monitored by many different monitoring platforms that excel at generating these reports. pfSense is not a reporting tool, and it has some excellent reporting capabilities. In order for pfSense to focus on what it does best (routing, etc.) a lot of the reporting capabilities are handled by more powerful 3rd party reporting tools. I rely on pfSense's internal reports but also have everything being pushed to a syslog server where I can do event correlation and other activities with the reported data.
It's a very powerful tool, but it is not a Swiss army knife.
-
Hmm, are you saying thr actual NIC LEDs do not blink to show activity?
That is a configurable setting on many NICs but rarely actually gets changed. No way to change it in pfSense (from the GUI).
Steve
-
@johnpoz said in New User to pfSense - some doubts:
@HansSolo said in New User to pfSense - some doubts:
My only two complaints at this point would be the difficulty in blocking Outbound traffic
What it takes like 2 freaking seconds to block anything you need to block outbound - like .2 seconds.
native auto-blocking.....such as for port probes or other potentially nefarious activity.
What? Dude out of the box all inbound unsolicited traffic is dropped anyway.. So your worried that you have port 80 forwarded, and you want to block IP xyz that starts checking ports at 1 and moves up 2,3,4 before he gets to your 80.. That doesn't stop just bot that hits you direct 80 without other ports being checked first... Its NONSENSE smoke and mirror security magic that does nothing.. Your service you open to the public is either secure or its not, trying to "hide" is not security!!
I don't like the options of adding additional cards just to get blinking activity LEDs
Again WHAT??
You get so excited over new user questions.
-
@tim-mcmanus said in New User to pfSense - some doubts:
@HansSolo said in New User to pfSense - some doubts:
@tim-mcmanus said in New User to pfSense - some doubts:
@HansSolo said in New User to pfSense - some doubts:
My only two complaints at this point would be the difficulty in blocking Outbound traffic and the lack of native auto-blocking.....such as for port probes or other potentially nefarious activity.
Outbound traffic is managed just as easily as inbound. You can even copy rules and change one drop-down to apply that rule to outbound traffic.
If you want pfSense to respond to malicious or suspicious activity, it's really easy to do. Download Snort to start with. If you're anything like me, your pfSense installation will block your computer from the entire network when you start testing to see if Snort works. And then you'll have to go over to another computer to get Snort to unblock your testing computer. I had Snort block every device on the network once. With great power comes great responsibility. Works great, just don't set it too aggressively to begin with.
Oh, and I need to find a way to at least see some blinking lights that represent active traffic across the Interfaces.
I see no reason this could not have been done on the Console and viewed onscreen same as with pftop etc.
I don't like the options of adding additional cards just to get blinking activity LEDsWhat about the bandwidth graphs? I use those all the time to monitor traffic. It's usually "good enough". There are other ways to check on traffic activity down to the port if need be.
Yeah, there are "ways" to do it..but my complaint is that it shouldn't be a process.
Which part?
It's actually better that it is a process. You have very acute control over nearly every aspect of pfSense, and many of the packages take advantage of the extensibility of the platform to bring significant enhancements to it.
pfSense can be monitored by many different monitoring platforms that excel at generating these reports. pfSense is not a reporting tool, and it has some excellent reporting capabilities. In order for pfSense to focus on what it does best (routing, etc.) a lot of the reporting capabilities are handled by more powerful 3rd party reporting tools. I rely on pfSense's internal reports but also have everything being pushed to a syslog server where I can do event correlation and other activities with the reported data.
It's a very powerful tool, but it is not a Swiss army knife.
Some of my comments are predicated on the fact that I've used certain other firewalls for so long and have grown accustomed to certain things and therefor naturally "expect" them in other firewalls whether a valid expectation or not.
As time passes and I get more learned with pfSense I'm sure some of the things I ask now will clear themselves up.
