Of course it's boring, I'm not allowed to say everything I have in mind Like I've said many times, there's not reason for a "password-stealer" file to be present unless YOU install it on your own. In that case, the problem is still the same as it has ever been: you. Because humans are not perfect, and even though developers try to make their software bug-free it's impossible to do that. You should be grateful that there are security teams handling and fixing these things, because on Windows you must rely on 100 people to find bugs and that include bugs on the security software you love so much. Just recently there were discoveries of vulnerabilities on Kaspersky and a handful of security programs that allowed for remote control of the machine. By your logic you should also install a program that would protect you from Kaspersky, right? But then you'd need a program to make sure that this program protecting you from Kaspersky also won't affect you from vulnerabilities! Oh no!! You're on an endless loop! You're again disrespecting security teams like the Debian or even the grsecurity ones. I'm not even going to respond to this level of ignorance. And you think your little Sophos will protect you in case that happens? LOL, you're a freaking comedian! You see, even if this actually happened, the downloaded package digital signature (.sig) wouldn't match what the other servers and your computer know, and this would cause an alert to everyone attempting to install that package, and it would be removed quickly and the server fixed. DONE. Except you don't realise you're wrong almost EVERY SINGLE TIME All you do is spread FUD, say "what ifs" that wouldn't affect you in any way, puke false claims that you can never back up with logic or reason (only with fear and conspiracy theories). Like me and others have said: You're bringing the Windows mindset to Linux. You're wrong, you just can't admit because of your ego. So sad. A good politician, for sure I know what they're capable of. Problem is, it seems you think they have some sort of magical power, not only them but these security companies too. Almost every conspiracy stupidity you say has no way of being scientifically verified, because it simply makes no sense. Like I said on my previous post, anyone can read your threads and see how wrong you are.
And that is where I know thats its time to stop discussing with you. Not the fact that everything is repeating and its useless answers and non-valid reasons but the fact that every example (eh I mean my stupid conspiracy) I have brought up has already happened numerous times in the past and/or are features/standart for malware since.. 2008? So then again, you dont seem know what malware can do and did alrrady and does on a daily basis just like their developers. The the other side you also dont seem to understand how security products (on windows) work and what they are for and why they are so critical.
Linux, OS X, BSD and all unix derived systems have architectural security that is based in limiting privilege. These OSes aren't sloppy with privilege in the way Windows is so the security paradigm is different. AVs with signature based scanning are less and less relevant these days even in Windows. In an OS that is locked down by default where privilege escalation is much more difficult, even more so. Amarildojr has a really good approach here. Whitelisting is always superior to blacklisting and just allowing the few necessary connections will prevent all kinds of malware exploits at both client and server level. With such a mechanism in place, an AV with a signature based blacklisting approach is going to be an auxiliary security mechanism, not a main one.
We are talking about completely different things here: I never said AVs with signature based scanning are any good.. they maybe were in 1990 but these days they aren't state of the art. Yes Linux is more locked down, but that doesn't help in the example I have given previousl (because you will actively grant something permission, because you won't change complete source code of e.g. libreoffice or firefox or... everytime it updates). Yes, blacklisting is always superior to white listening, I never said anything else. But that is not the case. KeePass, Browser, everything on my arch linux so far is able to connect where ever and when ever it wants. And that is easy play for any exploit. And that is exactly what disturbed me. I want each application to only be able to make the connections that are really necessary. So I think we are having the same goal here. Still an anti-malware solution would make sense (no, not and av with signature based scanning).
It's possible with Tomoyo too. For example, having inet dgram connect @ip-address port-number in the tomoyo profile will only allow the application to connect to the specific ip-address and through a specific port. It's not just only firewalling, the MAC thing in linux really provides very fine-grained control over applications. And as mentioned by mirmir, you can achieve application-specific firewalling by creating an application-specific user. People who want to secure their linux box should first try to learn things before declaring this and that about things they do not no much.
You simply don't understand the concept of open ports. I repeat: Arch Linux does not have open ports by default. Controlling outbound requests is a different story and usually unnecessary in Linux. Huh? Are you really sure that you know what you're talking about? I'm just using a handful packages or a bit more from the AUR. All other packages are from the official repositories.
You simply don't understand what I am refering to: Sending files away from your computer (e.g. password, personal information, etc). I haven't talked/mentioned/or said anything about incoming connections, never. For me, outbound requests are as important as inbound, if not more important. Malware an my system which I can't dedect / notice? Well blocking its outbound request will semi-fix that atleast. True, the official repo has a lot of packages (and I love it !) but still I would need quite some stuff from the AUR.
It's VERY hard to get malware on Linux. Even if you use Wine, which is a compatibility layer that allows installing Windows binaries, most malware won't even run, let alone harm the system. Read the PKGBUILD. AUR is a place where users share scripts to build programs; if you don't read the PKGBUILD it's your problem.
Iptables ? where is the interest ? loss of time ? cultural display ? use GUFW. http://doc.ubuntu-fr.org/gufw No open services ( Ubuntu ), no firewall behind a router, unnecessary. Netfilter is not application filtering, it is a outbound filter with large holes.
Yes, it is. You can see >HERE< that, like I said, even if you run malware through Wine, they can't harm Linux and won't propagate. So even if you intend to run malware on Wine, all you gotta do is hit Ctrl-C to stop it But then again, one gotta be REALLY dumb to purposely run malware through Wine. And if you have the right mitigations in place (like Firejail) you have nothing to worry about even if you're try the same thing that guy did. But of course, I'm sure there are people naive to install unknown packages with root privileges hehehehe Are these the same people who don't read the PKGBUILD's on new AUR packages and cry about them not being safe? Probably. For these people, the safest OS in the world won't help them because of their ignorance.
I have to disagree here a bit. The Wine developers themselves view this differently. That article which you mentioned was written in 2005 - since then Wine has improved a lot (to the benefit of Windows malware). Removing the z: drive (although called a "weak defense") is something I always do. Likewise blacklisting ~/.wine in Firejail.
I have to agree with Wine developers on their conservative position, but they're nevertheless very conservative. On the page you link they said an "infection has happened"; that is not true in the sense that "Linux got infected"; and as on the link I provided, reseting Wine got rid of the *malware running on Wine's directory*. So even when the user runs a malware through Wine on an "unprotected Linux machine" (with no grsec or firejail), the malware can't do harm to the system. That is not to say "run Wine the way you want", but "malware probably never harmed the system". I myself did this very same test, but with way more malware, and got the same results as the guy at the page I linked. I downloaded and installed at least 50 0-day trojans, exploits, ransomwares, and ran all of them through Wine. None propagated, none did harm to the system.
Yes, but I guess that's because it was malware which was not explicitly written to run under Wine and target a Linux system. This does not contradict what the Wine developers write: Hence, confining Wine and only running absolutely trustworthy applications in Wine is certainly a good idea.
Yes, when dealing with any Windows system or windows application it is wise to sandbox it, even if running it through Wine
(Jan 10) - Added rule for FlightGear/TerraSync, and where to look to see which port to use. TODO: Update pastebin's paste.
Does anyone know what port GPG uses? I'll create my GPG keys tonight, but GPG can't connect to the internet with my current Firewall rules.
My opinion (and people are free to disagree) is that the distinction between "open" and "closed" ports on Linux doesn't matter that much. A closed port is filtered by the firewall and connections are dropped. An open port isn't subject to that. But, whether it's open or closed doesn't matter if no program is listening on that port. Trying to ssh to port 21 on a server that's not running sshd isn't going to do anything.
Exactly. An open port isn't something to worry if there's no service listening. Not only that, but my rules close the firewall, then block most commong attacks, block invalid traffic and etc, and only then open connections that are stablished or related. This means that connections are only accepted if they originated from the machine in the first place, outside connection won't be accepted at all. Then all invalid traffic is blocked on the output, then only establised/related traffic is allowed, but this alone won't allow outbound connections. THEN, most common services are allowed, like DNS/http, etc. Even though it's not a per-application firewall setup, it's actually very strict. Most servers wouldn't run such a stric Firewall
Is there any chance you could translate those rules to "gufw" rules or tell me how I can add them to gufw? Thanks !
