Bastille - firewall in ISPConfig.

Discussion in 'Installation/Configuration' started by keybd_user, Jun 24, 2006.

  1. keybd_user

    keybd_user Member


    I installed ISPConfig lattest version in a X86_64 mean machine and everything is perfect. (a dauting task :)
    Looking at the startup message I can see that ISPConfig in the boot System V sequence starts after the network has been initiated, after some other stuff has also been started.
    (network S05network and S07ispconfig_server in runlevel 3).
    I can perfectly see in the log file that ispconfig_server starts and his own instance of apache is also up and running.
    My question is When does the firewall start.
    I followed the perfect setup but I can not see when the iptables rules are set.
    The script bastille-firewall does not show in the init.d rc levels.
    Also using
    # iptables --list
    The rules appear to be there correctly setup.
    But It does show up in yast2 runlevel editor :confused: and it is not possible to make it "active".

    Should I just make

    chkconfig bastille-firewall --add
    chkconfig bastille-firewall on --level 3,5


  2. till

    till Super Moderator Staff Member ISPConfig Developer

    No, dont add Bastille in the runlevels, it is controlled and started be ythe ISPConfig startscript.

    Just enable the Firewall under management > server > services.
  3. keybd_user

    keybd_user Member

    Hi Till,

    Yeah, I noticed that the iptables --list did show the rules set up correclty so it obviously must start in the middle of the ISPConfig scripts.
    I added some more ports to make a backup sshd service with a different sshd config file.
    So the issue is this one:
    If the ISPConfig scripts starts the firewall then I think we have a problem.
    In the startup order ISPConfig is the last to start.
    And, for example the NTP service takes a long time to connect to ntp servers and start and this happens Before we have the ISPConfig => Firewall activated.
    All other services are up ...
    That is why I wonder if it is not better to start the iptables Before ISPConfig and disable in ISPConfig the firewall.
    It will be there on the runlevel we wich on the order we determine and is best suited.
    In case of need we can use ISPConfig interface to change the firewall rules only (they do not change that often anyway ... ).
    In a datacenter environment a long start without firewal can be complicated ...
    What is your opinion.

  4. till

    till Super Moderator Staff Member ISPConfig Developer

    I agree in case you run services that shall not be available for external users.

    But normally you run on a webserver only services like apache, pop3, imap, smtp that shall be used from outside, so these ports are open anyway. It makes no big difference if the firewall is on or not, as these ports are open anyway for all running services.

    This does not apply for firewalls for a network or a firewall on a desktop that shall not accept connections from outside.
  5. keybd_user

    keybd_user Member

    Hi Till,

    I fully agree with your point.
    But that is only valid if you know in advance exactly what services (and ports they are using) are running in the server at boot time.
    But if one day by any change (and trust me, this things happen) I forget a service startup that has a vulnerability of some sort (and they are so many to mention ... ) that could be a serious problem.
    Moreover, my server is used by other programmers that have repositories with their development ... I fully and totally trust them ... but has we all know :) :cool: us Java Developers, are know to make "imaginative" server-side programs ... sometimes to save a login under ssh ...
    Go figure.

    Well ... I do not expect a lot of reboots ... so this should not be a problem.
    Anyhow, it is too late now to make this things wait any longer.
    I simply have to be more cautious.
    I will change the ntp startup order for after the ISPConfig (it is the one that takes longer this will dramatically reduce any type of attack attempt).


Share This Page