I noted some weirdness:
tcp 0 0 xx.xx.xx.xx:http 141.138.130.37:http SYN_RECV
Variation on earlier
Don't try to use my system to attack another.
I viewed the traffic with p0f and noticed there isn't variation in the
sources now:
95.131.186.32:80 - UNKNOWN [8192:59:1:40:.:.:?:?]
-> xx.xx.xx.xx:80 (link: unspecified)
95.131.186.32:80 - UNKNOWN [8192:59:1:40:.:.:?:?]
-> xx.xx.xx.xx:80 (link: unspecified)
141.138.130.37:80 - UNKNOWN [8192:51:1:40:.:.:?:?]
-> xx.xx.xx.xx:80 (link: unspecified)
141.138.130.37:80 - UNKNOWN [8192:39:1:40:.:.:?:?]
-> xx.xx.xx.xx:80 (link: unspecified)
141.138.130.37:80 - UNKNOWN [8192:39:1:40:.:.:?:?]
-> xx.xx.xx.xx:80 (link: unspecified)
95.131.186.32:80 - UNKNOWN [8192:67:1:40:.:.:?:?]
-> xx.xx.xx.xx:80 (link: unspecified)
95.131.186.32:80 - UNKNOWN [8192:43:1:40:.:.:?:?]
-> xx.xx.xx.xx:80 (link: unspecified)
All trying to make my system take part in an attack on 141.138.130.37
and 95.131.186.32, both part of "William Hill Organization" on Gibraltar.
The rules saying that I want to limit the amount of outgoing tcp syn/ack
packets to one IP are working. Of course the real source of the attack is
some network that does not implement BCP38 source address filtering.