[snip]
> 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.
Well.. we are running two apps actually. One is a custom java app and
the other was running for only a couple of hours (Team Fortress server
for Linux ::grinz::). Ran TF for only a couple of hours and was
surprised to see UDP 9 hit at all.
>
>
> Where you running IPChains or ipfwadm?
Portsentry.conf has a setting for ipfwadm to add any "perceived" attacks
to the deny policy though if I do IPCHAINS -L it shows all policies.
> 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. :-)
Yah.. 2.4 looks good. I heard they switched the firewall software (again).
>
>
> 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?
The java app talks directly to an oracle database (port 1521 I
believe). It requires something called osagent (part of the visibroker
tools I believe). Osagent had trouble going through our NAT firewall so
we moved it outside to run our tests.
>
>
> 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.
I've heard of this. I'll make this change. Thx :-)
>
>
> 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.
Hmmm... ok.... I overreacted then. /me blushes
>
>
> 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.
That's about it actually. I appreciate it
/me goes to the corner now
Thx
Frank
>
>
>> 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
_______________________________________________
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list
