Intrusion attempts and hosts.deny/hosts.allow
There is some hacker from the outside world trying to get into mysql . I have ALL : ALL in hosts.deny with specific hosts listed in hosts.allow. The guy uses some automated script trying to connect to the mysql server. The ALL : ALL in hosts.deny results in an entry to the system log for each failed connection attempt, filling my system log quite rapidly. I tried to slow things a but down by listing him in /hosts.allow with ALL : 219.156.0.0/16 : twist /bin/echo -e "\n\rAccess from %h declined\n\rGo away\n\r"; sleep 100 this works perfectly with attacks on the ssh port, but with mysql it does not work, I get rather a second error message for each connection attempt: May 18 23:40:50 basilisk mysqld[26613]: error: /etc/hosts.allow, line 614: twist option in resident process and also has the rather annoying side effect of being unable to start/restart mysql unless the sleep 100 in the twist has expired. Questions: Why can I feed the hacker with some bullshit with ssh, but not with mysqld? What else can I do to stop the log growing too big too fast without loosing the information of these intrusion attempts? Peter
On 18/05/06 10:10, Peter Sutter wrote:
There is some hacker from the outside world trying to get into mysql . I have ALL : ALL in hosts.deny with specific hosts listed in hosts.allow.
If this guy is this much of a bother, I would blacklist him in the firewall. If you are using SuSEfirewall2, then you can put the command(s) into /etc/sysconfig/scripts/SuSEfirewall2-custom, in an appropriate function. Easiest would probably be fw_custom_before_port_handling() because this one is called before the INPUT and FORWARD traffic is redirected to another chain within the firewall. First log his attempts, maximum 3 times per minute, with a special prefix: iptables -A INPUT -s 219.156.0.0/16 -m limit --limit 3/min -j LOG --log-prefix "Wanker " Now you can do whatever you want/can legally get away with ( ;-) ): iptables -A INPUT -s 219.156.0.0/16 -j DROP Maybe he'll just go away forever if you use REJECTs instead: iptables -A INPUT -p tcp -s 219.156.0.0/16 -j REJECT --reject-with tcp-reset iptables -A INPUT -p udp -s 219.156.0.0/16 -j REJECT --reject-with icmp-port-unreachable If this doesn't give the hint, then use the single DROP instead. Note: in the 9.3 SuSEfirewall, these two commands can be replaced by a single "iptables -A INPUT -s 219.156.0.0/16 -j reject_func". In your version, run "iptables-save |grep reject_func" to see if the same chain is defined. If it is just one particular IP, you could even forward the packets back to him on some really nasty port, say 0 -- fill up his logs. I do not guarantee the legality of this, however ;-) It could also eat up your outbound bandwidth very quickly, depending on how persistent this moron is. While this does not address your specific questions (I don't know the answer to the first one), it should give an easier way to handle this guy, short of setting up a honeypot. It also keeps logging of the intrusion attempts, but at a more manageable level. PS, I just did a "whois", and you could probably change the netmask from /16 to /15 which will trap vast tracts of {a recently emerging economic giant with lots of net kiddies and open email servers, which shall not be further identified ;-) }.
On Friday 19 May 2006 01:00, Darryl Gregorash wrote:
On 18/05/06 10:10, Peter Sutter wrote:
There is some hacker from the outside world trying to get into mysql . I have ALL : ALL in hosts.deny with specific hosts listed in hosts.allow.
If this guy is this much of a bother, I would blacklist him in the firewall. If you are using SuSEfirewall2, then you can put the command(s) into /etc/sysconfig/scripts/SuSEfirewall2-custom, in an appropriate function. Easiest would probably be fw_custom_before_port_handling() because this one is called before the INPUT and FORWARD traffic is redirected to another chain within the firewall.
First log his attempts, maximum 3 times per minute, with a special prefix:
iptables -A INPUT -s 219.156.0.0/16 -m limit --limit 3/min -j LOG --log-prefix "Wanker "
Now you can do whatever you want/can legally get away with ( ;-) ):
iptables -A INPUT -s 219.156.0.0/16 -j DROP
Maybe he'll just go away forever if you use REJECTs instead:
iptables -A INPUT -p tcp -s 219.156.0.0/16 -j REJECT --reject-with tcp-reset iptables -A INPUT -p udp -s 219.156.0.0/16 -j REJECT --reject-with icmp-port-unreachable
If this doesn't give the hint, then use the single DROP instead.
[...] Here's another option: You could also use the TARPIT extension from patch-o-matic. See http://www.netfilter.org/patch-o-matic/pom-extra.html, 4th item. This requires recompiling the kernel. iptables already knows about TARPIT (man iptables), all it needs is the TARPIT kernel module. Cheers, Leen
On 19/05/06 01:52, Leendert Meyer wrote:
<snip> [...]
Here's another option:
You could also use the TARPIT extension from patch-o-matic. See http://www.netfilter.org/patch-o-matic/pom-extra.html, 4th item. This requires recompiling the kernel.
iptables already knows about TARPIT (man iptables), all it needs is the TARPIT kernel module.
I couldn't find "TARPIT" in man iptables. It's probably not something you'd want to use with SuSEfirewall anyway, because that requires the conntrack module, whereas netfilter.org suggests that using both at the same time is probably a massive waste of resources. Other than that little hiccup, it looks like a rather elegant solution to this sort of problem.
On Friday 19 May 2006 15:13, Darryl Gregorash wrote:
On 19/05/06 01:52, Leendert Meyer wrote:
<snip> [...]
Here's another option:
You could also use the TARPIT extension from patch-o-matic. See http://www.netfilter.org/patch-o-matic/pom-extra.html, 4th item. This requires recompiling the kernel.
iptables already knows about TARPIT (man iptables), all it needs is the TARPIT kernel module.
I couldn't find "TARPIT" in man iptables.
leen@ws-03:/home/leen> man iptables | grep -n TARPIT Reformatting iptables(8), please wait... 1695: iptables -A INPUT -p tcp -m tcp --dport 80 -j TARPIT 1702: iptables -A FORWARD -p tcp -j TARPIT 1706: NOTE: If you use the conntrack module while you are using TARPIT, you 1708: sarily allocate resources for each TARPITted connection. To 1709: TARPIT incoming connections to the standard IRC port while using 1714: iptables -A INPUT -p tcp --dport 6667 -j TARPIT
It's probably not something you'd want to use with SuSEfirewall anyway, because that requires the conntrack module,
Requires? Hmm, really? (I know about the warnings, i.e. you should avoid using conntrack with tarpit, because /then/ tarpit will use resources; without conntrack it doesn't.)
whereas netfilter.org suggests that using both at the same time is probably a massive waste of resources.
from the manpage:
NOTE: If you use the conntrack module while you are using TARPIT, you should also use the NOTRACK target, or the kernel will unnecessarily allocate resources for each TARPITted connection. To TARPIT incoming connections to the standard IRC port while using conntrack, you could: iptables -t raw -A PREROUTING -p tcp --dport 6667 -j NOTRACK iptables -A INPUT -p tcp --dport 6667 -j TARPIT
(I only learned from the 'NOTRACK' target just today, so I'm not sure if it needs another kernel patch... 'grep -ir notrack' in the pach-o-matic sources yields nothing, so I guess not.)
Other than that little hiccup, it looks like a rather elegant solution to this sort of problem.
Yes, it does. Too bad it's not in the kernel. Cheers, Leen
On 19/05/06 07:51, Leendert Meyer wrote:
On Friday 19 May 2006 15:13, Darryl Gregorash wrote:
<snip> I couldn't find "TARPIT" in man iptables.
leen@ws-03:/home/leen> man iptables | grep -n TARPIT Reformatting iptables(8), please wait... 1695: iptables -A INPUT -p tcp -m tcp --dport 80 -j TARPIT
Which version are you running? I have SuSE 9.3 with iptables 1.3.1-3. Or is there an updated manpage in the tarpit module source?
It's probably not something you'd want to use with SuSEfirewall anyway, because that requires the conntrack module,
Requires? Hmm, really? (I know about the warnings, i.e. you should avoid using conntrack with tarpit, because /then/ tarpit will use resources; without conntrack it doesn't.)
a massive waste of resources. from the manpage:
NOTE: If you use the conntrack module while you are using TARPIT, you should also use the NOTRACK target, or the kernel will unnecessarily allocate resources for each TARPITted connection. To TARPIT incoming connections to the standard IRC port while using conntrack, you could: iptables -t raw -A PREROUTING -p tcp --dport 6667 -j NOTRACK iptables -A INPUT -p tcp --dport 6667 -j TARPIT
This is the ticket. Looks like netfilter.org needs to update a webpage or two though :-) -- without the conntrack module, iptables is just another stateless firewall, an improvement over ipchains (and a quantum leap over ipfwadm) but not much else. The conntrack modules (there is also conntrack_ftp) turn iptables into a very nice stateful firewall, something I for one would be very reluctant to give up just to simplify
Yes, requires -- there is "-m state --state <blah>" all over the place, which requires conntrack. the problem of catching hack0rz and other sorts of slime.
Too bad it's not in the kernel.
So a few thousand emails to Linus should take care of that :-)
On Saturday 20 May 2006 05:23, Darryl Gregorash wrote:
On 19/05/06 07:51, Leendert Meyer wrote:
On Friday 19 May 2006 15:13, Darryl Gregorash wrote:
<snip> I couldn't find "TARPIT" in man iptables.
leen@ws-03:/home/leen> man iptables | grep -n TARPIT Reformatting iptables(8), please wait... 1695: iptables -A INPUT -p tcp -m tcp --dport 80 -j TARPIT
Which version are you running? I have SuSE 9.3 with iptables 1.3.1-3. Or is there an updated manpage in the tarpit module source?
SL-10.1 - still smelling fresh
It's probably not something you'd want to use with SuSEfirewall anyway, because that requires the conntrack module,
Requires? Hmm, really? (I know about the warnings, i.e. you should avoid using conntrack with tarpit, because /then/ tarpit will use resources; without conntrack it doesn't.)
Yes, requires -- there is "-m state --state <blah>" all over the place, which requires conntrack.
You're talking about /your/ firewall script, right?
a massive waste of resources.
from the manpage:
NOTE: If you use the conntrack module while you are using TARPIT, you should also use the NOTRACK target, or the kernel will unnecessarily allocate resources for each TARPITted connection. To TARPIT incoming connections to the standard IRC port while using conntrack, you could: iptables -t raw -A PREROUTING -p tcp --dport 6667 -j NOTRACK iptables -A INPUT -p tcp --dport 6667 -j TARPIT
This is the ticket. Looks like netfilter.org needs to update a webpage or two though :-) -- without the conntrack module, iptables is just another stateless firewall, an improvement over ipchains (and a quantum leap over ipfwadm) but not much else. The conntrack modules (there is also conntrack_ftp) turn iptables into a very nice stateful firewall,
Did some reading on Wikipedia: Firewall_(networking) and iptables. Ftp is an example where a statefull firewall comes in handy.
something I for one would be very reluctant to give up just to simplify the problem of catching hack0rz and other sorts of slime.
I see now. Hmm, wouldn't that be something like plugging one hole with the stop of another hole?
Too bad it's not in the kernel.
So a few thousand emails to Linus should take care of that :-)
Or know the right people who know the right... Cheers, Leen
participants (3)
-
Darryl Gregorash -
Leendert Meyer -
Peter Sutter