iPhone/iPad App Keeps Crashing

Have an app that keeps crashing when you try to load it?  Here are some steps to resolve it:

  1. Remove the App from Multi-tasking and start again (http://support.apple.com/kb/HT4211)
  2. Free up running memory by closing apps that are running in the multi-tasking background.
  3. Reconnect to Cellular or WiFi network.
  4. Verify that you have the latest iOS installed on your device. (Settings > General > Software)
  5. Make sure that you iOS device has enough free storage space. Low space can cause crashes, slowness etc. (Settings > About > Capacity).
  6. Reboot your iOS device (Turn your device off and then on again, and launch the app.)

 

 

Password Protection #netsec

We all hate it when our companies make us change our passwords every 60 days.  But they do it for a reason!  It’s more secure!

With all of the hoopla over the leaked celebrity scandalous pictures, I thought I’d revisit a topic that’s been covered to DEATH, but no one seems to really take the advice of the experts.

Password protection isn’t just in the hands of companies, it’s in the hands of users too.  It’s not just “use long passwords” either.  Hackers with access to fast compute resources can crack 16 character passwords in under an hour using a dictionary brute-force attack.

Stanford’s network admins have a password policy that could be a good idea for remembering easier passwords. (until processors can handle 20 character passwords)

Here are some things companies and employers can do to help secure passwords:

  1. HASH the passwords (with a salt preferably).  NEVER store anything plain text ever.
  2. Encrypt the channels between the password databases and the systems accessing them.
  3. Encrypt the databases themselves
  4. LOCK down access to the password database.
  5. Force the use of a password at LEAST 12 characters long.
  6. Force special character usage
  7. Force numerical character usage
  8. Force multiple uppercase usage
  9. Use a dictionary of your own to DISALLOW words in the dictionary
  10. Use 2 factor authentication for EVERYTHING
  11. Force a password change after 1-2 failures (mentioned in my East-to-West Security blog post)
  12. Force password changes every so often
  13. Remove “stale” users
  14. ENFORCE your password security policy.  (If you see passwords on post-it notes, discipline them!!)
  15. Monitor “unusual” login sources (i.e. Different Countries)
  16. Don’t allow password REUSE
  17. Restrict application access to lowest common setting.  Don’t give users too much power!
  18. Deploy brute-force and intrusion detection systems!
  19. Deploy centralized management servers (RADIUS, TACACS, LDAP)
  20. Deploy Secure Tokens
  21. Regularly change your WiFi access point passwords
  22. Don’t use plain-text applications (Use SCP, SSH, HTTPS, etc)

Here are some things end users can do to secure passwords:

  1. Don’t share your password with ANYONE!!! ANYONE… EVER!! Even if you know them and they’re “trying to help”
  2. Use a different password for every service/login
  3. Never “stay logged in”
  4. Do NOT use the “remember me” or “remember password” feature
  5. DON’T WRITE YOUR PASSWORDS DOWN! (Physically)
  6. DON’T WRITE YOUR PASSWORDS DOWN! (Electronically, e-mail, text, whatever)
  7. Change passwords regularly
  8. If the service allows for 2 Factor Authentication… USE IT!
  9. Be aware of “social engineering”.  Good “social hackers” can guess your passwords after a couple of drinks at a bar.
  10. Don’t use ANY of these 500 passwords. (or ANY remotely similar)
  11. Use phrases that are easy for you to remember, but hard to brute-force (i_l!K3_t0_E/-\t_l@5aGn/-\)
  12. Use the longest password possible
  13. Never enter a password on a website that isn’t encrypted and trusted (that little lock screen)
  14. If you choose to use applications like 1password, ensure they are using 256bit encryption
  15. REPORT anyone asking for your password

 

 

 

 

 

Know Your Environment #netsec

In one of my recent posts (5 Things Every Network Needs) I mentioned application/endpoint visibility.  Let’s look into this idea a bit further.

When you are looking to implement security mechanisms in your network, you need to know what you’re securing.  Not just “what” you’re securing, but how it works, what it’s for, and where it goes.

How does the Secret Service start to secure the President?  They know WHERE he is going, HOW he is getting there, and WHAT he is going there for.  They know everything there is to know and that makes him much easier to secure.

Your data, applications, and customers are the same way.  Know their ins and outs and every move and you’ll be able to protect them better.

Adding security layers on top of each other without thinking through the application flow can cause more havoc than security holes it fills.  More security is important and mostly necessary, but first understand what you’re protecting and the risks associated with protecting those assets.

And BE REASONABLE! Security always adds a little more complexity and usually an additional hop for traffic to traverse.  When it comes to operating networks, simple is always more cost effective, so don’t go overboard with security mechanisms in places you don’t need them.

East to West Data Center Security? #netsec

I always recommend layered security. And East-to-West Data Center Security is no different!  However, security for the sake of security isn’t ever a good thing. So let’s take a look at East-to-West DC security.

I’d also wholeheartily agree with intrusion prevention (IPS) and possibly application layer security on east-to-west data center traffic.  Hackers are breaching East-to-West systems through zero days, injections, and brute force, something user identification wouldn’t really help with.

In regards to user-id, there shouldn’t ever be user identifiable traffic in that direction.  When there is, it is the same user over and over again.

Example:
From DMZ web services to backend DB servers there should only be the DB API ports open. Nothing else.  DB users shouldn’t be the same as the underlying system’s users and are *rarely* AD/Radius users anyway.

Because of the system/user differences, I tend to think of east to west security as more of a “IT Security Posture” than a specific technology implementation.

Other than intrusion prevention and application identification (is this DB call really a DB call), I’d recommend rolling password changes for the DB API call users, lockouts after 1 failed attempt, and never “select *” privileges let alone root.  If your application coders don’t know what they want, they’re slowing the application performance anyway.

You could say “what about administrators of the east-to-west systems?” But even that traffic is north to south at some point before it gets to them.  I’d do user identification there.

Just my 2cents.  Leave a comment and tell me your east-to-west security approaches!

Stop Bothering Us #caturday

Sometimes they’re just so cute you want to pinch their cheeks!

Then they give you the death look for waking them up and making them pose for a Caturday blog post!

Sleepy Kitties

Sleepy Kitties

5 Things Every Network Needs

Run a service provider network, enterprise, commercial, health, financial, or retail network?  Run any sort of network?

Well then, here are 5 things your network NEEDS today!

  1. Redundancy
  2. Security
  3. Capacity Management
  4. Logging (SIEM)
  5. Application/Customer/Endpoint Visibility

 Redundancy

Have you ever owned a computer that didn’t blue screen or give you the spinning beach ball of death?  No? Neither have I.  Network devices are just computers, but they have faults and eventually need to be upgraded, rebooted, fixed, or removed.  They’re going to fail.  It’s better to plan for the failures with redundant systems before the failures occur.

Security

Hear about the Playstation Network DDoS in 2011?  What about the one a couple days ago?  What about Target last year? Or even the NSA spygate stuff?  Hackers, governments, disgruntled employees, everyone wants to infiltrate your network for one reason or another.  Your need firewalls upon firewalls, DDoS prevention, Web Application Firewalls, RSA tokens, single sign-ons, 802.1x, intrusion detection, malware detonator, etc.  Basically, you need more security than you need network equipment.

Capacity Management

Whether it’s a freeware version of Cacti or a 6 month implementation Solarwinds, CA, HP, your links are going to bottleneck somewhere.  It’s best to know where those will be and predict them before they happen.  Your datacenter users won’t like it when your 1G trunk between switches overloads during a 20TB database sync.

Logging (SIEM)

When dealing with network, security, wireless, and data center equipment you’re going to have a LOT of devices in your network.  You need a log management solution that takes the logs from each device and correlates the thousands of messages into useful, digestible information.  The best SIEM systems integrate security awareness and threat/vulnerability into them.

Application/Customer/Endpoint Visibility

What is your network for?  The customer of course!  All those big pipes, secured devices, encrypted tunnels, and log management servers are doing no good if you don’t know what/who rides your network!  Get to know your customer.  Whether you’re an ISP and your customer is a person or company or you’re in a datacenter and your customer is a rack full of HADOOP cluster servers, it’ll make your network run so much smoother when you have visibility into what’s riding your pipes.

P.S.  The next step in that application/customer/endpoint visibility?  Software Defined Networking of course!

 

Get these 5 things in your network and your customers and your bosses will LOVE you!

 

 

Fitbit Flex Won’t Charge?

I’ve had one version of the Fitbit or another since 2012.  I’ve lost or broken probably 4 or 5 of them.  All of them were my fault.  Except the latest….

For some reason the Fitbit Flex’s design makes the charging contacts get smudged and dirty VERY easily and prevent charging.  This has happened 5 times in the last 9 months and I’ve actually returned 3 of these to Best Buy because of it.

Most of the time you can fix the issue with the following solutions:

  1. Rub the Fitbit charging contacts with alcohol swabs
  2. Rub the Fitbit charging contacts with qtips doused in vinegar
  3. Clean the Fitbit charging dongle with alcohol swabs

You can also check out the Fitbit provided page on cleaning the Flex here: https://help.fitbit.com/customer/portal/articles/1615435-how-do-i-clean-the-charging-contacts-on-my-flex-

 

 

 

DDoS Protection with NetFlow

DDoS Protection: The Problem with NetFlow

“Netflow collection.” This is what I kept hearing from DDoS providers when I asked how they monitored networks.  But there are a couple problems with utilizing NetFlow.

Problem 1: Sampling Rates…

I’ve very rarely seen a sampling rate of 1 on routers.  Cisco’s CRS shelves and ASR9ks as well as Juniper’s TX Matrix Plus and MX960s are certainly capable of sampling 100% of flows and packets through the box.

But because of performance worries, the majority of implementations I’ve seen monitor 50-80% of packets traversing core routers.  This means that the majority of customers aren’t viewing 20-50% of the flows per second.

In fact, JUNOS is only capable of sampling 65,535 packets per second.  Have more flows that than? Sorry.

Pulling Netflow from a firewall?  These sampling rates are typically in the 20-60% range due to the processing done on packets.

Basically, your cloud provider is starting out behind the 8-ball and possibly missing out on a lot of the flows making it into your network.

Problem 2: Low and Slow attacks are COMPLETELY missed

Low and Slow DDoS attacks are getting more and more frequent.  DNS and NTP amplification attacks, Slowloris, and SlowHTTPTest are all ways to creep through IPS, Netflow, and Firewalls.

NetFlow collection techniques won’t recognize this traffic as harmful.  DNS/NTP amplification visibility may show up on the radar, but if you operate a public facing DNS, it may not.

These DDoS mechanisms are designed exploit protocol vulnerabilities.  You can’t close those vulnerabilities without closing the functionality of HTTP/DNS/NTP.

Problem 3: Reputations aren’t as reliable anymore

But, you say that there are known Slowloris instances at certain IP addresses?  Ok, fine, but does that mean it’s a hacker or could it be your grandma’s compromised machine legitimately trying to visit your website?

“Well what about China?”  There are some companies who know they’ll NEVER see traffic from China.  They can block and mitigate this traffic, but the globalization of today’s economy is increasingly making it difficult to black-list entire countries.

“What about a mass of users all of the sudden?” Go check with your marketing department, they may have just tweeted a 95% off coupon for the next hour.  This type of thing happens all of the time and is typically a false alarm for NetFlow DDoS mechanisms.

Solution? On-premise 1st line of defense

On premise detection and/or mitigation is the way to go for your first line of defense.

Almost every company has a firewall. Most companies have an IPS/IDS solution in place.  A lot have Malware detection/mitigation in place.  Few have a dedicated DDoS appliance installed.  When asked, most customers reply with “Well, my signatures and SCREENs should catch the traffic.”

Not so! As mentioned above, attacks are utilizing common transport protocol mechanisms for their attacks.  And the traffic being let in isn’t matching any signatures or it is going too slow to hit your screens.

That said, you CAN put something on your network that inspects the traffic for behaviors instead of signatures.  Much like a load balancer, these systems view resource loads and inspect packets to make decisions based on the likelihood of traffic being genuine or not.

Check out Juniper’s DDoS Secure,  Radware’s DefensePro, and Vectra Networks for heuristic-based protection.  These are really cool technologies!

Parting Thoughts…

  • If your bandwidth can’t handle the flood, send the dirty traffic to the cloud laundry service, for everything else, keep it on premise.
  • It’s a good idea to have more than one detection mechanism, so I’d still recommend using a NetFlow collector, but just not as a primary tool, and definitely not one tied into anything very “automatic”.

Have an opinion?  Leave a comment!

 

Down for a couple days…

I upgraded this server from OS X Mountain Lion Server to OS X Mavericks Server two nights ago…..

The server is remotely managed by Macstadium and they HOOKED me up when it didn’t return from the upgrade.  They rebuilt the upgrade from USB and  put it back where it needed to be!  Kudos to Phil @ Macstadium!

Anyway, Mavericks decided to change my httpd.conf config, my custom SSH port, and upgraded PHP.

The httpd.conf changes were pretty easy to manage especially with this post at dillieo digital.

Next, I had to change the ssh port away from the default 22 (so many hackers from China all up in my grill!).  Super easy with this Coded Memes Post.

Lastly, I had to update some old PHP from my Instagram Plugin….  This Stackoverflow question helped me update the Instagram Code…

 

So, in the end.  If you’re going to upgrade something critical, it’s probably best to stick around and check baselines instead of going to sleep! 🙂