ssh connections getting thru closed port

I host a Linux server (adrift.org.uk) which has an iptables firewall.
The only service ports I have open are 25, 80 and 443, with ports >
1024 open. I have verified this with grc.com.

Looking in my auth.log, I can see numerous attempts to connect via
ssh, like so:

Apr 4 08:33:56 digby sshd[6291]: Illegal user ezsetup from
192.168.1.3
Apr 4 08:33:56 digby sshd[6291]: Failed none for illegal user ezsetup
from 192.168.1.3 port 39497 ssh2
Apr 4 08:33:57 digby sshd[6302]: Illegal user ro from 192.168.1.3
Apr 4 08:33:57 digby sshd[6302]: Failed none for illegal user ro from
192.168.1.3 port 39504 ssh2
Apr 4 08:33:57 digby sshd[6302]: Failed password for illegal user ro
from 192.168.1.3 port 39504 ssh2
Apr 4 08:33:57 digby sshd[6305]: Illegal user rwa from 192.168.1.3
Apr 4 08:33:57 digby sshd[6305]: Failed none for illegal user rwa
from 192.168.1.3 port 39505 ssh2
Apr 4 08:33:57 digby sshd[6305]: Failed password for illegal user rwa
from 192.168.1.3 port 39505 ssh2
Apr 4 08:34:02 digby sshd[6385]: Illegal user stoogr from 192.168.1.3
Apr 4 08:34:02 digby sshd[6385]: Failed none for illegal user stoogr
from 192.168.1.3 port 39551 ssh2
Apr 4 08:34:04 digby sshd[6406]: Illegal user help from 192.168.1.3

192.168.1.3 is my internal address of my server, so it would appear
that whoever is trying to get in is spoofing their IP address. What I
can't understand is how they are managing to make a connection to sshd
when port 22 is closed? Am I missing something fundamental here?

Thanks.

On Mon, 04 Apr 2005 12:11:21 -0700, Campbell mumbled something like this:

> I host a Linux server (adrift.org.uk) which has an iptables firewall. The
> only service ports I have open are 25, 80 and 443, with ports > 1024 open.
> I have verified this with grc.com.
>
> Looking in my auth.log, I can see numerous attempts to connect via ssh,
> like so:
>
> Apr 4 08:33:56 digby sshd[6291]: Illegal user ezsetup from 192.168.1.3
> Apr 4 08:33:56 digby sshd[6291]: Failed none for illegal user ezsetup
> from 192.168.1.3 port 39497 ssh2
> Apr 4 08:33:57 digby sshd[6302]: Illegal user ro from 192.168.1.3 Apr 4
> 08:33:57 digby sshd[6302]: Failed none for illegal user ro from
> 192.168.1.3 port 39504 ssh2
> Apr 4 08:33:57 digby sshd[6302]: Failed password for illegal user ro from
> 192.168.1.3 port 39504 ssh2
> Apr 4 08:33:57 digby sshd[6305]: Illegal user rwa from 192.168.1.3 Apr 4
> 08:33:57 digby sshd[6305]: Failed none for illegal user rwa from
> 192.168.1.3 port 39505 ssh2
> Apr 4 08:33:57 digby sshd[6305]: Failed password for illegal user rwa
> from 192.168.1.3 port 39505 ssh2
> Apr 4 08:34:02 digby sshd[6385]: Illegal user stoogr from 192.168.1.3 Apr
> 4 08:34:02 digby sshd[6385]: Failed none for illegal user stoogr from
> 192.168.1.3 port 39551 ssh2
> Apr 4 08:34:04 digby sshd[6406]: Illegal user help from 192.168.1.3
>
> 192.168.1.3 is my internal address of my server, so it would appear that
> whoever is trying to get in is spoofing their IP address. What I can't
> understand is how they are managing to make a connection to sshd when port
> 22 is closed? Am I missing something fundamental here?

Yes, you should have iptables rules to prevent spoofing. Something along
the lines of:

$IPTABLES -A INPUT -i $EXTERNALIF -d 127.0.0.0/8 -j REJECT
$IPTABLES -A INPUT -i $EXTERNALIF -s $INTERNALNET -j REJECT

HTH
--
Rinso
/\
/ \
/wizz\
~~~~~~~~~~~~

> Apr 4 08:34:04 digby sshd[6406]: Illegal user help from 192.168.1.3
>
> 192.168.1.3 is my internal address of my server, so it would appear
> that whoever is trying to get in is spoofing their IP address. What I
> can't understand is how they are managing to make a connection to sshd
> when port 22 is closed? Am I missing something fundamental here?

Try cat /proc/sys/net/ipv4/conf/all/rp_filter
If enabled (1) this should prevent IP spoofing of this sort, I think!

Let us know what that setting is. I think the only case where you would
leave rp_filter disabled is in the case of a multi-homed connection.

--
Jem Berkes
Software design for Windows and Linux/Unix-like systems
http://www.sysdesign.ca/

Thanks.

/proc/sys/net/ipv4/conf/all/rp*_filter = 0, but
/proc/sys/net/ipv4/conf/eth0/rp_filter = 1 and
/proc/sys/net/ipv4/conf/eth1/rp_filter = 1

I don't know which of these takes precedence?

The firewall I'm using is Monmotha's v2.3.8 from
http://monmotha.mplug.org/firewall/index.php, so I'm wondering why
noone else has come across this problem.

So how is the attacker actually connecting to sshd? Is it actually
going via port 22 because it thinks it's a local connection, or is it
going via a different port?

On Mon, 04 Apr 2005 14:13:13 -0700, google wrote:

> Thanks.
>
> /proc/sys/net/ipv4/conf/all/rp*_filter = 0, but
> /proc/sys/net/ipv4/conf/eth0/rp_filter = 1 and
> /proc/sys/net/ipv4/conf/eth1/rp_filter = 1
>
> I don't know which of these takes precedence?
>
> The firewall I'm using is Monmotha's v2.3.8 from
> http://monmotha.mplug.org/firewall/index.php, so I'm wondering why
> noone else has come across this problem.
>
> So how is the attacker actually connecting to sshd? Is it actually
> going via port 22 because it thinks it's a local connection, or is it
> going via a different port?

Since it appears that you have two Ethernet interfaces, are you
have checked the iptables settings for both of them? I suspect
your check by grc.com has only tested the external interface.
Perhaps the ssh attempts are really coming from 192.168.1.3, from
your internal network.

--
Steve

Campbell wrote:
> I host a Linux server (adrift.org.uk) which has an iptables firewall.
> The only service ports I have open are 25, 80 and 443, with ports >
> 1024 open. I have verified this with grc.com.
> Looking in my auth.log, I can see numerous attempts to connect via
> ssh, like so:
> Apr 4 08:33:56 digby sshd[6291]: Illegal user ezsetup from
> 192.168.1.3
> ... SNIP ...
> Apr 4 08:34:04 digby sshd[6406]: Illegal user help from 192.168.1.3
> 192.168.1.3 is my internal address of my server, so it would appear
> that whoever is trying to get in is spoofing their IP address. What I
> can't understand is how they are managing to make a connection to sshd
> when port 22 is closed? Am I missing something fundamental here?
Given that its SSH which is TCP based, I'd personal summise that:
- This box is dual homed
- The IPTables scripts is filtering the external interface with above
rulebase
- For TCP based spoofing to work the attacker would need to sit inline
traffic flow (to you and back to source) to be able to complete TCP
handshakes etc.. Given that you are getting user attempts, not only has
the 3 way handshake occurred, but also the comms channel is passing SSH
negioitations over protocols and username/passwords. Therefore I would
say this has a low probability of being spoofed.
- Given that your internal interface is initiating the attacks, it is
likely the source of the packets (See above spoofing notes).

I'd check your box for signs of rootkits, as some of those usernames
match to use of a tool like sshf (See
http://www.security.org.sg/gtec/hone...diary=20041102).

Stephen Sentoff <steve30401@hotmail.com> wrote in message news:<pan.2005.04.05.00.55.21.988776@hotmail.com>. ..
>
> > /proc/sys/net/ipv4/conf/all/rp*_filter = 0, but
> > /proc/sys/net/ipv4/conf/eth0/rp_filter = 1 and
> > /proc/sys/net/ipv4/conf/eth1/rp_filter = 1
>
> Since it appears that you have two Ethernet interfaces, are you
> have checked the iptables settings for both of them? I suspect
> your check by grc.com has only tested the external interface.
> Perhaps the ssh attempts are really coming from 192.168.1.3, from
> your internal network.

eth0 is my Internet connection and eth1 is my local network
connection, but it is a home network so I know that no-one is trying
to connect from internally (I'd be very worried if they were directly
on 192.168.1.3 as that would mean they were in my loft!)

I pretty much trust everything on the internal network with all the
tough firewall stuff stopping attacks coming in on the internet
connection.

Campbell wrote:

> eth0 is my Internet connection and eth1 is my local network
> connection, but it is a home network so I know that no-one is trying
> to connect from internally (I'd be very worried if they were directly
> on 192.168.1.3 as that would mean they were in my loft!)
>
> I pretty much trust everything on the internal network with all the
> tough firewall stuff stopping attacks coming in on the internet
> connection.

Perhaps someone on your internal network has gotten infected
by email with trojan software, and the trojan software can
reach out to the Internet to find its commander and take orders.
The fact that 192.168.1.3 is in your loft does not prove that
it is not being used by someone in Russia or Langley to explore
your network.

--
Peter Pearson
To get my email address, substitute:
nowhere -> spamcop, invalid -> net

Rincewind, lun20050404@22:15:23(CEST):
>
> $IPTABLES -A INPUT -i $EXTERNALIF -d 127.0.0.0/8 -j REJECT
> $IPTABLES -A INPUT -i $EXTERNALIF -s $INTERNALNET -j REJECT

Aside of the already mentioned rp_filter, this is better stated as:

$IPTABLES -A INPUT -P DROP
$IPTABLES -A INPUT -i $EXTIF -d $EXTIP -j ACCEPT

Always reject everything and allow what's explicitly allowed.


--
David Serrano

> Try cat /proc/sys/net/ipv4/conf/all/rp_filter
> If enabled (1) this should prevent IP spoofing of this sort, I think!
>

Well, it's been almost a week now, and I've not had any login attempts
so hopefully this has been what fixed it. I'll repost if anything
changes, but looking good so far...! Thanks.