PfSense GUI Login banner


  • Galactic Empire

    @promise2k said in PfSense GUI Login banner:

    warning, this devise is monitored, etc

    It's not on the login banner but if they get past that there is the home page.

    Create an image and use the picture widget.

    Screenshot 2019-09-03 at 11.57.20.png

    Screenshot 2019-09-03 at 12.00.00.png

    Or a RSS entry.


  • Galactic Empire



  • If you read pfSense hardering recomdations you will see that webconfigurator must not be accessible from public internet or even guest network. I really like pfsense but can't say what will be for example in 1-3 years, maybe I leave company where I support this software and new administrator will not updated it. WebConfigurator is most sensetive and potentially insecure part of pfSense, I hope no one except your system administrators will never see your "banner" and it will be accessible only from management vlan or at least internal LAN


  • LAYER 8 Global Moderator

    @promise2k said in PfSense GUI Login banner:

    i want to create this for compliance purposes.

    Like putting a sign on the inside of locked room that says do not enter. The only people that should be able to access the webgui to even attempt a login or admins. I would think admins are well aware that they are monitoring their system ;)


  • LAYER 8 Netgate

    Compliance requirements can be idiotic. Doesn't change the fact that they must be complied with.

    Perhaps a closer reading of the requirements would show that an administrative login screen accessible only from administrative networks can be exempted/waived.


  • LAYER 8 Global Moderator

    @Derelict said in PfSense GUI Login banner:

    only from administrative networks can be exempted/waived.

    This is always an option, even if not written in the documents.. All it would take is signoff of risk letter at the most.



  • @Derelict I never understand that messages, can someone explain what profit of that?
    They really think that if someone already compromised part of corporate network when will see that banner: would be scared and run away?)
    Or it will help them punish this intruder by law more hard then without banner on compromised system?
    By my view: saw you banner or not: if you cracking somebody's internal network you 💯% know that you breaks the law and if you will be captured you will be punished...


  • LAYER 8 Netgate

    Of course not. Look at the effectiveness of NO GUNS signs. I'm not saying it will have any effect on a bad guy who's already inside.

    But if it's in the compliance requirements and he needs to comply with it there's not much he can do other than:

    1. Make it comply
    2. Use something else that complies
    3. Get a waiver
    4. Change the requirement
    5. Be non-compliant


  • This post is deleted!

  • LAYER 8 Netgate


  • Rebel Alliance Developer Netgate

    There is an old urban legend/myth that a hacker was acquitted at a trial for cracking a server because there was a welcome message printed on the terminal inviting them in.

    "Scary" banners always seemed like a panicked overreaction to the myth from someone in a legal department that had no idea how technology works.



  • @dragoangel said in PfSense GUI Login banner:

    WebConfigurator is most sensetive and potentially insecure part of pfSense

    If needed, even LAN access can be forbidden.
    If needed, the WebConfigurator's webserver (nginx) can be bound to an interface at choice when booting like 192.168.1.1, and not to 'any' as it does right now. This needs some scripting, and I guess this will get implemented in the future.

    Or this one : block WebConfigurator access on all interfaces (except localhost ?) and get in, if needed , using the console access or USB keyboad + screen.

    Anyway, nothing coming in on WAN can access the WebConfigurator - the firewall works.

    pfSense can be as secure as needed and even better, but the guy that sets it up has a word to say.

    At work, I reserve the LAN NIC for admin purposes, everybody else is on other LAN's



  • @Gertjan that is too paranoid, setting it to management vlan with all others networking admin panels, servers bmc etc is more than enough.



  • @jimp I know, the whole thing is stupid but if adding a text banner can check a compliance box and enable Netgate to make more sales, then add the banner. Every single customer that I connect to for support reasons has those access banners on login to their Windows servers.



  • @KOM in thread already you can find link to task...



  • @KOM said in PfSense GUI Login banner:

    @jimp I know, the whole thing is stupid but if adding a text banner can check a compliance box and enable Netgate to make more sales, then add the banner. Every single customer that I connect to for support reasons has those access banners on login to their Windows servers.

    I agree it would be a worthwhile addition in terms of checking "compliance boxes" to have a configurable login banner for the GUI and SSH. The login banner message is required by all of the popular cyber standards I am aware of (NIST 800 and the US Nuclear Regulatory Commission Cyber Rules). Technically you can get an "out" if the device does not support a banner, but that is usually reserved for more dumb products like industrial control components and maybe IoT type devices. The auditors really like to see the banners configured on managed switches, firewalls, servers and employee workstations.

    I understand that at the techie level, the banner does nothing. If I want to break into your system, a stupid banner certainly does not deter me. However, when dealing with non-techie bureaucrat types grilling you over a cyber audit checklist, it's nice to be able to just check that box and get an easy "A" on that point at least ... ☺ .


  • LAYER 8 Global Moderator

    I agree its prob best to add the feature, since prob not a battle worth fighting over.. But in the bigger picture tech types need to stand up to this sort of bureaucrat nonsense..

    Wouldn't it be better the standard actually do something like, insure that admin interfaces are only accessible via admin IPs and or networks. With restrictions in place to even access said network where the interfaces are available..

    I could put the interface open to the internet - and with said banner I can check off some box? Makes zero sense!



  • @johnpoz said in PfSense GUI Login banner:

    I agree its prob best to add the feature, since prob not a battle worth fighting over.. But in the bigger picture tech types need to stand up to this sort of bureaucrat nonsense..

    Wouldn't it be better the standard actually do something like, insure that admin interfaces are only accessible via admin IPs and or networks. With restrictions in place to even access said network where the interfaces are available..

    I could put the interface open to the internet - and with said banner I can check off some box? Makes zero sense!

    True, but most of the regulations also usually want the admin interfaces isolated. In my nuclear world, that was a requirement for firewalls and managed switches and you would fail without that configuration. However, they still wanted to see the stupid banner as well ... ☹ .

    And when executive management is looking at a black mark on a cyber audit and comparing that to the cost of changing firewall vendors (or swapping out the firewall admin for a new guy willing to say "yes"), they will choose one of the latter two options every single time ... 😁 .


  • Rebel Alliance Developer Netgate

    Worth of banners notwithstanding, I can see the belt-and-suspenders approach being required by some regulations. Yes, the admin interface should be isolated, but on the off chance a user stumbles upon the interface anyway, they should still see the warning. Because 💩 happens, despite the best of intentions.


  • Galactic Empire

    Maybe implement something in the style of Cisco banners:-

    1. banner login - warning messages pre auth

    2. banner exec - warning post auth

    3. banner motd - not sure if this would be needed due to /etc/motd


Log in to reply