Announcement

Collapse
No announcement yet.

Problems with Apache, subdomains, and cellphones.

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Problems with Apache, subdomains, and cellphones.

    I have something weird going on here. I've setup a subdomain on my server and I've created a virtualhost entry for it. I'm running Apache 2.4.27. I have the DNS entries configured.

    On the computers I've tested, it works just fine. I go to git.example.com and I see the GitLab login screen. On my wifes cell phone, it works just fine. I go to git.example.com, I see the GitLab login screen.

    On my cell phone, on my friend's cell phone (much cheaper cell phones), I go to git.example.com, and I see example.com's website, not GitLab's login screen.

    I check the log files. I have custom logs setup for git.example.com and when I use her cell phone, or the computers, I see the connections in the custom logs for git.example.com. But when I use my cell phone or my friend uses his, the data does appear only in the example.com log files.

    Any idea what's going on here? I've cleared the cache in Chrome on the cell. I've removed site data on Chrome. I've tried it in Incognito Mode, thinking it was some sort of caching issue. It's very frustrating.


    Here's the log file where I connect with my cell and it actually goes to the example.com's website instead of git.example.com's website (with my IPv4 home address removed):

    Code:
    192.168.1.2 - - [04/Aug/2017:09:02:55 -0400] "GET /favicon.ico HTTP/1.1" 404 - "https://git.example.com/" "Mozilla/5.0 (Linux; Android 6.0.1; SM-S120VL Build/MMB29M) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.125 Mobile Safari/537.36"
    192.168.1.2 - - [04/Aug/2017:09:09:41 -0400] "GET / HTTP/1.1" 200 1790 "-" "Mozilla/5.0 (Linux; Android 6.0.1; SM-S120VL Build/MMB29M) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.125 Mobile Safari/537.36"
    192.168.1.2 - - [04/Aug/2017:09:12:52 -0400] "GET / HTTP/1.1" 200 1790 "-" "Mozilla/5.0 (Linux; Android 6.0.1; SM-S120VL Build/MMB29M) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.125 Mobile Safari/537.36"
    The favicon.ico doesn't exist for example.com, but it does exist for git.example.com. The DocumentRoot for git.example.com is /opt/gitlab/embedded/service/gitlab-rails/public The DocumentRoot for example.com is /home/sporkschivago/public_html/

    It's like for whatever reason, the DocumentRoot for git.example.com isn't being honored when I use the cell phone.

    I just try again now, a good 20 minutes later. This is all that's in the logfile:
    Code:
    192.168.1.2 - - [04/Aug/2017:09:35:37 -0400] "GET / HTTP/1.1" 200 1790 "-" "Mozilla/5.0 (Linux; Android 6.0.1; SM-S120VL Build/MMB29M) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.125 Mobile Safari/537.36"
    Now it doesn't even show the git.example.com

    Thank you!!!!
    Last edited by Spork Schivago; 08-04-2017, 07:37 AM. Reason: added new log entry.
    -- Law of Expanding Memory: Applications Will Also Expand Until RAM Is Full

    #2
    Re: Problems with Apache, subdomains, and cellphones.

    I checked /etc/apache2/logs/error_log after restarting Apache and I see this:

    Code:
    [Fri Aug 04 09:35:37.899870 2017] [:error] [pid 24992] [client 192.168.1.2] 
    ModSecurity: Warning. IPmatch: "192.168.1.2" matched at REMOTE_ADDR. 
    [file "/etc/apache2/conf.d/modsec_vendor_configs/OWASP3/rules/REQUEST-
    002-WHITELIST-HOME-IPv4.conf"] [line "9"] [id "8888778"] 
    [msg "Matched Home IPv4 Address (192.168.1.2). Disabling ModSec"] 
    [hostname "git.example.com"] [uri "/"] 
    [unique_id "WYR4KUBVHVqAdtfufSGM3AAAAAA"]
    So I know the cell is trying to reach git.example.com. I can't see how ModSec would be messing with things. I don't think it's that though. Here's the modsec logfile entry for my last connection attempt, just in case it is though.

    Code:
    [root@franklin modsec_audit]# cat ./sporkschivago/20170804/20170804-0935/20170804-093537-WYR4KUBVHVqAdtfufSGM3AAAAAA 
    --fdf5570c-A--
    [04/Aug/2017:09:35:37 --0400] WYR4KUBVHVqAdtfufSGM3AAAAAA 192.168.1.2 60516 192.168.4.10 443
    --fdf5570c-B--
    GET / HTTP/1.1
    Host: git.example.com
    Connection: keep-alive
    Upgrade-Insecure-Requests: 1
    User-Agent: Mozilla/5.0 (Linux; Android 6.0.1; SM-S120VL Build/MMB29M) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.125 Mobile Safari/537.36
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
    DNT: 1
    Accept-Encoding: gzip, deflate, br
    Accept-Language: en-US,en;q=0.8
    
    --fdf5570c-F--
    HTTP/1.1 200 OK
    Strict-Transport-Security: max-age=63072000; includeSubdomains; preload
    X-Frame-Options: SAMEORIGIN
    X-Content-Type-Options: nosniff
    Keep-Alive: timeout=5, max=100
    Connection: Keep-Alive
    Transfer-Encoding: chunked
    Content-Type: text/html; charset=UTF-8
    
    --fdf5570c-H--
    Message: Warning. IPmatch: "192.168.1.2" matched at REMOTE_ADDR. [file "/etc/apache2/conf.d/modsec_vendor_configs/OWASP3/rules/REQUEST-002-WHITELIST-HOME-IPv4.conf"] [line "9"] [id "8888778"] [msg "Matched Home IPv4 Address (192.168.1.2). Disabling ModSec"]
    Apache-Handler: cgi-script
    Stopwatch: 1501853737899484 24741 (- - -)
    Stopwatch2: 1501853737899484 24741; combined=419, p1=406, p2=0, p3=0, p4=0, p5=13, sr=0, sw=0, l=0, gc=0
    Producer: ModSecurity for Apache/2.9.0 (http://www.modsecurity.org/); OWASP_CRS/3.0.0.
    Server: Apache
    
    --fdf5570c-Z--
    Does anyone see anything that doesn't look right?
    -- Law of Expanding Memory: Applications Will Also Expand Until RAM Is Full

    Comment


      #3
      Re: Problems with Apache, subdomains, and cellphones.

      your cell may be being logged through an invisible proxy.
      NOKIA was caught doing this a while back by using a fixed DNS server that they owned.
      it returned a datacenter number every time, that then acted as a proxy for the real i.p. address.

      TRUST NOBODY!!!

      Comment


        #4
        Re: Problems with Apache, subdomains, and cellphones.

        Originally posted by stj View Post
        your cell may be being logged through an invisible proxy.
        NOKIA was caught doing this a while back by using a fixed DNS server that they owned.
        it returned a datacenter number every time, that then acted as a proxy for the real i.p. address.

        TRUST NOBODY!!!
        This doesn't make sense to me though Stj. If they were using a proxy, wouldn't I see the IP address of the proxy? Or is this what you mean by invisible? Do they manipulate the packets and spoof the IP address so it appears to be coming from my home system? Again though, this doesn't make sense. If the server sees IP address A but connection is really coming from IP address B, the server will send the responses directly to A, not B.

        Furthermore, from looking at the Apache logs, it does appear that the cell is in fact connecting to git.example.com, just for some reason, Apache, when it's a cheap cell phone (or maybe ModSec) is showing the wrong DocumentRoot....very frustrating.

        I don't block the traffic to no one. Just sometimes, when I'm developing, ModSec and / or ConfigServer Firewall, will think that I'm trying to attack my server (ie, me trying to get connect to git.example.com really quick like in a certain number of seconds). This is why I've whitelisted my home IP address in CSF and ModSec. This is also why I've kinda ruled out ModSec and CSF as being the culprit here. But I might be wrong. I see a few ModSec rules seem to get processed before my whitelist rule gets triggered. At least, that's how I interpreted the data.
        -- Law of Expanding Memory: Applications Will Also Expand Until RAM Is Full

        Comment


          #5
          Re: Problems with Apache, subdomains, and cellphones.

          open a shell on the fone and ping your home network, compare the time taken om each fone.

          Comment


            #6
            Re: Problems with Apache, subdomains, and cellphones.

            Originally posted by stj View Post
            open a shell on the fone and ping your home network, compare the time taken om each fone.
            How do I do that? Through ADB? I'm not cell phone suave. It's not rooted or anything. Weird my friends phone exhibit the same symptoms. Makes me think it's a configuration error somewheres on the server side.

            Thanks.
            -- Law of Expanding Memory: Applications Will Also Expand Until RAM Is Full

            Comment


              #7
              Re: Problems with Apache, subdomains, and cellphones.

              It's totally up to the browser (i.e. client side) to do the right thing when connecting to a vhost. If the client side browser does it wrong, you'll get the default site.

              (oh gawd, if we cant trust isps transmitting the right data in an unencrypted connection, then all bets are off.)
              Last edited by eccerr0r; 08-04-2017, 10:48 PM.

              Comment


                #8
                Re: Problems with Apache, subdomains, and cellphones.

                or course you cant trust them.
                remember when the fuckers where injecting extra adds in frames or even reformatting the html to add a banner!!

                and dont think https would stop that, they ARE the man-in-the-middle.
                they could and probably do handshake the encryption key with you, then do the same on the outbound connection to keep it looking encrypted even though both ends are using a different key!

                Comment


                  #9
                  Re: Problems with Apache, subdomains, and cellphones.

                  Originally posted by stj View Post
                  or course you cant trust them.
                  remember when the fuckers where injecting extra adds in frames or even reformatting the html to add a banner!!

                  and dont think https would stop that, they ARE the man-in-the-middle.
                  they could and probably do handshake the encryption key with you, then do the same on the outbound connection to keep it looking encrypted even though both ends are using a different key!
                  The way my server is setup, man in the middle attacks shouldn't be possible. Or at the very least, they would be very hard to pull off.

                  I got to thinking last night. I think my cheap phone and my friends cheap phone are connecting via the IPv4 whereas my wives fancy phone I think has an IPv6 address. When she gets back, I'm going to check this. My DNS server on the VPS has DNSSEC configured in narrow mode. It should be sending out white lies and I thought this made some walking impossible. But I see some stranger has discovered the git subdomain. I wonder how they discovered it and how I can hide RR that I want to remain private...
                  -- Law of Expanding Memory: Applications Will Also Expand Until RAM Is Full

                  Comment


                    #10
                    Re: Problems with Apache, subdomains, and cellphones.

                    Originally posted by eccerr0r View Post
                    It's totally up to the browser (i.e. client side) to do the right thing when connecting to a vhost. If the client side browser does it wrong, you'll get the default site.

                    (oh gawd, if we cant trust isps transmitting the right data in an unencrypted connection, then all bets are off.)
                    We're using the same browser on all three phones, Chrome for Android. I have perfect forward secrecy configured, HSTS, and I'm on the preloading list. For all new versions of Chrome, Firefox, IE, etc. it should be impossible to visit my site with an unencrypted connection. Programs like Lynx don't following the preloading rules so I can visit an unencrypted version of my site. But I have rewrite rules that redirect to the secure version if something like this happens.

                    I wonder if on the server, when I was setting up the VirtualHost directories, if for some reason, I forgot the IPv4 address of the server and just added the IPv6. Maybe some how, Apache has a catch all somewhere for something like this.
                    -- Law of Expanding Memory: Applications Will Also Expand Until RAM Is Full

                    Comment


                      #11
                      Re: Problems with Apache, subdomains, and cellphones.

                      I tried with my wife's cellphone. First, I checked to see if she was using IPv4 or IPv6. She's currently using IPv4 on her cell. I go to git.example.com again, and this time, it shows example.com's website, NOT git.example.com.

                      Yet on the computers, running Chrome, git.example.com shows the login screen for GitLab.

                      Frustrating. The other day, her phone displayed it just fine. Now, today, it doesn't....I followed the GitLab tutorial to configure GitLab to use Apache 2.4 instead of that Nginx or whatever it's called (that comes with GitLab's binary on CentOS). I followed the official documentation and used their configuration file for that. cPanel mutilates the Apache configuration file. They use scripts that modify it. I kinda hate that. It looks real nasty like, not all nice. But you can't just edit /etc/apache2/conf/httpd.conf. The /scripts/rebuildhttpdconf script will always overwrite it. You have to use "include" files or modify templates. cPanel gets updated a lot. Maybe the other day, after I manually setup the virtualhost entries for git.example.com and created the resource records and added them to the DNS zone, maybe cPanel updated, seen the domain and tried creating a virtualhost entry itself. I'll double check the conf files and see if I can figure out what's going on.

                      If I was on a computer, I'd use a program like curl to try and see what's going on. But because I'm on a cell phone, I think my options are limited. Would opening a non-root shell using Adb allow me to connect via the terminal somehow on the cell to the server to see things like the header and responses from the server?

                      Thanks!
                      -- Law of Expanding Memory: Applications Will Also Expand Until RAM Is Full

                      Comment


                        #12
                        Re: Problems with Apache, subdomains, and cellphones.

                        Originally posted by stj View Post
                        and dont think https would stop that, they ARE the man-in-the-middle.
                        they could and probably do handshake the encryption key with you, then do the same on the outbound connection to keep it looking encrypted even though both ends are using a different key!
                        "could and probably" is only a "maybe" but https indeed does stop MITM attacks. However there is a BIG caveat: people usually don't check to make sure that the keys are correct (and most of the times they can't!!!). ISPs can't (easily) fake the real target site's key, but they can give their own valid certificate...

                        In any case, make sure your browser caches are cleared and try again. This leads to the other problem - ISP side caching - ISP doing HTTP caching is evil. HTTPS caching is supposed to be impossible. Any ISPs caught *trying* to cache HTTPS needs to be dragged out into the street and shot even if they don't succeed.

                        Comment


                          #13
                          Re: Problems with Apache, subdomains, and cellphones.

                          I believe I found the problem!!!! I was looking at the VirtualHost entry for git.example.com

                          for cPanel installations, it's the /etc/apache2/conf.d/includes/pre_virtualhost_global.conf file.

                          I saw this:
                          Code:
                          <VirtualHost 192.168.10.2:80 [fe80::f03c:91ff:fee0:11b4]:443>
                          Any see the problem there? I had copied and pasted the IPv4 address from the port 80 configuration, but forgot to modify it so it was for port 443.

                          My wife's cell phone must support IPv6, but for whatever reason, something on her phone must have broken and she must be using IPv4 now. Hence the problem. When she was connecting with IPv6, the VirtualHost entry was being honored, because every connection gets redirected to the secure ports. But when she went back to IPv4, it'd redirect, and Apache must have some catch all, where if the ServerName isn't found, it defaults to whatever the hostname's VirtualHost entry is.

                          I've checked on my phone and my wife's phone, and it's working as expected now.

                          Now I just gotta figure out how someone figured out about the git.example.com DNS resource record. I thought walking my zones wasn't possible because of the DNSSEC and narrow mode.
                          -- Law of Expanding Memory: Applications Will Also Expand Until RAM Is Full

                          Comment


                            #14
                            Re: Problems with Apache, subdomains, and cellphones.

                            Originally posted by eccerr0r View Post
                            "could and probably" is only a "maybe" but https indeed does stop MITM attacks. However there is a BIG caveat: people usually don't check to make sure that the keys are correct (and most of the times they can't!!!). ISPs can't (easily) fake the real target site's key, but they can give their own valid certificate...

                            In any case, make sure your browser caches are cleared and try again. This leads to the other problem - ISP side caching - ISP doing HTTP caching is evil. HTTPS caching is supposed to be impossible. Any ISPs caught *trying* to cache HTTPS needs to be dragged out into the street and shot even if they don't succeed.
                            You are absolutely right about ISPs and caching. Because my site changes a bit, I've disabled caching on the server side. With Chrome, this wasn't the easiest thing to do. Firefox, IE, you can do it the old way. But with Chrome, you gotta do some funky shit.

                            With HSTS, the server tells the client to never allow connections that are unsecure. So a user cannot be forced to connect to a non-secure version of the site, so long as the client supports HSTS and implements it properly, correct?

                            I think by me sending the HSTS header, this makes man-in-the-middle attacks impossible on my server.

                            With DNSSEC properly configured, if someone were to try and redirect my visitors to another site, wouldn't it fail to load? I think this definitely helps to prevent MITM attacks.

                            It prevents DNS cache poisoning, so if I understand it correctly, that means when visitors visit my site, they're certain they're visiting my site and not someone elses site that's designed to look like mine. People can't forge the DNS response and send them to some other site that isn't mine.
                            -- Law of Expanding Memory: Applications Will Also Expand Until RAM Is Full

                            Comment


                              #15
                              Re: Problems with Apache, subdomains, and cellphones.

                              i think you will finf that unless your giving people the actual i.p. address they can get re-directed in a few ways still.
                              DNS is the biggest security flaw, and unless the intended victim knows not to use it or atleast not to use untrustable ones, you cant pretect them.

                              DNS rules:
                              1: dont use google - i dont care how fucking fast it's supposed to be!
                              2: dont use your isp - they will associate and log the lookups to your account.
                              3: dont let the router do the lookups unless you have it running custom firmware - some makers like netgear use their own server regardless of the settings!!
                              4: dont use a DNS in your own country if they are opressive filth that log it all or block sites.
                              (like the u.k., china, germany, france, russia, canada, australia or the u.s.)

                              most people dont know about shit like this:
                              http://www.ukispcourtorders.co.uk/
                              Last edited by stj; 08-05-2017, 03:17 PM.

                              Comment


                                #16
                                Re: Problems with Apache, subdomains, and cellphones.

                                I know places like Google doesn't take them to my actual site at first (google for something, instead of clicking on the link, right click, copy the link, then paste. You'll see it's not the place you want to go but some google site with the site you want to go to appended. I think this is for data mining purposes (aka, analytics)).

                                But with DNSSEC, when they query my website, they will always end up at my site, right? I mean, this was one of the biggest problems with DNS originally, cache poisoning, wasn't it? Tell people that server A isn't really located at location A, but really location B. So when they try going to server A, instead of ending up at location A, they end up at location B, accessing server B. I thought DNSSEC fixed that.

                                Am I wrong in this? Obviously, if someone's gained control of the actual clients computer, they could redirect traffic and interfere (ie, rootkits for Windows).
                                -- Law of Expanding Memory: Applications Will Also Expand Until RAM Is Full

                                Comment


                                  #17
                                  Re: Problems with Apache, subdomains, and cellphones.

                                  it's my understanding that DNSSEC is just a layer of encryption on the lookups,
                                  it wont help if the actual server is "working for the darkside"

                                  my whole setup is fixed-i.p. and i put specific dns servers in the computer settings.
                                  i wont be hijacked by the isp or router.
                                  and i wont let my network get screwed over by a dhcp scan.
                                  (because there is no server-process to query)

                                  Comment


                                    #18
                                    Re: Problems with Apache, subdomains, and cellphones.

                                    I don't think it's just a layer of encryption for the queries. For example, even though I have PowerDNS configured, and DNSSEC properly configured, I can configure DNSSEC in such a way, where people can walk my zone. They can figure out exactly what subdomains I have. When I configure it for narrow mode, it sends out these "white lies" and it's supposed to be impossible to walk my zone.

                                    But it does more than that. I believe (I can run some tests), if the digest on my server doesn't match the digest at the registrar, people won't be allowed to visit my site. They'll get a message saying someone might be trying to impersonate my site and they've been denied access because of this.

                                    I'll do some tests at the registrar and change the digest to see what happens. But that'll have to happen tomorrow. Gonna go spend some quality time with the wife and then get some sleep.
                                    -- Law of Expanding Memory: Applications Will Also Expand Until RAM Is Full

                                    Comment

                                    Working...
                                    X