Carlos E. R. wrote: > > The Wednesday 2007-04-25 at 10:29 +0100, G.T.Smith wrote: > > > Disabling ftp will solve first cause... but there is something of more > > concern here... > > > Occasionally I need to enable external ssh access. When I enable > > external ssh access, I usually get ssh scan attacks. They do not > > normally make a heavy impact on network or server load.. > > There is a new rule in the susefirewall2 script to handle repeated > attempts; I mentioned it the other day. Before that we had to do it by > hand. > > > What I do not > > get is the subsequent high level of DNS error responses if an address > > not resolvable. This may be because the way my DNS setup is configured, > > or I am just lucky. The extra traffic (1 DNS resolution request seems > > to have generated 14 responses) and the associated overheads is > > effectively a DoS attack, but for this effect to be experienced either > > the settings of the DNS servers queried or the DNS settings of the > > target server are not quit right . This could cause problems not just in > > this scan attack but for anything that needs to resolve an address and > > the address is not resolvable (sending a raft of mail from an > > unresolvable or spoofed address could have a similar effect). That is > > worrying... > > But this is not the fault of the atacked DNS. The first dns error message > is this: > > Apr 22 11:14:55 bonza named[5250]: unexpected RCODE (SERVFAIL) > resolving '110.241.101.216.in-addr.arpa/PTR/IN': 66.76.2.130#53 > > If you try yourself that IP, you will get an error: > > [EMAIL PROTECTED]:~> host 216.101.241.110 > Host 110.241.101.216.in-addr.arpa not found: 2(SERVFAIL) > > > And if I look at my '/var/lib/named/log/named-lame-servers' file I see > those same log entries he got: > > 25-Apr-2007 11:49:59.332 info: unexpected RCODE (SERVFAIL) resolving > '110.241.101.216.in-addr.arpa/PTR/IN': 80.58.61.254#53 > 25-Apr-2007 11:50:00.386 info: unexpected RCODE (SERVFAIL) resolving > '110.241.101.216.in-addr.arpa/PTR/IN': 80.58.61.250#53 > 25-Apr-2007 11:50:00.838 info: lame server resolving > '110.241.101.216.in-addr.arpa' (in '241.101.216.in-addr.arpa'?): > 206.13.29.11#53 > 25-Apr-2007 11:50:01.556 info: lame server resolving > '110.241.101.216.in-addr.arpa' (in '241.101.216.in-addr.arpa'?): > 206.13.28.11#53 > 25-Apr-2007 11:50:01.830 info: unexpected RCODE (REFUSED) resolving > '110.241.101.216.in-addr.arpa/PTR/IN': 63.192.50.218#53 > 25-Apr-2007 11:50:02.518 info: unexpected RCODE (REFUSED) resolving > '110.241.101.216.in-addr.arpa/PTR/IN': 198.69.181.18#53 > > > So there is nothing wrong with his DNS or those of his providers; the > fault is with the atacker DNS! "Hey, please, Mr. Bad Guy, would you > please correct your DNS entries before attacking me, please?" ;-) :-p
Behave ... :-) > > > Why the OP gets 5 rcode entries and me two (before the lame error) might > have to do with the number of forwarders in his definition. The first > block in my case corresponds to the forwarders, the second I don't know; > in any case, they are DNS servers my daemon interrogated. But the culprit > one is that of the atacckers, not any dns in our side. > My DNS is purely a cache DNS and is only authoritative for local address space and is not that busy. I do not see the above after making the host query (though the dns logs do not seem to have been updated for quite some time and I have not made any changes the configuration in this respect for one hell of a long time, so this something I need to check). My DNS logs are also directed to the main log files and nothing shows up there. My firewalling is done at the DSL router (I tend to prefer not to have front line firewalling on a machine that is providing other services), the DSL modem relays external DNS requests (no local machine directly contacts the ISPs DNS servers). There was a serious pause for the first request for the address but subsequent request were rejected quite quickly.... I note here that 6 servers are being queried, two are returned as lame, two fail and two are refused and these seem to be a different set of servers than those the original query was seeing.... now currently I am connecting via BT who maintain what is effectively a DNS server pool, and the DNS server addresses are dynamically allocated as are IP addresses. (BT do not encourage people to statically set up DNS details as the servers addresses do change. This could mean they are handling this type of problem at their level which is maybe why I am not seeing anything... but I will hold fire on that... ) In this case, the fails are legitimate rejections... of the other four one has to ask why are these asked again (and again) in the original case when they either broken or do not want to talk... I would also ask are these addresses defined as the forwarding servers. If both you and the original poster are both running a full DNS server this would suggest that queries to the address space quoted is being re-directed to an address of a server which the referrer believes can handle this address space (it is a long time since I read the relevant RFCs and I cannot remember how this bit is supposed to work so I am probably way off beam here ). These referrals seem to be broken hence the DNS error reports... This would tend to imply that the initial ftp query is not an attack on the ftp accounts concerned but an attempt to attack the DNS itself by firing up a lookup for a dodgy address via a mangled server. I cannot replicate the problem but it might be worthwhile to have a look at the communication involved by those who can . -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
