On Tue, Feb 13, 2001 at 09:59:13AM -0700, Frank Carreiro wrote:
> I'm running portsentry on a test application server which is outside our
> firewall (we had no choice.. our custom app needed this to work properly).
> I have it setup to automatically add any system that portscan's us into
> our IPCHAINS deny policy. I have done a whois and contacted the admin
> who "claims" they never port scanned us (I don't believe him of
> course). This may have been stupid but as he is the network admin of
> his company I gave him the IP address of the server which was
> portscanned. Attached is the part in our messages log I am concerned about.
> Anyway... I'm bringing the machine down today anyway. We've completed
> the work it was intended to do so it's a moot point. Still for
> educational purposes I was hoping someone could confirm.
Well, then, for educational purposes...
Does not look like a port scan to me.
You triggered on a single UDP port event? I'm not sure what the
tcp even stuff was to port 27015, but it looks like a on session packet
with an active connection. You don't mention what the system might have
been doing at the time. A single packet to the discard service could
be something "normal" for some custom apps if your system was already
communicating with the other system. A tcp connection between ports
3205 and 27015 looks like some sort of allocatable data connection
with allocatable ports on either end.
Where you running IPChains or ipfwadm? The logs look like
IPChains but you are using the ipfwadm command. There is a chain name
in the message and it just happens to be the name of the inp chain used
by some of the backward compatibility scripts to make IPChains look sort
of like ipfwadm (it creats an inp chain and links it to the input chain).
If you are using IPChains, you are long past time to get off the crutch
of the compatibility scripts and start running IPChains natively. Just
in time to start worrying about the change to Netfilter. :-)
You said this is a custom app that has to run outside of the
firewall. Then you put a firewall on it (portsentry + ipfwadm/IPChains).
The fact that this app requires that it be outside of a firewall should
have been a clue that "strange things might happen" when it interacts
with a firewall like ipfwadm or something like portsentry. Why did this
app require that it be outside of your firewall?
1) Do not trigger firewall reconfiguration on UDP scans. These can
be spoofed to create denial of service attacks against you or to do more
amusing things. If someone thought you were running portsentry and shuting
down your firewall based on UDP they could do real amusing things by spoofing
packets at you as if they came from all the root name servers. :-) Just
deny UDP ports you are not using.
2) Do not trigger firewall reconfiguration based on Stealth
scans (see #1 above).
3) One packet, a port scan does not make. The fact that you had
so LITTLE traffic (that you showed us) really indicates that this was
not a port scan. If it had been a UDP services port scan you should
have seen a flood of them. I would have also expected to see some
serious attempts to contact well known tcp services and that's not
in the log segment you posted either.
One UDP packet to port 9 and a couple of retries on what looks to
be an estabished socket simply does NOT look like a port scan unless there
was a LOT more that you didn't post.
> Greatly Appreciated.
> Frank.
> Feb 12 00:54:17 testapp_001 portsentry[1883]: attackalert: UDP scan from host:
>djinn-open.gene.com/192.12.78.2 to UDP port: 9
> Feb 12 00:54:17 testapp_001 portsentry[1883]: attackalert: Host 192.12.78.2 has been
>blocked via wrappers with string: "ALL: 192.12.78.2"
> Feb 12 00:54:18 testapp_001 portsentry[1883]: attackalert: Host 192.12.78.2 has been
>blocked via dropped route using command: "/sbin/ipfwadm -I -i deny -S 192.12.78.2 -o"
> Feb 12 00:54:18 testapp_001 kernel: Packet log: inp DENY eth0 PROTO=17
>192.12.78.2:3205 166.70.202.30:27015 L=40 S=0x00 I=43300 F=0x0000 T=17 (#1)
> Feb 12 00:54:20 testapp_001 kernel: Packet log: inp DENY eth0 PROTO=17
>192.12.78.2:3205 166.70.202.30:27015 L=40 S=0x00 I=44870 F=0x0000 T=17 (#1)
> Feb 12 00:54:22 testapp_001 kernel: Packet log: inp DENY eth0 PROTO=17
>192.12.78.2:3205 166.70.202.30:27015 L=40 S=0x00 I=45274 F=0x0000 T=17 (#1)
> Feb 12 00:54:24 testapp_001 kernel: Packet log: inp DENY eth0 PROTO=17
>192.12.78.2:3205 166.70.202.30:27015 L=40 S=0x00 I=45647 F=0x0000 T=17 (#1)
Mike
--
Michael H. Warfield | (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
_______________________________________________
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list
