COMMAND LINE WARRIORS

Taking Control of your Own Technology

How to find out your IP address in Python

24 November 2007

Interesting Fact for Anoraks

Before Avahi and Zeroconf and so on, the classic way that a computer knows where to find other machines on the network is the hosts file. The /etc directory is the main location for configuration files on Linux/Unix. So the location for the hosts file is /etc/hosts.

BSD had one of the first implementations of an TCP/IP stack, this was then taken by a company called Spider Systems and flogged to Microsoft, who added it to Windows NT. Over time, much of Microsoft's TCP/IP layer has probably been modified and re-factored over time, but there is a continuous line of code from BSD to Windows NT/XP/VISTA.

So in these later Windows systems, where is the hosts file? It is:

C:/WINDOWS/system32/drivers/etc/hosts

Which is pretty interesting (or not if you are without your anorak).

How to find out your hostname

The hostname is the computer's individual name. To find out your hostname on a Linux/Unix system, you can use the coreutils command uname:

uname -n

(There are also various commands called 'hostname' which very according to platform).

There is also a C function gethostname() (in Linux provided by glibc), this makes a call to the system information and returns the name of the system.

The Python Socket Module is a binding to many of these C functions that deal with low-level network programming. So to get the hostname via the socket module, you can run:

> ::import socket > socket.gethostname() >

If you are not used to python, just type this into a terminal:

python -c 'import socket; print socket.gethostname()'

How to find out your IP Address

Now we might like to find out the IP Address of the system. This is slightly more difficult to do cleanly and in a cross-platform fashion.

There was a discussion on the Python mailing list today when someone asked exactly this question.

A common way to get the IP address of the local system is to use the socket module's binding to the C function called gethostbyname() and then feed in the hostname that we discovered above:

> ::import socket > socket.gethostbyname(socket.gethostname()) >

This will work for many systems but not all. Most servers will have a fixed IP address added to their /etc/hosts file. However, desktops often will not have this, especially if they are laptops that move from network to network.

Jean-Paul Calderone replied to the mailing list with a cunning solution; prepare a dummy socket and see what the socket name is:

> ::import socket > s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) > s.connect(('google.com', 0)) > s.getsockname()[0] >

Discuss this post - Leave a comment

1 Zeth says...

Okay `this `_ is not cross-platform, but rather cool for how many different text processing tools you can get in there:

System Message: WARNING/2 (<string>, line 1); backlink

Inline interpreted text or phrase reference start-string without end-string.

System Message: WARNING/2 (<string>, line 1); backlink

Inline interpreted text or phrase reference start-string without end-string.

import os os.popen("ifconfig eth0 | grep inet | awk '{print $2}' | sed -e s/.*://", "r")

Posted at 1:02 a.m. on November 25, 2007


2 Zeth says...

In CGI, showing the remote IP of the visitor is simply a matter of getting os.environ['REMOTE_ADDR'] as demonstrated here: http://zeth.me.uk/python/myip.txt

Of course, if the browser has a router then the IP address will come from that.

Posted at 1:16 a.m. on November 25, 2007


3 Arne Babenhauserheide says...

Many thanks for the info!

But the problem is: This doesn't reach out over a NAT.

It would be nice to have it implemented in theƂ  standard-module, giving me the option to specify the host to use.

Something like socket.getlocalip socket.getexternalip

Posted at 6:51 p.m. on November 25, 2007


What do you have to say?


About

Hello, my name is Zeth, I'll be your host here.

Command Line Warriors is about taking control of your own technology, it looks at our experiences of computing; especially using GNU/Linux, the Python programming language, the command-line and issues such as techno-ethics, best practices and whatever is cool now. If you take control of your technology then you are a Warrior too!

This site is your site too which means that you can contribute and get involved. You can leave comments using the facility provided. For me, the comments and discussions are by far the best part of the site. So please do have your say!

Latest Discussions

Zeth

May 16, 2008
To Anonymous, I tried your script with some old SSH keys and it did not manage to break into an apparently vulnerable system. 1. The script requires a known username. My system did not allow root logins. 2. After failed three logins, the script's IP address got added to deny hosts.
Swap out your ssh keys

Zeth

May 16, 2008
To Anonymous, I said to do three things: 1. Accept the update. 2. Replace your keys. 3. Don't *have a panic attack about it.* And I still stand by that. Most non-technical users won't even be using openssh-server. While the update, blacklists and instructions on how to regenerate comes down automatically for those that do. Indeed, I think this episode shows how fast the free/open source community can move. Everytime the open source software has a panic attack over an in-theory, technically possible, but not actually being used, 'exploit', then proprietary software people say "Look their software is no better, it is just as insecure as ours". However, that is not true. There is a range of exploits, from theoretically possible with some serious preparation and knowledge about the target system, through to automated attacks that will work against any machine without the need for knowledge about it.
Swap out your ssh keys

Anonymous

May 15, 2008
Like stefano says, you are being VERY irresponsible by downplaying this as only "theoretically possible with a supercomputer". Linked on the page stefano mentioned is this: http://milw0rm.com/exploits/5622 That will break into your computer in a couple hours is you're using public-key logins, which are considered the safest kind, and are used on many, many machines that are supposed to be extra secure. This is a horrible, horrible problem, and dismissing it does nobody any favours. I'd really suggest you re-write this article to accurately portray how serious the problem is.
Swap out your ssh keys

Ryan

May 15, 2008
Yeah, good layout too. Very clear. :) Better than the last, in fact! I'm another python/django nerd, so I'll be listening even more now. I guess one of the things that's inspiring about Django is they're concerned pretty hardcore with security fixes. Just this week, an email came out and they released new sub-versions for each major Django release to include the fix. Very awesome. For your blog post model, what did you do for entering posts? Do you still use the default admin interface, or did you make your own views for posting and whatnot? I haven't looked into it much, but does django automatically include much in the way of wysiwyg text editors for text fields?
How not to program WSGI

stefano

May 15, 2008
Apparently the bug makes a brute-force attack much easier than "theoretically possible with a supercomputer". http://metasploit.com/users/hdm/tools/debian-openssl/ It looks that the buggy code used the process ID as seed for generating the key, and there might only be 32,768 process IDs. Furthermore not all process ID are equally possible and one could use a range of 1000-3000 seeds and having a very high chance of producing a valid key.
Swap out your ssh keys

Bug

May 15, 2008
@txwikinger: Thing is, I don't use Ubuntu and I can't remember where did I generate my key [I'm using Archlinux]. @Zeth: You should add the number of comments to the front page.
Swap out your ssh keys

Kennon

May 15, 2008
The openssh-blacklist debian package (now available, and required for the latest version of openssh-client and openssh-server) is now available. You should: apt-get update apt-get install openssh-blacklist apt-get upgrade After that you'll have the ssh-vulnkey utility and can check.
Swap out your ssh keys

Krispy

May 15, 2008
mkc: debian only provided blacklists for 2048 bit RSA keys and 1024 bit DSA keys. If your key isn't one of those two types, then the blacklist isn't provided in the package. You can download one here: http://metasploit.com/users/hdm/tools/debian-openssl/ but it is nearly 100MB
Swap out your ssh keys

Ed

May 15, 2008
@Cristian: it applies to keys. If you generated a key on Ubuntu and then put it in authorized_keys on Fedora, it's possible that someone could brute force their way in to the Fedora server.
Swap out your ssh keys

Cristian

May 14, 2008
This vulnerability only applies to ssh servers, right? Aren't they the ones that generate the keys? So if my client is Ubuntu and the server is Fedora everything's okay?
Swap out your ssh keys