LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   General (https://www.linuxquestions.org/questions/general-10/)
-   -   Security Suggestions (https://www.linuxquestions.org/questions/general-10/security-suggestions-4175596481/)

linux4evr5581 12-30-2016 03:35 PM

Security Suggestions
 
Stuff I learned along the way on the interwebs, LQ, youtube etc.. I posted for whoever might be able to find something useful ;)

Always whitelist instead of blacklist as blacklisting is a fools erand, since you can't blacklist all potential variables/programs that may occur

Conduct security assesments on your systems

Use namespaces/containers/chroot jails, but remember nothing stops an app from removing itself from a chrooted jail. A jail is easily broken cause the jail just edits something in the memory of an app's process, and nothing is stopping that process from editing it's own memory. Then changing back to root directory, and therfor escaping the chroot jail.

Dont use torrents

Prevent DNS leakage

Use a VPN that does not log

Dont allow startup of any programs until VPN connection is established

Spoof mac address because a hacker can find the manufactuer of a router/modem by the first 3 octets of the mac address (OUI)

Users digital objects (e.g. programs/files) should be isolated from other users digital objects in system memory... (As there's usually if not always a vulnerability wherever sharing takes place)

Dont keep permanent members in highest elevated groups

Always check if a user is allowed to use a program that they shouldn't be using

Sign your own code/kernel/modules (custom Secureboot) by generating random keys that you then throw away AFTER you generated all of the modules. Which means that no one can ever try to insert anything in your kernel (Linus does this)

Implement GRsecurity patches

Make your own efi specifications for your bios

Unofficial - Maybe try this, have a VPS server in VM's that hosts your services. So this way the ports running for the services are not accesible/visible on your physical machine (Also look into using VLANS and virtual routers)

Unoffical - Have a seperate device thats only used for changing passwords or use a liveCD or do both..Also have another device that's only used to view notes/downloaded videos that's on your external memory. (Assume all external drives like SD cards and USB sticks are infected, so either format or switch out for new ones every few months; format external drives using a live CD

Dont download anything from URL's (Especially firmware) as someone can link a malitious command to it, or it could have one already in the URL string... So instead download from files.. Also something that relates to this is DO NOT download unfiltered user supplied content!!

Keep in mind when you send email even though its encrypted it's destination is usually not.

Dont run a bunch of programs while in root cuz a hacker can easier find a vulnerability..

Check your hardware BIOS and make sure no other BIOS has been secretly installed, because when BIOS is looking for video cards it will execute any other BIOS's detected in the process...Video cards have non volatile RAM where root kits can hide...

Make sure theres no malware hiding in your init

Setuid programs running as root is a vulnerability. Like /usr/bin/chsh or /usr/bin/passwd are big ones they want...This is like the surface for any permission escalation attacks! So audit setuid/setgid system calls, and disable such programs as nessessry.

Unofficial - Remember hackers can tell what youre doing by what ports are open, and different ports do different things.. To mitigate this look into allowing only 1 special port with key only ssh and having a restrictive /etc/hosts.xfile(s) Im not sure but if you do this you may need to do stuff like load balencing and advanced routing techniques... Then stealth this special port like Comodo???

Always keep unessesary windows closed because other servers can try to trick your device's network software to connect to something malitious...

Prevent DNS poisoning, and there are many ways to do this. One is to restrict the amount of time records can stay in the cache before their updated. If you dont try to mitigate such an attack a hacker will change the cache on a local name server to point to a bogus server, instead of the real address...(probaly most sophisticated way they can infect you with a RAT?)

Check certificates and keys to see if your HTTPS webpage is from your DNS server, and not some private DNS server that a hacker set it to

Have 2 virtual back up firewalls next to your router in case the main fails. Also use hardware based firewalls on something like a RasberryPie loaded with PfSense/Smoothwall. Use Smoothwall as the outer firewall, and PfSense as the inner. Then a third honeypot linux distro using iptables as a honeypot machine...If the two virtual backup firewalls fail make a script to shutdown the machines...

Unoffical - Routers that have a hard drive can have anti-virus installed on it (If using a pc as a router definitely make efi specifications for the bios) (Maybe a bad idea since anti-virus has high privileges that can maybe be taken advantaged of? It might even be a risk on your main PC too, so what about only using live cd anti-virus scanning of partitions ? LOOK INTO IT )

Make shared folders READ ONLY!

If really trying not to have something stored while using a live cd, remove the hard drive aswell as specialized malware can target your CD-R and use that as an attack vector to upload malware onto your hard drive..

Unoffical - If you must have devices connected to the same network that cant be secure by nature. OR you just need to make another LAN for a group of people/servers who are not trusted. Then for these reasons make a VLAN for them so theres no possible attack vektors on the same LAN...

Unofficial - Isolate embedded systems in a network by putting them in a guest network that some routers have..

Unofficial - Make honeypots by constructing SNMP traps to contain attackers (damage control) via firewalls/chroot-jails/containers etc, that automate based on a set of rules met on your shadow network (or use the time to learn more about their orgins/motives; unless their in your real network!)

Turn off usb,optical drives,ssh, and if you do use ssh use it with key only authentication (As passwords can be brute forced)

Unofficial - Use a small Linux ISO, this way it would be much easier to spot malware...This however could be a double edged sword as they can probaly find your logs easier. So maybe only use this on shadow networks?

Enable logging to detect hackers, and see what their trying to do (Keep in mind a pro will atempt to scrub or turn off your logging)

Things to log:Firewall, HTTP requests, TSL/SSL certs, DNS requests, Setuid/Setgid system calls, Packets, Outgoing traffic (OpenDLP I think mitigates this), Failed login attempts, Sudo, Failed drivers, Activities requiring resources, Moves files, corrupt files, failed access to files, Group member additions, System reboots, Service restarts

Instead of going to a webpage by search engine go straight to it via URL

When you ssh into a system and you need root, first login to it as your normal user, then use su no hyphen. This way you dont pass a root shell and variables to the system you're logging into, and wont have the remote chance of someone sniffing the password off your local machine...

Block executables at the gateway

The program finger can be a security hole which is why many distos dont ship with it

HIDS should be set up before you connect to the internet

ISO's should be READ ONLY as they are CD file systems

Make USB pass keys to prevent time attacks

Dont run Wireshark/Tshark with super user priviledges as the abundent amount of protocals it uses to capture packets is a security risk..(Wireshark/Tshark may have been upated where you shouldn't need super user anyways, as it now uses dumpcap to capture packets. Some platforms may still need super user, but atleast it will only be for dumpcap)

Unoffical - Rename all files and change their locations (especially log files), and also change their colors

Turn off javascipt and add exceptions for sites that need javascript

Dont use flash, use a terminal based browser

Don't back up SIM cards with contacts/messages

Unoffical - Have all downloads go through a sandboxed integrity check before being extracted to the OS (Maybe setup ClamAV as a reverse proxy)

Block downloads to the system

Unofficial - Make a script to disconnect the hosts from the router incase it gets malitiously reseted, where it then goes into a 30sec vulnerable state while it's rebooting...And look into using a UPS (uniteruptable power supply)

Unofficial - When signing up for something that requires an email verification link, first reset the browser and clear privacy before checking and clicking the link. (Maybe something malitious can be attached to the URL, browser or webpages) Or just confirm it in another VM...

Remember to check what default permissions a distro has set on it's files. (May not be the best for security) Also remember Debian based distros has iptables off by default...

Type exit to securely exit out a server, configuration page or terminal (Or else a hacker can pick up where you left off)

Unoffical - Use command arp instead of ARP

Look into a priviledge seperation program for your OS for priviledged programs. As its easier to compromise thousands of lines of code, than 20 lines of heavily audited code...

Encrypt the hard drive so even if you get pwned by a liveCD all your data will be encrypted (or turn off optical drives or both)

Unoffical - Best to use survalence cams that connect directly to the hard drive

Keep SMB's closed as having them open is a security flaw, and nmap will find them if their open...

Always remove unused public WI-FI hotspots from your device, as it could potentially be a Snoopy network. So as long as it's listed in your used hotspots, hackers can track and sniff your data... (Wireless based IDS Kismet can spot this)

Have multiple emails for your various activities (shopping, social media etc)

Unoffical - Depending on the situation when your network is breached restrict bandwidth to the targeted device so the hackers cant upload malware or steal data so fast.

Make prepared statements to help protect your website's database

Becareful of which IP you allow to do zone transfers

Make a non privledged user account for every service you use

Rebuild corrupted log files (Could show malitious activity)

Use special browsers to evade malitious servers

Before you exit the console vim and delete everything in the .bash_history file, then overwrite it and save. Finally shred the file and reset the terminal...

Only run non-free software in a VM so only your virtual freedoms will be harmed

Unoffical - Use NAS and NFS to extend the CAM table of a switch to mitigate MAC flooding attacks (If possible?)

Block http traffic otherwise data can be manipulated and redirected

Use ad-block and script block software

Turn off internet when looking at documents or multi-media files as those can have an embedded I-frame in them which is web enabled and can retrieve info from you and send it to a server or anywhere it's programmed to...

Block ping and SNMP if not using them (block ping through the router; SNMP can be blocked by blocking its ports with a firewall)

Setup a kiosk

Install Kali on its own drive cus Antivirus on another partition can scan it which is not good. So ideally use kali on its own hard drive instead of duelbooting...

For hardware exploits a kernel patch may provide a temperary fix

Use Ksplice for livecds to upgrade linux kernel security patches

Unoffical - To mitigate DDOS attacks use pf's rate limit feature, use pf at the router, log monitor scripts + dynamic tables, mod_security, mod_evasive.. Some switches have a security option where if they get flooded they will still be able to process management traffic...

Disable scripts and macros

Unoffical - Keep disks unmounted when running a livecd, OR with an installed OS set you partition option in the /etc/fstab to noexec so nothing can execute

Unofficial - Max out the write limit on USB drives

Switches can offer security against internal threats by having options such as VLANS, ACLs for your LAN or VLAN, embedded ecryption for traffic going to and from the switch.. One of the ACL functions is port security where the port requires MAC address authentication (use this with VLAN)

wagscat123 12-31-2016 03:03 PM

How long have you been in the Linux/UNIX world to accrue all of these tips?

linux4evr5581 12-31-2016 10:23 PM

Probaly around 1 1/2 - 2 years tops, but note I cant actually implement alot of these techniques myself. I know of the concepts around them but knowing and doing are 2 seperate things. But knowing is the first step I think.. Also the ones that say unofficial im not 100% sure are actually good practices, but the others im 90% sure or more...

ondoho 01-01-2017 09:51 AM

Quote:

Originally Posted by linux4evr5581 (Post 5648302)
Dont use torrents

what are the alternatives?

273 01-01-2017 10:15 AM

There are valid reasons for telling point-and-click Windows users not to use torrents but the majority of those have to do with the types of files being sought and seeded not the technology itself. Yes, of course, potentially the torrent client may have a vulnerability but what with various layers of NAT and the like they're not likely to be any more risky than browsing the web.

linux4evr5581 01-01-2017 11:10 AM

I dont use torrents because from my understanding when downloading from a torrent, your download consists of bits and pieces being shared across multiple people. In one of my notes above I said that vulnerablities usually happen wherever sharing take place. I download straight from a mirror instead, as you cant go wrong with the source (for the most part). Also browsing the internet is probaly one of the most risky activites you can do with parsing of HTML, drive by downloads, ads containing specially crafted JS, flash, and displaying of images which can leave you suceptiple to XSS (lions, tigers, and bears oh my).. Using a text based browser can mitigate alot of those though..

273 01-01-2017 11:28 AM

Quote:

Originally Posted by linux4evr5581 (Post 5648909)
I dont use torrents because from my understanding when downloading from a torrent, your download consists of bits and pieces being shared across multiple people. In one of my notes above I said that vulnerablities usually happen wherever sharing take place.

Yes, and? What does it matter where those bits come from as long as they build the correct file? What's wrong with sharing? Yes, of course, there's a little risk when running any network process but I've not seen anything to suggest that torrent clients are especially vulnerable.

linux4evr5581 01-01-2017 11:38 AM

Dont get me wrong I think sharing is great just not in certain applications reguarding computer networks or local user accounts. I think the speed torrents provide is like a trade off of some security for improved performance.. Because when a torrent is downloaded, the person receiving it gets a look at the IP addresses of all the contributing peers. Online hackers sometimes collect this information so they can target one computer at a time until a vulnerable one is found..

273 01-01-2017 11:44 AM

Quote:

Originally Posted by linux4evr5581 (Post 5648919)
Dont get me wrong I think sharing is great just not in certain applications reguarding computer networks or local user accounts. But I think the speed torrents provide is like a trade off of some security for improved performence.. Because when a torrent is downloaded, the person receiving it gets a look at the IP addresses of all the contributing peers. Online hackers sometimes collect this information so they can target one computer at a time until a vulnerable one is found..

That's only security through obscurity though. Trust me, people are scanning all IP ranges all the time for listening ports already so whether you run a torrent client or not you will be scanned.
Yes, it's possible that somebody finds something which can be injected into a torrent datagram stream which will cause something like a buffer overflow in certain clients but that's not some terrifying risk it's just one of many which have to be expected and mitigated against.

linux4evr5581 01-01-2017 12:19 PM

I agree torrents definitely do have their place as the numbers of internet connected users continues to grow, mirrors will become congested.. But besides that I think it comes down to personal preference as to me it's just one more vektor.

sundialsvcs 01-02-2017 08:00 AM

Many people believe that "torrent = TOR = The Onion Router™" was designed to provide anonymity. It was not, and it does not.

The Internet itself was originally designed (as MILNET) to allow the President of the United States, wherever he was hiding after the entire East Coast had been nuked into a glow-stick, to somehow send the order to "turn Russia into a glow-stick, too," no matter how many other American cities had been glow-sticked. It does this by enabling packets to find their own way to a destination.

TOR's real purpose is to enable a message to get through, assuming that the owners/controllers of the network would be hostile to the existence of the message and would block it if they could identify it or its pieces. It does this by wrapping different pieces of the communication in different "onion layers" of encryption at each and every hop.

TOR also does not assume that anyone has a holistic, all-encompassing view of the network itself, such that they could perform traffic analysis or exploit the other known characteristics of the TOR algorithm and subnetwork topology. (But, Guess Who does, and can ...?)

linux4evr5581 01-02-2017 01:07 PM

Yeah TCP/IP was invented by DARPA and was not intended to be secure, but just to serve as a framework for communication.. But I think Tor stated that their, again, leveraging between security and performance. I understand your point though about the messaging and it does make sense.. ARs had a good article on Tor's weaknesses such as like when you browse the web and continue to open up website after website, you then also open up more nodes. Than sooner or later you'll get a compromsied node, cus math...

sundialsvcs 01-02-2017 02:45 PM

In the original concept for TCP/IP and so on, the idea was that packets would find their own way around whatever cities had not yet been "atom"-ized, so that, one way or the other, our "MAD" plan for "Mutually-Assured Destruction" would succeed in wiping out the other half of Planet Earth. :rolleyes:

TOR won't protect you against any agency that can realistically monitor every TOR connection simultaneously ... as Governments can. But it can ensure that the messages will get past anyone who, armed with knowledge of "who might be talking to who" and what those messages might contain, may wish to block or interfere with those messages.

The notion of "internet anonymity," therefore, "in the specific context of TOR," has an ambiguous meaning. It is both true and not-true.

ondoho 01-03-2017 05:28 AM

Quote:

Originally Posted by sundialsvcs (Post 5649118)
Many people believe that "torrent = TOR = The Onion Router™"

i don't think torrenting has anything to do with TOR?

anyhow i think i should have specified my original question:
Quote:

Originally Posted by ondoho (Post 5648877)
don't use torrent - what are the alternatives?

to read:

"don't use torrent - What are the alternatives for file sharing?"

linux4evr5581 01-03-2017 08:59 AM

@Sundialsvcs - I think may be ok to use for short-lived use cases such file downloads or uploads every now and then, but not consistant daily browsing...

@Ondoho - Some alternatives I would look into is GNUnet and blockchains


All times are GMT -5. The time now is 06:13 AM.