Re: Why is portmap installed by default?
Michelle Konzack wrote: Am 2006-08-20 14:49:53, schrieb kevin bailey: Why is portmap installed by default on a vanilla basic Debian Sarge install? Sorry, but portmap is NOT installed... This was changed from Woody-Sarge and I was surprised too, that I had to install portmap my own As far as I can see this is mainly used by by NFS and NIS - so if we're not using either of these then why should it be installed. It is not - and IF it is there, it was installed as Dependency. Greetings Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant Hmmm... I don't think I installed anything which needs to have portmap - certainly not NFS or NIS. Anyway, I'll check after the next vanilla install. Cheers, Kevin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Why is portmap installed by default?
Why is portmap installed by default on a vanilla basic Debian Sarge install? As far as I can see this is mainly used by by NFS and NIS - so if we're not using either of these then why should it be installed. I'm asking mainly because chkrootkit is reporting what seems like a false positive due to an open RPC port - and this seems to be a well known false positive. Kev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why is portmap installed by default?
Mike Hommey wrote: On Sun, Aug 20, 2006 at 02:49:53PM +0100, kevin bailey [EMAIL PROTECTED] wrote: Why is portmap installed by default on a vanilla basic Debian Sarge install? As far as I can see this is mainly used by by NFS and NIS - so if we're not using either of these then why should it be installed. Probably because of fam, which uses it. Mike H Fam can be used by NFS. I also think fam is used by some GUI/X file managers. As far as I can see it should be ok to remove portmap from an installation which does not have X installed or uses NFS or NIS. I'm sure it's been included in to the default setup for a reason - but I will be removing it on most servers. Kevin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: closing unwanted ports - and what is 1720/tcp filtered H.323/Q.931
Adrian von Bidder wrote: On Thursday 15 December 2005 23.54, Noah Meyerhans wrote: given the choice between having your users use weak but easy to remember passwords and having them use complex passwords that they have to write down, My experience suggests that users use weak passwords *and* need to write them down. :-( (This can be construed as an argument that encryption is not necessary: if the passwords are easily guessable anyway...) Including an 'official' note with all passwords hanging at the whiteboard in one small company (ca. 5 people).. -- vbi at least i use pwgen or gpw to generate passwords for the users which they then can't change. passwords generated with gpw seem to be acceptable by most people. kev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
hardening checkpoints
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. 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]
closing unwanted ports - and what is 1720/tcp filtered H.323/Q.931
hi, these ports seem to be open by default on a standard sarge setup PORT STATESERVICE 9/tcpopen discard 13/tcp open daytime 21/tcp open ftp 22/tcp open ssh 25/tcp open smtp 37/tcp open time 80/tcp open http 110/tcp open pop3 111/tcp open rpcbind 143/tcp open imap 443/tcp open https 1720/tcp filtered H.323/Q.931 the server will just be serving email and websites so can these services be turned off? PORT STATESERVICE 9/tcpopen discard 13/tcp open daytime 37/tcp open time 111/tcp open rpcbind i presume they are mostly from inetd the service: 443/tcp open https is used to protect the webmail service. it is meant to stop the email passwords from being sniffed. what is 1720/tcp filtered H.323/Q.931 ? and how do i turn it off if it is uneccessary. thanks, kev -- 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
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
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
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 running. and how do you turn off un-needed services :-) --- you left off email ... make sure email logins and pwd is NOT the same
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
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
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
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: closing unwanted ports - and what is 1720/tcp filtered H.323/Q.931
Noah Meyerhans wrote: On Thu, Dec 15, 2005 at 12:35:09PM +, kevin bailey wrote: the service: 443/tcp open https is used to protect the webmail service. it is meant to stop the email passwords from being sniffed. If you're concerned about passwords being sniffed, you better shut off pop3 and imap, too (unless you configure IMAP such that plaintext passwords will never be prompted for, which should be possible according to section 6.2.2 of RFC 3501). In the case of pop3, it is not possible to configure secure authentication mechanisms, and you should switch to the SSL-tunnelled pop3s if you really need POP support. good point - also the fact that the users stick their email passwords to their monitors using postits! i'm almost thinking to switch the webmail service to normal apache - this would save me from having to run apache-ssl altogether. the email accounts are virtual accounts and are not system/FTP accounts run on a courier email server. what is 1720/tcp filtered H.323/Q.931 ? and how do i turn it off if it is uneccessary. It may be nothing. The fact that it showed up as filterd in the nmap output indicates that nmap didn't received a TCP RST packet back when it tried to contact that port. That may mean you have iptables configured to DROP packets to that port. iptables has not been set up - but i take what you say. so if i set up a firewall and drop nearly all packets does nmap report ports as unfiltered? thanks for your points, kev noah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: closing unwanted ports - and what is 1720/tcp filtered H.323/Q.931
Dale Amon wrote: On Thu, Dec 15, 2005 at 12:35:09PM +, kevin bailey wrote: what is 1720/tcp filtered H.323/Q.931 Are you running any VOIP? H323 is the standard for telephone interchanges. and how do i turn it off if it is uneccessary. netstat, lsof, fuser, the usual suspects... i've not used the first couple of tools - will check them out, kev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: closing unwanted ports - and what is 1720/tcp filtered H.323/Q.931
Will Maier wrote: On Thu, Dec 15, 2005 at 12:35:09PM +, kevin bailey wrote: these ports seem to be open by default on a standard sarge setup [...] Not a standard, default setup; you've installed and enabled other services which aren't turned on by default. the server will just be serving email and websites so can these services be turned off? [...] Yes, those services can be turned off in most environments; still, you should verify that there aren't any users for them before removing them entirely. what is 1720/tcp filtered H.323/Q.931 ? H.323 is usually used by Voice Over IP applications. To find out what particular application on your server is listening on that port, try the following: # lsof -Pni :1720 thanks for the help and how do i turn it off if it is uneccessary. This depends very much on the particular application; it may be started in rc.d or via inetd.conf. Most of these questions are asked rather frequently; their answers can be found in the archives and on google. i did have a quick look but nothing much eemed to come up RE this particular response - will look further, thanks, kev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: closing unwanted ports - and what is 1720/tcp filtered H.323/Q.931
Noah Meyerhans wrote: On Thu, Dec 15, 2005 at 06:46:02PM +0100, Florian Weimer wrote: It may be nothing. The fact that it showed up as filterd in the nmap output indicates that nmap didn't received a TCP RST packet back when it tried to contact that port. That may mean you have iptables configured to DROP packets to that port. It could also mean that the the ISP filters 1720/TCP, in order to prevent its customers from using VoIP. Good point. I suspect that's more likely. noah will check with demon to see if this is the case for my connection -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: closing unwanted ports - and what is 1720/tcp filtered H.323/Q.931
On Thu, Dec 15, 2005 at 12:35:09PM +, kevin bailey wrote: } hi, } } these ports seem to be open by default on a standard sarge setup } } PORT STATESERVICE } 9/tcpopen discard Useless. Turn it off. will do } 13/tcp open daytime Useless. Time in text format, without a timezone. Off. ok } 21/tcp open ftp Off. Security hole if passwords are sent, they aren't encrypted. will be trying to move to SFTP } 22/tcp open ssh I move to another port number to foil port scanners. good idea } 25/tcp open smtp I run postfix for my mailserver. Much simpiler than exim. i have actually switched to courier for this server because i was able to set up virtual domains i have used postfix for other clients and will be moving to it now because it handles virtual domains and i simply prefer it. } 37/tcp open time Can be turned off, but I leave it on and change the user from root to nobody. I am a public ntp server and many people like to use this time service also. rdate gets the time from this service. will turn off } 110/tcp open pop3 I firewall this off from the outside. I don't want passwords being passed to this from the outside. they are virtual accounts which are probably left by the users all over the place - there's not much i can do to protect these passwords - but at least they are not system accounts } 111/tcp open rpcbind Do NOT leave this one open. will do. } 143/tcp open imap You probably don't need this AND pop 110. I don't run this. } 1720/tcp filtered H.323/Q.931 Don't know what this is. But I don't have it. seems like it may be due to demon stopping VOIP traffic. thanks for your help,, kev -- E Frank Ball [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit has me worried!
(I hope you don't mind if I publish our correspondence in Linux Gazette, http://linuxgazette.net/ .) No problem at all. Kevin Bailey -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit has me worried!
thanks for the replies. what with it being several different symptoms i tend to think this is not a false positive. cause: this is an old server which has been running for 4 years. i have tried out lots of different things on this server and have made the mistake of leaving unnecessary services running. in this case i think that webmin was running the miniserv.pl server and this had a security warning issued for the version i had. it doesn't seem to have been fixed in the debian security fixes - i'll contact debian RE this. or it might have been a weakness in zope. luckily i was halfway through moving everything off this server to a new pair of servers and have been able to move the changeover forwards. also - very luckily - no data on the server has been damaged. it seems to spawn lots of hidden processes and has had to be rebooted to get it under control again. main points learnt. make sure you have snapshot backups going back months. regularly run chkrootkit and get the server to email the results to you. if backing up to another server get that server to pull backups out. on my new machines i was pushing out the backups from the primary server - this would mean a cracker would then have an easy way in to the backup machine because i was using authorized_keys so the backup would run in a script. but mainly only run required services - and check them closely - and don't rely on your distro to incorporate every single security patch required for your server. kev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
chkrootkit has me worried!
hi, the following output looks like i've been rooted. i'm in the process of moving all services to another machine and restoring from backups etc. could anyone provide any analysis of what attack caused the problem - i would guess that it's possibly something o do with zope. thanks, kev :/usr/local/sbin# chkrootkit ROOTDIR is `/' Checking `amd'... not found Checking `basename'... not infected Checking `biff'... not found Checking `chfn'... not infected Checking `chsh'... not infected Checking `cron'... not infected Checking `date'... not infected Checking `du'... not infected Checking `dirname'... not infected Checking `echo'... not infected Checking `egrep'... not infected Checking `env'... not infected Checking `find'... not infected Checking `fingerd'... not found Checking `gpm'... not found Checking `grep'... not infected Checking `hdparm'... not found Checking `su'... not infected Checking `ifconfig'... not infected Checking `inetd'... not infected Checking `inetdconf'... not infected Checking `identd'... not found Checking `killall'... not infected Checking `ldsopreload'... not infected Checking `login'... not infected Checking `ls'... INFECTED Checking `lsof'... not found Checking `mail'... not infected Checking `mingetty'... not found Checking `netstat'... INFECTED Checking `named'... not found Checking `passwd'... not infected Checking `pidof'... not infected Checking `pop2'... not found Checking `pop3'... not found Checking `ps'... INFECTED Checking `pstree'... not infected Checking `rpcinfo'... not infected Checking `rlogind'... not found Checking `rshd'... not found Checking `slogin'... not infected Checking `sendmail'... not infected Checking `sshd'... not infected Checking `syslogd'... not infected Checking `tar'... not infected Checking `tcpd'... not infected Checking `top'... INFECTED Checking `telnetd'... not found Checking `timed'... not found Checking `traceroute'... not infected Checking `write'... not infected Checking `aliens'... /dev/ttyop /dev/ttyoa Searching for sniffer's logs, it may take a while... nothing found Searching for HiDrootkit's default dir... nothing found Searching for t0rn's default files and dirs... nothing found Searching for t0rn's v8 defaults... nothing found Searching for Lion Worm default files and dirs... nothing found Searching for RSHA's default files and dir... nothing found Searching for RH-Sharpe's default files... nothing found Searching for Ambient's rootkit (ark) default files and dirs... nothing found Searching for suspicious files and dirs, it may take a while... /usr/lib/zope/lib/python/Products/DCWorkflow/.Xserver-lcd /usr/lib/zope/lib/python/Products/ZnolkSQLWizard/.selectColumns.dtml.swo /usr/lib/zope/lib/python/Products/ZnolkSQLWizard/.selectColumns.dtml.swp /usr/lib/zope/lib/python/SearchIndex/.testinfo /usr/lib/nmh/include/lib/.sniffer Searching for LPD Worm files and dirs... nothing found Searching for Ramen Worm files and dirs... nothing found Searching for Maniac files and dirs... nothing found Searching for RK17 files and dirs... nothing found Searching for Ducoci rootkit... nothing found Searching for Adore Worm... nothing found Searching for ShitC Worm... nothing found Searching for Omega Worm... nothing found Searching for Sadmind/IIS Worm... nothing found Searching for MonKit... nothing found Searching for anomalies in shell history files... Warning: `//root/.bash_history' file size is zero nothing found Checking `asp'... not infected Checking `bindshell'... not infected Checking `lkm'... You have 107 process hidden for readdir command You have 113 process hidden for ps command Warning: Possible LKM Trojan installed Checking `rexedcs'... not found Checking `sniffer'... eth0 is PROMISC Checking `wted'... nothing deleted Checking `z2'... nothing deleted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit has me worried!
and.. :/usr/local/sbin# /usr/lib/chkrootkit/chkproc -v PID 4: not in ps output PID 1769: not in ps output PID 15688: not in ps output PID 15690: not in ps output PID 17760: not in ps output PID 17762: not in ps output PID 21583: not in ps output PID 21585: not in ps output PID 21919: not in ps output PID 21921: not in ps output PID 23002: not in readdir output PID 23002: not in ps output PID 23085: not in readdir output PID 23085: not in ps output PID 23105: not in readdir output PID 23105: not in ps output You have 3 process hidden for readdir command You have13 process hidden for ps command and freeway:~# cd /proc/1769/fd freeway:/proc/1769/fd# ls -l total 0 lrwx-- 1 root root 64 Nov 29 05:11 0 - /dev/null lrwx-- 1 root root 64 Nov 29 05:11 1 - /dev/null lrwx-- 1 root root 64 Nov 29 05:11 2 - /dev/null lrwx-- 1 root root 64 Nov 29 05:11 3 - socket:[300] freeway:/proc/1769/fd# grep 300 /proc/net/udp freeway:/proc/1769/fd# grep 300 /proc/net/tcp 26: :0016 : 0A : 00: 00 300 freeway:/proc/1769/fd :/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
