# ip spoofing

## nein

Hi,

 I have two computers A,B where B grants access only to A by ssh and A grants access only to B by ssh. All the other ports are filtered or closed.

I am a bit worried because some computers on the subnet where B is have been hacked. I have started considering the posibility that an attacker could change the IP adress of another computer C to fake the IP address of B (the hackers have been playing with virtual net interfaces). These situations are somehow controled but it might take 24 hours before an action is taken (I am not the net admin) and that could be to late.

How can I secure the ssh access to be sure about the idendity of B at computer A ?

Thanks in advance.

----------

## smart

I never set up a trust relationship between two hosts as i'm always doing a login. But i'd expect ssh to use the hostkeys to verify the host identity, so i'd in this case (after verification that identity check takes place) not see a problem with spoofed ips.

too lazy to google it up for myself now  :Smile: 

let me know though, would be interested  :Smile: 

----------

## nein

There is no trust relationship. I have to type the login name and password. It is at the firewall level where the ip restriction is.

The problem is that the B computer has an old version of ssh and it is probably possible to make it fail and gain access to that computer. I just suppose it must suffer from several vulnerabilities due to its age.

I know I should upgrade it but I just wanted a fast temporary solution.

----------

## smart

The no worries per se, since when you try to login to your server, you will automatically get informed if the identity of the server has changed.

----------

## nein

But how can the server know that the login request comes from my computer and not another one?.  The server can be attacked because port 22 is "open" to my ip adrdress or to someone that is faking my ip address.

Thanks for your replies.

----------

## Casshan

The nature of IPs means that if someone spoofs a ip it will not work (well).

Example:

Computer A is 192.168.0.2

Computer B is 192.168.0.1

Computer C is 192.168.0.100 (this is our hacker)

Rule: A only accepts IP of B

Hacker spoofs IP of B to get into A (by spoofing he replaces his Ip with 192.168.0.1 in all packets that are generated by his computer).

He sends the "I want to connect packet"

Computer A see this and looks at IP and sees that it is ok so he tell 192.168.0.1 that he can connect.

Because the hackers IP is 192.168.0.100 he will never see this packet (unless he is packet sniffing on the same subnet).

Computer B gets the packets thinks I'm not trying to connect and discards the packet.

Conclusion:  The hacker could do a one way converstion, but he would have to guess what the responses would be bacause his computer would never get the return/info packets from Computer A, (There might be a problem with TCP sequence numbers too, not sure on this one).

IP spoofing is good for only one way stuff, like DOS attacks.

----------

## chimy

@Casshan: exactly!

+ its ssh... hopefully you have asynchronous encryption. if yes computer c will never be able to read the content of the package.

----------

## nein

How do I know if I have "asynchronous encryption" ?

 I had a look at the sshd config file and did not find anything like "asynchronous"

Thanks everybody for your help.

----------

## smart

@Casshan & @chimy ..... BULLSHIT

i'll explain in next post, just had to get that out first before anyone else  :Smile: 

----------

## smart

First, i'll go back to the original question, 'cause that's what this thread is about.

The original question is, how to make ssh safe against spoofing the servers IP. As stated before, you don't, since it's safe per se. This is because the server has an identity. The first time you connect to an ssh server, information about this identity is transferred to your computer and safed.

Now in case somebody spoofs the server, he will be asked for his identity by the client. Since he cannot give the same as the original server, the verification will fail and the ssh client will let you know that the possible case is that somebody spoofs the server IP.

Client user will have to act upon this to either accept the new identity or stop it.

----------

## nein

I know that if the server gets spoofed I will notice. The ssh client will complain about the server. 

My problem is the inverse one. The unsecure network is on client side. So what happens if the client gets spoofed ? Will the server notice that the client is a fake one ?

My server only allows one client to connect to it by filtering ip addresses using a firewall and I want to be sure about the client.

----------

## smart

Now to spoofing.

 *Quote:*   

> 
> 
> The nature of IPs means that if someone spoofs a ip it will not work (well).
> 
> 

 

That depends, it can work very well.

 *Quote:*   

> 
> 
> Rule: A only accepts IP of B 
> 
> 

 

Not of interest. We want to spoof the IP, we know that. This may be because a firewall doesn't want us otherwise, but more often, spoofing is done to receive data the spoofer doesn't normally receive. This rule is unrelated to spoofing.

 *Quote:*   

> 
> 
> Hacker spoofs IP of B to get into A (by spoofing he replaces his Ip with 192.168.0.1 in all packets that are generated by his computer).
> 
> 

 

As above, main point normally is receiving data. Not to get into some machine. This would be possible though e.g. is you use rsh tools silly for example by setting trusted hosts.

Furthermore, you will normally not do the task of mangling packets, but simply set your machines IP to the targeted IP. Simple as that. Now you already can generate packets and you can send as you described. As you described as well, this is not much fun and not sooo much useful yet except maybe for stupid DOS.

Next you do 2 steps at the same time. You spoil ARP and you DOS the original owner of IP. That is, you advertise your MAC as the owner of the IP and hinder real owner to do the same. Thus, normally the networking equipment will accept you as the real owner of the IP. Now you receive everything the original owner of the IP would.

Going further, you would possibly act as man in the middle, knowing the original owners MAC address.

Note: faking sender IP does not equal spoofing.Last edited by smart on Tue Jun 08, 2004 12:05 pm; edited 1 time in total

----------

## smart

A spoofing client is a different topic and is not what you described in your original post. So we go back  :Smile: 

Now to understand better, what are you wanting to avoid really. Say your client is a martian. If he wants to log in he needs to provide his credentials. Now you receive the credentials of grandma, then you know grandma is on Mars.

As long as grandma recognises that she uses her own Laptop this should be no problem. If grandma uses any computer that just sits there, that might, but as far as i understood, i think this is not your problem. So what danger you look at ?

----------

## smart

Before we forget, asynchronous encryption sounds nice, but i guess asymmetric is what is meant. This is always used for the negotiating session keys/login. Out of the head i'd say symmetric encryption is used for the session, but i'm not sure.... in any case, it doesn't matter at all to the topic.

----------

## nein

Smart, I did not quiete understant your reply (grandma & martians) but I will explain my problem with more detail.

Lets supose my server using a firewall that only allows computer A (192.168.0.33) to access port 22. Let C be a computer on the same network as A which spoofs its ip:

- The firewall will think that C is A and will let it access port 22.

The question is, will my server know that C is spoofing the ip address of A ? does it previously store any information about A to later be sure about who is the client?

----------

## smart

Back to the original post based on client side issue:

 *Quote:*   

> 
> 
> I am a bit worried because some computers on the subnet where B is have been hacked.
> 
> 

 

THIS would definitly be a problem. And the sad truth is, it means you are fucked. Nothing to do about it in the first place than to MAKE SURE YOUR LOGIN MACHINES ARE SANE. If the login machines are compromised that's it, you're done. Keys might be copied, passwords keylogged, machine identity stolen and root out of hand. What else can you loose ?

None of your users identities are safe and there's no alternative to recreating an identity for all users that used a compromised system to log in.

----------

## smart

Oops, we mix up times between questions and replies  :Smile: ).

You may take the firewall out of the equation here. A, it doesn't matter, B, it cannot help either. What counts is what ssh daemon does.

If the hacker just uses his own equipment, he can try to login to your server. If he uses his own credentials and they are valid, that doesn't make an issue except that the original owner of the IP has a problem  :Smile:  The user, though using his laptop, is a valid user that didn't gain any more roights on your system than he had before.

If the hacker uses his laptop to try and break other accounts, he faces the same effort as he would using one of your normal clients. EDIT: except maybe he brings better tools on his laptop - but if there was a tool to break ssh, that would cry out for a bugfix of ssh. In standard terms, he doesn't know the password. Getting to know the password in ssh terms is a bit of a task as long as there is no bug in the software  :Smile: , that's about updating, different topic.

The problem only arises, when he finds a person stupid enough to use his laptop to login to your server. You can't really fight that technically. You'll have to solve that physically by beating up that user  :Smile: Last edited by smart on Tue Jun 08, 2004 12:33 pm; edited 1 time in total

----------

## nein

As I mentioned in some of my previous posts  the login machine is only one and it is safe (is does not allow any other machines access it, except the server).

----------

## smart

Then per se, you hsould be allright, no matter if spoofing takes place or not. I Will have a look if it's possible to restrict clients by machine identitty, one would think that should be possible.

Separate from ssh, you might (as long as you are in the same subnet as you rclients) as an extra hurdle use /etc/ethers (man ethers) to bind IPs to MACs. That will require a smarter spoofer, not meaning that would really be a safety, since MACs can be spoofed as well, easy, but extra hurdle.

Planning to come back on the client identity question...

----------

## nein

Client machine identity is the point!!! The question would be if it is possible to check it  or even if ssh uses it by default.

Im my case the spoofing part is only relevant because it is the only way to bypass the firewall. But as you mentioned we better leave the firewall and spoofing out.

Finally, the server and the client are not on the same network

And about breaking sshd, are you sure there are no buffer overflows or similar for old versions ? The server has an at least 3 years old openssh.

Thanks for your time smart

----------

## smart

Use of client identity as restriction per default ? No. Normally this is not necessary, and it owuld mean that in standard installation no login is possible at all since no client is registered.

I cannot count up what kind of problems are in sshd from 3 years ago, but you should certainly keep up with security related updates. Since there was one not so far in the past you are hereby suggested to update your ssh installation  :Smile: 

----------

## nein

I already suspected an upgrade was mandatory but hoped there was another option. This will probably mean a complete system installation because I doubt there will be any updates for a Suse 7.0 and triying to install suse 9.0 packages will lead to a rpm hell

At least my gentoo client is safe and updated   :Very Happy:  Good thing is that the server will become gentoo and will therefore have easy update possibilities. 

Thanks everybody for your help

----------

## smart

There is an "AllowHosts" and the possiblity to use "AllowUsers" beefed up with host restrictions. But as of yet i found nothing convincing that this would go beyound a hostname/IP verification, but also nothing that would state it would not use machine identity... if somebody could clarify on that... and/or point to how it can be made do so... still looking for some more, too.

----------

## saccory

AFAIK there's no mechanism to restrict logins based on a client id (other than the ip address) in ssh.

And just for the record: I don't think it would be that usefull b/c if ssh is exploiteable the exploit can apply before all such checks or even exploit such check.

I think the bottom line is: if you have a daemon listen on a (semi-) public interface, keep it up-to-date.

And btw. the lack of support from other distros for old editions is one of the reasons I'm a happy gentoower.

Btw. have you checked your logs?

----------

## davidblewett

I think what the OP is wanting to know is how secure SSH is. In order to be able to login, the client must present some form of credentials:

1. Host-based (not recommended, and vulnerable to the attacks described)

2. Password-based (better, but not ideal)

3. Public-key based (what SSH v2 was built for)

The best way is public-key. This means the client presents their user id. The ssh daemon then looks up that user's list of authorized keys. It starts at the top of the list, encrypting a packet with each key. If the client can successfully decrypt that packet and send the contents back, it is allowed access to the server. 

In order to do this, the client must have the private key match to the public key that encrypted the packet. This is where the strength of the method lies. If the key was created without a passphrase, whoever can get a copy of the private key can use it to login to the daemon. If it was created with a passphrase, the client must type it in every time an authentication request for that key is made. There are sophisticated methods of minimizing this inconvenience (sshagent, and keychain written by Gentoo's founder Daniel Robbins). 

If the client is trying to break in and has the private key but not the passphrase, the security of the account is only as good as the strength of the passphrase. It would be MUCH easier to try to brute force the passphrase than try to brute force the actual key. Mathematicians have been trying to undo what public key encryption does for centuries, without success.  

While not 100% sure, I would imagine that it would be very unlikely that there is an exploitable weakness in the authentication phase even for such an old version of the daemon. It still should be updated, though.

----------

## saccory

You shouldn't be that sure. E.g  http://www.suse.com/de/security/2003_038_openssh.html and of course http://www.suse.de/de/security/adv004_ssh.html

----------

## davidblewett

 *nein wrote:*   

> 
> 
> And about breaking sshd, are you sure there are no buffer overflows or similar for old versions ? The server has an at least 3 years old openssh.
> 
> 

 

Since we're not sure what version is in use, it would be hard to advise. One of the links you mentioned was for the ssh package, not openssh. This link: http://www.openssh.com/txt/buffer.adv provides a patch to fix it for openssh versions less than 3.6.1. On that page, they say it is uncertain if the vulnerability is even exploitable. Nevertheless, it is very prudent to keep such a vital door to the system as up to date as possible.

----------

## smart

david...

the initiator of this thread has asked for a possiblity to verify and only allow specific client systems to be able to succesfully connect, as a second measure to restrict access, besides verifying user credentals. This is a valid request and is not really related to which of the user identification schemes to choose from.

since the security of the login procedure relies on the security of the client, too, this is not a silly thing to ask for, though maybe the conditions under which it is effective are very rare.

Nonetheless, there is the topic.

----------

## barlad

To answer one of your concern, if you use a ssh version that can be exploited (buffer overflows or whatever else) then your box can be compromised. 

The attacker may want to use arp cache poisoning + ip spoofing technics to bypass the firewall (if your firewall only allows one ip) then exploit the vulnerability in sshd.

----------

## smart

we were at that stage on page 1.

the task is to verify client identity.

----------

## think4urs11

Hi!

These could be of interest

Host based authentication

GSI-enabled SSH

T.

----------

## barbar

To answer the initial question: *nein wrote:*   

> 
> 
> How can I secure the ssh access to be sure about the idendity of B at computer A ?
> 
> 

 

Use key authentication and make sure to use ssh2. ssh1 connections can be sniffed with tools like ettercap.

----------

## davidblewett

My point was that ssh is designed to be an extremely reliable means to positively identify users and secure communications. I guess there is no harm in being paranoid, but I think everything else is redundant. It might add a small bit of security through obscurity, but the added complexity makes it harder to maintain and more prone to error. I think it can also lead to a false sense of security, as the posts concerning the ease of IP spoofing prove. 

GSI seems to be a mechanism to have a large central authentication system, which would be good for a university or corporation but hardly seems warranted in this situation. Host based authentication is *not* recommended, as it is vulnerable to all the attacks suggested so far.

----------

## smart

 *Quote:*   

> 
> 
> I guess there is no harm in being paranoid, but I think everything else is redundant.
> 
> 

 

It is not redundant. As you stated yourself, what is done per se is verification of user. This is about adding verification of client machine used to login.

 *Quote:*   

> 
> 
> It might add a small bit of security through obscurity,
> 
> 

 

so you succeeded in learning that such is a bad thing, but you failed to understand or admit that in principle we are trying to do sth. very simple. We do not only want the client to verify the identity of the server (as happens to alert the user when the machinekey changes), we simply try to do the same thing the other way 'round, leaving the server to be able to drop connections for clients whose machinekeys do not match what is stored on the server. Nothing new really, nothing complicated.

 *Quote:*   

> 
> 
> but the added complexity makes it harder to maintain and more prone to error.
> 
> 

 

Harder to maintain yes, since you need to copy the allowed public keys to the server, more error prone not really, only if you didn't get what it is about.

 *Quote:*   

> 
> 
> I think it can also lead to a false sense of security, as the posts concerning the ease of IP spoofing prove.
> 
> 

 

Exactly the opposite. This is actually the sense of the game. We want to stop ip spoofing from being successful.

 *Quote:*   

> 
> 
> Host based authentication is *not* recommended, as it is vulnerable to all the attacks suggested so far.
> 
> 

 

Yes, host based authentication is not what we recommend nor really look at, but as a side effect, it could be made more safe using what we are looking for.

Hope this finally succeeds in defining the topic. Seems i'm really bad at such.

----------

