<div style="color:rgb(69,69,69);font-family:UICTFontTextStyleBody;font-size:17px;text-decoration:-webkit-letterpress"><span style="background-color:rgba(255,255,255,0)">Hi <yonjah>,</span></div><div style="color:rgb(69,69,69);font-family:UICTFontTextStyleBody;font-size:17px;text-decoration:-webkit-letterpress"><span style="background-color:rgba(255,255,255,0)"><br></span></div><div style="color:rgb(69,69,69);font-family:UICTFontTextStyleBody;font-size:17px;text-decoration:-webkit-letterpress"><span style="background-color:rgba(255,255,255,0)">This is really in reply to anyone who still doesn't understand...</span></div><div style="color:rgb(69,69,69);font-family:UICTFontTextStyleBody;font-size:17px;text-decoration:-webkit-letterpress"><span style="background-color:rgba(255,255,255,0)"><br></span></div><div style="color:rgb(69,69,69);font-family:UICTFontTextStyleBody;font-size:17px;text-decoration:-webkit-letterpress"><span style="background-color:rgba(255,255,255,0)">My approach is not complex, but it is time-consuming, I'll admit. But any sysadmin worth their salt should be doing similar things, establishing verified, trusted copies of the OS install file(s) and security updates, creating trusted system backup images, securing their network devices and policies, etc. Nothing unusual other than that it's for a home setup dedicated solely for limited important online work (online banking, etc).</span></div><div style="color:rgb(69,69,69);font-family:UICTFontTextStyleBody;font-size:17px;text-decoration:-webkit-letterpress"><span style="background-color:rgba(255,255,255,0)"><br></span></div><div style="color:rgb(69,69,69);font-family:UICTFontTextStyleBody;font-size:17px;text-decoration:-webkit-letterpress"><span style="background-color:rgba(255,255,255,0)">I've mentioned the threat or exposure in just about every email in this thread: an untrusted SOHO router. Have a look at <a href="http://routersecurity.org/bugs.php">http://routersecurity.org/bugs.php</a>. A cursory scan will show you how many SOHO routers are vulnerable or are being actively exploited by whoever (it doesn't really matter who). How can one reconcile all these vulnerabilities and exploits with a network policy that refuses to accept a SOHO router may not be trustworthy?</span></div><div style="color:rgb(69,69,69);font-family:UICTFontTextStyleBody;font-size:17px;text-decoration:-webkit-letterpress"><span style="background-color:rgba(255,255,255,0)"><br></span></div><div style="color:rgb(69,69,69);font-family:UICTFontTextStyleBody;font-size:17px;text-decoration:-webkit-letterpress"><span style="background-color:rgba(255,255,255,0)">ATMs aside, would anyone use XP for their online banking? Of course they wouldn't, but we don't need to define the threats, the actors, perceived v real risks, ad infinitum, to justify that decision.</span></div><div style="color:rgb(69,69,69);font-family:UICTFontTextStyleBody;font-size:17px;text-decoration:-webkit-letterpress"><br></div><div style="color:rgb(69,69,69);font-family:UICTFontTextStyleBody;font-size:17px;text-decoration:-webkit-letterpress"><span style="background-color:rgba(255,255,255,0)">I agree</span> <yonjah> that <span style="background-color:rgba(255,255,255,0)">MD5 is broken, but it's only really an issue for small files, passwords, server certs, etc, that can be modified and MD5'd many times a second in the search for a collision. But no-one's gonna run millions and millions of modified 1GB .iso files thru MD5, trying to generate a collision, although I guess they could work with an intermediate checksum (e.g. for the 1st 990MB, and then continue the hash with millions of variations for the remaining bytes). Anyway, I do use SHA algorithms (or some combination of them) as well, especially for smaller files.</span></div><div style="color:rgb(69,69,69);font-family:UICTFontTextStyleBody;font-size:17px;text-decoration:-webkit-letterpress"><span style="background-color:rgba(255,255,255,0)"><br></span></div><div style="color:rgb(69,69,69);font-family:UICTFontTextStyleBody;font-size:17px;text-decoration:-webkit-letterpress"><span style="background-color:rgba(255,255,255,0)">Btw, there are theoretically billions of collisions no matter whether you use a 128, 160, 256, 384, or 512-bit checksum. All of these checksums have by definition a finite number of outputs (e.g. 2^512), but you can feed in an infinite range of file data, so a vast number of collisions must be possible whether it's MD5 or SHA512. They're just very very rare, especially with the larger outputs.</span></div><div style="color:rgb(69,69,69);font-family:UICTFontTextStyleBody;font-size:17px;text-decoration:-webkit-letterpress"><span style="background-color:rgba(255,255,255,0)"><br></span></div><div style="color:rgb(69,69,69);font-family:UICTFontTextStyleBody;font-size:17px;text-decoration:-webkit-letterpress"><span style="background-color:rgba(255,255,255,0)">Cheers, Dirk</span></div><div style="color:rgb(69,69,69);font-family:UICTFontTextStyleBody;font-size:17px;text-decoration:-webkit-letterpress"><span style="background-color:rgba(255,255,255,0)"><br></span></div><div style="color:rgb(69,69,69);font-family:UICTFontTextStyleBody;font-size:17px;text-decoration:-webkit-letterpress"><span style="background-color:rgba(255,255,255,0)"><br></span></div><br>On Friday, 23 October 2015, ıuoʎ <<a href="mailto:yonjah@gmail.com">yonjah@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Sorry, didn't notice I replied personally to you.<br>You can reply publicly on the list</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 23, 2015 at 2:58 PM, Dirk <span dir="ltr"><<a href="javascript:_e(%7B%7D,'cvml','justanothergreenguy@gmail.com');" target="_blank">justanothergreenguy@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi <yonjah>, do you prefer I didn't respond via the PLUG list?<div><div><div><br></div><div><br><br>On Thursday, 22 October 2015, ıuoʎ <<a>yonjah@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>Dirk. <br></div>You keep mentioning MD5 for checksums. As far as I know MD5 is horribly broken and should not be trusted.<br></div>Any way it is still not clear what threat you are trying to protect.<br></div>Preventing your router from joining a bot net ? all the protection you'll to your pc connection are meaning less<br></div>Protecting your communication from point A to B ? <br>From who ? from you next door neighbour ? your ISP disgruntled employee ?a big and unnamed government agency ? The measurements your going to take are going to be different for each adversary and for a big enough player anything you'll do wont be good enough but for average to small one we have plenty of good and simple solution to securily communicating from A to B without trusting any node on the way (which method depends more on B and what kind of control you have over it)<br><br></div><div>Your setup sounds highly complex and sometime and can actually be damaging.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 22, 2015 at 8:57 PM, Dirk <span dir="ltr"><<a>justanothergreenguy@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Bill,<div><br></div><div>Your setup probably makes a lot of sense for your needs, but I don't need to remote out or remote in, or support VoIP, or support multiple platforms. It's just one PC and a modem router. There should be a simple solution.<div><br><div>I wipe and restore my throwaway Linux OS and swap part'n after each online session, and restore a fresh trusted MBR each time. The throwaway OS is updated offline using verified package lists and security update .deb's from previous sessions (from CD, not USB). My Mint ISO is a verified good copy (MD5). And yet I'm experiencing corrupted package lists, so I can only suspect my BIOS or the router. I don't think BadUSB exploits are circulating as yet, so the mouse and keyboard should be fine. I'm careful where I browse and what I click on when using this PC. Java, Flash, JavaScript (unless req'd), application launching in the browser, linked fonts, smbd, avahi-daemon, auto-mounting, etc etc are all disabled. I'm far less concerned when I'm using other devices with my wifi router, as I don't log into anything important with them.</div><div><br></div><div>So my consumer / SOHO modem router is by far the weakest link. It's secured as best as possible (re UPnP and WAN-side admin disabled, strong admin password, no wireless functionality, unsolicited packets are dropped, etc etc), but the firmware is well out of date (no surprises there, most are), and hackers are turning their attention to SOHO routers, coz most people wouldn't know it if their router was hacked and added to a botnet (or whatever); e.g. AV doesn't reach into the router. SOHO routers are the new low-hanging fruit for hackers.</div><div><br></div><div>So I don't think it's all that unreasonable for a SOHO to regard their SOHO router as untrusted (i.e. like anyone needing to connect thru an untrusted hotel (W)LAN, for instance), and to seek a solution that allows for such untrusted elements, as per my original post.</div><div><br></div><div>You are of course right. There are many many areas of risk apart from the router. But what other vulnerabilities can I address? What do you mean by 'real risks', if not what I'm already addressing above?</div><div><div><div><br></div><div><br></div><div><br></div><div><br><br>On Thursday, 22 October 2015, BillK <<a>billk@iinet.net.au</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>The VPN is set up for multiple clients in routed mode. I regularly use an android phone and tablet, occasionally a windows desktop and site to site links. I did set up an iPad at one time. Carries ssh, email, calendaring, sip VoIP, security video etc all on private networks. It's all tied together by ospf on the router and various gentoo Linux hosts including the VPN concentrator VM.<br>
<br>
I also use a stunnel instance in the VM with proxy tunnel and putty on windows to tunnel ssh out of heavily locked down networks. Both openvpn and tunnel listen on public non-standard ports port forwarded through the router. SSL is also port forwarded to an ssl multiplexor in the VM listening on port443 to redirect incoming SSL to either openvpn or stunnel as required, the end points terminate as SSH on my desktop.<br>
<br>
It sounds complex, isn't really and is quite useful. <br>
<br>
However what has bothered me about this thread is the emphasis on the router as a problem ... It generally isn't, a router is not automatically compromised so fix that vulnerability first, then attend to real risks. These days you are at far more risk from perverted/subverted mobile devices ... In the scheme of things routers are just one of, and definitely not the main thing you have to worry about.<br>
<br>
BillK<br>
<br><br><div class="gmail_quote">On 22 October 2015 4:25:51 pm AWST, Dirk <<a>justanothergreenguy@gmail.com</a>> wrote:<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Thanks Bill,<div><br>Your setup looks a bit too complicated for me as well :) ...but good to know iiNet are assigning private IP addresses to their mobile users.</div><div><br></div>Is the VPN just between your VM and your phone? Interesting idea, although I'm not sure Android would be the safest bet :) ...oops, I hope I didn't start any Android v iPhone pie-slinging :)<div><br></div><div>Anyway, I think I'm going to pursue the 4G USB modem idea for now, and see how I go.</div><div><br></div><div>Thanks everyone so much for your ideas and comments. I didn't mean for my wee little Qu to dominate the PLUG forum, and I kinda feel like I'm stretching my welcome a little bit for a first time contributor, so I do apologise to all who put up with me the last few days.</div><div><br></div><div>But if the group is ok with it, and anyone has any further ideas, or feedback on the 4G USB modem approach, please don't hesitate to let me
know.</div><div><br></div>Cheers, Dirk<div><br><div><br><div><br><br>On Thursday, 22 October 2015, Bill Kenworthy <<a>billk@iinet.net.au</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">my iinet mobile (GalaxyS5 with cyanogenmod) is using a 10.160 private<br>
address - I have no problems running openvpn over it to a vm inside my<br>
network (including security camera video over the vpn when I want to<br>
take a peek). I am using a Cisco 1841 with an alcatel speadstream<br>
bridged with the router doing pppoe to iinet. Stable but I need to work<br>
on the QoS more.<br>
<br>
BillK<br>
<br>
<br>
<br>
On 22/10/15 07:12, Dean Bergin wrote:<br>
> Hello Dirk,<br>
><br>
> This is probably not going to help solve your particular issue, but one<br>
> thing I recently did, was install OpenWRT on a Rpi2 and set up PPPoE<br>
> over one of two subinterfaces (VLAN) to a cheap netgear modem (with the<br>
> help of a Cisco Catalyst switch). I also put the Rpi2 OpenWRT<br>
> effectively into it's own routed subnet/DMZ (part of the design) so that<br>
> even if there where to be some kind of funny business, things like uPNP<br>
> theoretically should not work since my experience has taught me that<br>
> most consumer-grade modems/routers do not route/NAT anything other than<br>
> their resident subnet, therefore I believe that not only are uPNP<br>
> implementations (and many other services on consumer-grade routers)<br>
> usually bound to the subnet to which they are running on, but should be<br>
> disabled in cases where the device is in pass-through mode.<br>
><br>
>>Does anyone know whether 4G modems (and smart phones, for that matter)<br>
> are assigned a publicly-routable IP address or are they<br>
> typically NAT'd behind a small number of IP addresses of the mobile<br>
> service provider's servers? I can't imagine billions(?) of mobile<br>
> phones all having unique publicly-routable IP addresses (on top of all<br>
> the servers and so on, around the world).<br>
><br>
> I had the opportunity to test this, as I was able to tether my phone to<br>
> a Rpi2 running OpenWRT as part of the labs I did for my now current<br>
> nework design, but I did not think to test this specific scenario.<br>
><br>
> Shouldn't be too difficult to create a lab to test this, if someone has<br>
> a spare raspberry pi (mine is currently in 'prod' now)?<br>
><br>
><br>
> On Wed, Oct 21, 2015 at 6:27 PM Dirk <<a>justanothergreenguy@gmail.com</a><br>
> <mailto:<a>justanothergreenguy@gmail.com</a>>> wrote:<br>
><br>
> Thanks Andrew. Will follow up on those ideas too, thanks.<br>
><br>
> However, I have another idea, a bit left field, but it may just do<br>
> the trick...<br>
><br>
> Does anyone know whether 4G modems (and smart phones, for that<br>
> matter) are assigned a publicly-routable IP address or are they<br>
> typically NAT'd behind a small number of IP addresses of the mobile<br>
> service provider's servers? I can't imagine billions(?) of mobile<br>
> phones all having unique publicly-routable IP addresses (on top of<br>
> all the servers and so on, around the world).<br>
><br>
> If they're NAT'd, then maybe a pre-paid 4G USB modem dongle would be<br>
> the way to go for low MB critical online work, eg. fetching package<br>
> lists, logging in to ASIC, ATO, webmail, our utilities, etc. Should<br>
> block all scanners on the net that are looking for routers to<br>
> exploit, by virtue of sitting behind the Svc providers routers.<br>
> (...and then use an unsecured computer and ADSL router pair for<br>
> general web browsing, content streaming, etc).<br>
><br>
> Does anyone know if this would work?<br>
><br>
> (Of course, if a 4G dongle is not NAT'd then I don't really gain<br>
> anything).<br>
><br>
><br>
><br>
><br>
> On Wednesday, 21 October 2015, Andrew Cooks <<a>acooks@gmail.com</a><br>
> <mailto:<a>acooks@gmail.com</a>>> wrote:<br>
><br>
> On Wed, Oct 21, 2015 at 9:43 AM, Dirk<br>
> <<a>justanothergreenguy@gmail.com</a>> wrote:<br>
><br>
><br>
> Cheers for that Pavel. And thanks again Brad for your<br>
> input. You've both given me some ideas, although I was<br>
> hoping for an easy OpenVPN option :)<br>
><br>
> If anyone else has any thoughts or suggestions, please let<br>
> me know!<br>
><br>
> My internet access is slow enough, so I'm not really excited<br>
> about pushing everything through a VPN.<br>
><br>
> I trust my router. I have a TP-Link TD-8817 modem in bridge<br>
> mode, connected to a fit-pc<br>
> (<a href="http://www.fit-pc.com/web/solutions/multilan/" target="_blank">http://www.fit-pc.com/web/solutions/multilan/</a>) running IPFire<br>
> (<a href="http://www.ipfire.org/" target="_blank">http://www.ipfire.org/</a>). IPFire tells me I can trust my DNS.<br>
> IPFire packages are kept up to date. The modem could conceivably<br>
> modify the PPPoE frames in transit, except that it's a dirt<br>
> cheap consumer product with little functionality that could be<br>
> exploitable and it's unlikely to have enough processing power to<br>
> do that kind of thing.<br>
><br>
> There is nowhere safe, only acceptable risks.<br>
><br>
> a.<br>
><br>
> _______________________________________________<br>
> PLUG discussion list: <a>plug@plug.org.au</a> <mailto:<a>plug@plug.org.au</a>><br>
> <a href="http://lists.plug.org.au/mailman/listinfo/plug" target="_blank">http://lists.plug.org.au/mailman/listinfo/plug</a><br>
> Committee e-mail: <a>committee@plug.org.au</a> <mailto:<a>committee@plug.org.au</a>><br>
> PLUG Membership: <a href="http://www.plug.org.au/membership" target="_blank">http://www.plug.org.au/membership</a><br>
><br>
> --<br>
><br>
> Kind Regards,<br>
><br>
> /Dean Bergin/.<br>
><br>
><br>
><br>
> _______________________________________________<br>
> PLUG discussion list: <a>plug@plug.org.au</a><br>
> <a href="http://lists.plug.org.au/mailman/listinfo/plug" target="_blank">http://lists.plug.org.au/mailman/listinfo/plug</a><br>
> Committee e-mail: <a>committee@plug.org.au</a><br>
> PLUG Membership: <a href="http://www.plug.org.au/membership" target="_blank">http://www.plug.org.au/membership</a><br>
><br>
<br>
_______________________________________________<br>
PLUG discussion list: <a>plug@plug.org.au</a><br>
<a href="http://lists.plug.org.au/mailman/listinfo/plug" target="_blank">http://lists.plug.org.au/mailman/listinfo/plug</a><br>
Committee e-mail: <a>committee@plug.org.au</a><br>
PLUG Membership: <a href="http://www.plug.org.au/membership" target="_blank">http://www.plug.org.au/membership</a><br>
</blockquote></div></div></div>
<p style="margin-top:2.5em;margin-bottom:1em;border-bottom:1px solid #000"></p><pre><hr><br>PLUG discussion list: <a>plug@plug.org.au</a><br><a href="http://lists.plug.org.au/mailman/listinfo/plug" target="_blank">http://lists.plug.org.au/mailman/listinfo/plug</a><br>Committee e-mail: <a>committee@plug.org.au</a><br>PLUG Membership: <a href="http://www.plug.org.au/membership" target="_blank">http://www.plug.org.au/membership</a></pre></blockquote></div><br>
-- <br>
Sent from my Android phone with K-9 Mail. Please excuse my brevity.</div></blockquote></div></div></div></div></div>
<br>_______________________________________________<br>
PLUG discussion list: <a>plug@plug.org.au</a><br>
<a href="http://lists.plug.org.au/mailman/listinfo/plug" rel="noreferrer" target="_blank">http://lists.plug.org.au/mailman/listinfo/plug</a><br>
Committee e-mail: <a>committee@plug.org.au</a><br>
PLUG Membership: <a href="http://www.plug.org.au/membership" rel="noreferrer" target="_blank">http://www.plug.org.au/membership</a><br></blockquote></div><br></div>
</blockquote></div>
</div></div></blockquote></div><br></div>
</blockquote>