Re: hardening checkpoints
On Wed, Dec 21, 2005 at 08:48:19PM +0100, Davide Prina wrote: > steve ha scritto: > > >connection time, so she simply refused. Moreover, in Italy you have to > >give an ID (they do a photocopy of it; she couldn't tell me how long they > >keep it..) to be able to use a computer in an Internet Café (terrorism > >you know...). > > yes. All data (only your person identification and all sites you have > visited) will be registered, for now, until 31 December 2007 (but this > date can be delayed with a next law) It is with great reluctance that I have agreed to this calling. I love democracy. I love the Republic. Once this crisis has abated, I will lay down the powers you have given me! Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hardening checkpoints
steve ha scritto: connection time, so she simply refused. Moreover, in Italy you have to give an ID (they do a photocopy of it; she couldn't tell me how long they keep it..) to be able to use a computer in an Internet Café (terrorism you know...). yes. All data (only your person identification and all sites you have visited) will be registered, for now, until 31 December 2007 (but this date can be delayed with a next law) > right : you eat better in France than in Italy wrong Ciao Davide -- Dizionari: http://sourceforge.net/projects/linguistico Conoscere il TC: http://www.no1984.org Strumenti per l'ufficio: http://it.openoffice.org Sistema operativo: http://www.it.debian.org Browser: http://www.mozilla.org/products/firefox Client di posta: http://www.mozilla.org/products/thunderbird Linux User: 302090: http://counter.li.org -- Non autorizzo la memorizzazione del mio indirizzo di posta a chi usa outlook: non voglio essere invaso da spam
Re: hardening checkpoints
Alvin Oga wrote: italians just passed a law that all isp and internet cafe etc are required to ask for ID of "ALL" visitors and users of their PCs and services it shouldnt matter to that if we reboot etc, etc... but it's their computers... and you might get stiffed with a fine/penalty if oyu do something and it doesn't go back to what the "counter clerks" expect i think id's is a good thing ... i don't need/want spams originating from *.it domains There are better ways to stop spam originating from internet cafes. Maybe they should just configure their firewalls correctly. I don't believe that you can fight terrorism or spam by just checking passports of people entering internet cafes. You simply annoy everyone. Johannes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hardening checkpoints
On Wed, 21 Dec 2005, Johannes Wiedersich wrote: > > Wrong. I was in Milano (Italy) a few month ago, and I wanted to do exactly > > that. The person at the desk looked at me as if I were a Martien when I ask italians just passed a law that all isp and internet cafe etc are required to ask for ID of "ALL" visitors and users of their PCs and services it shouldnt matter to that if we reboot etc, etc... but it's their computers... and you might get stiffed with a fine/penalty if oyu do something and it doesn't go back to what the "counter clerks" expect i think id's is a good thing ... i don't need/want spams originating from *.it domains > > her if I could reboot the machine on my personnel Debian live-cd. First, > > she > > didn't understand what all that was about, and second she could'nt control > > my > > connection time, so she simply refused. Moreover, in Italy you have to give > > an ID (they do a photocopy of it; she couldn't tell me how long they keep > > it..) to be able to use a computer in an Internet Café (terrorism you > > know...). c ya alvin
Re: hardening checkpoints
Le Mercredi, 21 Décembre 2005 12.40, Johannes Wiedersich a écrit : > steve wrote: > > Le Mardi, 20 Décembre 2005 16.18, Michelle Konzack a écrit : > >>But in ALL Internet Cafes I can use my own (selfmade) Debian Live-System > >>with my prefered Desktop. In all Internet Cafes i get an IP via DHCP. > > > > Wrong. I was in Milano (Italy) a few month ago, and I wanted to do > > exactly that. The person at the desk looked at me as if I were a Martien > > when I ask her if I could reboot the machine on my personnel Debian > > live-cd. First, she didn't understand what all that was about, and second > > she could'nt control my connection time, so she simply refused. Moreover, > > in Italy you have to give an ID (they do a photocopy of it; she couldn't > > tell me how long they keep it..) to be able to use a computer in an > > Internet Café (terrorism you know...). > > > > Sorry ;-) > > Wrong: in Europe you shouldn't mix Italy with France. right : you eat better in France than in Italy. No, being serious again, I read Michelle's post a bit to fast and I mixed things up. I don't know why, but I thought she was thinking of Europe in her post. > I don't know > anything about Italian or French internet cafes, but I would be really > surprised, if there would be anything similar in the way their > administration works. You're right, they don't, politics is now the difference, at least in Internet Cafés. > For Italy, no matter what you do or where you are, it is always a sure > bet, that the person behind the counter (hotel, airport, etc. etc. > internet cafe) won't allow anything 'unusual' without double and tripple > checking with his/her boss. .. who is rarely there. So Michelle's solution seems to be quite unrealistic. > This usually means that you have to insist and wait. I'm ok with waiting 5 minutes, but more is too much, especially when you're just looking for a theather's timetable and you're in a hurry (and the theather's phone is down. Own experience.) > (In Italy 'unusual' means 'slightly different from normal'). I'll let you the responsability of that definition ;-) > Short message: two countries in Europe (say Italy and France) are about > as different from each other than any European country is from say the US. I'm with you on that one. But living near France, I'm very much willing to go there and give it a try. Just for the sake of it. But, I don't know why, I feel that my live-cd won't be very much appreciated.. really too scary stuff, isn't it? > Johannes -- steve jabber : [EMAIL PROTECTED]
Re: hardening checkpoints
steve wrote: Le Mardi, 20 Décembre 2005 16.18, Michelle Konzack a écrit : But in ALL Internet Cafes I can use my own (selfmade) Debian Live-System with my prefered Desktop. In all Internet Cafes i get an IP via DHCP. Wrong. I was in Milano (Italy) a few month ago, and I wanted to do exactly that. The person at the desk looked at me as if I were a Martien when I ask her if I could reboot the machine on my personnel Debian live-cd. First, she didn't understand what all that was about, and second she could'nt control my connection time, so she simply refused. Moreover, in Italy you have to give an ID (they do a photocopy of it; she couldn't tell me how long they keep it..) to be able to use a computer in an Internet Café (terrorism you know...). Sorry ;-) Wrong: in Europe you shouldn't mix Italy with France. I don't know anything about Italian or French internet cafes, but I would be really surprised, if there would be anything similar in the way their administration works. For Italy, no matter what you do or where you are, it is always a sure bet, that the person behind the counter (hotel, airport, etc. etc. internet cafe) won't allow anything 'unusual' without double and tripple checking with his/her boss. This usually means that you have to insist and wait. (In Italy 'unusual' means 'slightly different from normal'). Short message: two countries in Europe (say Italy and France) are about as different from each other than any European country is from say the US. Johannes Greetings Michelle Have a nice day -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hardening checkpoints
Le Mardi, 20 Décembre 2005 16.18, Michelle Konzack a écrit : > But in ALL Internet Cafes I can use my own (selfmade) Debian Live-System > with my prefered Desktop. In all Internet Cafes i get an IP via DHCP. Wrong. I was in Milano (Italy) a few month ago, and I wanted to do exactly that. The person at the desk looked at me as if I were a Martien when I ask her if I could reboot the machine on my personnel Debian live-cd. First, she didn't understand what all that was about, and second she could'nt control my connection time, so she simply refused. Moreover, in Italy you have to give an ID (they do a photocopy of it; she couldn't tell me how long they keep it..) to be able to use a computer in an Internet Café (terrorism you know...). Sorry ;-) > Greetings > Michelle Have a nice day -- steve jabber : [EMAIL PROTECTED]
Re: hardening checkpoints
On Tue, Dec 20, 2005 at 04:18:12PM +0100, Michelle Konzack wrote: > Hi Kevin, > > Am 2005-12-15 12:27:01, schrieb kevin bailey: > > hi, > > > 4. enhance authentication > > > > maybe set up ssh access by authorised keys only - but again this has a > > problem when i need to log in to the server from a putty session on a PC in > > an internet cafe . > > > > certainly check the strength of the existing passwords. > > As someone allready told, the computer my be infected with a > virus/keylogger ore something like this. > > OK, the Internet Cafes in France I know, using all windows and Ghost, > which mean, after each reboot, they will get a clean system... > Do not know, how long it takes to be reinfected... > > But in ALL Internet Cafes I can use my own (selfmade) Debian Live-System > with my prefered Desktop. In all Internet Cafes i get an IP via DHCP. > > So, there is no problem with infected Windows Machines... :-) > > I suggest you, to create your own striped down Live-System + USB-Key But you still have the possibility of hardware keyloggers to consider. Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hardening checkpoints
Hi Kevin, Am 2005-12-15 12:27:01, schrieb kevin bailey: > hi, > 4. enhance authentication > > maybe set up ssh access by authorised keys only - but again this has a > problem when i need to log in to the server from a putty session on a PC in > an internet cafe . > > certainly check the strength of the existing passwords. As someone allready told, the computer my be infected with a virus/keylogger ore something like this. OK, the Internet Cafes in France I know, using all windows and Ghost, which mean, after each reboot, they will get a clean system... Do not know, how long it takes to be reinfected... But in ALL Internet Cafes I can use my own (selfmade) Debian Live-System with my prefered Desktop. In all Internet Cafes i get an IP via DHCP. So, there is no problem with infected Windows Machines... :-) I suggest you, to create your own striped down Live-System + USB-Key > any comments gratefully received, > > kevin Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hardening checkpoints
In article <[EMAIL PROTECTED]> you wrote: > Actually, iptables -A INPUT will _append_ a rule to your INPUT chain > (iptables(8)), and this won't help you if your connection is matched by > an earlier blocking rule. To really make sure that you can reach the > machine after a failed firewall-reconfiguration, replace -A with -I, > which makes the rule inserted at the head of the chain, and hence, the > first rule to be matched. And dont forget to do this to the other tables, at least OUTPUT, also. Gruss Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hardening checkpoints
Hi, > > */3 * * * * rootiptables -A INPUT -i eth0 -p tcp -s > > MY_WORKSTATION_IP --dport 22 -j ACCEPT && echo "issued iptables cmd" > > > > | mail -a "From: [EMAIL PROTECTED]" -s "[iptables-keepalive]" > > > > [EMAIL PROTECTED] > > > > That does 2 things: > > > > 1. guarantees my access to the machine no matter how stupid I am > > configuring shorewall :) > > Actually, iptables -A INPUT will _append_ a rule to your INPUT chain > (iptables(8)), and this won't help you if your connection is matched by > an earlier blocking rule. To really make sure that you can reach the > machine after a failed firewall-reconfiguration, replace -A with -I, > which makes the rule inserted at the head of the chain, and hence, the > first rule to be matched. this also wont help you if you lock yourself out with a rule in the mangle or nat table. I think iptables -t mangle -I PREROUTING 1 -i eth0 -p tcp -s $MY_WORKSTATION_IP --dport 22 -j ACCEPT should be the better way to do it your way. Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hardening checkpoints
On Thu, 15 Dec 2005, kevin bailey wrote: > Alvin Oga wrote: > > > On Thu, 15 Dec 2005, kevin bailey wrote: > > > >> was recently rootkitted on a debian machine because i'd left an obscure > >> service running. > > > > if you know how they got in .. i assume oyu have since fixed it > > my guess it was the miniserv.pl run by webmin - it had a security problem > which does not seem to have been address by debian. webmin thingie's can be good or bad .. :-) > another possibility was zope - it had had soem of its files altered. one can alter any files once they got in .. > definitely - the first machine was a try out machine - and i'd installed > loads of stuff on it. i consider all my machines to be "first machines to test" and all important data saved on other test machines > now i have two machines - one ready to take over from the first - with far > fewer services running. combining wiht your other post, be careful when and why your "backup" machine will take over for the first machine ... - if they hacked your first machine, they will also be trying to hack the 2hd (backup) machine too - if both machines are identical in hw and apps that;s installed, than the 2nd box will also be rm -rf'd - if someone takes down my machines.. i want it to stay down, and play possom .. till somebody knowledgable takes a look at it and can explain why it went down and how and why - if it is critical that machines have to stay up, one should have the budget ( time, $$$ and resources ) for "high availability" and not just hot-swap 2 machines for failover - load balancing is better, since you know all machines is up and working ... and in sync ( data-wise ) with each other - even if its 3x 586 ( something cheaper and fast enough ) is still better than 1 superfast/expensive P4 box if you always want to be online ... - i'd definitely use different hw and different patch levels of distro and apps ... so that the machines will not fall for the same cracker's tricks > > http://www.debian.org/doc/manuals/securing-debian-howto/ > > > > will read in detail! and if you have more things to add to the list ... i'm sure they'd be looking for comments ( good or bad ) > a second machine is set up ready to take over. see comments above > would like to do this - but i also need to be able to access the server from > my laptop which connects over 3G - i.e. different IP address every time. the ip# that you will be at will be a limited choice ... not the "whole world" .. just allow that smaller world ( ip# ranger of the other isp ) than the whole big "everybody and anybody" > now been made aware of this i'll not be using internet cafes again :-) one usually worries after the fact :-) and is always a convenience vs security ... > i tend to use gpw or pwgen to create all passwords - so they shouldn't be > too bad. in which case, as you stated elsewhere, postits should be fine, since all employee's and people in/near the pc should be trustable > but running the password checkers has to be done as you say. doesn't hurt when time is available .. always double check things when possible > i'm a programmer by training but finding that clients need reliable managed > servers. so i'm trying to do two jobs at the same time - set up and manage > servers - and write code to pay the bills! that's probably aplies to everybody :-) > debian has really helped so far - my original server ran for 4 years before > it was hacked - and that was with me installing loads of stuff and not > really doing much RE security. that's a damn good track history for 4yrs.. > hopefully i can be more proactive now and keep on top of the security issues > better!!! tough job to do.. ez to say .. :-0 have fun alvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hardening checkpoints
* alex black <[EMAIL PROTECTED]> [2005-12-15 23:50:42]: > I use this line: > > */3 * * * * rootiptables -A INPUT -i eth0 -p tcp -s > MY_WORKSTATION_IP --dport 22 -j ACCEPT && echo "issued iptables cmd" > | mail -a "From: [EMAIL PROTECTED]" -s "[iptables-keepalive]" > [EMAIL PROTECTED] > > That does 2 things: > > 1. guarantees my access to the machine no matter how stupid I am > configuring shorewall :) > Actually, iptables -A INPUT will _append_ a rule to your INPUT chain (iptables(8)), and this won't help you if your connection is matched by an earlier blocking rule. To really make sure that you can reach the machine after a failed firewall-reconfiguration, replace -A with -I, which makes the rule inserted at the head of the chain, and hence, the first rule to be matched. /Andreas -- andreas blaafladt <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hardening checkpoints
On Thu, Dec 15, 2005 at 10:02:46PM +, kevin bailey wrote: > > > >> - i may need to access the server over ssh from anywhere. > > > > bad idea... what you can do .. the cracker can also do from "anywhere" > > > > at least, lock down incoming ssh from certain ip# > > vi hosts.deny > > ALL : ALL > > > > vi hosts.allow > > sshd: your.own.machine.com > > > > would like to do this - but i also need to be able to access the server from > my laptop which connects over 3G - i.e. different IP address every time. > > but your right - maybe i should set it up as you say most of the time and > open up access for only the time i am away. IF you need this you have several options: - limit the firewall (or the tcp-wrappers config) to the IP address range of your ISP provider if you are being given a dynamic address over the 3G network. Granted, it's not a single IP, but it is far less than the full internet. - lock down the firewall to a list of valid IPs and use a port knocker (check knockd) to have a mechanism to open up the firewall if you need to from a given IP address at a given point in time. Regards Javier signature.asc Description: Digital signature
Re: hardening checkpoints
On Thu, Dec 15, 2005 at 05:20:19PM +, kevin bailey wrote: > > get DDOSed in retaliation (I am guessing really). Anyways on a > > multi-user web server it difficult to track down the vulnerable cgi > > unless you run the cgi's as the account owner (as apposed to all running > > as www-data), and the conversion to suexec or cgiwrap is nontrivial > > good point - i installed cg-wrap before and found it was ok to install on > debian. this should be there as a matter of course. Make sure you install the latest version (3.9-3.1) since it removes some security exposures that were in previous versions (not critical, that's why there's no DSA). Backporting it to stable should be straightforward. Regards Javier signature.asc Description: Digital signature
Re: hardening checkpoints
In article <[EMAIL PROTECTED]> you wrote: > BTW - FTP *has* to be available - many of the users only know how to use > FTP. give them WinSCP :) Gruss Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hardening checkpoints
I use this line: */3 * * * * root iptables -A INPUT -i eth0 -p tcp -s MY_WORKSTATION_IP --dport 22 -j ACCEPT && echo "issued iptables cmd" | mail -a "From: [EMAIL PROTECTED]" -s "[iptables-keepalive]" [EMAIL PROTECTED] That does 2 things: 1. guarantees my access to the machine no matter how stupid I am configuring shorewall :) 2. reminds me LOUDLY and annoyingly every 3 minutes to turn it off once I'm done testing. also if you run postfix I have a hardening script which turns it into a send-only mailer and disables local delivery. it's invisible on port 25, too, which is nice. :) _a On Dec 15, 2005, at 2:14 PM, kevin bailey wrote: Dale Amon wrote: On Thu, Dec 15, 2005 at 12:27:01PM +, kevin bailey wrote: 2. firewall not i'm not sure about the need for a firewall - i may need to access the server over ssh from anywhere. also, to run FTP doesn't the server need to be able to open up a varying number of ports. There is a way around this. If you are really worried about a mistake, use 'at' to turn the firewall off after 5 minutes. That way you can set up your test and if you screwed up you only have to wait a few min before it goes away. If it worked, you just kill the queued at command line. top tip!!! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- alex black, founder the turing studio, inc. 510.666.0074 [EMAIL PROTECTED] http://www.turingstudio.com 2600 10th street, suite 635 berkeley, ca 94710 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hardening checkpoints
Dale Amon wrote: > On Thu, Dec 15, 2005 at 12:27:01PM +, kevin bailey wrote: >> 2. firewall >> not i'm not sure about the need for a firewall - i may need to access the >> server over ssh from anywhere. also, to run FTP doesn't the server need >> to be able to open up a varying number of ports. > > There is a way around this. If you are really worried > about a mistake, use 'at' to turn the firewall off after > 5 minutes. That way you can set up your test and if > you screwed up you only have to wait a few min before > it goes away. If it worked, you just kill the queued > at command line. > top tip!!! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hardening checkpoints
Will Maier wrote: > On Thu, Dec 15, 2005 at 12:27:01PM +, kevin bailey wrote: >> now i've generally relied on debian issuing security patches but i >> thought i should be more proactive RE security. > > This is very important, as you're now aware. The most secure OS in > the world is only as secure as the admin makes it. > >> here's my proposed checklist to carry out for securing a domain >> server - > > This question comes up on email lists all the time; a quick google > search will complement your list below. > >> 1. before attaching server to network install and configure >> tripwire. > >> and could possibly put key executables on to CD-ROM and leave them >> in the server. > > Consider putting the tripwire binary somewhere read-only (NFS? > CD-ROM?). > >> 2. firewall > >> not i'm not sure about the need for a firewall - i may need to >> access the server over ssh from anywhere. also, to run FTP >> doesn't the server need to be able to open up a varying number of >> ports. > > Firewalls on the perimeter /and/ the host itself are very useful. > Your network should be protected on its edge already, but I strongly > suggest taking the time to design and implement a useful firewall on > the servers you run as well. Even if you're network firewall is > perfect, you (likely) can't fully trust other hosts on the inside. the machine is in a serverfarm - but after the advice given RE FTP/SFTP or forcing FTP to use the ports 21 and 20 - ftp-data - i should be able to implement a firewall. > >> BTW - FTP *has* to be available - many of the users only know how >> to use FTP. > > This is a frequently asked question -- iptables can be used to > firewall machines serving FTP. > >> since my experience of firewalls is to protect a home network i basically >> turned off access by default - and then only opened up a couple of ports >> which were needed. > > This is a practice which applies (or should apply) to servers and > business networks as well. > >> currently - i see no compelling need to set up a firewall - especially >> since if i get it wrong i could lose access to the machine. > > See the other post in this thread for a simple way to deal with > this. There are more elegant ways, but you get the idea. > >> 3. make sure only required services are accepting incoming >> requests. > >> so, use something like nmap to test for open ports on a remote >> machine. > > You may also want to audit the services you choose to run using > Nessus or by analyzing the code yourself (assuming you can get > access to the code). I also use lsof(8) to find applications > listening on the network when I'm on the host, or nc(1) to perform a > simple remote scan of the host when nmap isn't available. > >> make sure only required services are running. > > And that running services are patched, just as you keep track of > patches for the OS. > >> 4. enhance authentication > >> maybe set up ssh access by authorised keys only - but again this >> has a problem when i need to log in to the server from a putty >> session on a PC in an internet cafe . > > You could keep your key on a USB fob, which would allow you to > authenticate pretty much everywhere. Certainly, try to avoid > allowing both password- and key-based authentication. > >> certainly check the strength of the existing passwords. > > And check new passwords as users are added to the system. > >> 5. ongoing security > >> sign up to email lists to monitor security issues RE the services used. > > This list is a good start ; ). > > [...] >> get script to run and check status of server every day. > > Consider using a monitoring suite like Nagios, especially if you > have a group of servers to monitor. > thanks for your points, kev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hardening checkpoints
tomasz abramowicz wrote: > kevin bailey wrote: >> hi, >> >> was recently rootkitted on a debian machine because i'd left an obscure >> service running. > > which one? > i though it was webmin - but now i'm not so sure - i thought there was a vulnerability in webmin in 2005 which was not in the debian security list - but now i can't find it. >> 2. firewall >> not i'm not sure about the need for a firewall - i may need to access the >> server over ssh from anywhere. also, to run FTP doesn't the server need >> to be able to open up a varying number of ports. > > hmm. you could look into port knocking for your ssh problem. > ftp server can be configured to use only 21tcp and 20tcp (ftp,ftp-data) > (requires configuring clients active/passive mode) > will check this out definitely - it means that i can implement a firewall which only has certain ports open. >> BTW - FTP *has* to be available - many of the users only know how to use >> FTP. > hmm, a wide range of clients on all systems is begining to implement > scp/sftp, its worth *forcing* on users, in some sceanario's its not as > scary as it might seem. > >> currently - i see no compelling need to set up a firewall - especially >> since if i get it wrong i could lose access to the machine. > > no right attitude. > your compelling need is established by: > 1. you just got rootkited onto a port which couldve been closed. > 2. your going to be hooked up to internet. > >> so, use something like nmap to test for open ports on a remote machine. >> make sure only required services are running. > > absolutely. with and without the firewall running, scan everything. > >> run snort to check for attacks. > > this can get really annoying=not useful, especially when you decide > snort should also send you alerts via email or sms. > i would suggest you leave this to very last. > and if you do set it up, make sure to check out the 'acid' interface.. > has been noted - i'll check it out. > hth, > t. > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hardening checkpoints
Matt wrote: > Kevin - > > kevin bailey wrote: >> 1. before attaching server to network install and configure tripwire. >> >> and could possibly put key executables on to CD-ROM and leave them in the >> server. > In todays same day exploits, using something like tripwire for H.I.D.S. > may not prove useful... By the time tripwire runs a check it may already > be too late, or the check may not return anything as the intruder could > have cleaned up their mess by then or altered tripwire itself. You may > want to consider something such as SAMHAIN that performs real-time > monitoring and will notify you immediately, as opposed to tripwire that > will notify only 1X/day (or however often you run it). > > Also consider an intrusion response plan - if Tripewire, or samhain, > alert you - what are you going to do? For example, we have decided that > upon an alert the entire network will be pretty much locked down, > disconnected from the WAN, or, at least, the compromised server is taken > off-line until the postmortem analysis is complete and the security > issue resolved (of course thats the 'nut shell' procedure, the real one > is pages upon pages). The faster you respond to the alert, the less > potential for malicious damage. good point - the response should be documented. have a plan to switch to a hot-swap backup server - also backups are sent to a backup server via rdiff-backup. kev > > Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hardening checkpoints
Alvin Oga wrote: > > > On Thu, 15 Dec 2005, kevin bailey wrote: > >> was recently rootkitted on a debian machine because i'd left an obscure >> service running. > > if you know how they got in .. i assume oyu have since fixed it my guess it was the miniserv.pl run by webmin - it had a security problem which does not seem to have been address by debian. (oh that reminds me - i must sent a bug report in now) - but i can't find it now :o( it was very late at the time - i found a bug in webmin but debian fixed it in 2003. another possibility was zope - it had had soem of its files altered. maybe now i'll not be sure now someine got in - at the time i was more concerned with moving everything to another server. > > if you do not know how they got in ... > - time to change security policy big time to prevent the next time > and/or risk losing more data next time > definitely - the first machine was a try out machine - and i'd installed loads of stuff on it. now i have two machines - one ready to take over from the first - with far fewer services running. >> now i've generally relied on debian issuing security patches but i >> thought i should be more proactive RE security. > > good bet in most cases .. but if the machine is put(used) in "insecure > mode", all the effort into putting out patches will not help > >> here's my proposed checklist to carry out for securing a domain server - >> i.e. one which mainly deals with serving websites and email for virtual >> domains. > > i assume by domain server its not samba stuff since oyu mention > website/emails > > a bigger checklist for your "proposed debianized security checklist" > > http://www.debian.org/doc/manuals/securing-debian-howto/ > will read in detail! >> could people please supply any enhancements/corrections/deletions or >> point to any resources which detail a better hardening checklist for >> debian. >> >> 1. before attaching server to network install and configure tripwire. > > personally, tripwire teaches people to ignore security emails > that the server had been hacked since you will more than likely > ignore the gazillion emails it generates of every change to the system > - turning off the checks is also counter productive that oyu don't > see the real hacked/changed files > > use other methods to find changed files or files that not supposed to > exists > - update your security database after EACH critical change > > - if you ignore things in /tmp or /usr/tmp or /var/tmp, that's > where you'll find the cracker hiding too > noted >> and could possibly put key executables on to CD-ROM and leave them in the >> server. > > good idea to put a WHOLE copy elsehwere so you have a way to > double check against a non-hacked ( offline ) machine > a second machine is set up ready to take over. > if it's cdrw drive.. the rw cdrom can be changed :-) > >> 2. firewall >> >> not i'm not sure about the need for a firewall > > how good are your defenses ?? and recovery proceedures if they get in > > - easiest scenario ... assume the cracker/hacker is in your routers and > firewalls and now do what you can to protect your machines and data > >> - i may need to access the server over ssh from anywhere. > > bad idea... what you can do .. the cracker can also do from "anywhere" > > at least, lock down incoming ssh from certain ip# > vi hosts.deny > ALL : ALL > > vi hosts.allow > sshd: your.own.machine.com > would like to do this - but i also need to be able to access the server from my laptop which connects over 3G - i.e. different IP address every time. but your right - maybe i should set it up as you say most of the time and open up access for only the time i am away. >> also, to run FTP doesn't the server need to be able to open up a varying >> number of ports. > > once a legal connection is made, other ports can be opened > >> BTW - FTP *has* to be available - many of the users only know how to use >> FTP. > > too generic > > if they are using ftp, they can easily use "secure ftp" isntead and > never know the difference other than possibly use a different and > secure ftp > - if they like cmmandline ftp ... they won't notice much > difference with sftp > > - if they like gui for ftp ... > http://www.linux-sec.net/SSH/client.gwif.html#SFTP > - use winscp or filezilla or ?? i'm being convinced that forcing the use of SFTP is the way to go > if they need FTP gui's > > ftp login/password should be different than their email login/passwd > they are different. >> currently - i see no compelling need to set up a firewall - especially >> since if i get it wrong i could lose access to the machine. > > you've been rooted/cracked... > - would a firewall have prevented it ?? ... maybe .. maybe not .. > >> 3. make sure only required services are accepting incoming requests. >> >> so, use something like nmap to test for open ports on a remote machine. >> make sure only required services are r
Re: hardening checkpoints
> You can limit your FTP server to listen for data connections on a > specific port only (eg, ftp-data, or 20). Then you only have to allow > connections to ports 20 and 21. but after the initial connection doesn't the server then wait for the data connection on a port in a range above 1065? > This takes care of passive mode users; > active mode involves the FTP server connecting back to the users for > data transfer, and so relies on the users' own firewall policies > permitting the connections. fair point > > You could also set up SSL/TLS so that the users whose clients support it > recieve the benefits of an encrypted session. > >> BTW - FTP *has* to be available - many of the users only know how to use >> FTP. > > In that case it would be best to secure the machine assuming that the > user accounts have already been compromised. :) Can the users upload PHP > scripts? In that case anyone sniffing passwords from your FTP sessions > can run their code on your system... i'm beginning to think that i should force the users away from FTP! > > You could configure Apache to run each user's scripts as the user in > question, rather than www-data. This is rather difficult to do however, > and perhaps impossible to do in a way that doesn't suck. this is ok to do in cgi scripts due to cgi-wrap being relatively easy to install - however, i've never even heard of doing this for PHP. > > Keep on top of any privilige escalation bugs in the kernel since these > will allow the hypothetical attacker to take over the system entirely. > The stock Debian kernels recieved a security update yesterday... it was > a long time in coming but I believe the only issues in the stock kernels > have been fairly uninteresting DOS attacks anyway. > will check this out >> 4. enhance authentication >> >> maybe set up ssh access by authorised keys only - but again this has a >> problem when i need to log in to the server from a putty session on a PC >> in an internet cafe . > > An alternative to public key authentication is to make use of a one-time > password system. There are packages for OPIE in Debian, which challenges > you with a string of text that you enter into your OPIE calculator (you > can get dedicated calculators, or software to run on a PDA or mobile > phone) along with a secret password. The calculator gives you the > response which you use to log in to the server. > > A more low-tech solution is OTPW[0]. You simply print out 25 or so > pregenerated passwords into a bit of paper (write the system's SSH host > key on the back if you don't remember it). To log in, concatenate a > secret 'prefix password' with the next password on the list. > > In both cases, the paper/calculator is useless to an attacker without > knowledge of both your password and the particular host to which it > applies. > > Until all public access PCs have some kind of standardised smart card > reader that we can use for our SSH private keys and PGP keys, one-time > password systems are probably more secure if you must use untrusted > public terminals. Consider that a PC that you plug your usb disk into > may have been configured to make a copy of anything it finds for itself, > either by the crooked owner of an Internet cafe, or a user who is mining > the computers for interesting passwords and other data... > very interesting - will need to be looked into. > [0] http://www.cl.cam.ac.uk/~mgk25/otpw.html > >> 5. ongoing security >> >> sign up to email lists to monitor security issues RE the services used. >> >> get server to run chkrootkit regularly and email results. >> >> run snort to check for attacks. >> >> get script to run and check status of server every day. > > Logwatch or logcheck can help with this. An alternative approach is to > configure syslog to log everything of ERROR priority or higher to a > file, eg /var/log/important. Then put an entry such as the following > into /etc/crontab: > > @hourly root logtail /var/log/important | mail -e -s "Important log > events on $HOSTNAME" root > > Another good one is: > > @daily apt-get -qq update && apt-get -qq --dry-run upgrade | mail -e -s > "Upgradable packages on $HOSTNAME" root > > Also check out /etc/security/limits.conf; it will allow you to set up > resource limits for your users. See getrlimit(2) and the administrator's > guide from the libpam-doc package. > thanks again - very useful when i've finished the daily monitoring script i'll post it up in case it is useful to anyone else. kev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hardening checkpoints
On Thu, Dec 15, 2005 at 07:43:39AM -0600, Will Maier wrote: > > 4. enhance authentication > > maybe set up ssh access by authorised keys only - but again this > > has a problem when i need to log in to the server from a putty > > session on a PC in an internet cafe . > You could keep your key on a USB fob, which would allow you to > authenticate pretty much everywhere. Certainly, try to avoid > allowing both password- and key-based authentication. I'd never insert my USB-Stick with personal data into some PC in an Internet Cafe. Read-Access implies someone may copy all data to the local PC... Call me paranoid, but I learned just Monday some person I know keeps a keylogger running on his system... Immediately changed all my passwords. I would recommend using OTP (One Time Passwords), Debian contains everything needed to configure this and there are several Clients available... Stefan -- It would break down if you have sweaty fingers or blood on your hands, something which can occur easily in stressy Situations. [Prof. Jarke] signature.asc Description: Digital signature
Re: hardening checkpoints
Jeffrey L. Taylor wrote: > Quoting kevin bailey <[EMAIL PROTECTED]>: > [snip] >> 4. enhance authentication >> >> maybe set up ssh access by authorised keys only - but again this has a >> problem when i need to log in to the server from a putty session on a PC >> in an internet cafe . >> > > Buy a laptop. Trusting an unknown PC in an Internet cafe to not have > keystroke loggers is false economy. good point! i have a laptop but its too heavy to take everywhere. maybe i could get one of those nokia 770 things - they look like they should be easily portable and i'll guess that an ssh client will be available. kev > > Just my 0.02USD, > Jeffrey > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hardening checkpoints
> > I suggest you set up host based firewalling, where iptables limits > incoming/forwarding/outgoing traffic to whatever services you are > running. This is especially important if your running a webserver and > allow user cgi uploads, or cgi's with vulnerabilities are already > installed. For example, I had cacti from debian stable installed on a > monitor server at one point that got hacked by a script kiddie well > before the security patch was released. I have also had web users > install vulnerable cgi's that kiddies use to install programs that > launch DOS attacks on other networks, which in turn caused my network to > get DDOSed in retaliation (I am guessing really). Anyways on a > multi-user web server it difficult to track down the vulnerable cgi > unless you run the cgi's as the account owner (as apposed to all running > as www-data), and the conversion to suexec or cgiwrap is nontrivial good point - i installed cg-wrap before and found it was ok to install on debian. this should be there as a matter of course. > (although I recommend it highly as you can also get cpu/mem limits with > cgiwrap), so for me blocking new or unrelated outbound connections was > the easiest. Now this does not protect me really from root exploits > since it is obvious they can get in the door, but for now I am checking > my binaries regularly as well as keeping my kernel up to date. > Occasionally I see denied outbound connections to strange port numbers > in my logs, most of them look like they are from evil scripts trying to > call home. > > It would be really nice if iptables could tell me what user it was that > was trying to open the connection (I know I can setup a rule to match a > user, but wouldn't this create a lot of overhead to have one rule for > each user on my system? (I have a lot)). > > Here is the guide I used for creating my firewall rules, I also read up > a bit on netfilter/iptables and tested it on a local system before > installing it on my servers. > > http://www.sun.com/blueprints/1103/817-4403.pdf > i'll check it out >> also, surely the most important set is next - which is >> >> 3. make sure only required services are accepting incoming requests. >> >> so, use something like nmap to test for open ports on a remote machine. >> make sure only required services are running. >> >> 4. enhance authentication >> >> maybe set up ssh access by authorised keys only - but again this has a >> problem when i need to log in to the server from a putty session on a PC >> in an internet cafe . >> >> certainly check the strength of the existing passwords. >> >> 5. ongoing security >> >> sign up to email lists to monitor security issues RE the services used. >> >> get server to run chkrootkit regularly and email results. >> >> run snort to check for attacks. >> >> get script to run and check status of server every day. >> >> >> any comments gratefully received, >> >> kevin >> >> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hardening checkpoints
Am Donnerstag, 15. Dezember 2005 14:26 schrieb Dale Amon: > On Thu, Dec 15, 2005 at 12:27:01PM +, kevin bailey wrote: > > 2. firewall > > not i'm not sure about the need for a firewall - i may need to access the > > server over ssh from anywhere. also, to run FTP doesn't the server need > > to be able to open up a varying number of ports. > > There is a way around this. If you are really worried > about a mistake, use 'at' to turn the firewall off after > 5 minutes. That way you can set up your test and if > you screwed up you only have to wait a few min before > it goes away. If it worked, you just kill the queued > at command line. If you use shorewall to setup iptables, you may also just create a copy of the /etc/shorewall directory to e.g. /etc/shorewall.test, change the rules in shorewall.test first and test them from there with shorewall try /etc/shorewall.test 120 After the specified timeout (in seconds) shorewall reverts back to the default ruleset from /etc/shorewall. So if you made a mistake, your host will be accessible again after the timeout (with the default firewall ruleset running); if everything is fine, you can just press Ctrl-C to abort reverting to the default ruleset. Of course, afterwards update /etc/shorewall to incorporate your tested changes. Regards, Klaus -- Dipl.-Ing. Klaus Holler <[EMAIL PROTECTED]> pgprMRfQs9n69.pgp Description: PGP signature
Re: hardening checkpoints
On Thu, 2005-12-15 at 12:27 +, kevin bailey wrote: > hi, > > was recently rootkitted on a debian machine because i'd left an obscure > service running. > > now i've generally relied on debian issuing security patches but i thought i > should be more proactive RE security. > > here's my proposed checklist to carry out for securing a domain server - > i.e. one which mainly deals with serving websites and email for virtual > domains. > > could people please supply any enhancements/corrections/deletions or point > to any resources which detail a better hardening checklist for debian. > > 1. before attaching server to network install and configure tripwire. > > and could possibly put key executables on to CD-ROM and leave them in the > server. > > 2. firewall > > not i'm not sure about the need for a firewall - i may need to access the > server over ssh from anywhere. also, to run FTP doesn't the server need to > be able to open up a varying number of ports. > > BTW - FTP *has* to be available - many of the users only know how to use > FTP. > > since my experience of firewalls is to protect a home network i basically > turned off access by default - and then only opened up a couple of ports > which were needed. > > maybe the new iptables feature of --state ESTABLISHED which uses stateful > packet filtering is the way forward. > > currently - i see no compelling need to set up a firewall - especially since > if i get it wrong i could lose access to the machine. I suggest you set up host based firewalling, where iptables limits incoming/forwarding/outgoing traffic to whatever services you are running. This is especially important if your running a webserver and allow user cgi uploads, or cgi's with vulnerabilities are already installed. For example, I had cacti from debian stable installed on a monitor server at one point that got hacked by a script kiddie well before the security patch was released. I have also had web users install vulnerable cgi's that kiddies use to install programs that launch DOS attacks on other networks, which in turn caused my network to get DDOSed in retaliation (I am guessing really). Anyways on a multi-user web server it difficult to track down the vulnerable cgi unless you run the cgi's as the account owner (as apposed to all running as www-data), and the conversion to suexec or cgiwrap is nontrivial (although I recommend it highly as you can also get cpu/mem limits with cgiwrap), so for me blocking new or unrelated outbound connections was the easiest. Now this does not protect me really from root exploits since it is obvious they can get in the door, but for now I am checking my binaries regularly as well as keeping my kernel up to date. Occasionally I see denied outbound connections to strange port numbers in my logs, most of them look like they are from evil scripts trying to call home. It would be really nice if iptables could tell me what user it was that was trying to open the connection (I know I can setup a rule to match a user, but wouldn't this create a lot of overhead to have one rule for each user on my system? (I have a lot)). Here is the guide I used for creating my firewall rules, I also read up a bit on netfilter/iptables and tested it on a local system before installing it on my servers. http://www.sun.com/blueprints/1103/817-4403.pdf > also, surely the most important set is next - which is > > 3. make sure only required services are accepting incoming requests. > > so, use something like nmap to test for open ports on a remote machine. > make sure only required services are running. > > 4. enhance authentication > > maybe set up ssh access by authorised keys only - but again this has a > problem when i need to log in to the server from a putty session on a PC in > an internet cafe . > > certainly check the strength of the existing passwords. > > 5. ongoing security > > sign up to email lists to monitor security issues RE the services used. > > get server to run chkrootkit regularly and email results. > > run snort to check for attacks. > > get script to run and check status of server every day. > > > any comments gratefully received, > > kevin > > -- Vittorio R Tracy <[EMAIL PROTECTED]> Fastmetrics LLC. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hardening checkpoints
Quoting kevin bailey <[EMAIL PROTECTED]>: [snip] > 4. enhance authentication > > maybe set up ssh access by authorised keys only - but again this has a > problem when i need to log in to the server from a putty session on a PC in > an internet cafe . > Buy a laptop. Trusting an unknown PC in an Internet cafe to not have keystroke loggers is false economy. Just my 0.02USD, Jeffrey -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hardening checkpoints
kevin bailey wrote: 2. firewall not i'm not sure about the need for a firewall - i may need to access the server over ssh from anywhere. also, to run FTP doesn't the server need to be able to open up a varying number of ports. You can limit your FTP server to listen for data connections on a specific port only (eg, ftp-data, or 20). Then you only have to allow connections to ports 20 and 21. This takes care of passive mode users; active mode involves the FTP server connecting back to the users for data transfer, and so relies on the users' own firewall policies permitting the connections. You could also set up SSL/TLS so that the users whose clients support it recieve the benefits of an encrypted session. BTW - FTP *has* to be available - many of the users only know how to use FTP. In that case it would be best to secure the machine assuming that the user accounts have already been compromised. :) Can the users upload PHP scripts? In that case anyone sniffing passwords from your FTP sessions can run their code on your system... You could configure Apache to run each user's scripts as the user in question, rather than www-data. This is rather difficult to do however, and perhaps impossible to do in a way that doesn't suck. Keep on top of any privilige escalation bugs in the kernel since these will allow the hypothetical attacker to take over the system entirely. The stock Debian kernels recieved a security update yesterday... it was a long time in coming but I believe the only issues in the stock kernels have been fairly uninteresting DOS attacks anyway. 4. enhance authentication maybe set up ssh access by authorised keys only - but again this has a problem when i need to log in to the server from a putty session on a PC in an internet cafe . An alternative to public key authentication is to make use of a one-time password system. There are packages for OPIE in Debian, which challenges you with a string of text that you enter into your OPIE calculator (you can get dedicated calculators, or software to run on a PDA or mobile phone) along with a secret password. The calculator gives you the response which you use to log in to the server. A more low-tech solution is OTPW[0]. You simply print out 25 or so pregenerated passwords into a bit of paper (write the system's SSH host key on the back if you don't remember it). To log in, concatenate a secret 'prefix password' with the next password on the list. In both cases, the paper/calculator is useless to an attacker without knowledge of both your password and the particular host to which it applies. Until all public access PCs have some kind of standardised smart card reader that we can use for our SSH private keys and PGP keys, one-time password systems are probably more secure if you must use untrusted public terminals. Consider that a PC that you plug your usb disk into may have been configured to make a copy of anything it finds for itself, either by the crooked owner of an Internet cafe, or a user who is mining the computers for interesting passwords and other data... [0] http://www.cl.cam.ac.uk/~mgk25/otpw.html 5. ongoing security sign up to email lists to monitor security issues RE the services used. get server to run chkrootkit regularly and email results. run snort to check for attacks. get script to run and check status of server every day. Logwatch or logcheck can help with this. An alternative approach is to configure syslog to log everything of ERROR priority or higher to a file, eg /var/log/important. Then put an entry such as the following into /etc/crontab: @hourly root logtail /var/log/important | mail -e -s "Important log events on $HOSTNAME" root Another good one is: @daily apt-get -qq update && apt-get -qq --dry-run upgrade | mail -e -s "Upgradable packages on $HOSTNAME" root Also check out /etc/security/limits.conf; it will allow you to set up resource limits for your users. See getrlimit(2) and the administrator's guide from the libpam-doc package. -- Sam Morris http://robots.org.uk/ PGP key id 5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hardening checkpoints
On Thu, 15 Dec 2005, kevin bailey wrote: > was recently rootkitted on a debian machine because i'd left an obscure > service running. if you know how they got in .. i assume oyu have since fixed it if you do not know how they got in ... - time to change security policy big time to prevent the next time and/or risk losing more data next time > now i've generally relied on debian issuing security patches but i thought i > should be more proactive RE security. good bet in most cases .. but if the machine is put(used) in "insecure mode", all the effort into putting out patches will not help > here's my proposed checklist to carry out for securing a domain server - > i.e. one which mainly deals with serving websites and email for virtual > domains. i assume by domain server its not samba stuff since oyu mention website/emails a bigger checklist for your "proposed debianized security checklist" http://www.debian.org/doc/manuals/securing-debian-howto/ > could people please supply any enhancements/corrections/deletions or point > to any resources which detail a better hardening checklist for debian. > > 1. before attaching server to network install and configure tripwire. personally, tripwire teaches people to ignore security emails that the server had been hacked since you will more than likely ignore the gazillion emails it generates of every change to the system - turning off the checks is also counter productive that oyu don't see the real hacked/changed files use other methods to find changed files or files that not supposed to exists - update your security database after EACH critical change - if you ignore things in /tmp or /usr/tmp or /var/tmp, that's where you'll find the cracker hiding too > and could possibly put key executables on to CD-ROM and leave them in the > server. good idea to put a WHOLE copy elsehwere so you have a way to double check against a non-hacked ( offline ) machine if it's cdrw drive.. the rw cdrom can be changed :-) > 2. firewall > > not i'm not sure about the need for a firewall how good are your defenses ?? and recovery proceedures if they get in - easiest scenario ... assume the cracker/hacker is in your routers and firewalls and now do what you can to protect your machines and data > - i may need to access the server over ssh from anywhere. bad idea... what you can do .. the cracker can also do from "anywhere" at least, lock down incoming ssh from certain ip# vi hosts.deny ALL : ALL vi hosts.allow sshd: your.own.machine.com > also, to run FTP doesn't the server need to be able to open up a varying > number of ports. once a legal connection is made, other ports can be opened > BTW - FTP *has* to be available - many of the users only know how to use > FTP. too generic if they are using ftp, they can easily use "secure ftp" isntead and never know the difference other than possibly use a different and secure ftp - if they like cmmandline ftp ... they won't notice much difference with sftp - if they like gui for ftp ... http://www.linux-sec.net/SSH/client.gwif.html#SFTP - use winscp or filezilla or ?? if they need FTP gui's ftp login/password should be different than their email login/passwd > currently - i see no compelling need to set up a firewall - especially since > if i get it wrong i could lose access to the machine. you've been rooted/cracked... - would a firewall have prevented it ?? ... maybe .. maybe not .. > 3. make sure only required services are accepting incoming requests. > > so, use something like nmap to test for open ports on a remote machine. > make sure only required services are running. and how do you turn off "un-needed services" :-) --- you left off email ... make sure email logins and pwd is NOT the same as the ssh login/pwd - use pop3s instead of regular pop --- > 4. enhance authentication > > maybe set up ssh access by authorised keys only - but again this has a > problem when i need to log in to the server from a putty session on a PC in > an internet cafe . bad idea ... there is zero reason why you will need to use a pc at an internet cafe ( or any place where oyu did not install the sw ) that is most likely filled with trojans waiting for you to tell them your ip#, login and paswds > certainly check the strength of the existing passwords. run your favorite passwd crackers... it'd probably find 1/2 of your passwds of your users - if the passwd cracker found it .. the crackers know it too > 5. ongoing security > > sign up to email lists to monitor security issues RE the services used. > > get server to run chkrootkit regularly and email results. those will teach you to ignore "security alerts" that it didnt find anything > run snort to check for attacks. if you have the ti
Re: hardening checkpoints
Kevin - kevin bailey wrote: 1. before attaching server to network install and configure tripwire. and could possibly put key executables on to CD-ROM and leave them in the server. In todays same day exploits, using something like tripwire for H.I.D.S. may not prove useful... By the time tripwire runs a check it may already be too late, or the check may not return anything as the intruder could have cleaned up their mess by then or altered tripwire itself. You may want to consider something such as SAMHAIN that performs real-time monitoring and will notify you immediately, as opposed to tripwire that will notify only 1X/day (or however often you run it). Also consider an intrusion response plan - if Tripewire, or samhain, alert you - what are you going to do? For example, we have decided that upon an alert the entire network will be pretty much locked down, disconnected from the WAN, or, at least, the compromised server is taken off-line until the postmortem analysis is complete and the security issue resolved (of course thats the 'nut shell' procedure, the real one is pages upon pages). The faster you respond to the alert, the less potential for malicious damage. Matt begin:vcard fn:Matt Resong n:Resong;Matt org:DPD;IT / Graphics adr:;; W 78th Street;Edina;MN;55439;USA email;internet:[EMAIL PROTECTED] title:System Admin tel;work:952-946-1196 tel;fax:952-826-7993 tel;pager:612-510-2893 url:http://www.dpd-info.com version:2.1 end:vcard
Re: hardening checkpoints
kevin bailey wrote: hi, was recently rootkitted on a debian machine because i'd left an obscure service running. which one? 2. firewall not i'm not sure about the need for a firewall - i may need to access the server over ssh from anywhere. also, to run FTP doesn't the server need to be able to open up a varying number of ports. hmm. you could look into port knocking for your ssh problem. ftp server can be configured to use only 21tcp and 20tcp (ftp,ftp-data) (requires configuring clients active/passive mode) BTW - FTP *has* to be available - many of the users only know how to use FTP. hmm, a wide range of clients on all systems is begining to implement scp/sftp, its worth *forcing* on users, in some sceanario's its not as scary as it might seem. currently - i see no compelling need to set up a firewall - especially since if i get it wrong i could lose access to the machine. no right attitude. your compelling need is established by: 1. you just got rootkited onto a port which couldve been closed. 2. your going to be hooked up to internet. so, use something like nmap to test for open ports on a remote machine. make sure only required services are running. absolutely. with and without the firewall running, scan everything. run snort to check for attacks. this can get really annoying=not useful, especially when you decide snort should also send you alerts via email or sms. i would suggest you leave this to very last. and if you do set it up, make sure to check out the 'acid' interface.. hth, t. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hardening checkpoints
On Thu, Dec 15, 2005 at 12:27:01PM +, kevin bailey wrote:
> now i've generally relied on debian issuing security patches but i
> thought i should be more proactive RE security.
This is very important, as you're now aware. The most secure OS in
the world is only as secure as the admin makes it.
> here's my proposed checklist to carry out for securing a domain
> server -
This question comes up on email lists all the time; a quick google
search will complement your list below.
> 1. before attaching server to network install and configure
> tripwire.
> and could possibly put key executables on to CD-ROM and leave them
> in the server.
Consider putting the tripwire binary somewhere read-only (NFS?
CD-ROM?).
> 2. firewall
> not i'm not sure about the need for a firewall - i may need to
> access the server over ssh from anywhere. also, to run FTP
> doesn't the server need to be able to open up a varying number of
> ports.
Firewalls on the perimeter /and/ the host itself are very useful.
Your network should be protected on its edge already, but I strongly
suggest taking the time to design and implement a useful firewall on
the servers you run as well. Even if you're network firewall is
perfect, you (likely) can't fully trust other hosts on the inside.
> BTW - FTP *has* to be available - many of the users only know how
> to use FTP.
This is a frequently asked question -- iptables can be used to
firewall machines serving FTP.
> since my experience of firewalls is to protect a home network i basically
> turned off access by default - and then only opened up a couple of ports
> which were needed.
This is a practice which applies (or should apply) to servers and
business networks as well.
> currently - i see no compelling need to set up a firewall - especially since
> if i get it wrong i could lose access to the machine.
See the other post in this thread for a simple way to deal with
this. There are more elegant ways, but you get the idea.
> 3. make sure only required services are accepting incoming
> requests.
> so, use something like nmap to test for open ports on a remote
> machine.
You may also want to audit the services you choose to run using
Nessus or by analyzing the code yourself (assuming you can get
access to the code). I also use lsof(8) to find applications
listening on the network when I'm on the host, or nc(1) to perform a
simple remote scan of the host when nmap isn't available.
> make sure only required services are running.
And that running services are patched, just as you keep track of
patches for the OS.
> 4. enhance authentication
> maybe set up ssh access by authorised keys only - but again this
> has a problem when i need to log in to the server from a putty
> session on a PC in an internet cafe .
You could keep your key on a USB fob, which would allow you to
authenticate pretty much everywhere. Certainly, try to avoid
allowing both password- and key-based authentication.
> certainly check the strength of the existing passwords.
And check new passwords as users are added to the system.
> 5. ongoing security
> sign up to email lists to monitor security issues RE the services used.
This list is a good start ; ).
[...]
> get script to run and check status of server every day.
Consider using a monitoring suite like Nagios, especially if you
have a group of servers to monitor.
--
o--{ Will Maier }--o
| jabber:[EMAIL PROTECTED] | email:[EMAIL PROTECTED] |
| [EMAIL PROTECTED] | [EMAIL PROTECTED] |
*---[ Debian: The Universal Operating System (www.debian.org) ]*
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hardening checkpoints
On Thu, Dec 15, 2005 at 12:27:01PM +, kevin bailey wrote: > 2. firewall > not i'm not sure about the need for a firewall - i may need to access the > server over ssh from anywhere. also, to run FTP doesn't the server need to > be able to open up a varying number of ports. There is a way around this. If you are really worried about a mistake, use 'at' to turn the firewall off after 5 minutes. That way you can set up your test and if you screwed up you only have to wait a few min before it goes away. If it worked, you just kill the queued at command line. -- -- Artemis Systems Development Dale Amon [EMAIL PROTECTED]+44-7802-188325 International linux systems consultancy Hardware & software system design, security and networking, systems programming and Admin "Have Laptop, Will Travel" -- signature.asc Description: Digital signature
