Hi
> -----Original Message-----
>
> : on "12-20-2011" "Dermot Paikkos" writ: (my mother always told me
there is no such word as 'writ')
> as a general rule, size of these reports tends to suggest how
> active,
> system breach attempts, are. typically, 10K was seen as notable,
> lately,
> i'm seeing 40-80K per hour. t`would seem the natives are restless.
Indeed. Although my numbers are slightly down on yesterday.
A total of 4861 sites probed the server
1.22.41.192
1.23.101.84
> : A total of 5711 sites probed the server
> : 1.152.198.116
> : 1.22.185.5
> : 1.23.105.130
> : 1.38.24.232
> : 1.38.25.24
> : 1.39.95.219
> : 1.53.101.185
> : 101.108.239.43
> :
> : I'm not sure what the above probes are.
>
> that, if complete, tells you where the probes initiated. i have a
> vt
> running "lynx" pointed at arin to do arin, ripe, lookups. for
instance:
>
> re: 1.152.198.116
>
> "Network
> NetRange 1.0.0.0 - 1.255.255.255
> CIDR 1.0.0.0/8
> Name APNIC-1
> Handle NET-1-0-0-0-1
> Parent
> Net Type Allocated to APNIC" from 'arin';
>
> "inetnum: 1.128.0.0 - 1.159.255.255
> netname: TELSTRAINTERNET49-AU
> descr: Telstra
> descr: Level 12, 242 Exhibition St
> descr: Melbourne
> descr: VIC 3000
> country: AU" from "apnic".
I've followed your lead here although I haven't used lynx. I found the
providers through ripe and sent an email to abuse/hostmaster with the
log entries.
> : I also have several entries like this:
Today I had 94, all from someone in .cn.
A total of 94 possible successful probes were detected (the following
URLs
contain strings that match one or more of a listing of strings that
indicate a possible exploit):
> the "HTTP Response 200", on the surface of it, is troublesome.
> HOWEVER, the http (apache) logs are a more telling indicator of what
> served
> up.
I have changed the 200 response to a 404. By default (or mistake) all
the not found urls were being served up with a 200 response. I suspect
that might have attracted un-wanted attention and lead the abuser to
suspect we run php, which we don't.
>
>
> : To help secure the server, I installed UFW, enabled and allowed
HTTP,
> : HTTPS and SSH. I then monitored the logs to see what was happening.
> What
> : I am not clear on is what service the log entries below refer to.
> :
> : Dec 20 13:10:35 myserver kernel: [4808284.769172] [UFW BLOCK]
> : IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
> : SRC=194.27.44.2 DST=217.222.0.x LEN=52 TOS=0x00 PREC=0x00 TTL=109
> : ID=10243 DF PROTO=TCP SPT=6565 DPT=80 WINDOW=4320 RES=0x00 ACK FIN
> : URGP=0
>
> "PROTO=TCP SPT=6565 DPT=80"
>
> 'DPT=80' is the "destination port", YOU.
>
> from "/etc/services"
>
> "# service-name port/protocol [aliases ...] [# comment]
> http 80/tcp www www-http # WorldWideWeb
HTTP
> http 80/udp www www-http # HTTP"
>
> so, here we are seeing 'http' processed, however, i am not
> convinced it
> being blocked at all. from your supplied rules, looks like http wide
> open
> ...
>
>
> : Chain ufw-user-input (1 references)
> : pkts bytes target
> : 29164 1620981 ACCEPT tcp dpt:80 /* 'dapp_Apache' */
This is what I thought. This rule, and the one for 443, is pretty clear.
It should not be blocking port 80. So the log message is still a
mystery. As I said, if the site was not available on port 80, I would
have heard about it. The amount of logging ufw is making needs
attention. It's filling my kern, messages and syslog files with it's
output. Back to the man pages.
Thanks,
Dermot.
--
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
