On Sat, 2004-11-06 at 10:38, Paul M Foster wrote:
> All failed and some successful packets.
No analysis of those packets? No analysis to identify different packet
streams into an attack or, more common yet, an outgoing stream due to an
existing LAN client compromise?
> Logging from iptables. Other logging is not really important to me. If
> the machine goes down or panics, I can replace it rather quickly.
I think we're on a different wavelength here.
> Currently, all systems are Linux (Mepis). Java is turned off on all but
> one system. We have yet to see a browser compromise, and I'm not really
> concerned about it.
Okay, if you feel the risk is mitigated on the client, I can understand
that.
> I'm not tempermentally inclined to spend time analyzing logs. Plus, I
> haven't the expertise to do it with any rapidity. It's more of a
> slogging exercise with me.
A number of firewalls are coming with "point'n click" installations of
logging and Snort analysis. Well worth a hard drive to me.
Again, to each his own. As you stated, and I agreed based on your
viewpoint, you have mitigated risk on the client.
> I suppose if someone really really wanted to hack me, they could somehow
> intercept my traffic and analyze it. And I suppose I could then be
> hacked. But I consider the likelihood very very remote. I've watched the
> traffic go by, and it's mostly nuisance traffic (blind NETBIOS probes
> and such).
Clients are typically where systems are compromised these days, not
straight on attacks. It's just based on my experience, that's all.
> I decided a long time ago that I'd forego the Cheyenne Mountain school
> of thought for security on my home network.
I wasn't stating that I recommended that either. In fact, that's more
of an "layers of internal protection" approach, not applicable to
logging at all.
I was just suggesting that networking logging and analysis is great for
identifying when a client system is compromised. The danger isn't in
the hack, it's in being hacked and not knowing about it.
In your case, you feel you've mitigated risk to client exploits enough
that you do not need logging. Again, I can appreciate that viewpoint
now that you've told me what systems you have.
I have one XP system behind my firewall, so I have logging+IDS. I've
already caught several pieces of Spyware the latest "commercial" tools
missed.
> It is too much to absorb without an IDS. However, I can watch packets go
> by and fail, and see what ports, addresses and flags are involved. From
> there it's possible to determine if I need to look further into the
> situation. The logging is any failed packet and some successful
> packets. Certain IP addresses are blocked, and I see that traffic as
> well.
I know this is going to seem argumentative, but you are looking at this
in real-time, 24x7?
I'm not questioning you anymore. You've stated flat out that you do not
see your clients as a risk, so the point is now moot. I'm not going to
change your viewpoint, I understand. Not a big deal.
> Don't look for new techniques here. I'm not that good.
I'm not either. I'm far too "white hat" to be good. I just lay down
good practices for others to follow in my career. That's all.
You've stated you are mitigating risk at your clients, and that doesn't
require any further defense in-depth. You're already well ahead of
people who run Windows systems.
> I basically block all malformed session traffic, only allow properly
> formed session traffic from inside the LAN, and block any but already
> started session traffic from the internet. Derek's firewall script (on
> the SLUG FAQ page) is probably a close match for what I do. I log any
> failed packet.
And that's cool. All I said was that many compromised clients send out
proper traffic. And they are originally compromised in the same manner,
a fully well-formed stream. In your case, you feel you've mitigated
risk at the client itself, and I can appreciate that.
> Yes, you know far more about security than I do, and your networks are
> far more secure than mine.
I seriously doubt that.
> However, I don't have Fort Knox sitting behind my firewall, and it's
> not worth it to me to configure things as though I do.
I'm far more lazy than yourself. I use IPCop, check my logs twice
daily, and do updates. I have a few additional rules, but God knows I
don't use a "deny-all outgoing" by default either (most ideal).
> It's a trade-off. I sacrifice some security for ease of use.
I do the same, I run IPCop. Now I tighten it a bit, and one can even go
further, but "out-of-the-box," IPCop gives you basic IDS.
If you can use a web browser and can remind yourself to use it twice
daily, then you can do IDS with IPCop. ;->
> I suspect most people approach it that way, good or bad. If I were
> the security guy at IBM, I'd learn a lot more and approach things
> differently.
You don't need to with IPCop.
> Also note that for people who work with security all the time, setting
> up security networks is relatively straightforward. For me, it's not. I
> used to be an electrician, so working with household electrical
> equipment and electricity are simple to me.
Again, you don't need to with IPCop.
> But to most people, they're scared of it. Same thing, really.
Again, with IPCop, you don't need to. ;->
-- Bryan J. Smith b.j.smith@ieee.org ------------------------------------------------------------------ "Communities don't have rights. Only individuals in the community have rights. ... That idea of community rights is firmly rooted in the 'Communist Manifesto.'" -- Michael Badnarik----------------------------------------------------------------------- This list is provided as an unmoderated internet service by Networked Knowledge Systems (NKS). Views and opinions expressed in messages posted are those of the author and do not necessarily reflect the official policy or position of NKS or any of its employees.
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 16:33:32 EDT