Re: Port 699 listening
On Wed, Dec 14, 2005 at 11:18:29PM -0600, Jeffrey L. Taylor wrote: Quoting Alex Pankratz [EMAIL PROTECTED]: [snip] Did, and that made both 111 and 699 not show up in nmap scan. sweet, thanks Jeffery. I could swear that in the past I saw 111 open and I sort of ignored it, why would 699 be open now, and then closed? why is statd running, i dont use NFS. There are several services that use portmapper. Generally it has to be ripped out manually after a clean install (at least for Debian and SuSE). Read the portmap manpage. It tells you about the -i option and tcp_wrapper support. Jeffrey Aníbal Monsalve Salazar -- .''`. Debian GNU/Linux : :' : Free Operating System `. `' http://debian.org/ `- http://v7w.com/anibal signature.asc Description: Digital signature
Re: [SECURITY] [DSA 922-1] New Linux 2.6.8 packages fix several vulnerabilities
Hi. FYI, there seems to be a contradiction between message subject and package in contents : Le mercredi 14 décembre 2005 à 23:34 +0100, Martin Schulze a écrit : Package: kernel-source-2.4.27 Best regards, -- Olivier BERGER [EMAIL PROTECTED] Ingénieur Recherche - Dept INF INT Evry (http://www.int-evry.fr) OpenPGP-Id: 1024D/6B829EEC
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
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
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:
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
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.
--
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: 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: 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... -- -- 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
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
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
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
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 time to watch and what do you do when you're
Re: closing unwanted ports - and what is 1720/tcp filtered H.323/Q.931
* Quoting kevin bailey ([EMAIL PROTECTED]): hi, these ports seem to be open by default on a standard sarge setup PORT STATESERVICE 21/tcp open ftp This is not part of the default install. 25/tcp open smtp This is only open to localhost. 80/tcp open http 110/tcp open pop3 143/tcp open imap 443/tcp open https 1720/tcp filtered H.323/Q.931 This is not part of the default install. what is 1720/tcp filtered H.323/Q.931 ? `netstat -tulpen` shows you the listening UDP/TCP services and the corresponding program names. and how do i turn it off if it is uneccessary. Uninstall the program or edit the configuration files for the services, edit /etc/inetd.conf, /etc/hosts.allow. - Rolf -- 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
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
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: 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: 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. 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. noah signature.asc Description: Digital signature
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: closing unwanted ports - and what is 1720/tcp filtered H.323/Q.931
* Noah Meyerhans: 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. It could also mean that the the ISP filters 1720/TCP, in order to prevent its customers from using VoIP. -- 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 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 signature.asc Description: Digital signature
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]
Jazz Orgy List Invitation
Hello! Please pardon the intrusion. You are receiving this invitation because at one time or another, you expressed an interest in music on the internet. Since then, we paid someone for your email address. It's that simple. Since you like music, we thought you might be interested in subscribing to our email list. Rest assured, we promise to send only one email per month. The monthly email will include our calendar (upcoming performances, weekly residencies, special guests), web site updates (photos, songs, downloads), and any other exciting or interesting band news. So, without further adieu... If you want to subscribe, just click this link: http://www.jazzorgy.com/cgi-bin/dada/mail.cgi/n/jazzorgy_list/debian-security/lists.debian.org/14685322/ This is a one-time mailing. We promise that you won't hear from us again unless you subscribe to our email list. Contact: [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 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
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: 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: closing unwanted ports - and what is 1720/tcp filtered H.323/Q.931
On Thu, Dec 15, 2005 at 10:19:48PM +, kevin bailey wrote: good point - also the fact that the users stick their email passwords to their monitors using postits! Well, at least there's still *some* level of physical security there; an attacker has to be at your user's desk to get the password. Plus, 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, the latter is the better option. I'd suggest that they keep their password in their wallet or something, though, and only take it out when they need it. Treat it like a credit card or something, and it's basically safe. 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. Apache+mod_ssl is the way to go. If your users will only access their mail via the web interface, then configure your your IMAP server to only listen on the loopback interface. 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? ^^ You mean filtered. Yes. Normally, when a TCP SYN is sent to a port with nothing on it, the OS sends back a TCP RST packet, basically saying there's nothing here. If you configure iptables to DROP the packets, then nmap realizes that it didn't get the RST back and lists the port as filtered. If you want to firewall off a port such that it appears to the outside world that there is nothing on that port at all, use -j REJECT --reject-with tcp-reset in the iptables rule. As Florian pointed out, though, it's likely that your ISP is actually dropping the SYN packet, and that's why nmap isn't getting the RST back. Your OS never sees the SYN at all so it never sends back the RST. noah signature.asc Description: Digital signature
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: closing unwanted ports - and what is 1720/tcp filtered H.323/Q.931
Quoting kevin bailey ([EMAIL PROTECTED]): } 21/tcp open ftp Off. Security hole if passwords are sent, they aren't encrypted. Even in deployments where the only login supported is anonymous? ;- P.S.: http://linuxmafia.com/faq/Network_Other/ftp-justification.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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
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
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
