James Knott wrote:

david rankin wrote:

...

Mates,

I am experiencing an excessive load from the internet that looks like some kind of attack. The log entries that repeat over and over are:

Apr 22 11:14:54 bonza proftpd[10488]: bonza.rbpllc.com (216.101.241.110[216.101.241.110]) - FTP session opened. Apr 22 11:14:54 bonza proftpd[10488]: bonza.rbpllc.com (216.101.241.110[216.101.241.110]) - no such user 'alexander' Apr 22 11:14:55 bonza last message repeated 2 times Apr 22 11:14:55 bonza proftpd[10488]: bonza.rbpllc.com (216.101.241.110[216.101.241.110]) - FTP session closed. 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 Apr 22 11:14:56 bonza named[5250]: unexpected RCODE (SERVFAIL) resolving '110.241.101.216.in-addr.arpa/PTR/IN': 68.1.208.30#53 Apr 22 11:14:56 bonza named[5250]: unexpected RCODE (SERVFAIL) resolving '110.241.101.216.in-addr.arpa/PTR/IN': 68.1.208.25#53 Apr 22 11:14:56 bonza named[5250]: unexpected RCODE (REFUSED) resolving '110.241.101.216.in-addr.arpa/PTR/IN': 63.192.50.218#53 Apr 22 11:14:57 bonza named[5250]: unexpected RCODE (REFUSED) resolving '110.241.101.216.in-addr.arpa/PTR/IN': 198.69.181.18#53 Apr 22 11:14:57 bonza named[5250]: lame server resolving '110.241.101.216.in-addr.arpa' (in '241.101.216.in-addr.arpa'?): 206.13.29.11#53 Apr 22 11:14:57 bonza named[5250]: lame server resolving '110.241.101.216.in-addr.arpa' (in '241.101.216.in-addr.arpa'?): 206.13.28.11#53 Apr 22 11:14:57 bonza named[5250]: unexpected RCODE (SERVFAIL) resolving '110.241.101.216.in-addr.arpa/PTR/IN': 68.1.208.25#53 Apr 22 11:14:58 bonza named[5250]: unexpected RCODE (SERVFAIL) resolving '110.241.101.216.in-addr.arpa/PTR/IN': 68.1.208.30#53 Apr 22 11:14:58 bonza named[5250]: unexpected RCODE (SERVFAIL) resolving '110.241.101.216.in-addr.arpa/PTR/IN': 66.76.2.130#53 Apr 22 11:14:58 bonza named[5250]: unexpected RCODE (REFUSED) resolving '110.241.101.216.in-addr.arpa/PTR/IN': 63.192.50.218#53 Apr 22 11:14:59 bonza named[5250]: unexpected RCODE (REFUSED) resolving '110.241.101.216.in-addr.arpa/PTR/IN': 198.69.181.18#53 Apr 22 11:14:59 bonza named[5250]: lame server resolving '110.241.101.216.in-addr.arpa' (in '241.101.216.in-addr.arpa'?): 206.13.29.11#53 Apr 22 11:14:59 bonza named[5250]: lame server resolving '110.241.101.216.in-addr.arpa' (in '241.101.216.in-addr.arpa'?): 206.13.28.11#53

The biggest question is what can I do to stop this?? Is there an effective firewall rule or IP table recipe that will help?? The load caused the server to lock up last night causing a great deal of havoc. Any wise advise would be welcomed.

Do you actually have an FTP server available? If so, you may want to consider a more secure method such as sftp or scp. If not, your firewall should be configured to block all such attempts. If you need to have the server available, you can configure the firewall to restrict the acceptable addresses or block known hostile sites. Without knowing more about your situation, I can't be more specific.

The first two lines suggest an attempt to get in via FTP. The rest is a little more intriguing .... I may be wrong here but port 53 is a DNS resolution query...the lame server bit suggests that there is something wrong with DNS server the machine is making a resolution request against..... I would take hard look at your DNS settings.. if you are sitting behind a DSL router with default password settings there was exploit that was reported that could you use javascript to reset the routers DNS settings... on the other hand this might not be your problem and your ISPs DNS server may have a problem... I would use Dig to find out what is going on... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

The Wednesday 2007-04-25 at 00:56 +0100, G.T.Smith wrote:

...

The first two lines suggest an attempt to get in via FTP. The rest is a little more intriguing ....

I may be wrong here but port 53 is a DNS resolution query...the lame server bit suggests that there is something wrong with DNS server the machine is making a resolution request against..... I would take hard look at your DNS settings..

No, no. Check the attacking IP rDNS yourself, and you will see the same error. The FTP servers is simply trying to analyze the IP.

Thanks for all the responses! It looks like the primary problem is a lot of lame servers out there. This isn't my DNS's problem, it is a problem with a whole host of lame servers in my ISP's DNS chain (suddenlink is not known for its perfection in operation) I've limited FTP to internal addresses (proftp is needed by our copier to send .pdf scans to the server from the document feeder) -- David C. Rankin, J.D., P.E. 510 Ochiltree Street Nacogdoches, Texas 75961 (936) 715-9333 (936) 715-9339 fax www.rankinlawfirm.com -- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Darryl Gregorash wrote:

On 2007-04-24 23:12, david rankin wrote:

...

...

<snip>

Thanks for all the responses! It looks like the primary problem is a lot of lame servers out there.

As Carlos explained, the IP in question does not resolve with reverse DNS. However, I would not call that your primary problem: you seem to have the external interface (on your router, or whatever) open for ftp, and seem to be getting subjected to a dictionary attack (attempts to log in with any number of common potential user IDs and passwords). Close the external interface for ftp, unless you absolutely need it, and let the firewall handle the job of protecting your ftp server security.

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.. 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... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

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:

cer@nimrodel:~> 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: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Hello, On Thu, 26 Apr 2007 22:00:45 +0200 (CEST) "Carlos E. R." wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

The Wednesday 2007-04-25 at 21:27 +0100, G.T.Smith wrote:

...

...

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.

like mine.

...

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).

Because I have this entry in /etc/named.conf:

logging { channel lame_errors { file "/var/lib/named/log/named-lame-servers" versions 2 size 200k; severity debug 3; print-severity yes; print-time yes; }; category lame-servers { lame_errors; }; };

...

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....

More or less the same here.

...

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...

It must have to do with the response given by the DNS server that makes our side to think that the answer is not definitive and that another server may think different.

...

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...

Mine asks first my ISP DNS servers, then the root servers. Ie, I have "forward first".

...

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

It maybe coincidental and not intentional, but who knows.

I guess the original poster is setting 'UseReverseDNS off' up for proftpd and the others servers(e.g. Apache, SMTP, POP) do ReverseDNS and the attacker is attacking various servers at the same time. Therefore, the proftpd is silently processing it but the others servers complain. I thought so. Thanks, eshsf -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

From: "Darryl Gregorash" On 2007-04-24 23:12, david rankin wrote:

...

...

<snip>

Thanks for all the responses! It looks like the primary problem is a lot of lame servers out there.

As Carlos explained, the IP in question does not resolve with reverse DNS. However, I would not call that your primary problem: you seem to have the external interface (on your router, or whatever) open for ftp, and seem to be getting subjected to a dictionary attack (attempts to log in with any number of common potential user IDs and passwords). Close the external interface for ftp, unless you absolutely need it, and let the firewall handle the job of protecting your ftp server security.

Loud *pop* heard as Mr. Rankin resolves his cranial rectal inversion by closing port 21 on his router. Sometimes it truly is the forest for the trees. -- David C. Rankin, J.D., P.E. 510 Ochiltree Street Nacogdoches, Texas 75961 (936) 715-9333 (936) 715-9339 fax www.rankinlawfirm.com -- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org