Why binds pfSense (1.2.3) dameons to every interface



  • Hello,

    is there a certain cause why pfSense binds most dameons (lighttpd, sshd, dnsmasq)
    to all interfaces?

    I know that the default policy for pf do not allow to access these dameons except
    on LAN.

    But IMHO it is pretty useless to bind with one piece of "software" (sshd, dnsmasq,…)
    to interfaces (even where the function is not needed), and restrict access with
    another (even pretty good) piece of "software" (pf).
    (Wasn't this "bind everything to everything" a major issue in the last decade on all
    plattforms?!?).

    Another thing I would like to comment is the concept of "WAN" and "LAN". I think it
    comes from the mainly purpose of a fw, the bad side and the good side. Regarding
    my first point, in a concept of "WAN" and "LAN" I would put bindings (in standard)
    only to the "LAN" interface.

    Nowerdays there are so extrem different ways how pfSense is used so maybe this
    WAN-LAN (and therefore "hardcoding" different things to WAN or LAN) is somehow
    "outdated" and a better approache would be to let the admin take care of that,
    means:

    Interface-config:
    Interface - IP -  assign custom name - assign purpose (good side|bad side|nirvana|and-so-on).

    The auto-generated rules respectively the behaviour is then not made on the
    decision if it is WAN or LAN or OPT or whatever. It is made on the config purpose.

    Just my 50cents.
    Apologise if I was somehow to negativ or offended someone.

    Regards,
    CD



  • Most of what you're talking about are holdover conventions from m0n0wall which have been maintained for ease of use.  There's a case to be made for not binding important services like the webGUI and OpenSSH to all interfaces by default, however, there are plenty of difficult to manage edge cases that require it.  At the end of the day, these were design decisions made to assist the greatest number of users.  Certainly there is room for improvement, and pfSense is improving regularly, but feedback like yours helps raise important questions and spawn useful debate.  Hopefully some of the devs will sound off with their views.



  • Because many people open the web interface or SSH from specific remote locations for management and want to do so without having to NAT. Changing that now would break thousands of upgraded systems. I agree it wouldn't be a bad idea to have an option to only bind to specific IPs. Patches welcome.


Log in to reply