fail2ban eating cpu – 2.1.1

› VitalPBX Community Support › General Discussion › fail2ban eating cpu – 2.1.1

Up
0
Down
  • Post
    • December 27, 2018 at 4:49 am
    Up
    0
    Down
    toxicfusion
    Participant

    Unsure what is going on here.

    I’ve done logrotate -f /etc/logrotate.conf thinking log files being chewed up causing fail2ban to consume CPU.

    i have 3 instances (different installs) where fail2ban is eating 60-90% CPU constantly.  Other installs I have do not have this issue.  They are cloud available. Cloud installs.  Never had this issue before

    I’ve had to kill httpd to help with CPU.   also have skewed the ssh port.

    There any known bug?  As on 2.1.1 release I did have an initial issue with NTP / time/date configuration. Had to re-config it via timedatectl,  as configuring it via the vitalPBX admin settings didnt seem to work.

    starting to get annoyed that fail2ban is consuming so much CPU and causing drop calls.

    0
Viewing 4 replies - 1 through 4 (of 4 total)
  • Replies
    • January 2, 2019 at 2:19 pm
    Up
    0
    Down
    Jose Miguel Rivera
    Keymaster
    NI

    How did you apply the update, did you make the update from GUI or CLI?, if you did it from CLI, which command did you use?

    0
    • January 2, 2019 at 3:17 pm
    Up
    0
    Down
    Jose Miguel Rivera
    Keymaster
    NI

    Where do you have installed vitalpbx? in a VPS, Virtual Machine or Bare Metal?

    0
    • January 3, 2019 at 2:45 pm
    Up
    0
    Down
    toxicfusion
    Participant

    VPS is a cloud instance, with a cloud provider.

    Appears things are nominal as of now.  I skewed ssh port,  dropped traffic to port 22 via firewall rule, and logrotated.. etc.  Appears to of been a big attack.

     

    Although, 2.1.-06 release installs were fine? Only the 2.1.1.1 had issues.

     

    Update was done via yum update -y

     

    0
    • January 3, 2019 at 4:03 pm
    Up
    0
    Down
    Jose Miguel Rivera
    Keymaster
    NI

    After a full update  (yum update), the next most recommendable step is make a full restart of the machine.

    0
Viewing 4 replies - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.