News: This forum is now permanently frozen.
linktree m0n0wall Forum  >  m0n0wall Support (English)  >  Services  >  Captive Portal
linktree Topic: apparent flaw in captive portal 1.3b13...?
Pages: [1]
Topic: apparent flaw in captive portal 1.3b13...?  (Read 3091 times)
« on: August 14, 2008, 20:18:05 »
joeymorin *
Posts: 4
greetings forum readers.

been a long time since i've posted...

i've been playing around with CP under 1.3b13.  i'm rather new to it.

however, i've seen some unexplained behaviour.  it would appear that some traffic is being permitted out the wan, WITHOUT authentication.  in fact, without even getting served the portal page.

here are the relevant log entries:

Time      Src IP      Src Prt   Dst IP         Dst Prt   Proto
00:23:12.671996   192.168.108.253   5353   192.168.108.1      53   UDP
00:23:12.677943   192.168.108.253   5353   224.0.0.251      5353   UDP
00:23:13.432406   192.168.108.253   5353   224.0.0.251      5353   UDP
00:23:16.082183   192.168.108.253   5353   224.0.0.251      5353   UDP
00:23:28.094201   192.168.108.253   5353   224.0.0.251      5353   UDP
00:50:25.949305   192.168.108.253   5353   192.168.108.1      53   UDP
00:50:25.993620   192.168.108.253   49257   qb-in-f111.google.com   993   TCP
00:50:26.107267   192.168.108.253   5353   224.0.0.251      5353   UDP
00:50:57.167484   192.168.108.253   49258   qb-in-f109.google.com   993   TCP
01:06:19.210260   192.168.108.253   5353   192.168.108.1      53   UDP
01:06:19.224786   192.168.108.253   5353   224.0.0.251      5353   UDP
01:06:24.125292   192.168.108.253   49259   qb-in-f111.google.com   993   TCP
01:06:54.169871   192.168.108.253   49260   qb-in-f111.google.com   993   TCP
01:07:24.162549   192.168.108.253   49261   qb-in-f111.google.com   993   TCP
01:22:53.045409   192.168.108.253   5353   192.168.108.1      53   UDP
01:22:53.047851   192.168.108.253   5353   224.0.0.251      5353   UDP
01:22:53.294833   192.168.108.253   5353   224.0.0.251      5353   UDP
01:22:54.798671   192.168.108.253   5353   224.0.0.251      5353   UDP
01:22:59.045281   192.168.108.253   5353   224.0.0.251      5353   UDP
01:22:59.318045   192.168.108.253   49262   qb-in-f109.google.com   993   TCP
01:23:23.058018   192.168.108.253   5353   224.0.0.251      5353   UDP
01:23:29.333937   192.168.108.253   49263   qb-in-f109.google.com   993   TCP
01:23:59.363029   192.168.108.253   49264   qb-in-f109.google.com   993   TCP
01:39:28.210379   192.168.108.253   5353   192.168.108.1      53   UDP
01:39:28.212659   192.168.108.253   5353   224.0.0.251      5353   UDP
01:39:34.255000   192.168.108.253   49265   qb-in-f109.google.com   993   TCP
01:40:04.283483   192.168.108.253   49266   qb-in-f109.google.com   993   TCP
01:40:34.302736   192.168.108.253   49267   qb-in-f109.google.com   993   TCP
01:56:05.675798   192.168.108.253   5353   192.168.108.1      53   UDP
01:56:05.679224   192.168.108.253   5353   224.0.0.251      5353   UDP
01:56:06.060065   192.168.108.253   5353   224.0.0.251      5353   UDP
01:56:09.063257   192.168.108.253   5353   224.0.0.251      5353   UDP
01:56:09.339152   192.168.108.253   49268   qb-in-f111.google.com   993   TCP
01:56:21.073319   192.168.108.253   5353   224.0.0.251      5353   UDP
01:56:39.356874   192.168.108.253   49269   qb-in-f111.google.com   993   TCP
01:57:03.895970   192.168.108.253   5353   224.0.0.251      5353   UDP
01:57:09.405263   192.168.108.253   49270   qb-in-f111.google.com   993   TCP
02:12:40.672045   192.168.108.253   5353   192.168.108.1      53   UDP
02:12:40.676443   192.168.108.253   5353   224.0.0.251      5353   UDP
02:12:41.061640   192.168.108.253   5353   224.0.0.251      5353   UDP
02:12:44.059763   192.168.108.253   5353   224.0.0.251      5353   UDP
02:12:44.395969   192.168.108.253   49271   qb-in-f109.google.com   993   TCP
02:12:52.684481   192.168.108.253   5353   224.0.0.251      5353   UDP
02:13:14.423233   192.168.108.253   49272   qb-in-f109.google.com   993   TCP
02:13:44.499498   192.168.108.253   49273   qb-in-f109.google.com   993   TCP

the dns lookups are expected.
i don't know why multicast dns is being passed, nor why IMAPS is being passed to the google servers.  note that there isn't a single html request, and the portal page is never served.  there is therefore no captive portal log entries.

from dhcpd.log:  Aug  8 00:23:09 spike dhcpd: DHCPOFFER on 192.168.108.253 to 00:1e:c2:d4:66:4f (iKev-Wireless) via ath0

a mac address lookup shows this is an apple device.

i'm guessing it's an i-touch, or an i-phone, or some other mobile apple device.

in all other respects, captive portal appears to work as expected.

does anyone have any ideas what is going on?  am i missing something obvious?

many thanks!
jj

-------------------------------------

here are the relevant sections from config.xml:

    <captiveportal>
        <page>
            <htmltext>...ommited.for.brevity...</htmltext>
            <errtext>...ommited.for.brevity...=</errtext>
        </page>
        <timeout>60</timeout>
        <interface>opt1</interface>
        <maxproc/>
        <idletimeout/>
        <enable/>
        <auth_method>local</auth_method>
        <reauthenticateacct/>
        <httpsname/>
        <certificate/>
        <private-key/>
        <logoutwin_enable/>
        <bwdefaultdn>56</bwdefaultdn>
        <bwdefaultup>32</bwdefaultup>
        <redirurl>http://192.168.108.1:8000/captive_redirect.html</redirurl>
        <radiusip/>
        <radiusip2/>
        <radiusport/>
        <radiusport2/>
        <radiusacctport/>
        <radiuskey/>
        <radiuskey2/>
        <radiusvendor>default</radiusvendor>
        <radmac_format>default</radmac_format>
        <user>
            <name>guest</name>
            <fullname>guest</fullname>
            <expirationdate/>
            <password>xxxxx</password>
        </user>
        <element>
            <name>logo.gif</name>
            <size>2336</size>
            <content>...ommited.for.brevity...</content>
        </element>
        <element>
            <name>captive_redirect.html</name>
            <size>430</size>
            <content>...ommited.for.brevity...</content>
        </element>
        <peruserbw/>
    </captiveportal>



and these are the relevant rules:

        <rule>
            <type>block</type>
            <interface>opt1</interface>
            <source>
                <network>opt1</network>
            </source>
            <destination>
                <network>lan</network>
            </destination>
            <log/>
            <descr>Deny WLAN -&gt; LAN</descr>
        </rule>
        <rule>
            <type>block</type>
            <interface>opt1</interface>
            <protocol>tcp</protocol>
            <source>
                <network>opt1</network>
            </source>
            <destination>
                <address>192.168.108.1</address>
                <port>443</port>
            </destination>
            <log/>
            <descr>Deny WLAN -&gt; webgui https</descr>
        </rule>
        <rule>
            <type>block</type>
            <interface>opt1</interface>
            <source>
                <network>opt1</network>
            </source>
            <destination>
                <network>pptp</network>
            </destination>
            <log/>
            <descr>Deny WLAN -&gt; PPTP clients</descr>
        </rule>
        <rule>
            <type>block</type>
            <interface>opt1</interface>
            <source>
                <network>opt1</network>
            </source>
            <destination>
                <address>192.168.2.0/24</address>
            </destination>
            <log/>
            <descr>Deny WLAN -&gt; Joey's LAN</descr>
        </rule>
        <rule>
            <type>pass</type>
            <interface>opt1</interface>
            <source>
                <network>opt1</network>
            </source>
            <destination>
                <any/>
            </destination>
            <log/>
            <descr>Default WLAN -&gt; any</descr>
        </rule>
« Reply #1 on: August 18, 2008, 18:26:26 »
joeymorin *
Posts: 4
an update:

so, i had trouble believing that m0n0wall could have what appeared to be such a serious flaw.  long story short, it doesn't.

i put a machine running wireshark on the wan side of my m0n0, and found that despite the logs showing packets being passed (because that's what the rules say!), nothing was actually making it out the wan.

seems i misunderstood the way captive portal works.  i assumed the CP trapped packets BEFORE the rule filters.  seems that's not the case.  makes sense i suppose, since to work properly DNS has to pass first.

however, this brings up an interesting question.  what if CP were changed so that there were TWO rule sets:  one for un-authenticated traffic, another for authenticated traffic.  in a way, the pass-through functionality of CP is a way of achieving this, but without the fine control that firewall rules allow.  would there be any value to this?

cheers,
jj
« Reply #2 on: August 18, 2008, 18:51:16 »
joeymorin *
Posts: 4
one more thing:

to be clear, what i think the value of two rule-sets would be is to be able to differentially log unauthenticated traffic from authenticated traffic.  does anyone else think this would be useful?


Quote from: joeymorin on August 18, 2008, 18:26:26
an update:

so, i had trouble believing that m0n0wall could have what appeared to be such a serious flaw.  long story short, it doesn't.

i put a machine running wireshark on the wan side of my m0n0, and found that despite the logs showing packets being passed (because that's what the rules say!), nothing was actually making it out the wan.

seems i misunderstood the way captive portal works.  i assumed the CP trapped packets BEFORE the rule filters.  seems that's not the case.  makes sense i suppose, since to work properly DNS has to pass first.

however, this brings up an interesting question.  what if CP were changed so that there were TWO rule sets:  one for un-authenticated traffic, another for authenticated traffic.  in a way, the pass-through functionality of CP is a way of achieving this, but without the fine control that firewall rules allow.  would there be any value to this?

cheers,
jj
 
Pages: [1]
 
 
Powered by SMF 1.1.20 | SMF © 2013, Simple Machines