My LAN is behind a Netgear router, which does NAT. On the CentOS server I have fail2ban running. This morning my router reported 3 different IPs attempting to send UDP packets to port 38950, Since each address is only seen 4-5 times, I presume that fail2ban took over after that.
GRC reports that ports are stealthed (port 143 was open, but is now closed), but then:
Unsolicited Packets: RECEIVED (FAILED) — Your system's personal security countermeasures unwisely attempted to probe us in response to our probes. While some users believe that "tracking down" the source of Internet probes is useful, experience indicates that there is little to gain and potentially much to lose. The wisest course of action is to simulate nonexistence — which your system has failed to do. Your counter-probes immediately reveal your system's presence and location on the Internet.
So, two questions really. First, what should I be looking for on the router, to turn off this 'tracking down' activity?
Then, I want to read from my own IMAP server when I'm away from home. Is there a better way than opening port 143?
Anne
Then, I want to read from my own IMAP server when I'm away from home. Is there a better way than opening port 143?
The easiest would be if you had a fixed external IP and only allow it; but I guess that won't be the case. Maybe using an other port than 143? But I don't think that would fool port scanners. Or you could firewall everything and try "port knocking" to open it on demand and let you go through...
JD
John Doe wrote:
Then, I want to read from my own IMAP server when I'm away from home. Is there a better way than opening port 143?
The easiest would be if you had a fixed external IP and only allow it; but I guess that won't be the case. Maybe using an other port than 143? But I don't think that would fool port scanners.
Yes it will fool the port scanners.
On my centos server at a colo (er, not really my server, it's a xen virtual host on someone elses server, but it feels like mine - I love xen) I was seeing literally hundreds of attacks on the ssh port within a day of setting it up. I changed the port to one > 1024 and I haven't seen a single attack since.
If someone wants to attack your specific server, they'll do a full port scan and find what you have regardless of what ports you are using - but the vast majority of scripts don't because it takes longer to do a full port scan, machines run by people smart enough to change the port usually are run by people who have a clue, very often do not have a lot of users (machines that service a lot of users really need to use the standard ports) and thus are not as likely to have a brute force attack work. So the few extra hosts they find via full port scan isn't worth the time it takes, that time is better spent scanning for people without a clue who are running on the default port. I suspect a lot of scripts don't even bother to scan, they probably just try to connect and move to the next IP when they get a port closed.
On 12/23/08, Anne Wilson cannewilson@googlemail.com wrote:
My LAN is behind a Netgear router, which does NAT. On the CentOS server I have fail2ban running. This morning my router reported 3 different IPs attempting to send UDP packets to port 38950, Since each address is only seen 4-5 times, I presume that fail2ban took over after that.
GRC reports that ports are stealthed (port 143 was open, but is now closed), but then:
Try www.auditmypc.com or nmap-online.com rather than grc to look for open ports
So, two questions really. First, what should I be looking for on the router, to turn off this 'tracking down' activity?
Maybe your router is sending host / port unreachable icmp messages. You could try to see what is actually happening using wireshark on another computer from outside your LAN
Then, I want to read from my own IMAP server when I'm away from home. Is there a better way than opening port 143?
ssh tunnelling? fwknop? (if you want all ports to appear closed) http://cipherdyne.org/fwknop/
mike
Michael Simpson wrote:
GRC reports that ports are stealthed
Try www.auditmypc.com or nmap-online.com rather than grc to look for open ports
What advantages do they have, in your opinion?
there a better way than opening port 143?
ssh tunnelling?
I agree, though the default CentOS sshd configuration requires some tightening down to trust it on Internet-facing servers, IMHO:
1. In /etc/ssh/sshd_config, set "PasswordAuthentication no". No matter how good your password, it isn't as good as using keys. Remember, forwarding ssh opens it to pounding 24x7 from any of the millions on zombie boxes on the Internet.
2. On the machine(s) that you want to allow logins from, run "ssh-keygen -t rsa" to generate a key pair, if you haven't already. Then copy the contents of ~/.ssh/id-rsa.pub into ~/.ssh/authorized_keys on your home server. These keys are used to authenticate the remote system, in lieu of a password or physical token. You could put these keys on a USB stick instead, if you didn't want to keep them permanently on the remote hosts.
3. Disable SSHv1 protocol support in /etc/ssh/sshd_config: "Protocol 2", not "Protocol 2,1". SSHv1 has known weaknesses. Boggles my mind that it's still enabled by default....
4. Same file, set "PermitRootLogin no" if it isn't already.
(Aside: I also like to set up sudo with one account allowed to do anything, then lock the root account, so the only way to get root access is to log in as a regular user then sudo up, reducing the risk of passwordless keys.)
Having done all this, you're ready to allow remote access:
5. In your router, forward a high-numbered port to 22 on the server. If it's not smart enough to use different port numbers on either side, you can change the sshd configuration so it listens on a different port instead. I like to use 22022 for this.
This is *not* security through obscurity. It's simply a way to reduce the amount of log spam you have to dig through when monitoring your system's behavior. Everything that appears in your logs should be *interesting*. Constant port knocking from worms and script kiddies is not interesting.
In case you've not done ssh tunelling, Anne, the command that does what you want, having done all the above is:
$ ssh -p22022 -L10143:my.server.com:143 anne@my.server.com
This sets up port 10143 on the local system to be redirected through the ssh session to the IMAP port on your home server. You don't want to redirect 143 to 143 because that would require you to run ssh as root. It also prevents you from using this on a system that itself has an IMAP server.
With the tunnel up, you can set up your mail client to connect to port 10143 on localhost, and you'll be looking at your remote mail server.
On 12/23/08, Warren Young warren@etr-usa.com wrote:
Michael Simpson wrote:
GRC reports that ports are stealthed
Try www.auditmypc.com or nmap-online.com rather than grc to look for open ports
What advantages do they have, in your opinion?
they're not grc
auditmypc has been mentioned as an alternative to grc or sygate (after acquisition by symantec)
personally, i use nmap to scan my systems so nmap-online seems a reasonable way of doing this if you don't have access to an external box/colo server
i am lucky to have a very lightly loaded production webserver at my disposal for this.
mike
On Tuesday 23 December 2008 15:38:17 Warren Young wrote:
Michael Simpson wrote:
First, thanks to all who replied. I'll try to remember and consider all that has been said.
GRC reports that ports are stealthed
Try www.auditmypc.com or nmap-online.com rather than grc to look for open ports
What advantages do they have, in your opinion?
there a better way than opening port 143?
ssh tunnelling?
I agree, though the default CentOS sshd configuration requires some tightening down to trust it on Internet-facing servers, IMHO:
- In /etc/ssh/sshd_config, set "PasswordAuthentication no". No matter
how good your password, it isn't as good as using keys. Remember, forwarding ssh opens it to pounding 24x7 from any of the millions on zombie boxes on the Internet.
I use ssh with keys from this laptop over the LAN for updates etc. :-)
- On the machine(s) that you want to allow logins from, run "ssh-keygen
-t rsa" to generate a key pair, if you haven't already. Then copy the contents of ~/.ssh/id-rsa.pub into ~/.ssh/authorized_keys on your home server. These keys are used to authenticate the remote system, in lieu of a password or physical token. You could put these keys on a USB stick instead, if you didn't want to keep them permanently on the remote hosts.
This is done for this laptop, but I'll set the netbook up the same way before taking it on holiday.
- Disable SSHv1 protocol support in /etc/ssh/sshd_config: "Protocol 2",
not "Protocol 2,1". SSHv1 has known weaknesses. Boggles my mind that it's still enabled by default....
I think that's done, but I'll check
- Same file, set "PermitRootLogin no" if it isn't already.
It is
(Aside: I also like to set up sudo with one account allowed to do anything, then lock the root account, so the only way to get root access is to log in as a regular user then sudo up, reducing the risk of passwordless keys.)
Having done all this, you're ready to allow remote access:
- In your router, forward a high-numbered port to 22 on the server. If
it's not smart enough to use different port numbers on either side, you can change the sshd configuration so it listens on a different port instead. I like to use 22022 for this.
This is *not* security through obscurity. It's simply a way to reduce the amount of log spam you have to dig through when monitoring your system's behavior. Everything that appears in your logs should be *interesting*. Constant port knocking from worms and script kiddies is not interesting.
In case you've not done ssh tunelling, Anne, the command that does what you want, having done all the above is:
$ ssh -p22022 -L10143:my.server.com:143 anne@my.server.com
This sets up port 10143 on the local system to be redirected through the ssh session to the IMAP port on your home server. You don't want to redirect 143 to 143 because that would require you to run ssh as root. It also prevents you from using this on a system that itself has an IMAP server.
With the tunnel up, you can set up your mail client to connect to port 10143 on localhost, and you'll be looking at your remote mail server.
Thanks for the detailed how-to. I was feeling somewhat nervous of yet another system to learn, but I should be fine with this. I'll set it up over Christmas, all being well, though I may end up having to ask more questions. Providing I can persuade my son-in-law to add the netbook's MAC to his router I should be able to test from his network.
Thanks again
Anne
Top posting to ask a question regarding the article below:
Hi Warren, Nice explanation. I would like to ask what you recommend people do if they want to be able to ssh in from anywhere on the internet. Say they are going to be traveling and they know they will have to login from machines they have no control over, like an internet cafe or a Hotel's business services suite?
On Tue, Dec 23, 2008 at 08:38:17AM -0700, Warren Young wrote:
I agree, though the default CentOS sshd configuration requires some tightening down to trust it on Internet-facing servers, IMHO:
- In /etc/ssh/sshd_config, set "PasswordAuthentication no". No matter
how good your password, it isn't as good as using keys. Remember, forwarding ssh opens it to pounding 24x7 from any of the millions on zombie boxes on the Internet.
- On the machine(s) that you want to allow logins from, run "ssh-keygen
-t rsa" to generate a key pair, if you haven't already. Then copy the contents of ~/.ssh/id-rsa.pub into ~/.ssh/authorized_keys on your home server. These keys are used to authenticate the remote system, in lieu of a password or physical token. You could put these keys on a USB stick instead, if you didn't want to keep them permanently on the remote hosts.
- Disable SSHv1 protocol support in /etc/ssh/sshd_config: "Protocol 2",
not "Protocol 2,1". SSHv1 has known weaknesses. Boggles my mind that it's still enabled by default....
- Same file, set "PermitRootLogin no" if it isn't already.
(Aside: I also like to set up sudo with one account allowed to do anything, then lock the root account, so the only way to get root access is to log in as a regular user then sudo up, reducing the risk of passwordless keys.)
Having done all this, you're ready to allow remote access:
- In your router, forward a high-numbered port to 22 on the server. If
it's not smart enough to use different port numbers on either side, you can change the sshd configuration so it listens on a different port instead. I like to use 22022 for this.
This is *not* security through obscurity. It's simply a way to reduce the amount of log spam you have to dig through when monitoring your system's behavior. Everything that appears in your logs should be *interesting*. Constant port knocking from worms and script kiddies is not interesting.
In case you've not done ssh tunelling, Anne, the command that does what you want, having done all the above is:
$ ssh -p22022 -L10143:my.server.com:143 anne@my.server.com
This sets up port 10143 on the local system to be redirected through the ssh session to the IMAP port on your home server. You don't want to redirect 143 to 143 because that would require you to run ssh as root. It also prevents you from using this on a system that itself has an IMAP server.
With the tunnel up, you can set up your mail client to connect to port 10143 on localhost, and you'll be looking at your remote mail server. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
--
On Wednesday 24 December 2008 14:30:26 jkinz@kinz.org wrote:
Top posting to ask a question regarding the article below:
Hi Warren, Nice explanation. I would like to ask what you recommend people do if they want to be able to ssh in from anywhere on the internet. Say they are going to be traveling and they know they will have to login from machines they have no control over, like an internet cafe or a Hotel's business services suite?
That's precisely what I'm wanting to set up on my netbook, and I think that this explanation addresses that.
Anne
On Wed, Dec 24, 2008, jkinz@kinz.org wrote:
Top posting to ask a question regarding the article below:
Hi Warren, Nice explanation. I would like to ask what you recommend people do if they want to be able to ssh in from anywhere on the internet. Say they are going to be traveling and they know they will have to login from machines they have no control over, like an internet cafe or a Hotel's business services suite?
I always have my laptop with me, and have systems here configured to (a) accept only authorized_keys, (b) allow access from any IP, and (c) use fail2ban to limit the number of log entries from failed attempts to access the systems. All logins to our customer sites are then initiated from inside our network once I have established the initial connection from the remote location so those connections can be much more restrictive if necessary.
One possibility would be to have a machine configured to allow password access from the world which one could log into, then execute ssh-agent, and ssh-add (with a strong pass phrase) on that machine to get access to other systems on your network.
If there is some reason that an ssh cannot be established, usually it's possible to connect with OpenVPN, which works nicely behind NAT firewalls and does not require kernel hacking on CentOS as things like PPTP do.
You make the job much more difficult when asking that you be able to get in from any old machine you might find in public space. Other than the fact that the owners of these machines generally don't allow people to install software on them, I would be very reluctant to do anything on them that involved secure logins as who knows what key capture or other spyware is running on them.
One may be able to access you systems using webmin or its usermin module over an SSL connection, and webmin has a terminal interface allowing one to get a connection to systems. If I remember correctly, this does require Java(tm) on the connecting machine, and that webmin be configured to permit use of the terminal module.
I much prefer restrict webmin and usermin access though as I have seen far too many systems cracked through it because it only has username, password authentication, and too many times, user's passwords are easily cracked. Once somebody is logged into usermin, for instance, they may have access to tools such as the chfn (change finger information) command which at one time on SuSE systems allowed them to change their uid to ``0'' and gain root access to the system.
In summary, I would be extremely reluctant to allow access from public machines where there is no assurance how much malware is running on top of the Microsoft virus, Windows. It's very easy to revoke authorized_keys or OpenVPN access for a lost or stolen laptop. Allowing password access by any means opens up a large can of worms.
... Bill
On Wednesday 24 December 2008 17:43:19 Bill Campbell wrote:
In summary, I would be extremely reluctant to allow access from public machines where there is no assurance how much malware is running on top of the Microsoft virus, Windows.
When I said that I had used hotel computers I meant for using a web interface only. The problem with that is that they usually have only IE, which I don't trust.
It's very easy to revoke authorized_keys or OpenVPN access for a lost or stolen laptop. Allowing password access by any means opens up a large can of worms.
The only password access that is happening is when kmail reads from my imap server. I toyed with the idea of using ssh access to all my files, but watching the logs for a very short time convinced me that that's something that is not worth while. (No-one got in, but in that short time there were plenty of attempts.) I know it can be done securely, but it's not straightforward, and in truth there aren't so many documents that I'm likely to want to access while I'm away. I have sufficient local storage, too, that I can use termporarily and transfer when I get home.
I have no need to open up all sorts of services. I just need to feel that I have taken all reasonable precautions.
Anne
On Wed, Dec 24, 2008 at 09:43:19AM -0800, Bill Campbell wrote:
On Wed, Dec 24, 2008, jkinz@kinz.org wrote:
Top posting to ask a question regarding the article below: Summary: Enable ssh to allow login from any random point on the internet
I always have my laptop with me,
An excellent strategy Bill. I use it myself, but I explicitly excluded it in my question. Why? because there are lots of scenarios in the world where people won't be able to use their laptop or netbook and will have to fall back on using someone else's equipment.
Two examples : You are visiting the Otis Public Library in Norwich CT. They have Linux based public workstations (w/Internet access). (http://www.otislibrarynorwich.org/index.htm)
Or you are a consultant visiting a corporate client who doesn't allow "outside equipment" to be used on their network, so they maintain specific machines for "guests" to use. (Hint, "DOD" )
(I have run into both of these. :-) )
example three - A TSA attendant "accidentally" drops your laptop.. in front of a forklift... (Merry Christmas!)
All your ideas are good ones to which I would add using port knocking (not perfect at all but adds an additional small barrier)
The best technique I have used is to put up an https web page that requires the person desiring entry to be presented with a challenge<->response dialog that is generated from a specific one-time use pad of CR key pairs. That way, each session requires a unique response to enable it. This is awkward but help keep the unwanted visitors out. This would be a variation on your SSL webmin suggestion.
Unfortunately, the worst case scenario ( a compromised machine that does key logging) which you pointed out, will always be a potential problem..
So when on the road, perhaps we should restrict doing online banking to just the cell phone.. :-) hmm.......
accept only authorized_keys, (b) allow access from any IP, and (c) use fail2ban to limit the number of log entries from failed attempts to access the systems. All logins to our customer sites are then initiated from inside our network once I have established the initial connection from the remote location so those connections can be much more restrictive if necessary.
One possibility would be to have a machine configured to allow password access from the world which one could log into, then execute ssh-agent, and ssh-add (with a strong pass phrase) on that machine to get access to other systems on your network.
If there is some reason that an ssh cannot be established, usually it's possible to connect with OpenVPN, which works nicely behind NAT firewalls and does not require kernel hacking on CentOS as things like PPTP do.
You make the job much more difficult when asking that you be able to get in from any old machine you might find in public space. Other than the fact that the owners of these machines generally don't allow people to install software on them, I would be very reluctant to do anything on them that involved secure logins as who knows what key capture or other spyware is running on them.
One may be able to access you systems using webmin or its usermin module over an SSL connection, and webmin has a terminal interface allowing one to get a connection to systems. If I remember correctly, this does require Java(tm) on the connecting machine, and that webmin be configured to permit use of the terminal module.
I much prefer restrict webmin and usermin access though as I have seen far too many systems cracked through it because it only has username, password authentication, and too many times, user's passwords are easily cracked. Once somebody is logged into usermin, for instance, they may have access to tools such as the chfn (change finger information) command which at one time on SuSE systems allowed them to change their uid to ``0'' and gain root access to the system.
In summary, I would be extremely reluctant to allow access from public machines where there is no assurance how much malware is running on top of the Microsoft virus, Windows. It's very easy to revoke authorized_keys or OpenVPN access for a lost or stolen laptop. Allowing password access by any means opens up a large can of worms.
... Bill -- INTERNET: bill@celestial.com Bill Campbell; Celestial Software LLC URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way Voice: (206) 236-1676 Mercer Island, WA 98040-0820 Fax: (206) 232-9186
If the government can take a man's money without his consent, there is no limit to the additional tyranny it may practise upon him; for, with his money, it can hire soldiers to stand over him, keep him in subjection, plunder him at discretion, and kill him if he resists. Lysander Spooner, 1852 _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
--
On Wed, Dec 24, 2008, jkinz@kinz.org wrote:
On Wed, Dec 24, 2008 at 09:43:19AM -0800, Bill Campbell wrote:
On Wed, Dec 24, 2008, jkinz@kinz.org wrote:
Top posting to ask a question regarding the article below: Summary: Enable ssh to allow login from any random point on the internet
I always have my laptop with me,
An excellent strategy Bill. I use it myself, but I explicitly excluded it in my question. Why? because there are lots of scenarios in the world where people won't be able to use their laptop or netbook and will have to fall back on using someone else's equipment.
Two examples : You are visiting the Otis Public Library in Norwich CT. They have Linux based public workstations (w/Internet access). (http://www.otislibrarynorwich.org/index.htm)
Or you are a consultant visiting a corporate client who doesn't allow "outside equipment" to be used on their network, so they maintain specific machines for "guests" to use. (Hint, "DOD" )
I don't do business with government agencies, it just encourages them to continue their legal plunder (and often it takes forever to get paid -- unless one offers an early payment discount that they are required by law to use).
(I have run into both of these. :-) )
example three - A TSA attendant "accidentally" drops your laptop.. in front of a forklift... (Merry Christmas!)
That might well get me to cancel my trip.
All your ideas are good ones to which I would add using port knocking (not perfect at all but adds an additional small barrier)
I am aware of port knocking, but doing that certainly requires stuff on the client computer that wouldn't be available at the average Internet cafe or kiosk device.
The best technique I have used is to put up an https web page that requires the person desiring entry to be presented with a challenge<->response dialog that is generated from a specific one-time use pad of CR key pairs. That way, each session requires a unique response to enable it. This is awkward but help keep the unwanted visitors out. This would be a variation on your SSL webmin suggestion.
I saw something recently on one of the many mailing lists about a USB device that generates one-time-passwords at very reasonable cost. These can be plugged into anything with a USB port that would recognize a USB keyboard.
Unfortunately, the worst case scenario ( a compromised machine that does key logging) which you pointed out, will always be a potential problem..
So when on the road, perhaps we should restrict doing online banking to just the cell phone.. :-) hmm.......
My bank is set up to make one jump through several hoops when logging in from an IP that it has not seen a login to the account, and may even distinguish browsers as I think I have had to do something special when using Safari on my desktop instead of my normal Firefox. My bank is a small regional bank where the people at the branch know me, and even recognize my voice on the phone so it's pretty easy for me to do things by phone. I *HATE* dealing with megabanks where customer service is an oxymoron.
... Bill
jkinz@kinz.org wrote:
You are visiting the Otis Public Library in Norwich CT. They have Linux based public workstations (w/Internet access). (http://www.otislibrarynorwich.org/index.htm)
Do you trust the library, all of their employees, and every person who has ever used the computer you sit down at with the keys to your home? No? Don't give them the keys to your home.
Or you are a consultant visiting a corporate client who doesn't allow "outside equipment" to be used on their network, so they maintain specific machines for "guests" to use. (Hint, "DOD" )
Ditto.
Additionally, when using your employer's equipment, or your own equipment at on your employer's premises, the company is legally entitled to watch whatever you do, and demand that you provide keys so they can see through any encryption. Don't trust your employer with the keys to your home? Don't access your home system from work.
example three - A TSA attendant "accidentally" drops your laptop.. in front of a forklift... (Merry Christmas!)
Life is hard. You cannot plan for every eventuality.
All your ideas are good ones to which I would add using port knocking (not perfect at all but adds an additional small barrier)
Port knocking is just a type of key. If you use this from a system you do not trust or where the owner of the system has a right to know all the keys used on it and you don't want that person to know the key, don't give the key to that system.
Unfortunately, the worst case scenario ( a compromised machine that does key logging) which you pointed out, will always be a potential problem..
This is more than just a potential hazard. There are *millions* of zombies on the Internet now. Since there are only about a billion PCs in active use in the world, this means the chances of you borrowing time on a computer that's zombified is maybe 1 in a hundred. Would you get in a car if the chances of getting into an accident were 1:100?
The odds shift when you trust the security of the hardware.
On Wed, Dec 24, 2008 at 12:43 PM, Bill Campbell centos@celestial.com wrote: <snip>
Hi Warren, Nice explanation. I would like to ask what you recommend people do if they want to be able to ssh in from anywhere on the internet. Say they are going to be traveling and they know they will have to login from machines they have no control over, like an internet cafe or a Hotel's business services suite?
<snip> I again offer you my "solution", which is to take with me "Live CDs" for CentOS 5.2 and Knoppix. I reboot the box in an Internet cafe, from a Live CD, do what I need/want to do, and when I am done, I remove the Live CD and reboot the public box again. I have not installed anything on their box and I am much safer, surfing, etc., on a public box.
Lanny Marcus wrote:
On Wed, Dec 24, 2008 at 12:43 PM, Bill Campbell centos@celestial.com wrote:
<snip>
Hi Warren, Nice explanation. I would like to ask what you recommend people do if they want to be able to ssh in from anywhere on the internet. Say they are going to be traveling and they know they will have to login from machines they have no control over, like an internet cafe or a Hotel's business services suite?
<snip> I again offer you my "solution", which is to take with me "Live CDs" for CentOS 5.2 and Knoppix. I reboot the box in an Internet cafe, from a Live CD, do what I need/want to do, and when I am done, I remove the Live CD and reboot the public box again. I have not installed anything on their box and I am much safer, surfing, etc., on a public box.
i'm quite surprised many such internet cafes would let you run your own software on their hardware. many of the 'cafe' systems I've seen are booted off the network, or don't have CD drives, or could even be running Linux already, such as these http://www.dnalounge.com/backstage/src/kiosk/
John R Pierce wrote:
Lanny Marcus wrote:
On Wed, Dec 24, 2008 at 12:43 PM, Bill Campbell centos@celestial.com wrote:
<snip>
Hi Warren, Nice explanation. I would like to ask what you recommend people do if they want to be able to ssh in from anywhere on the internet. Say they are going to be traveling and they know they will have to login from machines they have no control over, like an internet cafe or a Hotel's business services suite?
<snip> I again offer you my "solution", which is to take with me "Live CDs" for CentOS 5.2 and Knoppix. I reboot the box in an Internet cafe, from a Live CD, do what I need/want to do, and when I am done, I remove the Live CD and reboot the public box again. I have not installed anything on their box and I am much safer, surfing, etc., on a public box.
i'm quite surprised many such internet cafes would let you run your own software on their hardware. many of the 'cafe' systems I've seen are booted off the network, or don't have CD drives, or could even be running Linux already, such as these http://www.dnalounge.com/backstage/src/kiosk/
Typically the case. The systems are 'locked' down boot wise, you might be able to do something they cannot charge for.
Bring your own computer. For $300 you can have an ASUS computer for these basic tasks. If they have not implemented NAC, you can unplug the cafe system if need be (done that enough times).
On Thu, Dec 25, 2008 at 6:18 AM, John R Pierce pierce@hogranch.com wrote: <snip>
I again offer you my "solution", which is to take with me "Live CDs" for CentOS 5.2 and Knoppix. I reboot the box in an Internet cafe, from a Live CD, do what I need/want to do, and when I am done, I remove the Live CD and reboot the public box again. I have not installed anything on their box and I am much safer, surfing, etc., on a public box.
i'm quite surprised many such internet cafes would let you run your own software on their hardware. many of the 'cafe' systems I've seen are booted off the network, or don't have CD drives, or could even be running Linux already, such as these http://www.dnalounge.com/backstage/src/kiosk/
I haven't done that often, but the few times I've done it, the boxes had a DVD or CD drive and I was able to boot off the Live CD. Now that I've read what you wrote, the next time I need to use a Public Box, I will try to look at it, first, before I pay, to be sure there's a DVD or CD drive to boot from! :-)
On Thursday 25 December 2008 11:12:19 Lanny Marcus wrote:
On Wed, Dec 24, 2008 at 12:43 PM, Bill Campbell centos@celestial.com wrote: <snip>
Hi Warren, Nice explanation. I would like to ask what you recommend people do if they want to be able to ssh in from anywhere on the internet. Say they are going to be traveling and they know they will have to login from machines they have no control over, like an internet cafe or a Hotel's business services suite?
<snip> I again offer you my "solution", which is to take with me "Live CDs" for CentOS 5.2 and Knoppix. I reboot the box in an Internet cafe, from a Live CD, do what I need/want to do, and when I am done, I remove the Live CD and reboot the public box again. I have not installed anything on their box and I am much safer, surfing, etc., on a public box.
I'll bet you're popular at those cafes :-)
Anne
Anne Wilson wrote:
On Thursday 25 December 2008 11:12:19 Lanny Marcus wrote:
On Wed, Dec 24, 2008 at 12:43 PM, Bill Campbell centos@celestial.com wrote: <snip>
Hi Warren, Nice explanation. I would like to ask what you recommend people do if they want to be able to ssh in from anywhere on the internet. Say they are going to be traveling and they know they will have to login from machines they have no control over, like an internet cafe or a Hotel's business services suite?
<snip> I again offer you my "solution", which is to take with me "Live CDs" for CentOS 5.2 and Knoppix. I reboot the box in an Internet cafe, from a Live CD, do what I need/want to do, and when I am done, I remove the Live CD and reboot the public box again. I have not installed anything on their box and I am much safer, surfing, etc., on a public box.
I'll bet you're popular at those cafes :-)
Going WAY back. Comdex Atlanta, learly 90s.
The hotel I got stuffed in quite a ways from downtown, had 'old' hardwired phones, no RJ11 jacks. But I was a REAL road warrior, I had my full tool kit of tools, jumper cables and the like. I had the phone apart and my computer wired in and cleaning came in for some reason (I was running late and had not left for the show yet). She freaked and called security. I had to show management that I knew more about their phone system than anyone around and would put everything back. SHEESH!
Then there was that 5 star hotel in Chicago where their integrated data jack could not support speeds faster than 1200bps no matter what they claimed (and I finally nailed the pbx rep on the junk they sold the hotel in front of the hotel manager).
It never ends. We are always dealing with the lowest common denominator, GREED! Followed by stupidity.
Scott Bradner, one of the original IETFers (his middle initial is 'O' and he LOVES to sign things with just his initials) once said at an IETF plenary session:
"The clue level in the Internet is a constant. The Internet is growing geometrically. I leave the math to you."
Lanny Marcus wrote:
On Wed, Dec 24, 2008 at 12:43 PM, Bill Campbell centos@celestial.com wrote:
<snip>
Hi Warren, Nice explanation. I would like to ask what you recommend people do if they want to be able to ssh in from anywhere on the internet. Say they are going to be traveling and they know they will have to login from machines they have no control over, like an internet cafe or a Hotel's business services suite?
<snip> I again offer you my "solution", which is to take with me "Live CDs" for CentOS 5.2 and Knoppix. I reboot the box in an Internet cafe, from a Live CD, do what I need/want to do, and when I am done, I remove the Live CD and reboot the public box again. I have not installed anything on their box and I am much safer, surfing, etc., on a public box.
If you MUST use a public computer, this is the only sensible approach.
If you cannot boot a public computer from a Live CD or USB, you should not use it at all.
Marginally, if you can have Firefox run from a CD or USB, you are marginally protected.
You have no idea what has been installed on a public computer. There could even be a key capture device on the system that would get you even a Live CD.
Don't like to carry a compter? Got a few hundred to protect your life? Get an ASUS. If you have $1500 get an OQO (you can carry that almost in your pocket). Just get your own computing platform.
Once upon a time, MIT had a little red button on their public SUN systems. You pushed the button and got a assured clean boot from their protected server (and I know the people protecting those servers, they were never compromised). After you finished, you could hit the red button and leave nothing behind. I don't know what they do at MIT or anywhere else these days. I would never trust a public computer for anything I would not leave on an empty seat in an airport.
Yes I have printed off presentations at hotel business centers and used their airline boarding pass systems. But that is IT!
Either your own boot environment (and check for key stroke loggers), or your own system.
Next we will address security WRT to your own system.
I *****AM**** paranoid, it is my business!
On Thu, 25 Dec 2008 09:27:05 -0500 Robert Moskowitz wrote:
Once upon a time, MIT had a little red button on their public SUN systems. You pushed the button and got a assured clean boot from their protected server (and I know the people protecting those servers, they were never compromised).
Which is still no assurance to anyone who doesn't know the people protecting those servers.
jkinz@kinz.org wrote:
Hi Warren, Nice explanation.
Thanks!
I would like to ask what you recommend people do if they want to be able to ssh in from anywhere on the internet. Say they are going to be traveling and they know they will have to login from machines they have no control over, like an internet cafe or a Hotel's business services suite?
Much of what I have to say on this has been said by others here already, but since you asked me, I'll repeat it.
You cannot trust hardware that's been in anyone else's hands. A compromised computer can be made to do *anything*. Furthermore, technology exists to make it extremely difficult to tell whether it has been compromised. Therefore, you must carry hardware you control, and that hardware must be resistant to attack. Whether it's a hacked-up Palm III running uC Linux or a MacBook Air, you must be in control of it, top-to-bottom, if you are going to trust it with the keys it needs to get into your home from the outside. If you can't trust the hardware, don't give it the keys.
Whatever portable system you choose, the key store must be strongly encrypted, or you must use a strong password on the individual keys. Again, this is the key to your home. If the hardware gets stolen, you want those keys to be unusable. Ideally, you want stolen hardware to be virtually worthless until reformatted.
I have two portable systems that I trust enough to give them the keys to my home system.
My primary portable is a MacBook Pro with the home directory encrypted with OS X's FileVault feature. This is AES encryption, keyed with my login password, which is suitably strong. Since my entire home directory is encrypted, I don't bother to use passwords on the ssh keys I keep on that system. (I also use secure virtual memory on this system, for what that's worth.)
The other portable is a little Asus Eee 701, reformatted to run Ubuntu Eee. (Since renamed Easy Peasy...wince...) I haven't yet got it doing full disk encryption, so I password-protect its ssh key.
On Friday 26 December 2008 21:18:27 Warren Young wrote:
The other portable is a little Asus Eee 701, reformatted to run Ubuntu Eee. (Since renamed Easy Peasy...wince...) I haven't yet got it doing full disk encryption, so I password-protect its ssh key.
Since I can't encrypt the whole disk at the moment, I also set a BIOS password. Just another hoop to jump through. Hopefully each hoop is strong enough on its own. Together they should make the hardware entirely un- enticing :-)
Anne
Anne Wilson wrote on Tue, 23 Dec 2008 13:06:01 +0000:
My LAN is behind a Netgear router, which does NAT. On the CentOS server I have fail2ban running. This morning my router reported 3 different IPs attempting to send UDP packets to port 38950,
which is per se nothing to worry about and there's no connection to IMAP that you mention in the rest of your mail.
Since each address is only seen
4-5 times, I presume that fail2ban took over after that.
I doubt you have it checking port 38950, do you? And the fail2ban doesn't run on your router. So, there is no connection.
GRC reports
What is that?
So, two questions really. First, what should I be looking for on the router, to turn off this 'tracking down' activity?
You may want to ask the GRC developer what he means by that.
Then, I want to read from my own IMAP server when I'm away from home. Is there a better way than opening port 143?
You can VPN to your router and then use your LAN like normal.
Kai
-
Anne Wilson -
Bill Campbell -
Frank Cox -
jkinz＠kinz.org -
John Doe -
John R Pierce -
Kai Schaetzl -
Lanny Marcus -
Michael A. Peters -
Michael Simpson -
Robert Moskowitz -
Warren Young