The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Issues with modsecurity OWASP and false positives.

Discussion in 'Security' started by Spork Schivago, Jul 18, 2016.

Tags:
  1. Spork Schivago

    Spork Schivago Well-Known Member

    Joined:
    Jan 21, 2016
    Messages:
    273
    Likes Received:
    20
    Trophy Points:
    18
    Location:
    corning, ny
    cPanel Access Level:
    Website Owner
    I see in /usr/local/apache/logs/error_logs a lot of error messages. Here's a small chunk.

    Code:
    [Mon Jul 18 19:19:34.821609 2016] [:error] [pid 6823] [client 127.0.0.1] ModSecurity: Warning. Operator EQ matched 0 at REQUEST_HEADERS. [file "/usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-20-PROTOCOL-ENFORCEMENT.conf"] [line "317"] [id "960009"] [rev "1"] [msg "Request Missing a User Agent Header"] [severity "NOTICE"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "9"] [tag "Host: "] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_UA"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [hostname "franklin.example.com"] [uri "/"] [unique_id "V41kBmjudWkAABqnkC4AAAAE"]
    
    
    [Mon Jul 18 19:19:34.822806 2016] [:error] [pid 6823] [client 127.0.0.1] ModSecurity: Warning. Operator GE matched 5 at TX:inbound_anomaly_score. [file "/usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/RESPONSE-80-CORRELATION.conf"] [line "35"] [id "981204"] [msg "Inbound Anomaly Score Exceeded (Total Inbound Score: 5): Request Missing a User Agent Header"] [tag "Host: "] [tag "event-correlation"] [hostname "franklin.example.com"] [uri "/index.html"] [unique_id "V41kBmjudWkAABqnkC4AAAAE"]
    
    
    [Mon Jul 18 19:20:01.427810 2016] [:error] [pid 6819] [client 127.0.0.1] ModSecurity: Warning. Operator EQ matched 0 at REQUEST_HEADERS. [file "/usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-20-PROTOCOL-ENFORCEMENT.conf"] [line "283"] [id "960008"] [rev "2"] [msg "Request Missing a Host Header"] [severity "WARNING"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "9"] [tag "Host: "] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_HOST"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [hostname "franklin.example.com"] [uri "/whm-server-status"] [unique_id "V41kIWjudWkAABqjYU0AAAAA"]
    
    
    [Mon Jul 18 19:20:01.427892 2016] [:error] [pid 6819] [client 127.0.0.1] ModSecurity: Warning. Operator EQ matched 0 at REQUEST_HEADERS. [file "/usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-20-PROTOCOL-ENFORCEMENT.conf"] [line "317"] [id "960009"] [rev "1"] [msg "Request Missing a User Agent Header"] [severity "NOTICE"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "9"] [tag "Host: "] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_UA"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [hostname "franklin.example.com"] [uri "/whm-server-status"] [unique_id "V41kIWjudWkAABqjYU0AAAAA"]
    
    
    [Mon Jul 18 19:20:01.428676 2016] [:error] [pid 6819] [client 127.0.0.1] ModSecurity: Warning. Operator GE matched 5 at TX:inbound_anomaly_score. [file "/usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/RESPONSE-80-CORRELATION.conf"] [line "35"] [id "981204"] [msg "Inbound Anomaly Score Exceeded (Total Inbound Score: 5): Request Missing a User Agent Header"] [tag "Host: "] [tag "event-correlation"] [hostname "franklin.example.com"] [uri "/whm-server-status"] [unique_id "V41kIWjudWkAABqjYU0AAAAA"]
    
    
    [Mon Jul 18 19:20:34.546597 2016] [:error] [pid 6820] [client 127.0.0.1] ModSecurity: Warning. Match of "pm AppleWebKit Android" against "REQUEST_HEADERS:User-Agent" required. [file "/usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-20-PROTOCOL-ENFORCEMENT.conf"] [line "299"] [id "960015"] [rev "3"] [msg "Request Missing an Accept Header"] [severity "NOTICE"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "8"] [tag "Host: 127.0.0.1"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_ACCEPT"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [hostname "127.0.0.1"] [uri "/whm-server-status"] [unique_id "V41kQmjudWkAABqkc0UAAAAB"]
    
    
    [Mon Jul 18 19:21:34.542318 2016] [:error] [pid 6821] [client 127.0.0.1] ModSecurity: Warning. Match of "pm AppleWebKit Android" against "REQUEST_HEADERS:User-Agent" required. [file "/usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-20-PROTOCOL-ENFORCEMENT.conf"] [line "299"] [id "960015"] [rev "3"] [msg "Request Missing an Accept Header"] [severity "NOTICE"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "8"] [tag "Host: 127.0.0.1"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_ACCEPT"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [hostname "127.0.0.1"] [uri "/whm-server-status"] [unique_id "V41kfmjudWkAABqlx7cAAAAC"]
    
    
    [Mon Jul 18 19:22:34.564614 2016] [:error] [pid 6822] [client 127.0.0.1] ModSecurity: Warning. Match of "pm AppleWebKit Android" against "REQUEST_HEADERS:User-Agent" required. [file "/usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-20-PROTOCOL-ENFORCEMENT.conf"] [line "299"] [id "960015"] [rev "3"] [msg "Request Missing an Accept Header"] [severity "NOTICE"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "8"] [tag "Host: 127.0.0.1"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_ACCEPT"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [hostname "127.0.0.1"] [uri "/whm-server-status"] [unique_id "V41kumjudWkAABqmocAAAAAD"]
    
    
    [Mon Jul 18 19:22:51.937856 2016] [:error] [pid 6823] [client 169.54.244.75] ModSecurity: Warning. Operator EQ matched 0 at REQUEST_HEADERS. [file "/usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-20-PROTOCOL-ENFORCEMENT.conf"] [line "317"] [id "960009"] [rev "1"] [msg "Request Missing a User Agent Header"] [severity "NOTICE"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "9"] [tag "Host: ip-104-238-117-105.ip.secureserver.net"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_UA"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [hostname "ip-104-238-117-105.ip.secureserver.net"] [uri "/"] [unique_id "V41ky2judWkAABqnkC8AAAAE"]
    
    
    [Mon Jul 18 19:23:34.612950 2016] [:error] [pid 6819] [client 127.0.0.1] ModSecurity: Warning. Match of "pm AppleWebKit Android" against "REQUEST_HEADERS:User-Agent" required. [file "/usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-20-PROTOCOL-ENFORCEMENT.conf"] [line "299"] [id "960015"] [rev "3"] [msg "Request Missing an Accept Header"] [severity "NOTICE"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "8"] [tag "Host: 127.0.0.1"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_ACCEPT"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [hostname "127.0.0.1"] [uri "/whm-server-status"] [unique_id "V41k9mjudWkAABqjYU4AAAAA"]
    
    I believe the ones from 127.0.0.1 are false positive. I believe a cPanel script is checking /whm-server-status to make sure the server is up but there's maybe something wrong with the request header in the script and because of it, perhaps a false positive is being triggered.

    I'd like to safely figure out how to whitelist this, so I don't see the log filled with these error messages whenever 127.0.0.1 tries connecting to /whm-server-status. I think the answer lies within the /usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-01-COMMON-EXCEPTIONS.conf file but I'm not sure how to properly write a rule. Can someone show me what I'd need to put in there?

    I've also sent this message to the OWASP mailing list and if I get an answer from them, I'll update this message with that answer.

    Thank you!
     
    #1 Spork Schivago, Jul 18, 2016
    Last edited by a moderator: Jul 28, 2016
  2. Spork Schivago

    Spork Schivago Well-Known Member

    Joined:
    Jan 21, 2016
    Messages:
    273
    Likes Received:
    20
    Trophy Points:
    18
    Location:
    corning, ny
    cPanel Access Level:
    Website Owner
    I mean I think the proper fix would be to figure out what scripts are causing this and just add a proper user agent and header field. I think I posted about this a long time ago but never really got that far with it. Any help is greatly appreciated. It is extremely hard finding real attacks when the log file is filled with these posts!!!! They come very often and are very frequent. I don't want to disable the rule completely because that makes my system more vulnerable. I just want to whitelist the stuff from 127.0.0.1, optimally, when we know for certain it's from a cPanel script.

    Thanks!
     
  3. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    30,723
    Likes Received:
    660
    Trophy Points:
    113
    cPanel Access Level:
    Root Administrator
  4. keat63

    keat63 Well-Known Member

    Joined:
    Nov 20, 2014
    Messages:
    765
    Likes Received:
    20
    Trophy Points:
    18
    cPanel Access Level:
    Root Administrator
    I found that I had to disable a small number of rules, 960015 being one of them.
    I have no idea what any of them do, and I've no idea whether they are false positives or real ones.
    I'm literally working on the basis that any rules left intact are helping to protect us, which is better than having none at all.
     
    Spork Schivago likes this.
  5. Spork Schivago

    Spork Schivago Well-Known Member

    Joined:
    Jan 21, 2016
    Messages:
    273
    Likes Received:
    20
    Trophy Points:
    18
    Location:
    corning, ny
    cPanel Access Level:
    Website Owner
    This is something I considered and didn't want to do. From looking at the contents of the REQUEST-01-COMMON-EXCEPTIONS.conf file, it seems modsecurity is extremely configurable and I should be able to write a custom rule that says something like,
    If the client is 127.0.0.1 AND it's missing the user agent or the header, AND it's trying to access /whm-server-status, let it through. Or if I could whitelist based on the MAC address and the IP, plus the other stuff, that'd be great.

    The problem is I'm not very familiar with modsecurity and I have googled a good bit and read a good bit of information but I don't think a lot of users who run it really know a lot about it. It comes with cPanel and cPanel includes the OWASP rule set by default. I think most people probably just enable it and might not even ever look at log files or know where they're located or any of that.

    I've seen many posts saying I fixed this by disabling this rule. And although that would work, don't get me wrong, it'd also disable that rule for real threats, you know what I'm saying? There's got to be a way to just write a custom rule in that file and get it to ignore the cPanel stuff.

    If I could figure out what script was causing the issues, I would just try and modify it myself. It might not be a script though, it might be a compiled executable. You know, binary. And without the source, there's not much I could do there. That'd be something cPanel would have to do.

    I'm going to read the links that cPanelMichael posted. Perhaps there's something in them besides disabling the actual rule.

    Thanks.
     
  6. Spork Schivago

    Spork Schivago Well-Known Member

    Joined:
    Jan 21, 2016
    Messages:
    273
    Likes Received:
    20
    Trophy Points:
    18
    Location:
    corning, ny
    cPanel Access Level:
    Website Owner
    Just in case anyone runs into this issue, I've added a new rule to the /usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-01-COMMON-EXCEPTIONS.conf file. I think perhaps this is better than completely disabling the rules that are causing the false positives. This is what I added:

    Code:
    #
    # Exception for cPanel whm-server-status check.
    #
    SecRule REMOTE_ADDR "^127.0.0.1" phase:1,nolog,allow,id:'981022',ctl:ruleEngine=off
    
    This not only stopped the error messages about the whm-server-status stuff but all the other false positives (I think maybe three or four in total) from appearing. It allows all traffic from 127.0.0.1. I think someone with a little more knowledge could perhaps fine tune this a bit more and specifically write it just so it whitelists stuff from 127.0.0.1 if it's trying to pull in whm-server-status or if we know for certain it's a cPanel script.

    Can anyone think of any negative effects this rule might have? I was thinking a hacker could try spoofing their IP address to 127.0.0.1, but I don't see what could that'd do. I don't see how they'd be able to connect to my server at all. And what would my server do? Respond to itself...I honestly can't see this having any negative side effects, but what do you guys think?

    Also, shouldn't something like this be in the REQUEST-01-COMMON-EXCEPTIONS.conf file? My understanding is everyone with a server running cPanel with mod_security enabled have this issue and most people are just disabling the rule.
     
  7. quizknows

    quizknows Well-Known Member

    Joined:
    Oct 20, 2009
    Messages:
    940
    Likes Received:
    55
    Trophy Points:
    28
    cPanel Access Level:
    DataCenter Provider
    Generally you should be OK whitelisting the localhost IP (127.0.0.1). The only way an attacker could legitimately send requests from localhost is if they were already operating in a hacked site on your server, in which case, you have bigger problems. Spoofing an IP is really only relevant (typically) for syn floods, UDP attacks / DNS reflections... DDoS attacks basically.

    If you wanted to allow it only for whm-server-status you can add additional conditions for a match with the "chain" feature, like this:

    Code:
    SecRule REMOTE_ADDR "^127.0.0.1" phase:1,nolog,allow,chain,id:'981022',ctl:ruleEngine=off
    SecRule REQUEST_URI "whm-server-status"
    
    This would make it so the request has to come from localhost AND be going to that URI to qualify for your "allow" action for the rule.
     
    Spork Schivago likes this.
  8. Spork Schivago

    Spork Schivago Well-Known Member

    Joined:
    Jan 21, 2016
    Messages:
    273
    Likes Received:
    20
    Trophy Points:
    18
    Location:
    corning, ny
    cPanel Access Level:
    Website Owner
    That's awesome! Thank you for sharing!!! There's more than one rule getting triggered but they're all from cPanel. I think cPanel should update the rules with something like we have here (there's already two rules in that file for cPanel stuff I believe but don't quote me) or change the script / program so it doesn't cause the false positives. I mean, honestly, the way it is by default just isn't right. It doesn't really cause physical problems but it makes it a lot harder going through logs because of how often this happens. The whm-server-status seems to happen once per minute. That adds up to a lot of log entries! It's very easy to miss real stuff.

    What's a DNS reflection? I couldn't think of anyway whitelisting the local loopback could hurt, I tried thinking of cases too....all I could come up with DDoS attacks, but generally, I don't think there's really a lot you can do to prevent those types of attacks via software anyway.

    There was another way I thought spoofing an IP could help an attack. What happens if I found away to spoof my IP to some random address and then I tried a bunch of exploits....and every one I tried, I assumed they went through and setup a remote shell so I could connect or something. Would something like that work? Would the server just ignore the packet or would it process it, even though I personally wouldn't get anything back on my end...I would this is one of the points of handshakes or something, right? To make sure the communications are two-way, with TCP I mean. Thanks for helping!
     
  9. quizknows

    quizknows Well-Known Member

    Joined:
    Oct 20, 2009
    Messages:
    940
    Likes Received:
    55
    Trophy Points:
    28
    cPanel Access Level:
    DataCenter Provider
    Like I said, whitelisting 127.0.0.1 is not a huge risk. You are right, OWASP could certainly be better "off the bat." It's a shame that it isn't, and seems to not have improved much in recent months/years.

    DNS reflections are attacks carried out by sending a packet with a spoofed source address to many DNS servers, so that the replies all go to whoever's IP is being spoofed as the source. This is made easier because DNS uses UDP, and UDP is not as robust as TCP in regards to handshakes etc. It pretty much just spews data and hopes that it gets there.

    Since protocols like HTTP use TCP, You're not going to be able to simply spoof your address for webapp attacks... the initial TCP SYN would get there and that's about it. Like you said that's where the handshake comes into play.
     
    Spork Schivago likes this.
  10. Spork Schivago

    Spork Schivago Well-Known Member

    Joined:
    Jan 21, 2016
    Messages:
    273
    Likes Received:
    20
    Trophy Points:
    18
    Location:
    corning, ny
    cPanel Access Level:
    Website Owner
    I gotcha. Thanks for the information. Are only authoritative DNS servers prone to DNS reflections? If not, is there a good document on how I could work on "hardening" bind? Thanks.
     
  11. quizknows

    quizknows Well-Known Member

    Joined:
    Oct 20, 2009
    Messages:
    940
    Likes Received:
    55
    Trophy Points:
    28
    cPanel Access Level:
    DataCenter Provider
    Generally as long as you are not an open resolver (allowing recursion) you are fine. You can check by performing a lookup for a domain you do not manage and ensuring your nameserver does not return a response, i.e.

    #dig not-your-site.com @your.server.ip.address

    if you get a proper response back (be sure to try a domain that actually exists, like google.com or something) then you need to disable or restrict recursion in your named (bind) config.
     
    Spork Schivago likes this.
  12. Spork Schivago

    Spork Schivago Well-Known Member

    Joined:
    Jan 21, 2016
    Messages:
    273
    Likes Received:
    20
    Trophy Points:
    18
    Location:
    corning, ny
    cPanel Access Level:
    Website Owner
    Good to go! I ran dig on google.com and received QUERY: 1, ANSWER: 0
    WARNING: recursion requested but not available.

    Thanks for sharing!
     
    quizknows likes this.
  13. keat63

    keat63 Well-Known Member

    Joined:
    Nov 20, 2014
    Messages:
    765
    Likes Received:
    20
    Trophy Points:
    18
    cPanel Access Level:
    Root Administrator
    any chance of a dummies guide on what you did please. ?
     
  14. quizknows

    quizknows Well-Known Member

    Joined:
    Oct 20, 2009
    Messages:
    940
    Likes Received:
    55
    Trophy Points:
    28
    cPanel Access Level:
    DataCenter Provider
    Keat63, basically just make sure recursion is disabled in the options section of named.conf like this:

    Code:
    options {
    allow-recursion { none; };
    allow-transfer  { none; };
    };
    
    You may have other options in there but as long as allow-recursion is set to none (or a trusted ACL but that's more advanced) you should not be used in DNS reflection attacks.
     
  15. keat63

    keat63 Well-Known Member

    Joined:
    Nov 20, 2014
    Messages:
    765
    Likes Received:
    20
    Trophy Points:
    18
    cPanel Access Level:
    Root Administrator
    Yesterday, I looked at the recursion thing and added those entries to the options section, but got errors relating to recursion being unknown when i restarted DNS.
    So Instead I searched named.conf and found 2 entries relating to recursion='yes', I changed these to 'no', then monitored the server.
    DIG revealed no recursion, and i saw no detrimental effects, that i'm aware of. Domains seem intact and running, no apparent disruption to emails.

    So provided this is still the case and that i've not done anything stupid, could someone talk me through making the changes to OWASP.
     
  16. Spork Schivago

    Spork Schivago Well-Known Member

    Joined:
    Jan 21, 2016
    Messages:
    273
    Likes Received:
    20
    Trophy Points:
    18
    Location:
    corning, ny
    cPanel Access Level:
    Website Owner
    Yup.

    Since you were able to edit the named.conf file manually, I'm going to assume you have shell access and know how to edit files via your shell access.

    Edit the file:
    Code:
    /usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-01-COMMON-EXCEPTIONS.conf
    
    I use nano, so for me, I type:
    Code:
    nano -w /usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-01-COMMON-EXCEPTIONS.conf
    
    At the very bottom of that file, copy and paste (or type this):
    Code:
    #
    # Exception for cPanel whm-server-status check.
    #
    SecRule REMOTE_ADDR "^127.0.0.1" phase:1,nolog,allow,id:'981022',ctl:ruleEngine=off
    
    If you type it, be extremely careful and make sure you type it exactly like that. Save the file (in nano, hit CTRL-X and enter). You might need to restart Apache, I'm not certain. For my CentOS system, to restart Apache, I type:
    Code:
    service httpd restart
    
    Because I'm on v58, there's a bug that I discovered and that command might not work. So, if that command gives you some stuff about PID not being found or httpd is already running or something like that, use the cPanel script.
    Code:
    /scripts/restartsrv_apache
    
    After that, you should be good.
     
  17. Spork Schivago

    Spork Schivago Well-Known Member

    Joined:
    Jan 21, 2016
    Messages:
    273
    Likes Received:
    20
    Trophy Points:
    18
    Location:
    corning, ny
    cPanel Access Level:
    Website Owner
    I believe you should do more than just set recursion=no.

    In /etc/named.conf, where you found the recursion=no, in that section, if you scroll down to the bottom of that section (not the file), you should see something like:
    Code:
    pid-file                 "/var/run/named/named.pid";
    dump-file                "data/cache_dump.db";
    statistics-file          "data/named_stats.txt";
    /* memstatistics-file    "data/named_mem_stats.txt";
    
    This is where I made my changes. I also hid my version of named to make it a bit harder for hackers to get in. This is what my section looks like:

    Code:
    pid-file                 "/var/run/named/named.pid";
    dump-file                "data/cache_dump.db";
    statistics-file          "data/named_stats.txt";
    /* memstatistics-file    "data/named_mem_stats.txt";
    allow-transfer    { "none"; };
    allow-recursion   { "none"; };
    
    /* Hide the version number so it's harder to attack us. */
    version none;
    
    Afterwards, you can check the config file to make sure you typed everything correctly:
    Code:
    named-checkconf /etc/named.conf
    
    If it doesn't give you any errors, restart named. On CentOS, I'd do this by running:
    Code:
    service named restart
    
    I hope this helps.
     
  18. keat63

    keat63 Well-Known Member

    Joined:
    Nov 20, 2014
    Messages:
    765
    Likes Received:
    20
    Trophy Points:
    18
    cPanel Access Level:
    Root Administrator
    I'm pretty much tied up for a short while, so I'll look at this when I can dedicate some monitoring time and can quickly react to any issues.

    Thanks
     
  19. Spork Schivago

    Spork Schivago Well-Known Member

    Joined:
    Jan 21, 2016
    Messages:
    273
    Likes Received:
    20
    Trophy Points:
    18
    Location:
    corning, ny
    cPanel Access Level:
    Website Owner
    Okay Keat63. Please keep me updated with your progress and let me know if you have any trouble.
     
Loading...

Share This Page