On Tuesday, August 27, 2019 10:09:12 AM MST Stephen John Smoogen wrote: > On Tue, 27 Aug 2019 at 13:01, Vitaly Zaitsev via devel > <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > On 27.08.2019 18:14, Björn Persson wrote: > > > > > If it could come from anywhere, then we must assume that it's > > > malicious. > > > You executed untrusted code. It's already past your firewall. Game > > > over, > > > you're infected. You're closing the stable door after the horse has > > > bolted. > > > > > > > > Any application can run backdoor or proxy on your machine with disabled > > firewall. Everyone from the Internet can connect it. > > > > > > > > If the firewall is enabled and all ports are closed, hacker cannot > > access your system. They will need to bypass firewall first and this is > > much more difficult. > > > > > > > You are both talking past each other and not seeming to get anywhere. > > Bjorn is talking about where the backapp is not opening up a localport > but tunnelling out via a vpn to a command and control device. The only > way to stop that is where your firewall also drops outbound > connections. Since most firewalls do not do that, the attack vector > they are discussing will bypass a firewall. > > Vitaly is talking about the other attack where the backdoor app opens > a local listening port which can then be access from the outside. This > used to be the standard security hole because setting up a CC and > doing reverse networking was hard for most hackers. > > The problem is that most toolkits come with the VPN solution these > days so a hacking group don't have to be rock-stars in > programming/networking to set it up. N number of satoshi on some > darkweb will get you a javascript tool which can be injected on a > webpage and do all the work for the hacker. So Bjorn is trying to > point out that the problem you need to worry about is not solved by > the shipped firewall. Instead some level of application firewall would > be needed to even 'try' to stop this. > > > > > -- > > Sincerely, > > > > Vitaly Zaitsev (vitaly@xxxxxxxxxxxxxx) > > > > _______________________________________________ > > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List > > Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List > > Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o > > rg > > > > -- > Stephen J Smoogen. > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List > Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List > Archives: > https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx The difference between the two is just in how it applies to this topic. The firewall, in this context, mostly applies to remote access to our locally bound ports. There is also a significant difference between these two issues With one, the end user is going out, and accidentally running something, or running vulnerable code. Their system is then affected in ways unknown, and we do our best effort. In the other, with a proper firewall config, you'd have to wait for the user to go out from there, if they do. With the GNOME spin's default, that's not the case, you're already a sitting duck, and the users aren't warned of this anywhere. -- John M. Harris, Jr. <johnmh@xxxxxxxxxxxxx> Splentity https://splentity.com/ _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
