On Fri, 2005-04-08 at 10:36 +0300, Dotan Cohen wrote: > On Apr 8, 2005 5:33 AM, Robert Spangler <bms@xxxxxxxxxxxxxxxx> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On Thursday 07 April 2005 16:08, Dotan Cohen wrote: > > > > > I would like nothing more than to use iptables to block them. Trouble > > > is, I can't seem to start firestarter. I get this error: > > > > > > And I know that eth0 is working because I am on the internet now! > > > > First run ifconfig to ensure there isn't some alias setup for your ethernet > > port. > > > > If everything looks good then to drop all ssh connections; > > > > iptables -A INPUT -i <eth?> -p tcp -m tcp --dport 22 -m state --state NEW -j > > DROP > > > > or to drop targetted addresses; > > > > iptables -A INPUT -i <eth?> -p tcp -m tcp -s <source ip> --dport 22 -m state > > - --state NEW -j DROP > > > > both must be on on line. > > > > - -- > > > > Regards > > Robert > > > > Smile... it increases your face value! > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.2.6 (GNU/Linux) > > > > iD8DBQFCVe2C0xJrO8dQYHgRAtknAJ4gLtSszYSZG6N8SL6yubzK1J86uwCfTzTD > > m9ngO3zMoObcibzkw1GYs4E= > > =haQE > > -----END PGP SIGNATURE----- > > > > > > > > First run ifconfig to ensure there isn't some alias setup for your ethernet > > port. > > This is what I got: > eth0 Link encap:Ethernet HWaddr 00:0D:87:29:C4:00 > inet addr:172.27.14.121 Bcast:255.255.255.255 Mask:255.255.240.0 > inet6 addr: fe80::20d:87ff:fe29:c400/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:3697172 errors:0 dropped:0 overruns:0 frame:0 > TX packets:158594 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:360217349 (343.5 MiB) TX bytes:23759055 (22.6 MiB) > Interrupt:11 Base address:0xd400 > > lo Link encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > inet6 addr: ::1/128 Scope:Host > UP LOOPBACK RUNNING MTU:16436 Metric:1 > RX packets:3093 errors:0 dropped:0 overruns:0 frame:0 > TX packets:3093 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:3671398 (3.5 MiB) TX bytes:3671398 (3.5 MiB) > > ppp0 Link encap:Point-to-Point Protocol > inet addr:192.117.111.61 P-t-P:192.117.122.13 Mask:255.255.255.255 > UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1460 Metric:1 > RX packets:136970 errors:0 dropped:0 overruns:0 frame:0 > TX packets:124998 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:3 > RX bytes:110074869 (104.9 MiB) TX bytes:15253397 (14.5 MiB) > > > > If everything looks good then to drop all ssh connections; > > iptables -A INPUT -i <eth?> -p tcp -m tcp --dport 22 -m state --state NEW -j > > DROP > > > > or to drop targetted addresses; > > iptables -A INPUT -i <eth?> -p tcp -m tcp -s <source ip> --dport 22 -m state > > - --state NEW -j DROP > > I see that the attacker is comming from multiple IP's. Although I > currently do not ssh into this comupter, I would like to leave that > option open. Acually, I would like to set that up as soon as possible. > What should I block if I am being attacked by several IP's, but I do > not want to block ssh altogether? Blocking the attackers' IP addresses is a waste of time. You're playing whack-a-mole and they come back from a different compromised box (found using the same method as their attacks on you) every time. If you want to block them using a firewall, the way to do it is to decide where you want to be able to connect from and then block *everywhere else* > By the way, the attacker is trying to access me by logging into > different accounts on my computer, such as: > oracle > richard > personal > eddie > > I am compiling a list of these names, so that I will know never to > make a user account with one of them. Would anybody else be interested > in this list? I think that it would be good to warn users who try to > create accounts with these names that they may be less secure in the > event of an attack such as this one. Or am I exaggerating? The list of accounts tried will change from time to time. It's a list of commonly-used account names. Using obscure account names (e.g. combinations of letters and numbers) might help to defeat this particular type of attack but you might find it less convenient to use and administer such a system when you need to look up which account name belongs to which "actual" user. Using suitably strong passwords (or certificates) is probably a better fix. Paul. -- Paul Howarth <paul@xxxxxxxxxxxx>
