Join the community today
Register Now

CSF Can ping but can't open page

Discussion in 'Other Centmin Mod Installed software' started by pamamolf, Aug 30, 2016.

  1. eva2000

    eva2000 Administrator Staff Member

    45,462
    10,318
    113
    May 24, 2014
    Brisbane, Australia
    Ratings:
    +16,003
    Local Time:
    12:15 AM
    Nginx 1.19.x
    MariaDB 5.5/10.x
    strange only a few legit cases for this to happen and that is the user shares an IP address with a distributed/brute force attacker i.e. sshd brute force attacks on your server will automatically be blocked via CSF Firewall for better security.

    and/or you enabled CSF Firewall block list at /etc/csf/csf.blocklists which can automatically communicate with known spam, abuse etc lists like SPAMHAUS, ProjectHoney Pot, Maxmind anonymous proxies list, Stopforumspam, and Dshield. So when a visitor with an IP listed in any of these known spam blacklists visits the server, CSF Firewall would block them. The CSF block lists are disabeld by default unless you enable them in /etc/csf/csf.blocklists.

    So check if your user's IP is blacklisted if you have enabled blocklists in /etc/csf/csf.blocklists
     
    Last edited: Sep 2, 2016
  2. pamamolf

    pamamolf Premium Member Premium Member

    3,861
    379
    83
    May 31, 2014
    Ratings:
    +731
    Local Time:
    4:15 PM
    Nginx-1.17.x
    MariaDB 10.3.x
    No i didn't enable anything related and in general i didn't touch anything after the default installation.....
    But some devices can browse the site and some not and after x seconds some can and some can't...

    Crazy i know....
     
  3. eva2000

    eva2000 Administrator Staff Member

    45,462
    10,318
    113
    May 24, 2014
    Brisbane, Australia
    Ratings:
    +16,003
    Local Time:
    12:15 AM
    Nginx 1.19.x
    MariaDB 5.5/10.x
    You can try enabling CSF Firewall watch ip mode to see what your visitor IP goes through see linked doc readme.txt at CSF Firewall - CentminMod.com LEMP Nginx web stack for CentOS or direct link at https://download.configserver.com/csf/readme.txt

    Code (Text):
    19. Watching IP Addresses
    #########################
    
    The CLI option csf --watch [ip] (csf -w [ip]) and configuration option
    WATCH_MODE logs TCP connection initiation (SYN) packets from a specified source
    as they traverse the iptables chains.
    
    This can be extremely useful in tracking where that IP address is being DROPed
    or ACCEPTed by iptables.
    
    WATCH_MODE should be used when watching IP addresses, although the csf -w [ip]
    option will still work without it but won't necessarily provide conclusive
    information on the final destination of the packet.
    
    WATCH_MODE is disabled by default and should be left as such unless actively
    watching an IP address as it will add an overhead to all accepted iptables
    traffic and increase overall iptables kernel logging through syslog.
    
    WATCH_MODE disables: DROP_NOLOG, PS_INTERVAL, DROP_ONLYRES
    WATCH_MODE enabled: DROP_LOGGING, DROP_IP_LOGGING, DROP_PF_LOGGING
    WATCH_MODE also logs iptables ACCEPT for watched IP addresses
    
    You should only watch a very small number of IP addresses at a time and for a
    very short period of time, otherwise the kernel log (usually /var/log/messages)
    will become flooded with entries. Also, any IP address rules added during the
    time of the watch will not necessarily be included in the logging rules for the
    watched IP addresses.
    
    IP address watches do not survive a csf (iptables) restart.
    
    You can use either an IP address or a CIDR address for csf -w [ip].
    
    Recommended method to use this function:
    
    1. Enable WATCH_MODE
    
    2. Restart csf
    
    3. Restart lfd
    
    4. Use the following to watch an IP:
    
    csf -w 11.22.33.44
    
    5. Watch the kernel iptables log for hits from the watched IP address
    
    Once you have finished watching an IP address you should:
    
    1. Disable WATCH_MODE
    
    2. Restart csf (which will also remove the watched ip rules)
    
    3. Restart lfd
    
    The kernel iptables log lines for watching an IP (usually in /var/log/messages)
    contain the direction of the packet in the chain and the chain name, e.g.
    I:INPUT is Incoming to the chain INPUT, O:LOCALINPUT is Outgoing from chain
    LOCALINPUT.
    
    The following is a trimmed down example log watch of 192.168.254.4 connecting
    to port 22:
    
    Firewall: I:INPUT SRC=192.168.254.4 DST=192.168.254.71 PROTO=TCP DPT=22
    Firewall: I:LOCALINPUT SRC=192.168.254.4 DST=192.168.254.71 PROTO=TCP DPT=22
    Firewall: I:GDENYIN SRC=192.168.254.4 DST=192.168.254.71 PROTO=TCP DPT=22
    Firewall: O:GDENYIN SRC=192.168.254.4 DST=192.168.254.71 PROTO=TCP DPT=22
    Firewall: I:DSHIELD SRC=192.168.254.4 DST=192.168.254.71 PROTO=TCP DPT=22
    Firewall: O:DSHIELD SRC=192.168.254.4 DST=192.168.254.71 PROTO=TCP DPT=22
    Firewall: I:SPAMHAUS SRC=192.168.254.4 DST=192.168.254.71 PROTO=TCP DPT=22
    Firewall: O:SPAMHAUS SRC=192.168.254.4 DST=192.168.254.71 PROTO=TCP DPT=22
    Firewall: O:LOCALINPUT SRC=192.168.254.4 DST=192.168.254.71 PROTO=TCP DPT=22
    Firewall: I:INVALID SRC=192.168.254.4 DST=192.168.254.71 PROTO=TCP DPT=22
    Firewall: O:INVALID SRC=192.168.254.4 DST=192.168.254.71 PROTO=TCP DPT=22
    Firewall: I:LOGACCEPT SRC=192.168.254.4 DST=192.168.254.71 PROTO=TCP DPT=22
     
  4. eva2000

    eva2000 Administrator Staff Member

    45,462
    10,318
    113
    May 24, 2014
    Brisbane, Australia
    Ratings:
    +16,003
    Local Time:
    12:15 AM
    Nginx 1.19.x
    MariaDB 5.5/10.x
    if you uninstall csf firewall, you will not have any default iptable rules setup so block most ports from public access so won't help unless you manually setup iptable rule to white list ports etc after you uninstall csf firewall
     
  5. eva2000

    eva2000 Administrator Staff Member

    45,462
    10,318
    113
    May 24, 2014
    Brisbane, Australia
    Ratings:
    +16,003
    Local Time:
    12:15 AM
    Nginx 1.19.x
    MariaDB 5.5/10.x
  6. pamamolf

    pamamolf Premium Member Premium Member

    3,861
    379
    83
    May 31, 2014
    Ratings:
    +731
    Local Time:
    4:15 PM
    Nginx-1.17.x
    MariaDB 10.3.x
    No they don't have any problems and they don't have any problems on another server that i setup a few days ago with the same method and exact same setup and that server was on the same datacenter ....
     
  7. eva2000

    eva2000 Administrator Staff Member

    45,462
    10,318
    113
    May 24, 2014
    Brisbane, Australia
    Ratings:
    +16,003
    Local Time:
    12:15 AM
    Nginx 1.19.x
    MariaDB 5.5/10.x
    very strange then.. were they all on same user IP or did their ISP rotate their IP addresses ?
     
  8. pamamolf

    pamamolf Premium Member Premium Member

    3,861
    379
    83
    May 31, 2014
    Ratings:
    +731
    Local Time:
    4:15 PM
    Nginx-1.17.x
    MariaDB 10.3.x
    Different ISP's with dynamic ip's....
     
  9. rdan

    rdan Well-Known Member

    4,992
    1,191
    113
    May 25, 2014
    Ratings:
    +1,813
    Local Time:
    10:15 PM
    Mainline
    10.2
    Instead of uninstalling CSF, try csf -x only.
     
  10. pamamolf

    pamamolf Premium Member Premium Member

    3,861
    379
    83
    May 31, 2014
    Ratings:
    +731
    Local Time:
    4:15 PM
    Nginx-1.17.x
    MariaDB 10.3.x
    Now i give up with it :(

    But i can produce it anytime and that's the issue.....

    Fire up any server vps or dedicated located anywhere and run the one line Curl installer and then try to view a website from the same network/ip from 5 devices and boom network and time outs errors :(
     
  11. eva2000

    eva2000 Administrator Staff Member

    45,462
    10,318
    113
    May 24, 2014
    Brisbane, Australia
    Ratings:
    +16,003
    Local Time:
    12:15 AM
    Nginx 1.19.x
    MariaDB 5.5/10.x
  12. pamamolf

    pamamolf Premium Member Premium Member

    3,861
    379
    83
    May 31, 2014
    Ratings:
    +731
    Local Time:
    4:15 PM
    Nginx-1.17.x
    MariaDB 10.3.x
    No i will try it now :)
     
  13. pamamolf

    pamamolf Premium Member Premium Member

    3,861
    379
    83
    May 31, 2014
    Ratings:
    +731
    Local Time:
    4:15 PM
    Nginx-1.17.x
    MariaDB 10.3.x
    Ok i did it and i got this:

    Code:
    LOG  tcp opt -- in * out *  useriphere  -> 0.0.0.0/0   tcp flags:0x17/0x02 LOG flags 0 level 4 prefix "Firewall: I:INPUT "
    LOG  tcp opt -- in * out *  useriphere  -> 0.0.0.0/0   tcp flags:0x17/0x02 LOG flags 0 level 4 prefix "Firewall: O:INPUT "
    LOG  tcp opt -- in * out *  useriphere  -> 0.0.0.0/0   tcp flags:0x17/0x02 LOG flags 0 level 4 prefix "Firewall: I:LOCALINPUT "
    LOG  tcp opt -- in * out *  useriphere  -> 0.0.0.0/0   tcp flags:0x17/0x02 LOG flags 0 level 4 prefix "Firewall: O:LOCALINPUT "
    LOG  tcp opt -- in * out *  useriphere  -> 0.0.0.0/0   tcp flags:0x17/0x02 LOG flags 0 level 4 prefix "Firewall: I:LOGDROPIN "
    LOG  tcp opt -- in * out *  useriphere  -> 0.0.0.0/0   tcp flags:0x17/0x02 LOG flags 0 level 4 prefix "Firewall: O:LOGDROPIN "
    LOG  tcp opt -- in * out *  useriphere  -> 0.0.0.0/0   tcp flags:0x17/0x02 LOG flags 0 level 4 prefix "Firewall: I:DENYIN "
    LOG  tcp opt -- in * out *  useriphere  -> 0.0.0.0/0   tcp flags:0x17/0x02 LOG flags 0 level 4 prefix "Firewall: O:DENYIN "
    LOG  tcp opt -- in * out *  useriphere  -> 0.0.0.0/0   tcp flags:0x17/0x02 LOG flags 0 level 4 prefix "Firewall: I:DENYOUT "
    LOG  tcp opt -- in * out *  useriphere  -> 0.0.0.0/0   tcp flags:0x17/0x02 LOG flags 0 level 4 prefix "Firewall: O:DENYOUT "
    LOG  tcp opt -- in * out *  useriphere  -> 0.0.0.0/0   tcp flags:0x17/0x02 LOG flags 0 level 4 prefix "Firewall: I:ALLOWIN "
    LOG  tcp opt -- in * out *  useriphere  -> 0.0.0.0/0   tcp flags:0x17/0x02 LOG flags 0 level 4 prefix "Firewall: O:ALLOWIN "
    LOG  tcp opt -- in * out *  useriphere  -> 0.0.0.0/0   tcp flags:0x17/0x02 LOG flags 0 level 4 prefix "Firewall: I:ALLOWOUT "
    LOG  tcp opt -- in * out *  useriphere  -> 0.0.0.0/0   tcp flags:0x17/0x02 LOG flags 0 level 4 prefix "Firewall: O:ALLOWOUT "
    LOG  tcp opt -- in * out *  useriphere  -> 0.0.0.0/0   tcp flags:0x17/0x02 LOG flags 0 level 4 prefix "Firewall: I:INVALID "
    LOG  tcp opt -- in * out *  useriphere  -> 0.0.0.0/0   tcp flags:0x17/0x02 LOG flags 0 level 4 prefix "Firewall: O:INVALID "
    LOG  tcp opt -- in * out *  useriphere  -> 0.0.0.0/0   tcp flags:0x17/0x02 LOG flags 0 level 4 prefix "Firewall: I:INVDROP "
    LOG  tcp opt -- in * out *  useriphere  -> 0.0.0.0/0   tcp flags:0x17/0x02 LOG flags 0 level 4 prefix "Firewall: O:INVDROP "
    LOG  tcp opt -- in * out *  useriphere  -> 0.0.0.0/0   tcp flags:0x17/0x02 LOG flags 0 level 4 prefix "Firewall: I:ALLOWDYNIN "
    LOG  tcp opt -- in * out *  useriphere  -> 0.0.0.0/0   tcp flags:0x17/0x02 LOG flags 0 level 4 prefix "Firewall: O:ALLOWDYNIN "
    LOG  tcp opt -- in * out *  useriphere  -> 0.0.0.0/0   tcp flags:0x17/0x02 LOG flags 0 level 4 prefix "Firewall: I:PORTFLOOD "
    LOG  tcp opt -- in * out *  useriphere  -> 0.0.0.0/0   tcp flags:0x17/0x02 LOG flags 0 level 4 prefix "Firewall: O:PORTFLOOD "
    LOG  tcp opt -- in * out *  useriphere  -> 0.0.0.0/0   tcp flags:0x17/0x02 LOG flags 0 level 4 prefix "Firewall: I:PORTFLOOD "
    LOG  tcp opt -- in * out *  useriphere  -> 0.0.0.0/0   tcp flags:0x17/0x02 LOG flags 0 level 4 prefix "Firewall: O:PORTFLOOD "
    LOG  tcp opt -- in * out *  useriphere  -> 0.0.0.0/0   tcp flags:0x17/0x02 LOG flags 0 level 4 prefix "Firewall: I:LOGACCEPT "
    LOG  tcp opt -- in * out *  useriphere  -> 0.0.0.0/0   tcp flags:0x17/0x02 LOG flags 0 level 4 prefix "Firewall: O:LOGACCEPT "
     
  14. eva2000

    eva2000 Administrator Staff Member

    45,462
    10,318
    113
    May 24, 2014
    Brisbane, Australia
    Ratings:
    +16,003
    Local Time:
    12:15 AM
    Nginx 1.19.x
    MariaDB 5.5/10.x
    If you haven't restarted csf and lfd yet and still in WATCH_MODE, also do a csf -g to grep ip of the user as well

    so

    1. enable WATCH_MODE and csf -w ip and check /var/log/messages for ip related using grep
    Code (Text):
    grep 'ip' /var/log/messages

    2. csf -g ip

    if output is lengthy, post contents of log to pastebin.com or gist.github.com
     
  15. pamamolf

    pamamolf Premium Member Premium Member

    3,861
    379
    83
    May 31, 2014
    Ratings:
    +731
    Local Time:
    4:15 PM
    Nginx-1.17.x
    MariaDB 10.3.x
  16. eva2000

    eva2000 Administrator Staff Member

    45,462
    10,318
    113
    May 24, 2014
    Brisbane, Australia
    Ratings:
    +16,003
    Local Time:
    12:15 AM
    Nginx 1.19.x
    MariaDB 5.5/10.x
    and grep ip from /var/log/messages ?
     
  17. pamamolf

    pamamolf Premium Member Premium Member

    3,861
    379
    83
    May 31, 2014
    Ratings:
    +731
    Local Time:
    4:15 PM
    Nginx-1.17.x
    MariaDB 10.3.x
  18. eva2000

    eva2000 Administrator Staff Member

    45,462
    10,318
    113
    May 24, 2014
    Brisbane, Australia
    Ratings:
    +16,003
    Local Time:
    12:15 AM
    Nginx 1.19.x
    MariaDB 5.5/10.x
  19. pamamolf

    pamamolf Premium Member Premium Member

    3,861
    379
    83
    May 31, 2014
    Ratings:
    +731
    Local Time:
    4:15 PM
    Nginx-1.17.x
    MariaDB 10.3.x
    Not sure exactly but yes about 5-6

    But i think he is able to get that issue with less also like 2-3 devices...
     
    Last edited: Sep 3, 2016
  20. eva2000

    eva2000 Administrator Staff Member

    45,462
    10,318
    113
    May 24, 2014
    Brisbane, Australia
    Ratings:
    +16,003
    Local Time:
    12:15 AM
    Nginx 1.19.x
    MariaDB 5.5/10.x
    CSF firewall might be blocking due to number of connections from same ip but from your provided /etc/csf/csf.conf config file at csf - Pastebin.com connection limit, port scan tracking and connection tracking are disabled and port flood doesn't cover port 80 and 443 so shouldn't be AFAIK

    You can also enable temporarily CSF Firewall email reports so you get notices when blocks happen for more clues in /etc/csf/csf.conf

    Code (Text):
    ###############################################################################
    # SECTION:Reporting Settings
    ###############################################################################
    # By default, lfd will send alert emails using the relevant alert template to
    # the To: address configured within that template. Setting the following
    # option will override the configured To: field in all lfd alert emails
    #
    # Leave this option empty to use the To: field setting in each alert template
    LF_ALERT_TO = ""
     
    # By default, lfd will send alert emails using the relevant alert template from
    # the From: address configured within that template. Setting the following
    # option will override the configured From: field in all lfd alert emails
    #
    # Leave this option empty to use the From: field setting in each alert template
    LF_ALERT_FROM = ""