Matthew Palmer wrote:
That would be debsums, I think. Useful as far as it goes, but on an alreadyI was talking about steps to take in preparation for an attack in order to minimize damage and down time - you
compromised machine, it's of limited utility, because the checker, the sums
can keep checksums and other data on read-only media and compare with the compromised machine.
database, or anything underlying either could have been compromised. You can take the system off-line and run from known, trusted sources, but you're 3/4 of the way to re-installing by that point, and you still can't be sure that something hasn't been *added* to the system you don't know about.
free version of
"electric fence"?
The electric fence I know is a buffer overrun checker.
I was thinking of trip-wire, as Erik wrote. (Thanks Erik).
I haven't been to the talk, I respond only to what I read in the posted slides.
3. logwatch (has a debian package) mails me every day what happened in
my logs, helps keep a casual eye on my logs without having to rummage through them
every day.
Again, mentioned in the talk, but worth mentioning again -- I've also seen
recent talk of a real-time log analyser, which would be of particular
interest if you had some sort of SMS or pager alert system available.
Certainly it's not adding to security by itself, but still I haven't seen any "dirty connects" on any of my
4. You might call this "security through obscurity" but I've grown tired of my apache/ssh/imaps
ports being scanned dozens of times per hour so I moved them to non-conventional ones and
reduced the load practically to zero. I'm aware this is not practical for public HTTP server but
it might help a bit with the other services. Lesser noise helps find actual attacks.
Definite security by obscurity. I'm surprised it's not more common, but I
know many proxy scanners will automatically try some/many other ports,
looking for "protocol signatures" (ie throw a simple HTTP/1.0 request at it
and see if it goes "poing", or see if the first three characters sent
straight after connection are '220'). This could easily be extended to
arbitrary port scanning to find open ports, then this sort of
protocol-signature scanning to find, say, the port you happen to have left
your SSH server on.
Basically, it's probably an effective technique to keep yourself out of the
"really low-hanging fruit" market, but certainly don't give it too many
points in your risk mitigation assessment.
non-standard ports since I started using them, so it's easier to watch for anomalies (which I do through
the logwatch e-mails).
That's what I was wondering about too - a dedicated firewall box should also make it possible to install
I'd be glad to hear what people think about these tools and practices what else can I do to protect
my home machine (which is connected 24/7 through ADSL).
If you can afford it, a second box to act purely as a firewall / router
(preferably transparent) is an *excellent* idea. It won't necessarily stop
the rodents, but it'll certainly slow 'em down a lot.
the absolute minimum on the dedicated firewall, making it yet harder for an attacker to find useful tools
there, easier to re-install (e.g. boot from a CD-ROM?). There are numerous firewall distributions for
this purpose.
Cheers,
--Amos
-- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
