[Firehol-support] Apparent bypass of firewall by ssh login probes

[Whit Blauvelt]

Hi Costa,

Thanks for responding.

> Are you sure these logs are not coming from another host?

Absolutely.

> You can verify that no one has connected to your machine, by running:
> 
> conntrack -L | grep dport=22

Well, now that I've installed conntrack as a utility I can.

> You have to be on top of it when it happens to see anything.

Not likely to be watching, it's a few times a day, at random times - and
that sort of password try is a split-second event.

> You can also do this in firehol.conf (for firehol v3)
> 
> server ssh accept connlog "SSH ACCEPTED"
> 
> This will log all ssh sessions accepted by your firewall.

Is that line separate from other ssh lines, such as:

server ssh accept src 12.34.56.68

or is connlog "SSH ACCEPTED" something to add to each such line? 

If the latter, I'll have to work out the equivalent for how I'm using ipset,
since I've got that up top of my firehol.conf (inherited from before FireHOL
had its own ways for ipset):

iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m set --match-set Client_SFTP src -j ACCEPT

> My bet is that pam_unix(cron:session) is the key here.
> You run something via cron that triggers this.

I don't think so. Those cron statements in auth.log are standard for Ubuntu.
I've got nothing in /etc/cron.d on this system, nothing in /etc/crontab,
nothing in /var/spool/cron/crontabs, and just standard Ubuntu stuff in
/etc/cron.daily and /etc/cron.weekly. How would something local in cron
attempt a login as a remote IP with an unreal timestamp anyway? 

I suppose an alternate explanation is that these probes actually happened at
the date and time recorded, but somehow took months to get to the log. Can't
picture how that would happen though.

Whit