On January 18th Chris Dinsmore brought vast knowledge of security to the Linux community. Setting up firewalls, stopping IP Spoofing, and preparing networking security (via Linux, of course) are only a few samples of what Mr. Dinsmore delivered. If you couldn’t join us then, enjoy the transcript; and we hope to see you on our next live Guild Meeting. You can find a schedule of Guild Meetings in your weekly TechProGuild TechMail or on the Guild Meeting calendar.

On January 18th Chris Dinsmore brought vast knowledge of security to the Linux community. Setting up firewalls, stopping IP Spoofing, and preparing networking security (via Linux, of course) are only a few samples of what Mr. Dinsmore delivered. If you couldn’t join us then, enjoy the transcript; and we hope to see you on our next live Guild Meeting. You can find a schedule of Guild Meetings in your weekly TechProGuild Notes TechMail or on the Guild Meeting calendar.

Note: TechProGuild edits Guild Meeting transcripts for clarity.

MODERATOR: Welcome, ladies and gents. This is Jack Wallen from TechRepublic welcoming you to this week’s Guild Meeting. Tonight I’d like to welcome Mr. Chris Dinsmore, who is going to enlighten us about Linux security!

CHRIS DINSMORE: Hi, everyone. As Jack said, I’m Chris Dinsmore. Just a little background; I’m a senior systems architect for a major security consulting firm in the northeast.

JOSH: NY?

JOSH: YEA! Cool, I am ready to learn.

CHRIS DINSMORE: I am a CheckPoint certified security engineer, administrator, and instructor, and MCSE, Nokia Certified security administrator, RSA certified administrator, and so on.

JSTEELE: Firm to remain unnamed?

CHRIS DINSMORE: The Salinas Group.

JSTEELE: Cool.

CHRIS DINSMORE: We are based in New York, but I’m the senior engineer for the Northeast region, which is based in Waltham, MA.

MODERATOR: Get your fingers ready, and welcome to Chris! Take it away, Mr. Dinsmore (and don’t forget, audience, to ask questions).

First thing’s first
CHRIS DINSMORE: Okay, the first thing I’d like to do is lay down some ground rules for tonight’s discussion.

JOSH: Do you know how many people usually join these meetings? (to moderator)

JSTEELE: I guess we’re supposed to start then 🙂

CHRIS DINSMORE: I won’t be giving you what command line switches to use in ipchains or what files to edit to enable ip forwarding.

MODERATOR: Attendance varies here at the Guild Meetings—between 12 and 18 on Tuesdays.

CHRIS DINSMORE: There are already too many how-to’s on that particular subject.

JSTEELE: Here, here!

CHRIS DINSMORE: And I’m not going to talk about how bad Microsoft security is. We all know there are problems there; let’s get past that particular dead horse.

CHUCK: Very generous!

CHRIS DINSMORE: What I would like to talk about are the principles of securing your information. There are lots of people out there calling themselves security experts who have learned how to install an operating system and disable some services. That’s not what security is all about. In order to provide real security, you need to have organization, focus, preparation, execution, and support. Before I begin, are there any specific topics people would like me to touch on tonight?

Remote control
TSTEELE: I’d like to hear about remote access security.

JSTEELE: I am quite interested in database-enabled Web sites.

JOSH: I’d like to hear some about Web access and how to make your Web server more secure.

CHRIS DINSMORE: Hmm, any relation between J and T?

WHILLARD_ALMA: I am interested in secure data transfer.

JSTEELE: Todd?

CHRIS DINSMORE: Okay, Josh, that’s a good one. Anything else?

JOSH: And how to make a firewall really count.

CHRIS DINSMORE: Interesting. This could have spawned a new catchphrase: The family that secures networks together, stays together 😉 Great. Okay, let’s get started.

JSTEELE: I’ll second both the Web/firewall.

TSTEELE: I’d really like to see what you think about cable modem remote access. I have a bunch of doctors that are screaming for it.

JOSH: Off topic: How to make a chat room like this.

CHRIS DINSMORE: The MOST important thing in any form of security, being physical or information security, is to have a coherent and comprehensive security policy.

CHUCK: Preferably one that allows reasonable access to authorized individuals?

Within reason
CHRIS DINSMORE: What that means, is that before you start any major project, you define what your needs are, what your assets are, and how you are going to facilitate and protect them.

SECTOR: Josh: You can run your own IRCD, which can be connected to one of the regular IRC networks, or be standalone. There are also Web-based options available.

JOSH: To Sector> Thanks.

CHRIS DINSMORE: Okay, back to the security. Anyway, let’s give some examples. Ladies and gentlemen, I don’t mind the occasional random thought, but could you take any off-topic threads out of band please. Thank you.

SECTOR: Josh: If you need further information, feel free to ask (I run an IRC server now).

CHRIS DINSMORE: Let’s start with a typical small business situation. You have a startup company with about 50 users. Those users need access to their email, you let them browse the Web, and you are even nice enough to let them use ICQ and AOL. You also have a Web server with credit card order processing, where customers enter personal information.

AJHAPPLI1288: Sounds like where I work.

CHRIS DINSMORE: Josh, no problem. Exactly, AJ. That Web site has to be able to access your order information and credit card processing system. Finally, you have payroll and accounting that the execs and HR people need to access, but that you absolutely want to keep nasty, external people out of. Not to mention Nasty internal people.

JSTEELE: Been there.

CHRIS DINSMORE: Let me tell you, the security Admins worst nightmare is the intelligent, furious computer programmer.

What a nightmare
CHRIS DINSMORE: I know, I’ve been that worst nightmare before.

JSTEELE: Hee, hee, hee.

CHUCK: Me, too.

NRUSSELL: Made it.

JOSH: I am only 18, but I will be some day.

JSTEELE: Okay, what kind of OSs are involved here?

CHRIS DINSMORE: Hee, hee ,hee. Good for you, Josh. Okay, let’s say that the accounting and admin people use Windows 98, NT is used for most departmental stuff and some of the programming, your art department uses Macs, and your programmers use a mix of NT, Solaris, and Linux.

JSTEELE: Maybe a Novell network and AS 400 🙂

CHRIS DINSMORE: Jsteele, that’s a little more esoteric than I want to get right now 😉 AS 400s have their own profession dedicated exclusively to their security.

NRUSSELL: Sounds like our shop, all the above plus VAXs.

JSTEELE: Sorry about that, Chris. I run across these things as a consultant.

CHRIS DINSMORE: Believe me, I understand; so do I.

JSTEELE: Skip the AS/400.

CHRIS DINSMORE: And VAX added on makes life even more interesting. You run into them a lot at hospitals and insurance companies. But they are mostly in legacy installs right now. Most startups aren’t going to have them.

JSTEELE: Thank God!

CHRIS DINSMORE: Anyway, as I was saying, with that list we have what we need to define a security policy.

NRUSSELL: No, curse the devil. 🙂

CHRIS DINSMORE: When you actually try to write your policy, you should keep the universal security axiom in mind. “That which is not explicitly allowed, is explicitly denies.” —Lavrenti Beria. I mean, “denied.” ‘Scuse me.

AJHAPPLI1288: Kill all the processes, and let Root sort them out?

JSTEELE: <access denied>

CHRIS DINSMORE: I’m a major typo monster. Unfortunately, I have extremely severe dyslexia. If it weren’t for the backspace key, I would be functionally illiterate 😉

CHUCK: Welcome to the club.

CHRIS DINSMORE: So keeping the explicitly-denied rule in mind, we can say the following: All internal users will be allowed to aces the external network over pop3 (email), http, https, ftp, telnet (for those UNIX guys), tcp 5190 (aol), and icw (which I forget the port number of).

TSTEELE: 4000.

CHRIS DINSMORE: Thank you. Internal users in the admin and HR departments are allowed to access the personnel records.

NRUSSELL: You open AOL? We don’t.

JSTEELE: Where are the personnel records being stored?

For internal use only
CHRIS DINSMORE: Internal users in the programming and Web departments are allowed to access the Web servers via FTP and Telnet (they use Netscape on Solaris).

TSTEELE: This is hypothetical situation “n” 😉

CHRIS DINSMORE: Lets say the personnel records are on the HR departments’ NT server.

JSTEELE: Gotcha!

CHRIS DINSMORE: The sales department has full access to the customer and credit card info. No other users can access that info. No other users can access the HR records, either.

AJHAPPLI1288: Accounting should be able to access the CC info.

CHRIS DINSMORE: External users can access the Web server via HTTP and HTTPS. AJ, no, accounting doesn’t get CC numbers; they only get invoices.

AJHAPPLI1288: Okay.

NRUSSELL: Web server outside firewall?

CHRIS DINSMORE: We’ll get to that in a minute. Finally, no external users can access any internal network information other than the Web server. So there’s our basic policy.

NRUSSELL: And SMTP server.

CHRIS DINSMORE: We know what we need to allow or prevent. Now we need to decide how to go about doing that.

CHRIS DINSMORE: Nrussell, actually external users should not be allowed to access SMTP servers directly.

What’s the difference?
JSTEELE: Quick question: Are the internal users on a different server than the NT?

NRUSSELL: SMTP relay server?

CHRIS DINSMORE: Actually, we aren’t even going into whether they have an account or not. This is just who needs to get what type of information from where. It’s a very common mistake to start thinking of things like user accounts and what type of firewall to use before you even have a policy defined.

AJHAPPLI1288: Define the policy, and then build the network around the policy. This causes a few less headaches.

TSTEELE: Not to mention cuts the user whining in half.

CHRIS DINSMORE: Exactly.

JSTEELE: But what if you can’t build the network around the policy?

CHRIS DINSMORE: Or change the network around the policy. Okay, if you try to define a policy around an existing configuration, you will inevitably open holes.

JSTEELE: Or are we talking about a new system?

MODERATOR: But who creates the policy? Is this a coordinated effort or the rantings of a single sys admin?

CHRIS DINSMORE: Define a broad policy, and then configure your site to work with it.

NRUSSELL: No, it’s the suits.

CHRIS DINSMORE: Jack, that’s the rub. This is where it gets difficult. You need to get management to buy in on the project at this point. Make the suits aware of how important security is to your company and how bad things could go if it’s not done properly.

CHUCK: Making everyone happy never works. Someone has to make the judgment call, and that has to be in the form of the policy.

In an ideal world
CHRIS DINSMORE: Ideally, you can get a manager or other “suit” to have a personal stake in the project.

SECTOR: Sometimes they are rather hard to convince.

CHRIS DINSMORE: That way they get a “win” if your project succeeds. This makes them work for you instead of against you. And Chuck, you are very right. Sometimes they are REALLY hard to convince. When you start a major security project, users start looking at you like you are trying to arrest them.

ANDY_DAVIS: Yes. A good point. Find stakeholders for your project. Who else wants this security policy?

CHRIS DINSMORE: But there’s another side to this debate, too. The users are really what’s important here. Without the users, there’s nothing for you to protect. You always need to keep the users’ needs foremost in your mind, and balance them against the security requirements. There’s really no way to avoid the trade-off.

AJHAPPLI1288: How you present your ideas also influences things, too. If you do it right, you can get the majority of management (in a startup or smaller company) to buy off on it easily.

CHRIS DINSMORE: But if you are smart, you can get around a lot of the problems, by getting your users to buy into the project, and finding ways to make what they need work.

TSTEELE: Protecting the users from themselves is the hardest part of policy. You want them to be happy, but you can’t have a manageable network without locking them down some.

CHRIS DINSMORE: Actually, you could care less if the users are happy. You want them to not be angry and to be productive. Don’t try to make people happy, try to make them satisfied.

NRUSSELL: Once we decide on the policy, what’s next?

CHUCK: Yea verily.

You can’t make everyone happy
CHRIS DINSMORE: If you try to make them happy, you are just going to shoot yourself.

ANDY_DAVIS: How do you balance users’ needs with protecting them and the company assets?

SECTOR: If you could just show the suits what could happen if security was breached?

CHRIS DINSMORE: Okay, next step, how are we gonna implement this policy. Sector, exactly correct. A good scare on the news will usually do the trick. Anyway, how are we gonna get this thing working?

TSTEELE: Linux. =)

CHRIS DINSMORE: The most common method for protecting a network is a firewall. Tsteele, how about you set up a normal Linux box on the net, and see how long it takes for someone to crack it? 😉

TSTEELE: Mine isn’t normal.

NRUSSELL: Same is true with many normal install; i.e. M$SQL

CHRIS DINSMORE: I don’t care how secure the operating system is inherently, and BTW Linux is by no means the most secure; if it is not specifically and systematically made into a firewall, it will be broken. And even then, it will be broken. It will just take some time. It’s just like with a car thief. If they want it bad enough, THEY WILL GET IN.

CHUCK: The best thing is to make it difficult enough to break that it is not worth the effort.

JOSH: At this point, don’t you have to think like a “hacker” to fully secure your systems?

CHRIS DINSMORE: Chuck, that’s only the first step. Josh, no. Don’t start thinking like a hacker, yet. I want you to start thinking like an architect. Specifically, like an architect building a fortress.

JOSH: Okay, that sounds like a smart thing as well. I didn’t think of it like that.

JSTEELE: Now, what about a router before the firewall.

CHRIS DINSMORE: And when you try and secure a military target, you trot out the old military defensive principles.

NRUSSELL: Using firewalls and TCP_wrappers?

CHRIS DINSMORE: Three words folks: DEFENSE IN DEPTH. Nrussell, not yet. We are still in the architecture phase.

MODERATOR: Explain “defense in depth.”

CHRIS DINSMORE: I was getting to that, Jack. 😉

SECTOR: Multiple layers of protection.

CHRIS DINSMORE: Okay, so we know that they will get in right?

MODERATOR: Here’s your 13 minute warning, folks – 😉

CHRIS DINSMORE: Yes, multiple layers of protection. Your publicly accessible server is the Web server. We need to let the outside world see that.

NRUSSELL: Outside firewall? But we definitely want it to be behind a firewall.

JSTEELE: Whew!

NRUSSELL: DMZ?

ZOP: I want to shoot the guy who wrote the IRC Gateway. They need to implement at least PING on here.

We need to talk
CHRIS DINSMORE: Not only that, but we have things like DNS, and mailservers that other servers from the outside world need to talk to.

CHRIS DINSMORE: Nrussell, exactly.

JOSH: DMZ is?

TSTEELE: Demilitarized zone.

CHRIS DINSMORE: You set up a network off of your firewall that directly connects to it but has access to the outside world. Then you set up your internal network so that it goes through the firewall to connect with those Web servers.

ZOP: Josh: Demilitarized Zone—servers on the DMZ of a firewall can access and touch both Internet and local resources.

CHRIS DINSMORE: So even if they break through to the Web server, they have to break in again to get inside the network.

JSTEELE: Like T1 -> router -> firewall ->web server ->internal net?

CHRIS DINSMORE: No, more like this.

NRUSSELL: t1 -> router ->firewall->web->firewall->inside.

JOSH: T1>router>Fire>web>fire>internal? Hee. Hee.

CHRIS DINSMORE: T1–>firewall–>dmz–>firewall–>internal net.

JSTEELE: Ah, a firewall behind the Web.

CHRIS DINSMORE: Hmm, sick minds think alike.

May I have seconds?
SECTOR: Anything that doesn’t need to be accessed publicly, put behind the second firewall.

NRUSSELL: What type of firewall, circuit, or packet for first firewall?

CHRIS DINSMORE: Right, Sector.

ZOP: Josh: You catch on quick 🙂

CHRIS DINSMORE: Okay, while we still have time, let’s just talk a bit about firewall types.

JOSH: ZOP> I try!

CHRIS DINSMORE: There are three main types of firewall, packet filters, application layer gateways (proxy server) and stateful inspection firewalls.

ZOP: Okay. I’m, like, so totally hating this IRC Server. Let’s see if Java works on the other computer.

CHRIS DINSMORE: A packet filter controls the flow of info based on the properties visible at the network layer; i.e. port, protocol, etc. An application layer gateway controls information by looking at the contents of the packet itself as well as the network layer info.

JOSH: I.E.?

CHRIS DINSMORE: And a stateful inspection firewall controls info based on both of those two factors, plus what is called the “connection state”. The connection state is basically a record of what network host connected to what other host at what time. So if I send out a request to a Web server saying I want a Web page, I know to allow the response from that Web server through the firewall.

NRUSSELL: 953?

Opening the gate… way
ZOP: Josh: App gateways are like WWW Load Balances. They look at the App Data (the GET or POST req) and decide where it should go. But a firewall type adds the ability to say “Not allowed” without ever reaching the WWW Server.

CHRIS DINSMORE: Pretty close, ZOP. Unfortunately, ipchains is basically a packet filter. Technically, it does have some stateful awareness, but not much.

NRUSSELL: Unfortunately because?

CHRIS DINSMORE: As is ipfw?

JOSH:ZOP> Thanks.

ZOP: Packet filters are quite limited.

CHRIS DINSMORE: Because it’s the most common free firewall software for Linux.

NRUSSELL: And slower?

CHRIS DINSMORE: And exactly, packet filters can’t do much.

ZOP: They can only tell what to do based on address and port.

CHRIS DINSMORE: Actually, packet filters are fast; they just aren’t very secure.

ZOP: Not necessarily slower, just less functional.

NRUSSELL: Okay.

CHRIS DINSMORE: Right, Zop.

NRUSSELL: Less secure?

Intrusion alert
SECTOR: What about logging of intrusion attempts?

CHRIS DINSMORE: Good news for businesses wanting to use Linux firewalls, however. FireWall-1 is coming out for Linux third quarter this year.

ZOP: Nrussel: Packet filters block regions of addresses or allow them, based on a host address.

MODERATOR: Ladies and gents, we have 5 minutes remaining.

JSTEELE: Do you have a Web address, Chris?

CHRIS DINSMORE: Yes, less secure. Since a packet filter can only read the network layer, it can’t deal with encryption, encapsulation, spoofing in a significant way, authentication, or user management.

ZOP: Nrussel: If someone manages to get an address they aren’t supposed to have, then your firewall is worthless (which of course depends that the router will always do the right thing, which sometimes doesn’t happen).

AJHAPPLI1288: FireWall-1 is one of the highest rated firewalls on the market. It’s pretty nice.

NRUSSELL: That’s where ipspoof comes in, right?

ZOP: _ACTION figures.

CHRIS DINSMORE: My corporate address is www.salinasgroup.com or www.managedfirewall.com, My personnel address is at http://chris.byrne.net.

ZOP: I’m an hour late.

The end of the road
TSTEELE: So does FW-1 do what packet filtering doesn’t? Just out of curiosity.

JSTEELE: Thanks.

CHUCK: Is FireWall-1 really more than vaporware at this point?

AJHAPPLI1288: Chuck: FireWall-1 has been out for Solaris and NT for sometime.

CHRIS DINSMORE: FireWall-1 is the leading firewall in the world. They have 48 percent market share with over 5 million users protected worldwide. They are also ridiculously expensive.

NRUSSELL: Leading in sales. What about security?

TSTEELE: Scary. Brings thoughts of the movie The Net to mind.

ZOP: I don’t like firewalls too much, though. Sometimes they lend the user a false sense of security.

CHRIS DINSMORE: Nrussell, they are also the most secure firewall I have seen for NT, or Solaris, and among the most secure for all operating systems.

NRUSSELL: Agreed!

CHRIS DINSMORE: SOP, you are definitely correct. A firewall is only as good as the policy it enforces, and the network it protects.

SECTOR: A simple thing that should be done is get rid of everything you don’t need in /etc/inetd.conf.

JOSH: What would you recommend I play with if I am just setting up one for my home, on a cable modem, just to learn?

CHRIS DINSMORE: Josh, use IPCHAINS for Linux, Black ice for NT, or FW for freeBSD.

MODERATOR: Well, time to wrap it up.

JOSH: Okay, I am going to try the Linux route, thanks.

MODERATOR: Tonight we had a lot of great participants.

SECTOR: Warning: If you connect the cable modem directly to the hub, it will be able to see all systems.

CHRIS DINSMORE: Hey, I just wish we had more time—A LOT more time 😉

ZOP: _ACTION will have to remember the right time.

SECTOR: More time would be nice.

AJHAPPLI1288: Thanks. I’ve been given some great ideas on how to redesign my network at work.

CHUCK: Appreciate everything, guys. It’s great to have a chance to learn something worthwhile.

JSTEELE: Thanks for the discussion, Chris! It was quite informative.

CHRIS DINSMORE: Tsteele, remember, before you get into the nuts and bolts, you need to get it planned out.
Our Guild Meetings feature top-flight professionals leading discussions on interesting and valuable IT issues. You can find a schedule of Guild Meetings in your weekly TechProGuild Notes TechMail, or on the Guild Meeting calendar.