BYOD

I thought I'd take a moment to give my opinion on BYOD (Bring Your Own Device).  I do not agree with BYOD in the workplace.  I don't see what advantages it brings.  Personal electronic devices have no place on a corporate network.  I can't even begin to imagine the types of security holes and malware infestations that end users would be connecting to the network.

It's obvious the reasons why an IT department would not want this.  There are certainly any number of risks associated with plugging in devices that you have no control over.  There may be severely out of date software on these devices, malware, and who knows what other security risks.  However, I also can't see why end users would want this. 

If you need a smartphone, tablet, etc. to do your job efficiently, then these things should be provided by your place of business.  You should never have to spend your hard earned cash on tools needed to perform your job.  If your employer refuses to give you the tools you need, then maybe it's time to look for another place of employment. 

Personally, I have always maintained a line between my personal and my professional life.  In the past, when I was told that I needed to join a conference call from home, my response was that they needed to provide me with a phone or I would not be joining that meeting.  The result was that I got a company issued phone.  There's a difference between being outright insubordinate and protecting your own assets. 

I do sometimes feel bad for those people who just prefer to use their own devices at work.  Because for every one of those people, there are a dozen others who would just use this as an excuse to play games or socialize all day instead of working on a presumably unmonitored device.

So if you're an end user who has been nagging your IT department to allow you to use your own device, please try to understand why they are telling you "no".  It's not because they want to feel powerful by telling you what you can and cannot do.  They are busy people, too.  Keeping a network safe and secure is a full time job.  They don't get to just plug in some appliance and set it and forget it.  They must constantly be analyzing intrusion attempts and attack vectors.  All the while patching software to minimize those attack vectors.  In addition to all that, they are still available whenever you forget your password.  So please, take it easy on those guys and gals.

See Percentage of Memory Used in Linux

You can use the following command to see the percentage of memory used on a Linux system.  Keep in mind that all it's actually doing is adding together the memory percentage used lines for each process listed.  Depending on your input method, the results could vary a little, but should generally be in the same ballpark.

The first example below adds together everything in the 4th column of "ps" output. 

The second example takes input from top, by running just one time in batch mode.  Then it adds together the values in the 10th column.

ps aux | awk '{sum +=$4}; END {print sum}'

top -b -n 1 | awk '{sum +=$10}; END {print sum}'

Snort to the Rescue!

I still use Base as a web frontend to my snort installation.  I know a lot of people are using things like Snorby now, but I think Base does everything I need it to do.  Anyway, I was looking at Base this afternoon and I noticed over 200 new alerts. 

All of the alerts were from my main router and they were of the type "ICMP Test".  Closer examination showed that the router was trying to ping a machine that was unreachable.  Since my router also acts as my DNS and DHCP server, I checked the syslog on that machine. 

The syslog was full of DHCP offers to the same IP address that snort was showing as unreachable.  I took the MAC address and ran it through an online MAC to vendor lookup and it showed me that it was a MAC from Motorola CHS.  I went through the house restarting all of my Motorola cable boxes.  Since doing that I noticed that the DHCP log shows that an acknowledgment was sent in response to the DHCP offer.  Snort has also stopped alerting for that particular ICMP Test. 

I guess one of the cable boxes just got hung up a bit.  It happens from time to time.  Usually I don't catch the problem until it is too late (e.g. my favorite TV shows aren't recording as scheduled in the DVR).  Thanks to Snort and Base, that won't be a problem tonight.

NTFSclone

I installed ntfsprogs on my Debian desktop because I have a Windows partition that I'd like to create an image of on my NAS.  I ran ntfsclone with the --save-image option and directed it to place the output in an NFS share to my NAS.  I started it last night and it's almost 60% of the way finished.

My lessons learned are as follows:
-  Software RAID sucks.  I should probably spring for a decent hardware RAID controller.
-  Consumer hard disks also suck for large file copies like this one.  Those cheap Western Digital disks in my NAS may have seemed like a great deal, but they just don't compare to higher-end SCSI disks.  The IO Wait is what's causing it to take so long.  It was over 50% when I last looked at it on the NAS.

I should really invest in better equipment at home :)

Update:  The ntfsclone imaging finally finished.  It turns out that I may have tracked down another culprit relating to the slow file transfer and the high iowait.  I have a 3-disk RAID 5 array in my Openfiler NAS.  Running mdadm -D /dev/md0 showed that one of the disks was faulty.  I rebooted the NAS and re-added that disk to the RAID array.  Right now it is in the process of rebuilding, so I'll have to wait a while to see how that goes.  Even if it comes back online okay, I'll still probably order an extra disk to add to the array as a spare. 

Snort: Sensitive Data

Man, I'll tell you, the sensitive data processor in snort was not designed to be used with web traffic.  If you've used it at all, you know it fires all the time when used in conjunction with regular web traffic.  If seems to throw alerts for detecting email addresses if it so much as finds the '@' symbol in a packet.  Any string of numbers in a packet makes it alert for finding supposed credit card numbers. 

Since in my current setup snort is processing all packets sent from my router, I'm going to have to disable sensitive data processing.  I guess if I was only monitoring traffic from my internal network, then there would be fewer of these alerts.  And then, the alerts I do get would probably at least be worth taking a look at.  Right now, though, I'm just getting flooded with false positives. 

Underscore in Hostname

I had to add this line to my Bind9 configuration for my home DNS server:

check-names master warn;

Had to do this mainly because I was getting crap like "bad owner name (check-names)" in my syslog everytime my Android phone tried to join the network.  Apparently, DNS doesn't like special characters in hostnames.  It seems Android phones tend to have an underscore character in their hostnames.  The annoying thing about this is that you can't change the hostname on a non-rooted phone.

But anyway, using the line up above in your named.conf file will stop your syslog from adding these alerts.  I think it's probably not the best thing to do, but until my phone uses a normal hostname, I have to do it to avoid sifting through tons of useless syslog alerts.

Interestingly enough, before adding that to clean up the log, Snort was also firing each time my phone joined the network, citing it as a possible Bind9 DoS attempt.  So even if I wasn't checking my logs regularly, snort would have at least let me know that I should pay closer attention to my phone. 

IPtables Port Spanning -- Sort of

I installed Snort on a Debian virtual machine in my home test lab.  I thought it would be fun to learn more about it.  What better way to learn than to just start using it?

I pretty much just followed one of the guides available at snort.org to get snort installed with PulledPork for downloading updated rulesets.  I've actually installed snort before, but it was several years ago and on Slackware instead of Debian.  I have noticed some things that are new to snort since the last time I installed it.  Things like the sensitive data preprocessor.  No, SDP, you're wrong.  None of those web packets contain CCN's or SSN's.  I actually disabled SDP in the end.  If you just comment out the sensitive data preprocessor line in snort.conf and the sensitive-data-rules line, you'll probably find that snort will die often and complain about something with "sd_pattern".  Just look in the snort.rules file and comment out the alert lines containing "sd_pattern".  That should solve that problem.  Unless of course, you really do need to look for sensitive data.  In that case, don't turn it off.  But do get ready for loads of false positives.

Having an IDS installed is not fun if you can't get packets for it to process, though.  I don't really care about chatter inside my network between the different machines.  I just wanted to process any packets sent or received through my router (machine running Debian and iptables).

I own a switch, not a hub, so plugging in the physical network connection used by the snort VM won't do any good.  And my switch is a cheap, unmanaged switch.  So I can't do a span port on it, either.

Then I learned about the TEE target in iptables.  It will copy the packets passing through the firewall and forward them over the network to another machine.  Yes, it's probably not the most secure method in the world, but it was exactly what I needed for my home network.  Kind of like a simulated span port.

However, it was a pain to get going on Debian stable.  In fact, you have to use xtables-addons along with iptables.  But it's not easy to get working correctly because of the versions of xtables-addons and iptables in the stable repos.  Instead I just ended up upgrading my router to Debian testing.  It was the easy way out.  That way everything is a new version and I got a nice shiny new 3.x kernel.  Once you get your system to recognize the TEE target and the --gateway option, you can add something like this to your iptables rules:

iptables -t mangle -A PREROUTING -j TEE --gateway x.x.x.x

(where x.x.x.x is the IP of the machine you want to receive the packets.)

Now that that's over, I can get back to configuring snort.  Any traffic coming into or out of my network through my router will also get copied over to snort for processing.  Yay!