Thursday, February 7, 2013

Renaming F5 objects (in version 11)

You may have need to rename one or more objects in an F5 load balancer.  Unfortunately this cannot be accomplished through the GUI, but there is a way to do it on the F5 command line. You'll need a username that has access to the Unix command line (or what F5 calls the "Advanced Shell".



Once you've logged into the command line on the F5 system, change to the /config directory and edit the bigip.conf file using the pico command line editor.  (I suppose you could use vi too)



Make sure you understand the syntax in the configuration file before making any changes.  It's always a good idea to take a backup of the configuration file first.

Search for the name of the object that you want to rename.  Make sure to search for every occurrence of the object's name and replace it with the new name, otherwise you'll break the configuration file.

If you're using partitions on your F5, your configuration is broken up into multiple bigip.conf files.  The common partition is contained in /config/bigip.conf.  The other bigip.conf files are in subdirectories in the /config/partitions directory.  You may need to edit these files too.



When search for the name of the of an object, do it just by the object name, not the partition name.  You may notice that most object references have a partition name in front and be tempted to include the partition name (i.e. "/Windows/mail.thepacketmaster.com_prod_https_activesync")  If you do this you may miss the object name if it's referenced in an iRule without the partition name.  Always search by the object name without the partition or preceding slashes (i.e."mail.thepacketmaster.com_prod_https_activesync")  By doing this, you'll find any references to pools in iRules (and anywhere else in the config)


Once you're done with the changes you should verify the configuration is okay before trying to load it.  Type: tmsh load sys config verify partitions all



If everything is okay, there won't be any error messages.  Otherwise, the verification process will spit out an "Unexpected error" message and indicate the issue.

When you've confirmed there are no issues anywhere, you can load the configuration by typing:
tmsh load sys config partitions all



Your configuration is now updated and running!

One piece of advice in naming objects.  While it may seem redundant, it is useful to use keywords that identify the object type in it's name.  For example use "pool", "virtual_server", "ssl_client_profile".  Otherwise, you might have a pool called "thepacketmaster.com_https", and a virtual server and ssl profile by the same name.  That's all fine, but if you ever need to edit things in the bigip.conf and you do a search, you'll be matching all these different types of objects when you may only be looking for one.  It will just mean you'll have to be careful to identify the object name you're editing.

 

Thursday, January 3, 2013

Detecting ZeroAccess Trojan with QRadar

Here's a quick way to detect the ZeroAccess trojan with your SIEM.  Look for any traffic that is originating from your internal network and going to the Internet, on destination ports 16461, 16464, 16465, 16470, or 16471.  Below is an example of this in QRadar:




If you find that you're getting false positives you can put in an additional condition to match when this is seen several times in a minute from the same source IP.




Monday, December 31, 2012

Dexter: New Point-Of-Sale Malware

Seculert has discovered a new piece of malware called Dexter which is designed to infect retail sales workstations and steal credit card information.

How it operates:
  • It scans the process list of an infected system and looks for Point-Of-Sale software.
  • It scans the memory segments of the POS software and pulls out the credit card data.
  • Communicates data back to a C&C server.
Infection vector:
  • Looks like its targets Windows systems, including Window Server systems. 
  • 50% of the infected systems are Windows XP
  • Most targets are in western countries.
  • How a system gets infected is still unknown.
Seculert is suggesting that because Windows Server systems are getting infected then drive-by downloads or web-based social engineering is not likely.  They're also theorizing that the credit card data is being used to clone credit cards.
 
SpiderLabs has a great analysis of how the C&C communication actually works.  The credit card data and other information is base-64 encoded and XOR encrypted and sent to the C&C server.  It looks like there are several domain names involved as the C&C servers.  The server sends back instructions, again base-64 encoded and XOR encrypted, in a cookie.

Volatile Labs had a list of domain names that the program uses.  They're just .com names of random jibberish, and they can probably change frequently.  But look out for domains like this going through your firewall:

  • 11e2540739d7fbea1ab8f9aa7a107648.com
  • 7186343a80c6fa32811804d23765cda4.com
  • e7dce8e4671f8f03a040d08bb08ec07a.com
  • e7bc2d0fceee1bdfd691a80c783173b4.com
  • 815ad1c058df1b7ba9c0998e2aa8a7b4.com
  • 67b3dba8bc6778101892eb77249db32e.com
  • fabcaa97871555b68aa095335975e613.com
The good news is that if it's just Windows systems being infected then you shouldn't need to worry if you use stand-alone terminals with a direct Ethernet connection.  Chase Paymentech uses these a fair amount, and I'm pretty certain they're not using Windows on those little devices.


Here are the original Seculert posting and some additional research from Trustwave SpiderLabs and Volatile Labs.




Sunday, December 30, 2012

Home Wireless Networks

A question I get asked often is how to setup multiple wireless access points in a house to get better wireless coverage.  When your Internet provider sets up your connection, it makes sense to put your wireless router at the same physical location.  If you're in an apartment or small bungalow that's generally not a problem for wireless coverage.  If you have a bigger living space then coverage becomes more of an issue.  Unfortunately most wireless routers only come with instructions on how to set them up as the only wireless router.  To make wireless routers function together there are several things to keep in mind.


We'll use this diagram for our discussions:

First, setup each wireless router with a different IP address on that same network.  If you're new to networking, then stick with something simple like in the diagram.  The first router would be 192.168.0.1, then second will be 192.168.0.2, and so on...


Second, each wireless router must use a separate wireless channel.  This is very important.  A lot of people think the complete opposite and try to setup all the wireless routers on the same channel.  When the routers are on the same channel, they just interfere with each other and you'll be lucky if you get anything working.  Your wireless devices are made so they can easily switch channels on the same wireless network without any dropped connections.

Third, each wireless router must use the same wireless security settings. The whole point of this is so you don't lose your wireless connection as you wander around the house.  If you have different security settings, you need separate SSIDs and you'd be dropping your connection all the time when you move around.  So make sure your security mode, algorithms, keys, key renewals, and beacon settings are all the same, whatever they might be.  (I recommend WPA2 with AES)

Fourth, only one routers should run DHCP.  I recommend the router that is connected to your Internet connection for this function.  The Dynamic Host Configuration Protocol is used to give unique IP addresses to your various devices.  If you have multiple DHCP servers and you don't set them up properly then you can end up with IP address conflicts or dropped connections as you move around the house.  When setting up DHCP, make sure to set a range that doesn't overlap with any of the router IP addresses you set from the first step.  Use a range like 192.168.0.100 to 192.168.0.200 should avoid any problems.

Fifth, there should only be one firewall.  The only firewall you should have on your network is the one that connects to the Internet connection.  If you can, I recommend disabling the firewalls on all the other routers.  While the last step will ensure there are no problems if you can't turn off all the firewalls, it's better if you do.

Lastly, only your router that connects to the Internet should have its "Internet" or "WAN" port connected to anything.  For any of the other routers, don't plug anything into the Internet ports.  When you connect your routers together, always use the "LAN" ports.  This keeps them all on the same network and prevents any firewalls from interfering with communications between your local devices.  You will still have the one firewall you setup in step five to protect you from anything on the Internet.






Friday, December 28, 2012

IPv6: When will it really happen?

I was looking through some old drafts in this blog, stuff I had never posted, and noticed one I had written about IPv6 in 2010.  I had started to learn about the details of IPv6 in 2010.  I know it's been coming for a while, but there really hasn't been a lot of pressure.  Need perhaps, but not pressure.

IPv6 is a scary thing to most people.  People are bad enough with the 4 octets of IPv4, but even some of the shorter IPv6 addresses can be downright frightening to them:

4102:44F0:7F0::1/64

This would invoke a WTF from most people.  Thankfully those types of  people will never have
to deal with this.  DNS in all its wonder and glory will be needed more than ever for the ordinary person.

The real question is when will we actually use IPv6?  I know why we need it, but using it is another thing.  I hear from my Windows admin coworkers that when they call in for a support problem to Microsoft and there is a suspected network issue, one of the first things they want is for you to turn off IPv6 (if you can).  Not a thrilling endorsement.

Even worse is that one of the fastest growing consumers of IPv6, mobile phones.  Mobile phones are not really ready for IPv6.  Last check, my Blackberry doesn't support IPv6.  Supposedly Apple has been supporting it since iOS version 4.1, and Android since 4.2 but I hear it's a bit buggy and not actually useful.  So, right now IPv6 is not deployed on a lot of carriers simply because the handsets aren't ready.

So if the mobile operating systems haven't completely gotten their act together, then how long will it be before developers actually start worrying about IPv6?  It's sad to say that we're still a few years away.  I know IPv6 launched this June 6th but I believe the adoption rate is only about 1%.  Some Internet transit providers I've called don't even offer IPv6 feeds and a lot of the residential ISPs still don't offer IPv6.

Wednesday, December 26, 2012

Packets Don't Lie

My nickname was given to me a while back, thepacketmaster.  It was because I love using packet tracers to solve problems.  I sometimes wonder if I'm unique in this sense or if other network/security admins use packet tracers as often as I do.  Time and again I solve problems using packet dumps when nothing else can work.  It's not that using packet tracers is an action of last resort.  It's simply that you can't argue with a packet traces.

Packets don't lie. I'm not saying that people are lying when they come to me with problems that they can't resolve. However, I've seen far too many instances where an administrator of an application, database, or server will come to me with a problem that is based on a false premise given to them by a poorly written error message.  More often than not it starts with, "I think there's a problem with the network".  Fair enough, it could be there is a problem with the network.  We in the network/security realm are not without problems and I never have a problem admitting that.  In my case I'd have to say the security side comes up more than the network side, simply because I prefer firewall rules that are as strict as possible and deny everything that isn't necessary.  Most of the other administrators aren't necessarily appreciative of that fact.

After making sure I understand the problem and checking that it isn't related to the network or security systems, I move onto trying to help the person understand what other problems it could be.  In many instances it could simply be that they've gotten some cryptic error message from a piece of software that says "Network error".  The bane of my existence are developers that write software with generic error messages that always mention the network.  Let this be a lesson to developers to always be specific in your error messages.  Instead of saying "Network error" put something useful like "Cannot bind to port" or "Unable to establish TCP connection to remote system".  Anything but "Network error"!

Once I have a feel for the problem I often try to suggest what other causes it could be.  In my previous lives, before I was a Network and Security Architect, I have been a UNIX admin, Network admin, Windows admin, Application admin, Security admin, database admin, and even a backup admin.  I've written in assembler, C, Perl, C++, php, bash, BASIC and COBOL.  In short, I have a holistic view of IT.  That's not to say I know it all.  Nobody, NOBODY, ever knows it all.  Those that claim to are full-of-it.

If a solution to the problem is still eluding detection, that's generally when I fallback to the packet capture.  This can tell so many things about what's actually going on.  Packet captures are mind altering experiences.  Previous conclusions that seemed unbreakable can be completely shattered or reinforced by a packet capture.  Problems and solutions never even imagined can be envisioned with complete clarity.  Packet captures can be a humbling experience.

The great thing is that nowadays you don't even need help interpreting what a packet capture says.  Tools like Wireshark are so user friendly that I can put it up on a projector to an entire room of people that have never seen a packet capture in their lives, show them what's I'm seeing and what is happening, and they'll understand the problem completely.

Monday, December 24, 2012

Fun with Gingerbread

Merry Christmas to all!  Work recently sponsored a gingerbread contest.   I was immediately interested in building a Cisco Nexus or a Juniper SRX.  I was a little disappointed to find out the  kits were pre-made gingerbread houses.  How much fun is it to just decorate a house that's the same as all the other houses?  (At least that was my thought).  Other coworkers did a great job of decorating their houses, very fancy and neat.  I have to say the attempt by myself and several accomplices was less that neat, but we made up for it with originality.  I will also caveat this by saying we only used the materials we were given.  Many people brought in "extra" decorations and frosting, which I feel went against the spirit of the competition, but I'll defer to the judges on that... (Next year, I'll get a freestyle kit and rock the competition!)

So without further ado, I give you the Gingerbread wireless router...