IPfilter question

[John Henrikson]

Hi,
I wondered if anyone could tell me how to write a quick rule to block a specific IP address from connecting to my server, which doesn't block any other connections? I tried:
block in quick from 200.27.182.114 to any
added to the example1 ipf.conf, but a hacker there still seems to get through.. so I guess there must be another rule there letting it through?
thanks
John Henrikson

[Steven E. Protter]

You need to look at the /var/adm/syslog/syslog.log carefully to make sure your hacker is coming in in from the ip you think the hacker is coming in on.

Here are some possible helpful entries:

block in proto tcp from 200.27.182.114 to any port = 22

That will block ssh access. I need this to block script kiddies.

block in proto tcp from 200.27.182.114 to any

That or some variation of it should stop your hacker on ALL tcp ports.

SEP

[Jannik]

http://www.obfuscation.org/ipf/ipf-howto.txt

go to 2.6 in the howto.

Best Regards.

[Biswajit Tripathy]

If you are sure that the hacker is coming in from
200.27.182.114, then the rule you configured
should be sufficient. Are you sure the rule is
configured properly? To test this, run the following
command :

# ipfstat -ioh

If the rule is configured properly, the above
command should print it out. Also, watchout for a
number at the beginning of each rule in the above
output. This should tell you howmany connections
have been blocked by the rule. You should see
a nonzero positive number if indeed someone is
coming from that IP address.

I would suggest that you log all the incoming traffic
and see you if have any entry for IP addresses that
you can block. Use following rules:

block in log quick from 200.27.182.114 to any
pass in log from any to any

Finally, you have to think about the whole security
policy and configure your IPFilter. If you are not
providing any service or provide only few services
to machines outside your own network, then
you might want to block everything else and
selectively open those ports. Let me know if you
any help configuring IPFilter.

One more thing. You are better off looking at the
HP IPFilter documentation at
http://www.docs.hp.com/en/B9901-90021/index.html
rather than going to public domain site as HP's
IPFilter has significant new features available.

- Biswajit

[John Henrikson]

Here is the output from my ipfstat:
# ipfstat -ioh
0 pass out quick on lo0 from any to any
0 block in log quick from any to any with short
0 block in log quick from 200.27.182.114/32 to any
0 block in proto tcp from 200.27.182.114/32 to any port = 22
0 pass in quick on lo0 from any to any

despite this, the hacker at 200.27.182.114 tried to get in again last night.. Here's a few lines from the syslog:
Jan 13 14:57:05 pro sshd[12843]: Failed password for illegal user john from 200.27.182.114 port 21991 ssh2

Jan 13 14:57:08 pro sshd[12845]: Failed password for root from 200.27.182.114 port 21793 ssh2

Jan 13 14:57:09 pro sshd[12847]: Failed password for root from 200.27.182.114 port 21902 ssh2

Jan 13 14:57:12 pro sshd[12849]: Failed password for root from 200.27.182.114 port 21787 ssh2

Any ideas what I'm doing wrong?
many thanks for all your help, points coming.

[Biswajit Tripathy]

Though your rules are not perfect (I will explain it
later), they should block the connection you want
to block. Since all the rules have zero hits, I don't
think your IPFilter is working fine. Post the following
outputs:

- Post the name (i.e lan0) and IP address of the
interface that's passing the hacker traffic.
- Go to /etc/rc.log and post the outputs of
/sbin/rc2.d/S130pfilboot and
/sbin/rc2.d/S131ipfboot startup scripts.

Run following commands and post the output :
1) $ ndd pfil qif_status
2) $ ipf -V
3) $ ipfstat

Now about your rules:

0 pass out quick on lo0 from any to any
0 block in log quick from any to any with short
0 block in log quick from 200.27.182.114/32 to any
0 block in proto tcp from 200.27.182.114/32 to any port = 22
0 pass in quick on lo0 from any to any

See that your 3rd rule blocks all traffic from
200.27.182.114 with a quick keyword; so your 4th
rule is unnecessary and never hit. Your 1st and last
rules filter on loopback interface and that's
unnecessary as IPFilter isn't effective on loopback
traffic (except under some particular onfigurations).

I will suggest alternate rules, but first send me the
above output.

- Biswajit

[John Henrikson]

I'm a bit hesitant to post the actual ip address.. its on lan0..
Here's the output from rc.log:
Configuring PFIL
Output from "/sbin/rc2.d/S130pfilboot start":
----------------------------

Starting IPFilter
Output from "/sbin/rc2.d/S131ipfboot start":
----------------------------
Set 0 now inactive
0 entries flushed from NAT table
0 entries flushed from NAT list

but when the machine was last booted there was no ipf.conf file, I have run ipfboot start several times since then.

ndd pfil qif_status
ifname ill q OTHERQ num sap hl len nr nw bad copy drop notip nodata notdata
QIF2 0 455e4c00 455e4d28 2 0 0 0 0 0 0 0 0 0 0 0
lan1 433da600 433d9c00 433d9d28 2 800 14 0 1609549 2345645 0 1570629 0 0 0 692
QIF1 0 433d9400 433d9528 1 806 0 0 1467 0 0 0 0 0 0 0
lan0 40d56800 433db800 433db928 1 800 14 0 3855400 6841719 0 6157740 0 0 0 1318
QIF0 0 433d9000 433d9128 0 806 0 0 1551770 0 0 0 0 0 0 0

ipf -V
ipf: HP IP Filter: v3.5alpha5 (A.03.05.10.04) (400)
Kernel: HP IP Filter: v3.5alpha5 (A.03.05.10.04)
Running: yes
Log Flags: 0 = none set
Default: pass all, Logging: available
Active list: 1
# ipfstat
dropped packets: in 0 out 0
non-data packets: in 0 out 0
no-data packets: in 0 out 0
non-ip packets: in 0 out 0
bad packets: in 0 out 0
copied messages: in 0 out 0
input packets: blocked 0 passed 862667 nomatch 487080 counted 0 short 0
output packets: blocked 0 passed 1253442 nomatch 491248 counted 0 short 0
input packets logged: blocked 0 passed 0
output packets logged: blocked 0 passed 0
packets logged: input 0 output 0
log failures: input 0 output 0
fragment state(in): kept 0 lost 0
fragment state(out): kept 0 lost 0
packet state(in): kept 0 lost 0
packet state(out): kept 0 lost 0
TCP connections: in 0 out 0
ICMP replies: 0 TCP RSTs sent: 0
Invalid source(in): 0
Result cache hits(in): 375587 (out): 762194
IN Pullups succeeded: 0 failed: 0
OUT Pullups succeeded: 0 failed: 0
Fastroute successes: 0 failures: 0
TCP cksum fails(in): 0 (out): 0
Packet log flags set: (0)
none


let me know if you see something in this that is preventing the rules from being applied.
My sincere thanks for your help!!!
John Henrikson

[Biswajit Tripathy]

John,

> I'm a bit hesitant to post the actual ip address..
> its on lan0..

I should have been more clear.. I just need "lan0".

> Here's the output from rc.log:

Looks perfect. No problem while loading DLKM
modules.

> ndd pfil qif_status
> ifname ill q OTHERQ num sap hl len nr nw bad copy drop notip nodata notdata
> QIF2 0 455e4c00 455e4d28 2 0 0 0 0 0 0 0 0 0 0 0
> lan1 433da600 433d9c00 433d9d28 2 800 14 0 1609549 2345645 0 1570629 0 0 0 692
> QIF1 0 433d9400 433d9528 1 806 0 0 1467 0 0 0 0 0 0 0
> lan0 40d56800 433db800 433db928 1 800 14 0 3855400 6841719 0 6157740 0 0 0 1318

No problem here.. Above "lan0" entry shows that
IPFilter is active on this interface. "ipf -V" shows
that IPFilter on your system is the latest release.

> # ipfstat
> .. ..
> input packets: blocked 0 passed 862667 nomatch 487080 counted 0 short 0
> output packets: blocked 0 passed 1253442 nomatch 491248 counted 0 short 0
> ....

So no packets blocked here.

> let me know if you see something in this that is preventing the rules from
> being applied.

Let me see if I understand this correctly. Your rules
are not loaded immediately after boot though they
are at /etc/opt/ipf/ipf.conf. Correct? What happens
if, after the boot, you manually load the rules by
"ipf -f /etc/opt/ipf/ipf.conf" command? Is then the
hacker blocked? If yes, then just check if
IPF_CONFDIR and IPF_CONF parameters are set
to /etc/opt/ipf and ${IPF_CONFDIR}/ipf.conf
respectively in file /etc/rc.config.d/ipfconf.

Also, use the following rules:

block in log quick from any to any with short
block in log quick from 200.27.182.114 to any
pass in all
pass out all

Let me know how it goes?

- Biswajit

[John Henrikson]

Thanks..
I meant that the rules weren't loaded after the *last* system boot, because the last boot was when I installed ipfilter.
I'll let you know how it goes today.. my thanks again for all your help.
John H.

[John Henrikson]

hacker didn't try to come in last night, I'm going to keep watching it but I think its working so far..
thanks again for your help everyone.
John H.

[Biswajit Tripathy]

One way to confirm would be to add another rule
exactly similar to the one you added to block the
hacker; but this time replace the hacker IP address
with the IP address of one of your machine. Then
try to login from that machine and see if the login
attempt is blocked. Once you confirm this, remove the
newly added rule.

BTW, this "hacker" guy does not seem much of a
hacker to me, if (s)he has to keep trying the root
passwd knowing (?) fully well that it will be logged in
one of the system log file :-)

- Biswajit

[Biswajit Tripathy]

Hi John,

I would really appreciate if you could let us know about
status of this problem. I did try to replicate your
problem on my machines, but couldn't. Are you still
seeing the problem?

- Biswajit
HP-UX IPFilter team
Hewlett Packard Company

[John Henrikson]

I did test the filter by adding an IP address of my own machine - it blocked the address as expected. So while I still have new addresses trying to hit the machien, the filter seems to be working as expected.
My thanks for your help.
John Henrikson

[Steven E. Protter]

Your attacking may be doing something that was tried against me, using someone elses IP address or appearing to do so.

It is kind of a spoof that takes advantages of unused IP addresses.

I recall bringing up a server after maintenance and being informed its primary IP address was already assigned.

For a few seconds I was able to traceroute that IP outside of my ISP's network. It was actually some kind of IP address slight of hand.

If however you implement my monbad protocol, the attacks will eventually be stopped.

SEP

[John Henrikson]

Could you elaborate a little on this mombad protocol?
Thanks!