On Wed, Aug 15, 2001 at 02:04:30AM +0200, Ogle Ron (Rennes) wrote: > > Do you mean that you have 3 interfaces on every machine or at least 2 where > at least 1 interface is connected to a LAN segment that connects your > logging machine? Or is there a separate firewall from your front end > firewall where this administrative traffic is filtered? Option 1 - three interfaces on each machine (where possible, sbus NICs cost a lot, and our budgets don't always stretch far enough). > If it is the first answer, how do you protect your log server from a > break-in on one of your web servers? I've seen many people try to explain > that by putting a second interface on a box without firewall protection to > use for administration makes the administrative LAN safe. Well, funny story actually - the loghost didn't used to be protected as well as it needed to be, and a security incident brought this to our attention fast (an admin added the box to NIS+ without telling anyone and the ssh port was open to the world, meaning open access to all valid NIS+ user accounts). Since then the box has been placed behind a packet filtering firewall. Only the two ports used for syslog are open to our internal nets (single port actually, but both UDP and TCP). For administrative access SSH is open to only two hosts (packet filters again) and the only authentication method available through the SSH daemon is public-key authentication (you'd better beleive the private keys used for this are encrypted, too). The host is actually running without a single SUID binary as well. I still don't claim the administrative LAN to be "safe", I just try to minimize the damage from any one host being compromised. Hopefully now the loghost is "safer" than most hosts. Heck, I don't know how anyone can ever call a LAN "safe". What does that mean? Even if every host used IPSec for their communication, they aren't safe from attack from each other. One machine can still try to brute force passwords against another, or port scan it, etc, etc. Even if each host also had packet filtering enabled, they likely need to leave some service running, and that service is vulnerable - like the syslog service on my loghost. I am only as safe as my firewall and my syslog daemon. I minimize/eliminate services running on firewalls and try as best I can to run daemons that Do The Right Thing(tm). > The only thing that this does is make the hacker happy. Once the hacker > owns one of your web front ends, then he/she has full access to all of the > interfaces on that box. This means that he/she now has full access to that > administrative network and all of the machines on that LAN without benefit > of a firewall to protect your log server from being attacked on all ports. Of course, all true. Segmenting was really for performance in our case, NetOps decided that we had outgrown a single-network architecture. Overall I'm glad we did it. > What's worse is that these people even use an automatic SSH or SSL > connection directly to the log server. This means that now the hacker has > direct SSH connection right on the log server without having to guess a > password. They do this believing that they are protecting the channel, but > in reality they are hiding all activity of the hacker from any sniffer or > NIDS. I agree that even used with a restricted shell for the account, an automatic SSH session is not the way to go. The encryption needs to used without shell access to the loghost machine. Perhaps if the loghost machine connected to the log "client" hosts, this could be closer to "acceptable". This isn't practical, however, since any break in the connection, due to a reboot or network problem, would necessitate the client having to signal the loghost to re-establish the forwarded connection though some home-grown system. Plus I hate automatic trusts in any direction, even from the loghost. > I believe the best solution is to make sure that the log server is on it's > own LAN protected from all other machines by a firewall. To move the logs, > only allow the normal syslog or equivalent program to run to the log server > from the "clients". Do NOT try to protect this channel with null password > public key authentication over IPsec, SSH or SSL. Sounds like we're getting closer to a "Central syslog server best practices" standard, like the subject says :) We may even want to write something up, once we hash all this out. I still like the idea of protecting the log stream with encryption, but this needs to be built into the syslog daemon, or done without using a shell account on *either* end of the connection, IMHO. Hell, doesn't the Windoze "cryptcat" utility do that already for arbitrary network data? Doesn't seem like it would be so hard, I just haven't gotten around to finding the "right" solution to this yet (some damn web server goes down or something whenever I think I'll have a free minute, you know how that goes ;) -- Nate Campi (415) 276-8678 UNIX Ops, Terra Lycos - WiReD SF --------------------------------------------------------------------- To unsubscribe, e-mail: loganalysis-unsubscribeat_private For additional commands, e-mail: loganalysis-helpat_private
This archive was generated by hypermail 2b30 : Wed Aug 15 2001 - 11:19:52 PDT