[iptables] log all incoming ssh
Harry Putnam
I'll admit I haven't digested the overbearing complex iptables syntax
and admit futher I will *NEVER* learn it from the man page.
Somewhere I need to be able to look at dozens of examples with
explanation of what they do to begin to understand it.
For example, why doesn't this do something simple like log all
incoming ssh connections?
iptables -A INPUT -p tcp -d 22 -j LOG
# iptables -nL --line
Chain INPUT (policy ACCEPT)
num target prot opt source destination
1 LOG tcp -- 0.0.0.0/0 0.0.0.22 LOG flags 0 level 4
Whereas this one does log everthing coming in on tcp
iptables -A INPUT -p tcp -j LOG
# iptables -nL --line
Chain INPUT (policy ACCEPT)
num target prot opt source destination
1 LOG tcp -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4
The first one with destinabion specified and no source specified seems
it should do as planned. All the ingredients are there to cause
logging of incoming ssh connections, yet I get none logged.
Tim Haynes
> iptables -A INPUT -p tcp -d 22 -j LOG
>
> # iptables -nL --line
> Chain INPUT (policy ACCEPT)
> num target prot opt source destination
> 1 LOG tcp -- 0.0.0.0/0 0.0.0.22 LOG flags 0 level 4
^^^^^^^^
Look again. You didn't mean to do that, in all probability.
--dport is your fwend(TM) ;8)
~Tim
--
12:18:57 up 3 days, 2:23, 15 users, load average: 0.01, 0.03, 0.05
pig...@stirfried.vegetable.org.uk |The light of the world keeps shining,
http://piglet.is.dreaming.org |Bright in the primal glow
Ralph Angenendt
> For example, why doesn't this do something simple like log all
> incoming ssh connections?
>
> iptables -A INPUT -p tcp -d 22 -j LOG
>
> # iptables -nL --line
> Chain INPUT (policy ACCEPT)
> num target prot opt source destination
> 1 LOG tcp -- 0.0.0.0/0 0.0.0.22 LOG flags 0 level 4
Well, it logs all incoming tcp packets which go to the host
0.0.0.22.
iptables -A INPUT -p tcp -d any/22 -j LOG
should do what you want.
Ralph
Dave
<rea...@newsguy.com> wrote:
Hi,
grep ssh /var/log/messages
should show all ssh transactions.
regards,
Dave
Michael Steiger
<ihr....@strg-alt-entf.org> wrote:
Ralph,
are you sure?
-d any/22 does not mean any address port 22
He should use --dport 22 instead
Michael
Ralph Angenendt
> On 31 Jul 2001 11:41:19 GMT, Ralph Angenendt <ihr....@strg-alt-entf.org> wrote:
>>
>> iptables -A INPUT -p tcp -d any/22 -j LOG
>>
>>should do what you want.
>
> -d any/22 does not mean any address port 22
>
> He should use --dport 22 instead
Hmmm, still ipfwadm impaired. I skipped on ipchains ...
Ralph
Harry Putnam
> For example, why doesn't this do something simple like log all
> incoming ssh connections?
>
> iptables -A INPUT -p tcp -d 22 -j LOG
>
> # iptables -nL --line
> Chain INPUT (policy ACCEPT)
> num target prot opt source destination
> 1 LOG tcp -- 0.0.0.0/0 0.0.0.22 LOG flags 0 level 4
Tim Haynes <use...@stirfried.vegetable.org.uk> writes:
[...]
> > iptables -A INPUT -p tcp -d 22 -j LOG
> > 1 LOG tcp -- 0.0.0.0/0 0.0.0.22 LOG flags 0 level 4
> Look again. You didn't mean to do that, in all probability.
> --dport is your fwend(TM) ;8)
Oh wow... and those shrinks told me the shock treatment would help!
Ralph Angenendt <ihr....@strg-alt-entf.org> writes:
[...]
> Well, it logs all incoming tcp packets which go to the host
> 0.0.0.22.
I hate it when it does what I tell it to do instead of what I want it
to do. Its kind of like looking at pictures of yourself. They always
look like you...
Michael Steiger <Michael...@gmx.at> writes:
> He should use --dport 22 instead
Thanks posters.
phil
The EASIEST way to get logging for THIS (the one that iptables is running
on) machine would simply be
iptables -A INPUT -p tcp --dport 22 -j LOG
now, since i like to be able to read my log....my line would look something
like this..
iptables -A INPUT -p tcp --dport 22 -j LOG --log-level 0 --log-prefix
"SSH_IN___"
PHIL
Ian Jones
Hash: SHA1
Harry Putnam wrote:
>
> For example, why doesn't this do something simple like log all
> incoming ssh connections?
>
> iptables -A INPUT -p tcp -d 22 -j LOG
I don't think that anyone has yet mentioned that if you only want to see a
log entry when an ssh session starts (rather than logging for every packet
that passes) you would want to use the packet state as a match:
iptables -I INPUT -i eth0 -p tcp --dport ssh -m state --state NEW \
-j LOG --log-prefix "START SSH "
I use `-I' rather than `-A' because I am assuming that you already have a
rule to ACCEPT the ssh connection, and that would end the traversal on the
INPUT chain. I use `-i eth0' because I assume you don't want to see logs of
connections from internal interfaces. I use `ssh' instead of 22 because it
is easier on the eyes :)
-----BEGIN PGP SIGNATURE-----
Comment: Keeping the world safe for geeks.
iD8DBQE7ZzB6wBVKl/Nci0oRAmg6AJwJdKdjkrPlOYzpQoCdg+el/UGLnACeNvet
wRKDOyKSvRFij68MNaCMZZQ=
=SF6B
-----END PGP SIGNATURE-----
Harry Putnam
growning in my poorly informed brain]
Ian Jones <i...@dsl081-056-052.dsl-isp.net> writes:
[...]
> > iptables -A INPUT -p tcp -d 22 -j LOG
>
> I don't think that anyone has yet mentioned that if you only want to see a
> log entry when an ssh session starts (rather than logging for every packet
> that passes) you would want to use the packet state as a match:
>
> iptables -I INPUT -i eth0 -p tcp --dport ssh -m state --state NEW \
> -j LOG --log-prefix "START SSH "
>
> I use `-I' rather than `-A' because I am assuming that you already have a
> rule to ACCEPT the ssh connection, and that would end the traversal on the
> INPUT chain. I use `-i eth0' because I assume you don't want to see logs of
> connections from internal interfaces. I use `ssh' instead of 22 because it
> is easier on the eyes :)
Good deal, thanks. This stuff is starting to make some sense.
Let me pursue this a little farther. But first a brief explanation of
what is being attempted here.
1) I'm behind a hardware firewall already. It is not as configurable
as iptables but offers a much simpler setup and low maintenance.
Logging is not nearly as configurable. I can only log what the
hardware with software setup sees as a threat of some kind.
2) Using iptables inside the firewall to verify for my own satisfaction
what is actually getting through. Sort of a second opinion I
guess. And a way to study certain kinds of traffic. That is, not
as a first line of defense firewall.
3) The hardware firewall (Netgear FR314) routes any ssh connections to
specific internal machine not visible to the internet. One of the
drawbacks is that logging is really only processable when it comes
in email, other wise logs can only be seen immediately by firing up
a browser and connecting to the firewall, then using java to do
business (no telnet or other text based access (bad aspect))
So to cut to the chase here, I wanted to study ssh connections. And
to have the option of knowing immediately who is connecting and from
where. Beyond `who', `w' or other OS info commands. As well as have
processable records of it.
Your guess was a good one, that I don't really wnat to see all the
back and forth traffic. Just the initial connections and possibly the
disconnect.
> I use `-I' rather than `-A' because I am assuming that you already have a
> rule to ACCEPT the ssh connection, and that would end the traversal on the
So is the initial policy of ACCEPT by itself enough of an allow rule
to use the type rules you suggest for logging purposes? At this point
I'm not concerned about blocking anything. That is supposed to have
happened upstream.
> iptables -I INPUT -i eth0 -p tcp --dport ssh -m state --state NEW \
> -j LOG --log-prefix "START SSH "
Can this be extended to any of the common ports by saying `ftp' or
whatever instead of `ssh'?
And can it also be broadended to cover any port just by not specifying
--dport? Not so easy to experiment with to find out really. It is
possible, but might save lots of traffic recording to hear some tips here.
What I'm getting at is, can the same results as that rule gets for ssh
be gotten for all incoming traffic, by leaving off --dport?
I think I'd like to keep a record of all connections on any port from
any source but only the initial connect, not the chit chat. For a
time until I start to see what is really going on. Can the rule you
show above be extended to do that?
Oh yes, I think I'll have to pass on the `--log-prefix' suggestions.
These logs already contain enough crazy looking acronym CAPS, and
other undecipherable guff. Already something like 175 characters
long. I'm tinkering with some shell/awk scripting that will present
me with what I want to see.
Ian Jones
Hash: SHA1
comments inline below...
Harry Putnam wrote:
> [Wind bag alert...
Sometimes you just can't say it one paragraph. Being a windbag myself, I
forgive you.
>> iptables -I INPUT -i eth0 -p tcp --dport ssh -m state --state NEW \
>> -j LOG --log-prefix "START SSH "
> 1) I'm behind a hardware firewall already. It is not as configurable
> as iptables but offers a much simpler setup and low maintenance.
> Logging is not nearly as configurable. I can only log what the
> hardware with software setup sees as a threat of some kind.
I would not depend exclusively on your Netgear. Not that there is anything
wrong with it, but that type of device is designed to offer maximum
useability with a minimum of support calls.
> 2) Using iptables inside the firewall to verify for my own satisfaction
> what is actually getting through. Sort of a second opinion I
> guess. And a way to study certain kinds of traffic. That is, not
> as a first line of defense firewall.
You will get more joy from tcpdump if you want to see what is passing
through.
> So is the initial policy of ACCEPT by itself enough of an allow rule
> to use the type rules you suggest for logging purposes? At this point
> I'm not concerned about blocking anything. That is supposed to have
> happened upstream.
Yes. If you are not dropping it later in the chain, you will just get the
LOG and then the chain policy will eventually be applied.
> Can this be extended to any of the common ports by saying `ftp' or
> whatever instead of `ssh'?
Anything that is defined in the file /etc/services.
> And can it also be broadended to cover any port just by not specifying
> --dport? Not so easy to experiment with to find out really. It is
> possible, but might save lots of traffic recording to hear some tips here.
Sure. You can even lose the -p tcp and just get all NEW connections. Be
careful you don't run out of disk space in /var.
> Oh yes, I think I'll have to pass on the `--log-prefix' suggestions.
> These logs already contain enough crazy looking acronym CAPS, and
> other undecipherable guff. Already something like 175 characters
> long. I'm tinkering with some shell/awk scripting that will present
> me with what I want to see.
Check out a log parser I wrote. It will let you define a template to format
the output any way you want:
http://www.speakeasy.org/~roux/dmn/
-----BEGIN PGP SIGNATURE-----
Comment: Keeping the world safe for geeks.
iD8DBQE7Z4QPwBVKl/Nci0oRAt0gAKDLe2a6dRF5S4JJnhgKGC60d4CIqwCeIOTe
bBXjDnPDEWtfVKn3x9dqI2w=
=IFCb
-----END PGP SIGNATURE-----
Bawb Bitchen
rea...@newsguy.com wrote on 7/31/01 3:00 AM:
>
> I'll admit I haven't digested the overbearing complex iptables syntax and
> admit futher I will *NEVER* learn it from the man page.
>
<not to get off on a rant here but..>
i am so happy to hear someone else say this!!! after messing with iptables
(ipchains, et. al.) for a long time i gave up on a linux for a firewall and
switch to openbsd. makes much more sense. iptables and the reset of them
were written by masochist.
here is how you do it in ipf on openbsd
pass in log quick on ep0 proto tcp from any to x.x.x.x/32 port = 22 flags
S/SA keep state
much cleaner. one basic syntax.
what do you want to do?
do you want to log it?
do you want me to do it without looking at the other rules?
on what interface?
what protocol?
from where?
to where?
what port?
should i keep state?
linux for the desktop (and the games) but openbsd for the firewall. iptables
give me a not to pleasant reminder of the evil config files of sendmail.
<but that is just my opinion. i could be wrong.>
now returning you to your regularly sched. news group.
Dave
<rea...@newsguy.com> wrote:
> So to cut to the chase here, I wanted to study ssh connections. And to
> have the option of knowing immediately who is connecting and from where.
> Beyond `who', `w' or other OS info commands. As well as have
> processable records of it.
>
> Your guess was a good one, that I don't really wnat to see all the back
> and forth traffic. Just the initial connections and possibly the
> disconnect.
>
>
I suggested the following earlier in the thread, but it seems to have been
overlooked (sorry if the wrap is funny).
[root@firewall snort]# grep ssh /var/log/messages
Jul 29 17:49:58 firewall sshd[21497]: Accepted publickey for dave from 192.168.2.1 port 1035 ssh2
Jul 29 19:40:38 firewall sshd[23877]: Received disconnect from 192.168.2.1: 11: Unable to authenticate using any of the configured authentication methods
Jul 29 23:17:59 firewall sshd[27174]: Accepted publickey for dave from 192.168.2.1 port 1058 ssh2
Jul 30 08:50:54 firewall sshd[2221]: Accepted publickey for dave from 192.168.2.1 port 1101 ssh2
Jul 30 11:01:54 firewall sshd[4040]: Accepted publickey for dave from 192.168.2.1 port 1277 ssh2
Jul 30 11:01:54 firewall sshd[4040]: subsystem request for sftp
<snip>
Jul 30 13:23:47 firewall sshd[1422]: Received disconnect from 192.168.2.1: 11: Unable to authenticate using any of the configured authentication methods
Jul 30 13:24:10 firewall sshd[1423]: Failed password for ROOT from 192.168.2.1 port 1036 ssh2
Jul 30 13:24:26 firewall sshd[1423]: input_userauth_request: mismatch: (dave,ssh-connection)!=(root,ssh-connection)
Jul 30 13:24:26 firewall sshd[1423]: Failed password for illegal user root from 192.168.2.1 port 1036 ssh2
Jul 30 13:24:41 firewall sshd[1423]: Failed password for illegal user root from 192.168.2.1 port 1036 ssh2
Jul 30 17:42:38 firewall sshd[6201]: Received disconnect from 192.168.2.1: 2:
Jul 30 17:42:53 firewall sshd[6202]: Received disconnect from 192.168.2.1: 2:
<snip>
If you wanted to automate this into a single logfile, you could run
tail -f /var/log/messages | grep ssh > /var/log/messages/ssh.log &
from your init scripts (perhaps at the end of rc.local).
regards,
Dave
Dave
<postm...@127.0.0.1> wrote:
> tail -f /var/log/messages | grep ssh > /var/log/messages/ssh.log &
oops, should have been:
tail -f /var/log/messages | grep ssh > /var/log/ssh.log &
Tim Haynes
(Warning: off-topicness alert here.)
[snip]
> <not to get off on a rant here but..>
>
> i am so happy to hear someone else say this!!! after messing with
> iptables (ipchains, et. al.) for a long time i gave up on a linux for a
> firewall and switch to openbsd. makes much more sense. iptables and the
> reset of them were written by masochist.
Well, that's as may be, but one user's masochist is another's playmate.... ;)
> here is how you do it in ipf on openbsd
[snip]
> much cleaner. one basic syntax.
I think iptables is one basic syntax, too: commandline with options. Take
away the leading `iptables' call and all the dashes, and you've got ipf's
style, if not exact syntax.
[snip]
> linux for the desktop (and the games)
Woooooah, I thought that concept was dead? <gd&r>
> but openbsd for the firewall. iptables give me a not to pleasant reminder
> of the evil config files of sendmail.
>
> <but that is just my opinion. i could be wrong.>
Opinions can't be wrong, but they can be a little weird. :8)
~Tim
--
Tell me where oh where has summer gone |pig...@stirfried.vegetable.org.uk
It hasn't come this year |http://spodzone.org.uk/
You always cry when swallows fly |
With doubts in search of dreams |