Posted by Cory Stoker
Fri, 27 Oct 2006 21:37:00 GMT
Often we run into a scenario where a client wants to improve security by implementing an IDS. Now this is OK but often we find out that they are not exactly "ready". What I mean by this is to effectively deploy an IDS on a network you should first cover your bases with what you already got. Before going IDS wild, are you using your existing infrastructure to get the knowledge you need first?
Of course just throwing out an IDS is a quick hit; it can cover your ass if the regulatory audit kids drop by, but for lots it becomes a security lame duck. Do you know how to really make it a valuable component of your security?
"Yeah we have [insert IDS vendor here] in place off the 6509."
"Sweet, what does your ruleset look like?"
"Well I think we have all rules enabled right now."
"Ok, what networks are you watching?"
"We want to see both ways so we are not restricting the nets."
"Do you know what kind of traffic and how much are you seeing?"
"Well, not really, but we have all the usual suspects: SMTP, HTTP, HTTPS, FTP and even IM."
"Do you know how much activity you’re seeing for each of those?"
"Man, we just threw it out there, its working!"
Yeah, that $20k went far. The point is to get off this copy-cat buy and forget.
First, I am a believer in doing the macro before the micro. You can’t pick whether a rule should be enabled or not until you know what’s going on in your network. Enabling all will protect you is bullshit. In fact, enabling all can make things worse (easier to exhaust resources, get blinded, or rev up the false positive counters). And forget about dealing with IDS evasion techniques.
Take logging, a macro thing. Logging is an enabler. Deducing traffic patterns is a macro enabler. You need to do these things first before considering an IDS. Engineers like to complain how hard it is to watch logs and I can empathize, but it is really not that hard to get some valuable numbers. Which firewall rules are taking hits, which are not? What kind of traffic are you seeing and how much? A couple scripts can get you those numbers.
So before you do the IDS thing, do these things at a minimum:
-
Grab your firewall rulesets and the counters for each allow/deny rule. With this you
info you can teach your IDS where to look (vitally important both direction so ingress and
egress).
-
Learn traffic patterns. What protocols are in use, which networks, and in what amounts.
High, average, low - all good numbers. Use this to tune the rulesets. Now you can identify
something like your top 100 talkers. If some server catapults to #1, check it out.\
-
What apps are running. Learn all the things your environment is hosting. When do your
backups run, which servers like to talk to which? Again, information vital to getting value
from an your infrastructure that will enable you to get even more value from your IDS.
Tags ClearNet Security, Cory Stoker, ids, logging, netflow, networking, security | 4 comments
Posted by Cory Stoker
Tue, 22 Aug 2006 23:42:00 GMT
In part 2 of my VA auditing experience I told you all about our "training" for the VA assessment. I am going to finish this out with my thoughts on the first site experience. If you missed it here is part 1. With all the things that had gone on with this project I was very interested in how the actual audit was going to go for each site. Before I could think long on it I was off to the wonderful state of Maine in February.
Now I live in Colorado and most people's preconception of Colorado in the winter is exactly what Maine was... Cold, snowy, and dark. For those of you that don't know, Denver Colorado has a very mild winter and snow barely stays a week on the ground. In the mountains is a different story but Denver is on the plains not the mountains.
So back in Virginia we were told that we needed to car pool with the other auditors and that each auditor was responsible for ensuring the whole team got to the site. This was interesting to say the least as the audit teams were thrown together maybe 2 days before we actually flew out. Each trip I went on had a team with different people. This fact was great for meeting new people but horrible for car pooling as the one person who had the car was expected to ferry us around! Now the issue that greeted me first was that I got to Portland, Maine at about 11:00 PM EST and had to get to Augusta which is about 1 1/2 hours away. Trying to get ahold of the guy with the car did not happen as it went to VM suprisingly enough. Suffice to say I had to take a taxi to Augusta which costs about 170 dollars, footed by the tax payers of course. For people that don't know Maine, Portland is in the south and Augusta, the capital, is in the lower center of the state so a taxi ride was costly.
The second issue was that none of the audit staff could get ahold of each other. In fact I didn't even get to the facility till later on Monday cause we all were staying at different hotels. Hotels, flights, and rental cars were chosen by the coordinators not the auditors so this was not negotiable. Anyhow we were scheduled to be at the facility for 4 days and leaving the 5th day so I was already thinking of how much fun I was going to have.
Onto Monday we go! After I get to the facility with my chauffeur. I finally find out how many computers we are testing. Lets see the audit team had 3 "windows testers" including me so that means we can get pretty good coverage in 4 days right? Well we had to test a grand total of 26 computers and all the mobile nursing stations for a grand total of 30. Remember the checklist, the one that takes about 20 minutes per computer max? 30 / 3 = 10 computers over 4 days. So doing some more math we can estimate about a 4 hour work day including lunch. Now this facility was pretty big. So big that I would have easily gotten lost without my VA companion. Off I went to verify the VA is secure with my clipboard! Suffice to say that my VA companion was pleased to only waste 4 hours running MBSA and Dumpsec.
At this point I am sure a few of you are thinking that it was easier for me to test this minuscule amount of computers and then just chill till it is time to leave but it wasn't. We were not allowed to have cell phones on in the building because of possible interference with medical equipment, we were not allowed to go onto the VA network with our laptops, which makes sense, and we were in the middle of nowhere. Luckily we got to go home on the 3rd day meaning that we had only spent 4 days total in snowy Maine.
A few thoughts on my whole VA auditing experience. First, I did actually like meeting the other auditors and the technical VA personnel. They were great and made the whole project actually move forward. I also got to go to places I would never have gone to if not on business. What a waste of money the whole endeavor was. As Bruce Schneier likes to always say, this definitely had the perception of being a proactive security measure but that is all it was, a perception. I think that there were some serious loopholes somewhere that allows this sort of thing to go on. Like I said earlier, if this kind of project happened elsewhere everyone would be fired, unless of course they are interested in the perception. We ended up doing 10 facilities before we just could not take it anymore. We were not alone in that feeling as I think every team I was on had people that were new who had replaced someone that went to the "training".
Tags Accreditation, Audit, C and A, Certification, ClearNet Security, Cory Stoker, security, VA, Veterans Affairs | 1 comment | no trackbacks
Posted by Cory Stoker
Tue, 22 Aug 2006 04:37:00 GMT
I hope all of you moved over to our new blog server without issue. The other blog software was causing us some issues so we decided to move to another setup. This one runs on Typo so it is more suited for us. Both Tate and I know Ruby somewhat so we should be able to keep this up and running.
I have been on a study path to try and reinforce my class I took at Blackhat on Reverse Engineering. Here is the list of books I have been using:
| Book Title |
Author |
Book Cover |
| "Reversing Secrets of Reverse Engineering" |
Eldad Eilam |
 |
| "Exploiting Software" |
Greg Hoglund and Gary McGraw |
 |
| "Hacker Disassembling Uncovered" |
Kris Kaspersky |
 |
| "Microsoft Windows Internals 4th Edition" |
Mark Russinovich and David Solomon |
 |
| "The Art of Assembly Language" |
Randall Hyde |
 |
| "Write Great Code Volume 1" |
Randall Hyde |
 |
| "Write Great Code Volume 2" |
Randall Hyde |
 |
If you are interested in disassembly or reversing then I highly recommend these books. The main book I am using is the "Reversing, Secrets of Reverse Engineering" and then I am following up with the other books as needed. The one book that might be disheartening is "The Art of Assembly Language". This book first teaches you a special language called High Level Assembly (HLA) and then slowly drops you down to low level assembly for the X86 thereby making you learn two languages. This is why it is so big..... I believe the reason is that it is hard to actually do something in assembly without knowing most of assembly so the author uses HLA to bridge the gap. I thought it worked out fine but I wish I had known that I had to learn HLA first then Assembly. By the time I realized this I was too far to stop.
Tags books, ClearNet Security, Cory Stoker, disassembling, hacking, Reversing, study | 2 comments | no trackbacks
Posted by Cory Stoker
Wed, 09 Aug 2006 01:58:00 GMT
At Black Hat I took the "Reverse Engineering on Windows: Application in Malicious Code Analysis" course. The class was about reverse engineering malicious executable programs on the Windows platform just like the anti virus guys do for big companies like Symantec and iDefense. This was a very fun class for me as my background is not in reverse engineering or it's associated technologies like:
I have taken many courses before for security and network related subjects but never from Black Hat. This was even my first Black Hat Briefings so I was very excited to see how it would turn out. Many times before I was disappointed with the classes I took as they tended to have a very interesting syllabus but then the classes ended up shallow on the technical depth that I thought I would get. This very thought process had me skeptical on the Black Hat course as well but man was I wrong! I think it took about 7 minutes into the class before we were launching IDA Pro and digging into the configuration of the tools we would use for the next 2 days. We didn't even introduce ourselves leaving us to guess who was even teaching us.
My teachers, Pedram Amini and Ero Carrera, were some very bright and intelligent guys that had been in the malware/virus reverse engineering circles for years. They were so adept at reversing things that they have written many tools to help with reversing such as:
As you can see they were both Python fans. Too bad Ruby rocks Python so much that Python needs to go bash the Perl guys to feel better.
So by the first half day I was already disassembling the Mydoom.A virus looking for what it was made of, what it did, how it worked etc... Now this was not a "live" analysis but rather it was loading the binary executable up in a disassembler/debugger called IDA Pro and dissecting the binary code looking for things of interest. Basically we learned two main methods of doing analysis, "top down" and "bottom-up".
Top down was where you start at the program's main function and start labeling all the functions that are called to see what they do. For example you eyeball a function and decide it is gathering the time from the system so you label the function "Gets the time" and so on. Once you do this for all defined functions you can then concentrate on the ones that perform actions of interest like opening sockets or creating processes.
The bottom up approach was where we look for interesting code snippets, items in the Import Address Table (IAT) and strings table. For example if you find a call to "htons" and above it you see the number 80 (in hex of course) being placed into a register, you can deduce that it is making a call out to port 80 on the network.
Yes I know this sounds hard and it was..... But anybody could possibly learn this skill with practice. I will try to write up some good snippets from my class if anybody is interested. Here are some interesting sites to peruse if you are intersted in reversing:
Tags BlackHat, ClearNet Security, Cory Stoker, Reverse Engineering, Reversing | no comments
Posted by Cory Stoker
Sat, 29 Jul 2006 20:58:00 GMT
OK so I guess I have touched a nerve with this subject as our traffic to our blog has spiked since Richard Bejtlich's blog linked to my "VA and Bureaucracy" post. As one to not let a good story go to waste I will finish the story in 2 more parts before I leave for BlackHat 2006.
As you remember from my previous post on the subject Tate and I were part of a large team of people contracted to go audit the VA computer networks and systems at every VA facility in the country. We had thought that we would be working with other individuals of our technical caliber on a comprehensive audit process that follows along with the NIST SP 800 series of documents. As we flew from Colorado to Virginia we had some expectations of this project that were brutally shattered in the coming days.
Before the trip our expertise had been doing security in the corporate space, i.e. a company would hire us to conduct a penetration test or a vulnerability assessment, etc. The government space with its money capital and processes at its disposal must be better, at least in my mind. However, it quickly became apparent that what we were really tasked to do at the VA would get us fired at any of our other private corporate space clients for negligence.
One note about the ethics of what we could do in this particular situation. Two things:
- First is that in the initial meetings with VA respresentatives there was spirited push back on the VA and
contract companies that this whole thing was just not right. In fact I think that many people just gave up after
the introductory meetings because no one was listening.
- Second is that we stayed on the project at this point mostly because we just couldn't forsee that it could
be as bad as it turned out to be. We were always looking for the gotcha that would dispel the myth and make
the project make sense.
And on with the story...
So Tate and I were flabbergasted at the first meeting with the VA but we were at least optimistic on what the next day would hold as we were being trained on the specific audit procedures for each technical area we would be qualified to test in. The technical areas we were going to test were Windows, network, and policy. So the next day bright and early we had to report to the main office of the chief company controlling all the audit teams.
First up for us was Windows testing. We had a lot of ideas of what we would want to hear, like which scanners were going to be run, what tools to follow up results with and what kind of forensic analysis would happen if a computer was exploited, infected, or warez'ed. Well basically a checklist was handed out and a so-called “trainer” read through the procedure. It went something like this:
- Write down info about computer like name, room location, date, OS installed.
- Run MBSA.
- Dump Registry.
- Dump users and groups
- Dump logs if any are even there
- Take a screenshot of the screensaver properties
Gee that sure is comprehensive huh? At least it is super expensive so it must be good. Basically our job as high paid and trained security professionals was to dictate step-by-step procedures (click here, click there, click save-as, etc.) to a VA employee while shoulder surfing. Then after they completed a step we would check it off along with the time it took to run it. The hardest part would be to get the room number and address of the computer we were on as a lot of the VA facilities did not label every room.
Right after our "training" a person asked how many computers we would have to do this to at each facility. The answer was a sampling and possibly all the Windows Servers. Later on at my first facility I went to I tested 10 computers at a VA facility that was about a ~1000 computer facility. I will tell more detail on this in my next entry.
Then another person in the room brought up scripting, "Hey you could write a script that could be run on logon or log off to grab these results from every computer in the facility"
The trainer replied "Scripting is not allowed because it is too dangerous; it could bring down a critical computer"
"OK then why not just leave the critical computers out and do those by hand and leave the non-critical computers in the script"
"No. No scripting can be done as was agreed earlier."
That was the end of that. No scripting because it is too dangerous. The network training was basically the same thing but added in that architecture was not to be looked at. For example if a facility left their network on the Internet with no firewall, it was not to be noted. Just stay to the checklist, don’t look left or right.
At this point we were seriously considering dropping off the project but we decided to give it a shot and remain open-minded. But I can tell you it was hard. I mean if I saw by happenstance (and I am not saying I did) that a computer was running a warez site, if it wasn't caught by the checklist then according to the VA’s audit procedures, it was OK. Again concerns were raised to the company we were contracted under and I believe they had sent it up the ladder but I never heard anything. The checklists were even revised multiple times because many people still had a hard time following it step by step, but the revisions they made never really meant much with respect to security.
In the next part I will talk about my first experience at a VA facility - as a screenshot properties collector, err I mean security auditor.
Tags Accreditation, Audit, C and A, Certification, ClearNet Security, Cory Stoker, security, VA, Veterans Affairs | no comments
Posted by Cory Stoker
Fri, 09 Jun 2006 06:52:00 GMT
So it has been awhile since I blogged. Sorry! So anyways I have been following the security breach that happened to the Veterans Affairs (VA) with interest. For those of that do not know, basically a VA worker had been taking veterans data like SSN and name etc, home so that he could work on his project from home. What happened was his laptop with USB drive got stolen from his house and the VA data went with it. No one knows what if anything happened to the data but it does leave millions of veterans open to identity theft. More info here.
This is near and dear to my heart as it was one of the first projects that Tate and I worked on. The project was at the time the largest Certification and Accreditation (C&A) process for the federal government was happening at the VA. Tate and I jumped onto a contract with a company that had head count and we were off to Virginia for training. Now for those of you that do not know, the C&A process is very large and detailed. It is created and kept by the National Institute of Science and Technology (NIST) and is the process all federal agencies need to follow to be compliant. The documents themselves are actually really well written and freely available. Basically the C&A process is summed up as this: develop a policy, test against it, determine risk points, and then remediation plans. The certification part is where the auditors, audit against the policy and the standards set by the C&A documents. The accreditation part is where the big hunchos of the agency either accept the risk and keep their IT going or stop it until the risk is remediated. This process was what we were "thinking" we were getting into. At this point we did not have C&A experience so this was worth it for us.
Ok.... so we get to Virginia and start what we thought was going to be some hard security work. In fact the company we were working under thought that our skill sets might not be up to par enough.... We had to go to a meeting with all the auditors and the VA staff where they were going to let us in on the work involved and this is where we had our first exasperating moment on this project. The main person involved on the VA side stands up and tells us this is the biggest C&A process ever and blah, blah......Oh yeah, no one other than VA personnel is able to touch ANY computer either physically or virtually! Wait a sec! I still remember the whole crowd of 200 or so auditors all collectively looking around and I think some people in the back row made a run for it at this point. Everyone was thinking exactly what you are thinking at this moment, how can you test "technical controls" without actually testing... Well they came up with the answer, which was to pair us up with our very own set of VA hands, still attached to a VA employee at each site we visit. Yup, now instead of us actually typing and testing a computer we were supposed to relay commands to a VA staff person and they would type it in! Sweet, I can give my carpal tunnel a rest and set my jaw wagging. I can just see it now, "Oh look, it looks like this computer has some malware. Click here, load this tool, select this hex field and check the registry....NO NOT THAT KEY! Run!"
Right about this time the second bomb shell went off.... The guy up front promptly says that all test results we collect are to be given to the VA. This makes sense as it is their computers and they are entitled to our analyzed results right? Wrong! The guy corrects himself and says that the results are not to be analyzed by the auditors but by VA personnel. Hmm...so at this point I am not touching a computer nor am I analyzing the results for risk or what is wrong. Something seems very broken about this process at this point.
In the next part I will explain the next day and our first site experience. In reading this I am sure you are now not surprised to hear about data breaches and lameness on the part of the VA. After all they pretty much subverted the C&A process to insure they pass.
Tags Accreditation, Audit, C and A, Certification, ClearNet Security, Cory Stoker, security, VA, Veterans Affairs | no comments
Posted by Cory Stoker
Sat, 08 Apr 2006 00:54:00 GMT
Friday Fun Crossword Puzzle
I have been reading the Head First series
of books and they have been very entertaining. I would say they are the most
exciting technical books I have read. So in the spirit of learning through fun I
have created a crossword puzzle for you guys to solve. It is compiled from a hodge
podge of facts and should be fun to solve.
Good luck, and here are the
answers.
Tags ClearNet Security, Cory Stoker, Crossword, Fun, security | no comments
Posted by Cory Stoker
Fri, 31 Mar 2006 01:06:00 GMT
So I am sitting here working in a Starbucks...(mmm Vanilla Latte) I look around and I see that the ONLY laptops in the place are Apple iBooks or Powerbooks. There are like 6 of them. Also it seems that Apple is very popular with Ruby programmers. Last week at the Boulder Ruby Users Group there were 9 laptops, 8 Apple, 1 Dell. The Rails creator
David Heinemeier Hansson uses an Apple along with most of his core developers. I am going through the
Head First books, and they use Apple. This progression seems to becoming more intense since Apple released the
Duo Core line. Man I just dont know, I like being pretty unique every where I go but I also could not fathom going back to a Windows style GUI so I might not be so unique anymore!
Tags Apple, ClearNet Security, Cory Stoker, Starbucks | no comments
Posted by Cory Stoker
Sat, 11 Mar 2006 04:08:00 GMT
So what is the furor over the Ruby programming language lately? I have known about Ruby for a few years but never got into it much until recently. I had always heard of it in context of Python vs. Ruby on the Python programming list usually with the Python guys bashing Ruby over this our that. So what is it that is making Ruby so popular now?
Now Ruby on Rails is a framework that helps you create a web application that can render dynamic content quickly and easily. What the hell does that mean? It basically means that Ruby on Rails has a lot of code and functionality ALREADY built for you to use. In a matter of minutes (after installing all the stuff of course!) you can have a web page that queries your database and displays the data.
So what does this have to do with Ruby exactly? Well Ruby enables Rails to be so simple and easy to use. So by now you are thinking what is it that makes Ruby the language so good… The official list most people will say is:
- It is object-oriented down to its toe nails
- Simple syntax, not too many non-alphanumeric in use
- It is interpreted, making prototyping fast
- It is cool as of March 6th, 2006
So what? Python (or insert other language) is Object oriented, simple, and interpreted. Well I will list some of MY items that make me want to continue to master Ruby.
First off the ability of an object to know all its methods is great. In many languages you have to pass a value to a function (I know sounds technical!?) to get that value to do something. A method is basically all the functions an object can execute and a function is a stand alone operation that is not associated with an object. The way this manifests is in the way you call each. A method is called like object.method and a function is function(value). An example would be making a string into a number:
The Python function:
- x = "11" <-- This is a string because of the double quotes.
- int(x) <-- We call a function called int() to make "11" in 11.
The Ruby method:
- x = "11" <-- Again this is a string saved to x.
- x.to_i <-- The string object x has a method to convert a string to integer this case 11.
Python of course has many objects and methods itself and the langauage is actually really cool too, it is just that I like Ruby that much more.
Second is the use of block code and iterators in Ruby instead of using the stereotypically looping constructs. This is great as you can essential build smarter “loops” as the objects themselves know how to iterate over themselves instead of you knowing (or learning) how to iterate over them. For example how you would iterate over a string is different than an array or hash right? How would you iterate over a custom object you create? In ruby it is simple to iterate over an object like so:
Ruby iteration:
- x = [1,2,3] <-- this is now an array (one object) of three things, 1, 2, and 3.
- x.each {|i| puts i} <-- This is a loop basically a for loop!
Now what happened there and what is all that stuff? Well first off x.each is a method call for the object x which happens to be an array. The each method will return each item in an array one by one. Then each will pass the item to the block which is everything between the {}. The block will put the item into the variable i then execute the statement "puts i" which prints the value to the screen. This will be done for each item passed to it by the objects “each” method. Sounds hard but it is easier than this:
A Java for loop:
- for ( i=1; i<6; i++ ) { <-- This will assign 1 to i and only run the loop if i is less than 6. Also i is added to each iteration. How do I know this from looking at it? I don't, a book told me.
System.out.println(i); } <--Prints what is stored in i.
Third, Ruby has CPAN like functionality. I don't mean that Ruby is watching the White House press room for late breaking info. What I mean is that Ruby has similar functionality to the Perl Comprehensive Archive Network. Well CPAN is where you go if you are a Perl programmer that needs ready made code for something like SSHing, parsing XML etc.
Odds are that someone has done that task and placed it on the web. CPAN allows perl programmers to easily retrieve and install these modules of code and use them. So what is the Ruby equivalent? It is called Ruby Gems. Gems is no where as Comprehensive as Perl yet, cause Perl is as old as the Rocky Mountains but it has lots of functionality already. The gem program is how you get rails installed onto your system.
So you want Rails to go with your ruby ring? Step into my gem room and we will see what we can do:
Red ~ # gem install rails
Attempting local installation of 'rails'
Local gem file not found: rails*.gem
Attempting remote installation of 'rails'
Updating Gem source index for: http://gems.rubyforge.org
Install required dependency rake? [Yn] y
Install required dependency activesupport? [Yn] y
Install required dependency activerecord? [Yn] y
Install required dependency actionpack? [Yn] y
Install required dependency actionmailer? [Yn] y
Install required dependency actionwebservice? [Yn] y
Successfully installed rails-1.0.0
Successfully installed rake-0.7.0
Successfully installed activesupport-1.2.5
Successfully installed activerecord-1.13.2
Successfully installed actionpack-1.11.2
Successfully installed actionmailer-1.1.5
Successfully installed actionwebservice-1.0.0
Installing RDoc documentation for rake-0.7.0...
Installing RDoc documentation for activesupport-1.2.5...
Installing RDoc documentation for activerecord-1.13.2...
Installing RDoc documentation for actionpack-1.11.2...
Installing RDoc documentation for actionmailer-1.1.5...
Installing RDoc documentation for actionwebservice-1.0.0...
Red ~ #
Hmm well I will let you guys off for now with this thought. Most times I find that I struggle with the language more than I struggle with the problem I am trying to solve. Ruby has helped me with this one issue. Doh!!! Now I have no excuse for not solving my issues...
Tags ClearNet Security, Cory Stoker, Python, Rails, Ruby, Ruby on Rails | no comments
Posted by Cory Stoker
Thu, 19 Jan 2006 20:39:00 GMT
I run a Powerbook 15", as my main system. It handles most things pretty well except for running Windows in VirtualPC. VirtualPC is so painful on the Powerbook that I hardly ever use it. Now with the Apple line going Intel their could be a possibility to dual boot Mac OS X and Windows. It all depends on the the new BIOS called EFI. If Windows can boot with using EFI, then I think I have found my new scanning laptop!
Tags Apple, ClearNet Security, Cory Stoker, laptop, Macbook Pro, Powerbook, scanning | no comments
Posted by Cory Stoker
Thu, 12 Jan 2006 04:39:00 GMT
PIX 7.x…. This long awaited release of the Cisco Firewall OS has finally been released and has had time to bake. I have had a chance to use some of its new features and definitely learned a few things. Of course the features of 7.0 were pretty large in itself with the advent of
“Bridging Mode” and
"Virtual Firewalls" PIX 7.0 is trying to be the all in one firewall. So when you upgrade the firewall a few things become apparent right away. First off the 7.0 command line is much more like a router than it is a traditional PIX. I think this is Cisco further assimilating the PIX technology into the Cisco technology collective. I am personally divided on this approach as it is now important to remember what mode you are in for certain commands where in the old days of PIX slinging you could execute almost all commands in the config mode. Having to traverse config levels like a router makes half your commands in a config file deal with moving around the OS and not real configuration commands.
Here is an example of old vs. new:
Changing interface details on PIX 6.x:
Changing interface details on PIX 7.x:
We had an interesting situation that would warrant the use of PIX 7.0. We had two external internet address spaces on the same physical link. Now the logistics of this project is that one space needs to be administered by one individual and the other by someone else. Now if this was the old days, it would be difficult to allow each person to administer the access list for its space only as the access lists are ultimately the same in PIX 6.x. Enter in Virtual Firewalls… Virtual firewalls was the answer here. Basically you create multiple images of the PIX OS and have each instance administered by the prospective admin. The virtual firewalls bind virtual interfaces to physical interfaces but for security they cannot affect the physical properties of the interfaces. This means that if an admin were to shutdown his virtual interface it would not affect any other virtual interface nor would it affect the physical interface. Also since each virtual firewall is separate each access list is wholly controlled by the virtual firewall admin.
Later I will show how to configure and use this virtual firewall and discuss the drawbacks of it as well.
Tags Bridging, ClearNet Security, Cory Stoker, Network, PIX, Virtual Firewalls | no comments
