[PacketFence-devel] ANN: PacketFence 5.3.0

[Louis Munro]

ANNOUNCING: PacketFence 5.3.0

The Inverse team is pleased to announce the immediate availability of PacketFence 5.3.0. This is a major release with new features, enhancements and important bug fixes. This release is considered ready for production use and upgrading from previous versions is strongly advised.

What is PacketFence ?

PacketFence is a fully supported, trusted, Free and Open Source Network Access Control (NAC) solution. Boasting an impressive feature set, PacketFence can be used to effectively secure small to very large heterogeneous networks.

Among the features provided by PacketFence, there are:

• powerful BYOD (Bring Your Own Device) capabilities
• state-of-the art devices fingerprinting with Fingerbank
• multiple enforcement methods including Role-Based Access Control (RBAC) and hotspot-style
• compliance checks for endpoints present on your network
• integration with various vulnerability scanners, intrusion detection solutions, security agents and firewalls
• bandwidth accounting for all devices

A complete overview of the solution is available from the official website: http://www.packetfence.org/about/overview.html

Changes Since Previous Release

New Features

• Support for Single Sign-On integration with the iboss platform
• Support for web authentication for NATed clients
• Support for MAC Authentication and 802.1x for Alcatel-Lucent switches
• Support for the IBM StackSwitch G8052 switch

Enhancements

• New Powershell scripts to allow unregistering nodes for disabled accounts on Active Directory
• Force a JSON response if the Accept header is set to 'application/json'
• Fingerbank processing in pfdhcplistener is now asyncronous using the webservices
• Integration of pfconfig commands in bin/pfcmd
• Added web form registration to Ruckus Controllers
• Improved database maintenance script to prevent prolonged locking of tables
• Active/Active mode will now send gratuitous ARPs to update routers when changing master node

Bug Fixes

• Fixed multiple XSS vulnerabilities in the administration GUI
• Fixed incorrect RADIUS realm detection when using windows computer authentication
• Fixed an issue with pfdns returning the wrong IP when using active/active mode
• Fixed an issue on Debian and Ubuntu where the GUI could not change some field values
• Fixed incorrect graphite document root on Ubuntu
• Fixed SMS bug where the list of carriers could be accidentally deleted

See https://github.com/inverse-inc/packetfence/commits/packetfence-5.3.0 for the complete change log.

See the UPGRADE file for notes about upgrading: https://github.com/inverse-inc/packetfence/tree/packetfence-5.3.0/UPGRADE.asciidoc

Getting PacketFence

PacketFence is free software and is distributed under the GNU GPL. As such, you are free to download and try it by either getting the new release or by getting the sources: http://www.packetfence.org/development/sourcecode.html

Documentation about the installation and configuration of PacketFence is also available: http://www.packetfence.org/documentation/

How Can I Help ?

PacketFence is a collaborative effort in order to create the best Free and Open Source NAC solution. There are multiple ways you can contribute to the project:

• Documentation reviews, enhancements and translations
• Feature requests or by sharing your ideas
• Participate in the discussion on mailing lists (http://www.packetfence.org/support/community.html)
• Patches for bugs or enhancements
• Provide new translations of remediation pages

Getting Support

For any questions, do not hesitate to contact us by writing to ***@inverse.ca

You can also fill our online form (http://www.inverse.ca/#contact) and a representative from Inverse will contact you.

Inverse offers professional services to organizations willing to secure their wired and wireless networks with the PacketFence solution.


--
Louis Munro
***@inverse.ca :: www.inverse.ca
+1.514.447.4918 x125 :: [phone] x125
Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org)

[Boris Epstein]

Hi Louis,

Thanks, installed it, playing with it.

Looks good - unfortunately, it looks like the RADIUS IP tracking fix which
I have tested and which seems to work didn't make it.

See:
https://github.com/borepstein/packetfence

Also, do you know if there has been any work on detecting when nodes go
off-line and marking them as inactive?

Cheers,

Boris.

[Louis Munro]

Hi Boris,

Post by Boris Epstein
Hi Louis,
Thanks, installed it, playing with it.
Looks good - unfortunately, it looks like the RADIUS IP tracking fix which I have tested and which seems to work didn't make it.
https://github.com/borepstein/packetfence

That was too late for inclusion in 5.3.
There’s a lot of testing that goes into a release, so last minute changes often end up being in the next release.

We need to take a look at that and I may have a few suggestions (making it optional, logging etc.).

Never fear, there will be a 5.4.

Post by Boris Epstein
Also, do you know if there has been any work on detecting when nodes go off-line and marking them as inactive?

I don’t think anything has been done about that.
It’s a harder problem than it looks at first glance.

How do you do it?
Using radius accounting? That might work.

What is harder is making it reliable.
Packets get dropped, switches are disconnected etc.

Pull requests are welcome, as always.
You could also open an issue on github if you haven’t done it yet.

Regards,
--
Louis Munro
***@inverse.ca :: www.inverse.ca
+1.514.447.4918 x125 :: [phone] x125
Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org)

[Boris Epstein]

Hello Louis,

Thanks for your detailed response.

Naturally, fixes need approval and there is always the next release:)

As for the node deactivation, I think there are several options. IMO, it
needs to at least be settable - i.e., if the PF admin declares a node
inactive, then inactive it is.

Secondly, I'd say something like active polling may work. As soon as you
poll and fail to detect it at the switch you last saw it plugged in you
mark it as inactive. Nothing wrong with that, IMO - if it reappears
elsewhere you just mark it as active again.

Be that as it may- what is the current SOP for handling these situations?

Cheers,

Boris.

Post by Louis Munro
Hi Boris,
Hi Louis,
Thanks, installed it, playing with it.
Looks good - unfortunately, it looks like the RADIUS IP tracking fix which
I have tested and which seems to work didn't make it.
https://github.com/borepstein/packetfence
That was too late for inclusion in 5.3.
There’s a lot of testing that goes into a release, so last minute changes
often end up being in the next release.
We need to take a look at that and I may have a few suggestions (making it
optional, logging etc.).
Never fear, there will be a 5.4.
Also, do you know if there has been any work on detecting when nodes go
off-line and marking them as inactive?
I don’t think anything has been done about that.
It’s a harder problem than it looks at first glance.
How do you do it?
Using radius accounting? That might work.
What is harder is making it reliable.
Packets get dropped, switches are disconnected etc.
Pull requests are welcome, as always.
You could also open an issue on github if you haven’t done it yet.
Regards,
--
Louis Munro
+1.514.447.4918 x125 :: [phone] x125
Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (
www.packetfence.org)
------------------------------------------------------------------------------
_______________________________________________
PacketFence-devel mailing list
https://lists.sourceforge.net/lists/listinfo/packetfence-devel

[Louis Munro]

As for the node deactivation, I think there are several options. IMO, it needs to at least be settable - i.e., if the PF admin declares a node inactive, then inactive it is.
Secondly, I'd say something like active polling may work. As soon as you poll and fail to detect it at the switch you last saw it plugged in you mark it as inactive. Nothing wrong with that, IMO - if it reappears elsewhere you just mark it as active again.

Polling does not scale all that well and is more trouble that it’s worth.

Some people have thousands of switches.

It would require a separate daemon that polls asynchronously and reconciles the locationlog.

I would need compelling arguments before I start doing that considering that RADIUS accounting already gets us 80% of the way there.

Be that as it may- what is the current SOP for handling these situations?

What situations exactly?
I must say I am not entirely sure I follow you.

Can you tell us explicitly what you consider an “active” node?


Best regards,
--
Louis Munro
***@inverse.ca :: www.inverse.ca
+1.514.447.4918 x125 :: [phone] x125
Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org)

[Boris Epstein]

Hello Louis,

I am fully with you as far as the notion of polling being burdensome and
not scaling well goes. And perhaps I lack clear understanding of what of a
node's intended life cycle - and that may be a cause for some confusion.

Let us say I have a node that i have disconnected and no longer have any
use for - it died, went to heaven, etc. So do I delete it - or just keep it
around as a memory in PF? Because for now it appears difficult to delete -
through the interface at least.

Or, perhaps, do I create a special role to it - like "departed" - and
assign it to that node?

This is what I am confused about.

Thanks in advance for any and all help.

Cheers,

Boris.

Post by Boris Epstein
As for the node deactivation, I think there are several options. IMO, it
needs to at least be settable - i.e., if the PF admin declares a node
inactive, then inactive it is.
Secondly, I'd say something like active polling may work. As soon as you
poll and fail to detect it at the switch you last saw it plugged in you
mark it as inactive. Nothing wrong with that, IMO - if it reappears
elsewhere you just mark it as active again.
Polling does not scale all that well and is more trouble that it’s worth.
Some people have thousands of switches.
It would require a separate daemon that polls asynchronously and
reconciles the locationlog.
I would need compelling arguments before I start doing that considering
that RADIUS accounting already gets us 80% of the way there.
Be that as it may- what is the current SOP for handling these situations?
What situations exactly?
I must say I am not entirely sure I follow you.
Can you tell us explicitly what you consider an “active” node?
Best regards,
--
Louis Munro
+1.514.447.4918 x125 :: [phone] x125
Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (
www.packetfence.org)
------------------------------------------------------------------------------
_______________________________________________
PacketFence-devel mailing list
https://lists.sourceforge.net/lists/listinfo/packetfence-devel