I was wondering if there is any way to make the syslog secure? By this I mean, how a newcomer to linux could make sure that he/she is not disposing confidential data by posting his/her syslog.txt to the forums? I refer to my post in another thread concerning Unraid crashing/hanging problem during shutting down for reboot. Just a second before posting the syslog.txt file to the forum, I wanted to check if it consists of confidential data and to my surprise I found "password", usernames, MAC address of the hardware in it and could not post the file before going through it line by line in order to remove these lines.

 

Is there any way to prevent this so one does not dispose similar confidential data for the entire internet to browse or download it? I don't think any syslog submitted here should contain passwords or usernames or MAC and IP addresses. Am I wrong?

 

PS: It was not the common syslog file downloaded, but I dumped the terminal outcome according to Tom's suggestion concerning the setting up a syslog by typing: tail -f /var/log/syslog in case of hanging.

 

No actual passwords are ever in the syslog unless the user installed a very unsecure addon.

Brit thnx for the reply. Could you please have a look at the thread I have referred to? There you will see my domain password and users' names in the syslog.

Brit thnx for the reply. Could you please have a look at the thread I have referred to? There you will see my domain password and users' names in the syslog.

What version of unRAID are you running?  I remember this being pointed out to lime-technology and they were removed (I thought) from the syslog in a subsequent version of unRAID.  Most of us do not log onto a MS domain as you, so we do not see those lines in the system log and would not know if they are still there in the most current versions of unRAID.

 

Jo L.

What version of unRAID are you running? 

Jo L.

 

version: 5.0-beta6a

I'm no network security expert, but I don't see how your server's IP could pose a security risk.  Your server should be behind a router, as unRAID is not designed to be directly connected to the internet.  So even if someone knew your server's IP address, they would have to hack your router before it became useful.  I say 'hack your router' without really knowing what is involved in that process.

 

If you are using MAC address filtering as a security measure on your router, then I could definitely see your server's MAC address getting out becoming an issue.  I don't use MAC address filtering, so I don't worry about it.

MAC address filtering is not any kind of security. If someone has broken in to your LAN, they can capture the MAC address and assign it easily to their host. There is no reason to keep a MAC address secret. If your IP address is in the private range (10.x.x.x, 192.168.x.x, 172.16.0.0 - 172.31.255.255) then it's not unique and not routable on the Internet. There is absolutely no reason to keep a private range address secret. There should be no reason to keep a public IP address secret, security though obscurity is not! All public IP addresses are routinely scanned by hackers looking for weakness.

 

If an add-on is recording logins and passwords in the syslog the add-on needs to be fixed.

 

The only security threat here is if a public IP address provides access to the server and login and password info is also provided. If specific ports are forwarded to the server and those ports don't provide a login-password challenge then the problem is marginalized as long as you trust the software listening on those ports.

 

UnRAID is not hardened enough to be accessible from the Internet.

 

If you feel this is a threat then you'll have to sanitize logs before posting. I've never seen a log with such information before.

MAC addresses are probably fine to post, but they probably should be masked in logs that are posted online.  There might be legitimate reasons to log them though, in which case the best option might be to mask them by hand or have some sort of automated masking option.  I can't think of any reason that you'd want to be concerned about it now, but down the road it could be more of a problem.  Part of the hope someday with IPv6 is that you'll be able to give each of your devices a public IP address, rather than relying on NAT.  A good portion of your IPv6 address will be your MAC.  It would be infeasible to "scan" the entire IPv6 Internet, but you might be able to run spiders on the Internet that look for IP and/or MAC addresses, and then scan those.

 

Of course, its a really, really bad idea to be logging passwords.  Usernames are probably appropriate to log, although again it might be a good idea to have an option to mask those.

 

I know unRAID wasn't "designed to be directly connected to the internet."  And I would never make it publicly accessible.  But I really think its a cop-out to say a product can have poor security mechanisms because its only intended to be used on an internal network.  unRAID is by no means the only offender.  Its really, really common for users and developers of software to take that position.  And I'm sure that philosophy has been responsible for a great many security breaches.  We've carried over this idea from the physical world, where you can try to build a big fence to keep the bad guys out.  You can't do that with networked IT systems.  Sure, you can put up a firewall, but you better expect people hopping over the fence.  Companies should really be running their internal networks like everything is available to the public Internet.  There's really no excuse not to, except that software developers have figured out they can be lazy when it comes to security measures.  The Operation Aurora attacks on Google and other companies worked, in part, because there were poor authentication and access control mechanisms protecting resources that were only supposed to be accessible to "trusted" folks on their internal networks.  The problem is, once someone accidentally opens a malicious PDF file, or visits a web page with a malicious java applet or flash file, you can no longer assume there are only trusted folks on your internal network.

 

Because phishing, spear-phishing and drive-by-download attacks have become to common, I think companies are starting to get a better appreciation for the importance of having secure internal networks.  But there are a lot of legacy applications out there that are going to make it very painful (and expensive) for companies to transition to more secure systems.

 

So, because unRAID wasn't "designed to be directly connected to the internet" I think you'd have to be crazy to use it in a business environment.  I'm not even completely comfortable, security-wise, using it in a home environment, but I'm willing to keep my fingers crossed since I like the features of unRAID.

 

 

So, because unRAID wasn't "designed to be directly connected to the internet" I think you'd have to be crazy to use it in a business environment.  I'm not even completely comfortable, security-wise, using it in a home environment, but I'm willing to keep my fingers crossed since I like the features of unRAID.

 

unRAID would never get implemented into such a corporate anyway (and if it were, the sysadmin should be talked to). It's read/write speeds don't respond well to multiple (think more than 5) users, much like the other cheap solutions.  Most users have unRAID in a business environment purely for archiving or backups. You'd never have such a device accessible to anyone else, why would unRAID be any different?

 

That is what unRAID is truly about, reliable and cheap storage. To say that unRAID use is crazy in a business, let alone home use, is unfair to the product. If you don't know what you're doing, unRAID is no more of a security issue than the box you used to write that post.

Why does it matter if someone knows your MAC address? I can not think a single reason to be concerned about MAC addresses. They were never intended to be secret. Every time you use WIFI your WIFI MAC address is visible to anyone who cares to look. WPA does not and can not mask the MAC address.