Whoops, shows how much I've been paying attention to that particular aspect of the security industry. Oh, well, MD5 still offer longer password lengths.
* Disable all the unused services. ftp, talk, biff, finger - the usual suspects. Make sure the inetd internal services (echo, chargen, discard, daytime, time) are disabled; there are some inetds that have overflow problems with these services, which will crash inetd.
* Shadow passwords.
* MD5 crypted passwords. Don't know if this is supported on RH, but Debian 2.0 or better does. This is a wonderful feature, it's settable in/etc/login.defs. It allows passwords longer than 8 characters (standard shadow limit), and to the best of my knowledge there are no password crackers which will crack MD5 hashed *NIX passwords. There's also lots of other fun stuff to mess with in login.defs, btw.
* Strict firewall rules; allow only addresses that should be coming into your system (or network) in on only the interfaces configured for them. Reject anything else, and log it. Reject ports you don't use. When setting up firewall rules, use numeric IP addreses to prevent DNS spoofing attacks.
* Make sure the line `ALL: PARANOID' is in/etc/hosts.deny - this will drop all connections from systems where the connecting ip and dns do not resolve properly; e.g. if a connect from 10.1.1.1 comes in, and reverse-resolves to proxy.somenet.com, but proxy.somenet.com resolves to 192.168.1.1, the connection is dropped. This prevents DNS spoofing attacks.
* Think about a chroot()'d webspace. Make sure the chroot() jail is writable only by a privledged user.
* Never log in as root. Have a user account and use su or sudo.
* Strong passwords.
* Never ever perform a privledged operation (like su) over an insecure transport like telnet or rsh. ssh is your friend here.
* Think about mounting your root partition read-only to prevent trojans. Maybe also set the ext2 immutable flag (chattr +i files) on areas which should not be modified;/bin/sbin/usr/bin/usr/sbin - etc.
* Run a logwatcher which will filter your logs and mail suspicious entries to you. Abacus logwatcher is good. (http://www.psionic.com/abacus/) Set it up to page your alphapager if something funny happens. (All serious *NIX admins have alphapagers, right? right??)
* Write an init script to alphapage you when the system changes runlevels.
* Workstations make bad servers, and vice-versa. Don't use a server as your desktop machine.
* Once you have a stable configuration, leave it unless you must change something. (bug etc)
Hmm... I played with a few backup solutions on my Debian box a while ago. I found that plain `tar czf' is the best way to go. It's reliable and fairly quick. I messed with Taper, but it was definitely not ready for prime time. I regularly got segfaults when doing full backups.
Can someone tell me how I might get dump to use all 4gb of my Travan-8 tape drive? By default it only uses a few megs before asking me to switch tapes, and I could not get it sorted out with the stuff in the man page.
Hmm, probably not too feasible. You might see if cdrecord/cdwrite will burn from stdin, then you could `tar czf | cdrecord -v dev=0,0 speed=1' and then access it with tar.
CD-Rs make good long-term backup media, but for most backup needs tapes are far superior. You can't make a coaster out of a tape.
I really hope that this moves the web browser arena forward. There are no adequate web browsers for Linux at this point; Communicator 4.xx is some of the most unstable software I have ever run on a Linux box. Konqueror dosen't support CSS. Gnome MC just plain sucks. I'm left with Lynx. At least it dosen't crash and renders CSS correctly.
It sure would be nice to be able to run that QNX web browser on Linux...
That is not caused by a hosed routing table, that happens when a router goes down; there should be another router on the same segment as CROM-something.CRL.NET, but it is unreachable, so that router forwards the packet back to T3-something.CRL.NET, as that is it's default gateway and may know an alternate route to the destination.
If you had an icmp logging type program you would be seeing net/dest unreach messages from the CDROM-something.CRL.NET router.
i stopped using altavista a while ago. i searched for something that should have had several matches- and got one "realname" match. obviously not what i wanted.
sorry guys, but i want a search engine that searches the web, not it's own advertisements.
Last I heard, the uClinux project had released a stable 2.0.32 kernel which worked on Palm devices- I personally ran it under XCopilot with 1mb ram.
However, I'm unsure if it supports the new DragonBall EZ processor in the new Palm V and IIIx. If/when I get some additional information, I am planning on flashing it onto my IIIx and starting to develop some PalmOS-like apps for it.
I want to be able to whip out my Palm, look up phone numbers, etc, and when I hit the memo pad button, I want to see VIM come up in a text console:)
Well, I don't think so- various emulators of Nintendo systems have been around for years. The first SNES emulators started development some time back in '93-'94. There are already many game boy/NES/SNES emulators out there, I don't see why they would care about one more. Go look here for info about Virtual GameBoy, the first (and one of the best) gameboy emulators out there.
Slashdot Mirror
Whoops, shows how much I've been paying attention to that particular aspect of the security industry. Oh, well, MD5 still offer longer password lengths.
Here's a quick(??) checklist:
/etc/login.defs. It allows passwords longer than 8 characters (standard shadow limit), and to the best of my knowledge there are no password crackers which will crack MD5 hashed *NIX passwords. There's also lots of other fun stuff to mess with in login.defs, btw.
/etc/hosts.deny - this will drop all connections from systems where the connecting ip and dns do not resolve properly; e.g. if a connect from 10.1.1.1 comes in, and reverse-resolves to proxy.somenet.com, but proxy.somenet.com resolves to 192.168.1.1, the connection is dropped. This prevents DNS spoofing attacks.
/bin /sbin /usr/bin /usr/sbin - etc.
* Disable all the unused services. ftp, talk, biff, finger - the usual suspects. Make sure the inetd internal services (echo, chargen, discard, daytime, time) are disabled; there are some inetds that have overflow problems with these services, which will crash inetd.
* Shadow passwords.
* MD5 crypted passwords. Don't know if this is supported on RH, but Debian 2.0 or better does. This is a wonderful feature, it's settable in
* Strict firewall rules; allow only addresses that should be coming into your system (or network) in on only the interfaces configured for them. Reject anything else, and log it. Reject ports you don't use. When setting up firewall rules, use numeric IP addreses to prevent DNS spoofing attacks.
* Make sure the line `ALL: PARANOID' is in
* Think about a chroot()'d webspace. Make sure the chroot() jail is writable only by a privledged user.
* Never log in as root. Have a user account and use su or sudo.
* Strong passwords.
* Never ever perform a privledged operation (like su) over an insecure transport like telnet or rsh. ssh is your friend here.
* Think about mounting your root partition read-only to prevent trojans. Maybe also set the ext2 immutable flag (chattr +i files) on areas which should not be modified;
* Run a logwatcher which will filter your logs and mail suspicious entries to you. Abacus logwatcher is good. (http://www.psionic.com/abacus/) Set it up to page your alphapager if something funny happens. (All serious *NIX admins have alphapagers, right? right??)
* Write an init script to alphapage you when the system changes runlevels.
* Workstations make bad servers, and vice-versa. Don't use a server as your desktop machine.
* Once you have a stable configuration, leave it unless you must change something. (bug etc)
* BUGTRAQ
* Common sense.
You might want to think twice about using 2.2.9. There are some known stability issues with 2.2.8 & 2.2.9; 2.2.7 is the latest stable `stable' kernel.
Hmm... I played with a few backup solutions on my Debian box a while ago. I found that plain `tar czf' is the best way to go. It's reliable and fairly quick. I messed with Taper, but it was definitely not ready for prime time. I regularly got segfaults when doing full backups.
Can someone tell me how I might get dump to use all 4gb of my Travan-8 tape drive? By default it only uses a few megs before asking me to switch tapes, and I could not get it sorted out with the stuff in the man page.
Hmm, probably not too feasible. You might see if cdrecord/cdwrite will burn from stdin, then you could `tar czf | cdrecord -v dev=0,0 speed=1' and then access it with tar.
CD-Rs make good long-term backup media, but for most backup needs tapes are far superior. You can't make a coaster out of a tape.
I really hope that this moves the web browser arena forward. There are no adequate web browsers for Linux at this point; Communicator 4.xx is some of the most unstable software I have ever run on a Linux box. Konqueror dosen't support CSS. Gnome MC just plain sucks. I'm left with Lynx. At least it dosen't crash and renders CSS correctly.
It sure would be nice to be able to run that QNX web browser on Linux...
Blah, 40 minutes left. Gotta get me a DSL...
That is not caused by a hosed routing table, that happens when a router goes down; there should be another router on the same segment as CROM-something.CRL.NET, but it is unreachable, so that router forwards the packet back to T3-something.CRL.NET, as that is it's default gateway and may know an alternate route to the destination.
If you had an icmp logging type program you would be seeing net/dest unreach messages from the CDROM-something.CRL.NET router.
i stopped using altavista a while ago. i searched for something that should have had several matches- and got one "realname" match. obviously not what i wanted.
sorry guys, but i want a search engine that searches the web, not it's own advertisements.
Last I heard, the uClinux project had released a stable 2.0.32 kernel which worked on Palm devices- I personally ran it under XCopilot with 1mb ram.
:)
However, I'm unsure if it supports the new DragonBall EZ processor in the new Palm V and IIIx. If/when I get some additional information, I am planning on flashing it onto my IIIx and starting to develop some PalmOS-like apps for it.
I want to be able to whip out my Palm, look up phone numbers, etc, and when I hit the memo pad button, I want to see VIM come up in a text console
Well, I don't think so- various emulators of Nintendo systems have been around for years. The first SNES emulators started development some time back in '93-'94. There are already many game boy/NES/SNES emulators out there, I don't see why they would care about one more. Go look here for info about Virtual GameBoy, the first (and one of the best) gameboy emulators out there.