←November→
Sun |
Mon |
Tue |
Wed |
Thu |
Fri |
Sat |
|
|
|
|
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
25 |
26 |
27 |
28 |
29 |
30 |
|
|
Sun, Oct 24, 2021 12:58 pm
Counting SSH break-in attempts by country
Yesterday, I installed
Fail2Ban on a
CentOS 7 server after
noticing SSH break-in
attempts by password guessing. Today, I checked the fail2ban log to see how
many IP addresses were banned and whether after being banned for an hour there
were any subsequent password guessing attempts from the same IP address. I saw
that 40 IP addresses had been banned since I installed Fail2Ban last night and
that some of those addresses had been banned multiple times. You can count
the number of times an IP address has been banned by using the
awk command
awk '($(NF-1) = /Ban/){print $NF}' /var/log/fail2ban.log | sort | uniq -c
| sort -n
. You can pipe the output of that command to the
wc command
wc -l
to count the total number of lines which tells you the number
of IP addresses that have been banned as explained at
Fail2ban logging.
[root@moonpoint ~]# awk '($(NF-1) = /Ban/){print $NF}' /var/log/fail2ban.log | s
ort | uniq -c | sort -n
1 103.50.219.194
1 104.200.134.181
1 104.244.77.37
1 107.189.14.174
1 107.189.14.230
1 107.189.14.41
1 107.189.1.96
1 107.189.31.223
1 107.189.8.233
1 183.157.169.70
1 183.195.121.197
1 205.185.123.33
1 205.185.124.131
1 209.141.42.29
1 221.131.165.50
1 221.131.165.56
1 221.181.185.151
1 221.181.185.198
1 222.186.30.112
1 222.187.254.41
1 64.225.49.153
1 71.9.165.219
2 104.244.76.64
2 107.189.12.163
2 209.141.36.75
2 209.141.40.64
2 221.131.165.65
2 222.186.30.76
2 222.187.232.39
3 107.189.13.104
3 45.61.184.115
3 70.62.137.84
4 187.149.76.88
4 189.85.145.113
4 205.185.122.239
4 209.141.57.74
4 210.73.207.44
4 222.186.42.137
5 209.141.34.165
5 89.211.207.62
[root@moonpoint ~]# awk '($(NF-1) = /Ban/){print $NF}' /var/log/fail2ban.log | sort | uniq -c | sort -n | wc -l
40
[root@moonpoint ~]#
[More Info]
[/security/attacks]
permanent link
Sat, Oct 23, 2021 7:36 pm
Break-in attempts via SSH from 221.131.165.50
While checking on a problem on a test CentOS Linux system today, I issued the
command journalctl -xe
from the root account to get more
details on the problem. Among the results displayed was an indication of
attempts to break into the system by guesses for the password of the root
account on the system.
# journalctl -xe
Oct 23 16:20:23 moonpoint systemd[1]: Unit mariadb.service entered failed state.
Oct 23 16:20:23 moonpoint systemd[1]: mariadb.service failed.
Oct 23 16:20:23 moonpoint polkitd[1684]: Unregistered Authentication Agent for u
Oct 23 16:21:35 moonpoint sshd[4558]: pam_unix(sshd:auth): authentication failur
Oct 23 16:21:35 moonpoint sshd[4558]: pam_succeed_if(sshd:auth): requirement "ui
Oct 23 16:21:37 moonpoint sshd[4558]: Failed password for root from 221.131.165.
Oct 23 16:21:38 moonpoint sshd[4558]: pam_succeed_if(sshd:auth): requirement "ui
Oct 23 16:21:40 moonpoint sshd[4558]: Failed password for root from 221.131.165.
Oct 23 16:21:40 moonpoint sshd[4558]: pam_succeed_if(sshd:auth): requirement "ui
Oct 23 16:21:42 moonpoint sshd[4558]: Failed password for root from 221.131.165.
Oct 23 16:21:42 moonpoint sshd[4558]: Received disconnect from 221.131.165.50 po
Oct 23 16:21:42 moonpoint sshd[4558]: Disconnected from 221.131.165.50 port 4518
Oct 23 16:21:42 moonpoint sshd[4558]: PAM 2 more authentication failures; lognam
Oct 23 16:21:55 moonpoint sshd[4561]: pam_unix(sshd:auth): authentication failur
Oct 23 16:21:55 moonpoint sshd[4561]: pam_succeed_if(sshd:auth): requirement "ui
Oct 23 16:21:57 moonpoint sshd[4561]: Failed password for root from 221.131.165.
Oct 23 16:21:57 moonpoint sshd[4561]: pam_succeed_if(sshd:auth): requirement "ui
Oct 23 16:21:59 moonpoint sshd[4561]: Failed password for root from 221.131.165.
Oct 23 16:21:59 moonpoint sshd[4561]: pam_succeed_if(sshd:auth): requirement "ui
Oct 23 16:22:01 moonpoint sshd[4561]: Failed password for root from 221.131.165.
Oct 23 16:22:02 moonpoint sshd[4561]: Received disconnect from 221.131.165.50 po
Oct 23 16:22:02 moonpoint sshd[4561]: Disconnected from 221.131.165.50 port 4175
Oct 23 16:22:02 moonpoint sshd[4561]: PAM 2 more authentication failures; lognam
[root@moonpoint ~]#
When I checked the number of password guesses the attacker had tried by
searching for the IP address in /var/log/secure
, I found 183
attempts to log in.
[root@moonpoint ~]# grep "221.131.165.50" /var/log/secure | grep -c "Failed password"
183
[root@moonpoint ~]#
When I checked the location for the IP address 221.131.165.50 with the
geoiplookup program, a program that is provided by the GeoIP package, I found
the address allocated to an entity in China:
[root@moonpoint ~]# geoiplookup 221.131.165.50
GeoIP Country Edition: CN, China
[root@moonpoint ~]#
A check of the IP address on DShield at showed that IP address has been
associated with many attempts at unauthorized access to systems by password
guessing - see
SSH Source Summary. The DShield
IP Info: 221.131.165.50 report for the system currently lists 82,133
reports with 283 targets with activity first reported on 2021-09-26.
When I ran the journalctl command again later, I saw evidence of attempts
from other IP addresses to gain unauthorized access to the system via SSH,
so I installed
fail2ban to automatically block IP addresses when a specific number of
failed SSH login attempts have been detected from IP addresses.
Related
-
Blocking SSH break-in attempts with fail2ban
Date: October 23, 2021
-
Finding which package provided a file on a CentOS Linux system
Date: October 23, 2021
-
Fail2ban Logging
Date: April 9, 2016
[/security/attacks]
permanent link
Fri, Sep 22, 2017 11:18 pm
Failed POP3 login attempts from 94.136.51.56
While checking the mail log file, /var/log/maillog
, on an email
server today, I noticed an attempted login from an IP address in an address
range I didn't recognize. The entry in the log file contained the following
text:
dovecot: pop3-login: Disconnected (tried to use disallowed plaintext auth):
user=<>, rip=94.136.51.56
I checked the country associated with the 94.136.51.56 IP address
(ds7247.dedicated.turbodns.co.uk) with geoiplookup (you can install
the GeoIP package on a CentOS Linux system with yum install
GeoIP
) and found it was an address assigned to an entity in
Great Britain.
$ geoiplookup 94.136.51.56
GeoIP Country Edition: GB, United Kingdom
$
[ More Info ]
[/security/attacks/pop3]
permanent link
Wed, Jan 04, 2017 10:32 pm
SSH brute-force break-in attempts from 49.116.40.31
While troubleshooting a problem with a Linux system this evening, I opened
Wireshark
and noticed a
Secure Shell (SSH) packet from an unexpected source
address,
49.116.40.31
. When I checked the
fail2ban log on
the system, I noticed that the
IP address
had been banned temporarily several times today, but break-in attempts resumed
whenever the timeout period for the ban expired.
# grep '49.116.40.31' /var/log/fail2ban.log | grep 'Ban\|Unban'
2017-01-04 17:20:46,190 fail2ban.actions [25142]: NOTICE [sshd] Ban 49.116.40.31
2017-01-04 17:30:47,135 fail2ban.actions [25142]: NOTICE [sshd] UnBan 49.116.40.31
2017-01-04 17:31:15,276 fail2ban.actions [25142]: NOTICE [sshd] Ban 49.116.40.31
2017-01-04 17:41:16,250 fail2ban.actions [25142]: NOTICE [sshd] UnBan 49.116.40.31
2017-01-04 17:41:43,390 fail2ban.actions [25142]: NOTICE [sshd] Ban 49.116.40.31
2017-01-04 17:51:44,299 fail2ban.actions [25142]: NOTICE [sshd] UnBan 49.116.40.31
2017-01-04 17:52:14,441 fail2ban.actions [25142]: NOTICE [sshd] Ban 49.116.40.31
2017-01-04 18:02:15,243 fail2ban.actions [25142]: NOTICE [sshd] UnBan 49.116.40.31
2017-01-04 18:02:43,383 fail2ban.actions [25142]: NOTICE [sshd] Ban 49.116.40.31
2017-01-04 18:12:44,182 fail2ban.actions [25142]: NOTICE [sshd] UnBan 49.116.40.31
2017-01-04 18:13:13,323 fail2ban.actions [25142]: NOTICE [sshd] Ban 49.116.40.31
2017-01-04 18:23:14,227 fail2ban.actions [25142]: NOTICE [sshd] UnBan 49.116.40.31
2017-01-04 18:24:23,414 fail2ban.actions [25142]: NOTICE [sshd] Ban 49.116.40.31
2017-01-04 18:34:24,183 fail2ban.actions [25142]: NOTICE [sshd] UnBan 49.116.40.31
2017-01-04 18:35:33,368 fail2ban.actions [25142]: NOTICE [sshd] Ban 49.116.40.31
2017-01-04 18:45:34,148 fail2ban.actions [25142]: NOTICE [sshd] UnBan 49.116.40.31
2017-01-04 18:46:44,331 fail2ban.actions [25142]: NOTICE [sshd] Ban 49.116.40.31
2017-01-04 18:56:45,126 fail2ban.actions [25142]: NOTICE [sshd] UnBan 49.116.40.31
2017-01-04 18:57:14,282 fail2ban.actions [25142]: NOTICE [sshd] Ban 49.116.40.31
2017-01-04 19:07:15,124 fail2ban.actions [25142]: NOTICE [sshd] UnBan 49.116.40.31
2017-01-04 19:07:44,270 fail2ban.actions [25142]: NOTICE [sshd] Ban 49.116.40.31
2017-01-04 19:17:45,043 fail2ban.actions [25142]: NOTICE [sshd] UnBan 49.116.40.31
2017-01-04 19:18:14,190 fail2ban.actions [25142]: NOTICE [sshd] Ban 49.116.40.31
2017-01-04 19:28:15,111 fail2ban.actions [25142]: NOTICE [sshd] UnBan 49.116.40.31
2017-01-04 19:29:23,297 fail2ban.actions [25142]: NOTICE [sshd] Ban 49.116.40.31
2017-01-04 19:39:23,304 fail2ban.actions [25142]: NOTICE [sshd] UnBan 49.116.40.31
2017-01-04 19:39:51,441 fail2ban.actions [25142]: NOTICE [sshd] Ban 49.116.40.31
2017-01-04 19:49:52,326 fail2ban.actions [25142]: NOTICE [sshd] UnBan 49.116.40.31
2017-01-04 19:50:21,472 fail2ban.actions [25142]: NOTICE [sshd] Ban 49.116.40.31
2017-01-04 20:00:22,251 fail2ban.actions [25142]: NOTICE [sshd] UnBan 49.116.40.31
2017-01-04 20:00:49,390 fail2ban.actions [25142]: NOTICE [sshd] Ban 49.116.40.31
2017-01-04 20:10:50,192 fail2ban.actions [25142]: NOTICE [sshd] UnBan 49.116.40.31
2017-01-04 20:11:19,338 fail2ban.actions [25142]: NOTICE [sshd] Ban 49.116.40.31
2017-01-04 20:21:20,121 fail2ban.actions [25142]: NOTICE [sshd] UnBan 49.116.40.31
2017-01-04 20:21:49,263 fail2ban.actions [25142]: NOTICE [sshd] Ban 49.116.40.31
2017-01-04 20:31:50,036 fail2ban.actions [25142]: NOTICE [sshd] UnBan 49.116.40.31
2017-01-04 20:33:38,258 fail2ban.actions [25142]: NOTICE [sshd] Ban 49.116.40.31
2017-01-04 20:43:39,059 fail2ban.actions [25142]: NOTICE [sshd] UnBan 49.116.40.31
2017-01-04 20:44:37,358 fail2ban.actions [25142]: NOTICE [sshd] Ban 49.116.40.31
2017-01-04 20:54:37,372 fail2ban.actions [25142]: NOTICE [sshd] UnBan 49.116.40.31
#
[ More Info ]
[/security/attacks/ssh]
permanent link
Fri, Dec 30, 2016 7:45 pm
SSH break-in attempts from 116.31.116.xxx IP addresses
Yesterday, while using the
free and open source
packet
analyzer software
Wireshark to observe network traffic reaching a router, I had
set a packet filter in Wireshark to filter on
Internet Control Message Protocol (ICMP) traffic. I saw
a lot of unexpected ICMP "port unreachable" packets coming from a
server behind the router headed outbound to the Internet to the
IP address
116.31.116.41.
Internet Control Message Protocol
Type: 3 (Destination unreachable)
Code: 3 (port unreachable)
Checksum: 0xa821 [correct]
[Checksum Status: Good]
Unused: 00000000
ICMP
destination unreachable packets are "generated by the host or its
inbound gateway to inform the client that the destination is unreachable
for some reason." There is a "code" field that follows the "type" field in an
ICMP packet. If the code is 3, then it indicates a port unreachable error
(the designated protocol is unable to inform the host of the incoming
message). When I checked the destination port at the server end, I saw it was
22, which is the
well-known port for the Secure
Shell (SSH) protocol.
[ More Info ]
[/security/attacks/ssh]
permanent link
Tue, Aug 09, 2016 10:26 pm
SSH break-in attempt from 221.229.172.35
When I checked the
fail2ban log on one of my servers today, I found that
fail2ban had banned IP address
221.229.172.35
for failed attempts to log into the system
via
Secure
Shell (SSH).
# tail -n 10 /var/log/fail2ban.log
2016-08-09 10:12:56,296 fail2ban.filter [1590]: INFO [sshd] Found 221.229.172.35
2016-08-09 10:12:57,914 fail2ban.filter [1590]: INFO [sshd] Found 221.229.172.35
2016-08-09 10:12:58,663 fail2ban.filter [1590]: INFO [sshd] Found 221.229.172.35
2016-08-09 10:12:59,143 fail2ban.filter [1590]: INFO [sshd] Found 221.229.172.35
2016-08-09 10:12:59,870 fail2ban.actions [1590]: NOTICE [sshd] Ban 221.229.172.35
2016-08-09 10:13:00,591 fail2ban.filter [1590]: INFO [sshd] Found 221.229.172.35
2016-08-09 10:13:01,298 fail2ban.filter [1590]: INFO [sshd] Found 221.229.172.35
2016-08-09 10:13:01,522 fail2ban.filter [1590]: INFO [sshd] Found 221.229.172.35
2016-08-09 10:13:03,538 fail2ban.filter [1590]: INFO [sshd] Found 221.229.172.35
2016-08-09 10:13:04,075 fail2ban.filter [1590]: INFO [sshd] Found 221.229.172.35
#
When I checked the country where that IP address is assigned using the
geoiplookup tool, I found it is assigned to an entity in China. The tool
is in GeoIP, a
geolocation
package, which can be installed on
Red Hat
derived distributions of Linux, such as
CentOS with
yum install geoip
. The free version of the software which I use is
provided by MaxMind
$ geoiplookup 221.229.172.35
GeoIP Country Edition: CN, China
$
[ More Info ]
[/security/attacks/ssh]
permanent link
Mon, Mar 24, 2014 8:17 am
Attempted SQL injection attack
When I checked the webserver's error log file this morning, I noticed
the following two entries related to the IP address 221.11.108.10:
[Mon Mar 24 08:15:07 2014] [error] [client 221.11.108.10] File does not exist: /
home/jdoe/public_html/ctscms
[Mon Mar 24 08:15:12 2014] [error] [client 221.11.108.10] File does not exist: /home/jdoe/public_html/plus, referer: http://support.moonpoint.com/plus/search.php?keyword=as&typeArr[111%3D@`\\'`)+and+(SELECT+1+FROM+(select+count(*),concat(floor(rand(0)*2),(substring((select+CONCAT(0x7c,userid,0x7c,pwd)+from+`%23@__admin`+limit+0,1),1,62)))a+from+information_schema.tables+group+by+a)b)%23@`\\'`+]=a
There is no ctscms file nor directory, nor do I use a search.php file, nor
even have a directory named plus on this web site, so the queries seemed
suspicious.
Performing a Google search on the attempted query to search.php, which
appears to be an SQL query, I
found links to a number of sites in the Chinese language. E.g.,
dedecms plus / search.php latest injection vulnerability (translated
to English).
The query I saw in the Apache error log appeared to be an
SQL injection
attack. In
Arrays in requests, PHP and DedeCMS, an InfoSec Handlers Diary Blog entry,
I found the following in relation to an SQL injection attack used against
/plus/download.php
, which is a PHP script associated
with the DedeCMS
Content
Management System (CMS):
And this definitely looks malicious. After a bit of research, it turned
out that this is an attack against a known vulnerability in the DedeCMS,
a CMS written in PHP that appears to be popular in Asia. This CMS has
a pretty nasty SQL injection vulnerability that can be exploited with
the request shown above.
So I blocked any further access to the server hosting this
site from that IP address using a route reject command.
# route add 221.11.108.10 reject
[root@frostdragon ~]# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
221.11.108.10 - 255.255.255.255 !H 0 - 0 -
171.216.29.9 - 255.255.255.255 !H 0 - 0 -
The 221.11.108.10 IP address
is allocated to an entity in China. I blocked another Chinese IP address,
171.216.29.9 two days ago.
The
Arrays in requests, PHP and DedeCMS blog entry indicated the
attacker discussed in that article was using a script that identified itself
with a
user agent string
of
WinHttp.WinHttpRequest
:
Additionally, as you can see in the log at the top, the User Agent string
has been set to WinHttp.WinHttpRequest, which indicates that this request
was created by a script or an attack tool executed on a Windows machine.
When I checked the Apache CustomLog to see what user agent string was
submitted with the queries to this site, I saw it was "Googlebot/2.1", so
the attacker appears to be using an updated script.
that misidentifies itself as
Googlebot. The Internet Storm Center blog entry was posted 6 months
ago and discusses a log entry from September 5, 2013. The log entry posted
in that article shows a source IP address of 10.10.10.10, which is a
private IP address
substituted in the article for the actual IP address from
which the attack originated.
I saw the following in my log:
221.11.108.10 - - [24/Mar/2014:08:15:07 -0400] "GET /ctscms/ HTTP/1.1" 404 291 "
-" "Googlebot/2.1 (+http://www.google.com/bot.html)"
221.11.108.10 - - [24/Mar/2014:08:15:12 -0400] "GET /plus/search.php?keyword=as&
typeArr[111%3D@`\\'`)+and+(SELECT+1+FROM+(select+count(*),concat(floor(rand(0)*2
),(substring((select+CONCAT(0x7c,userid,0x7c,pwd)+from+`%23@__admin`+limit+0,1),
1,62)))a+from+information_schema.tables+group+by+a)b)%23@`\\'`+]=a HTTP/1.1" 404
299 "http://support.moonpoint.com/plus/search.php?keyword=as&typeArr[111%3D@`\\
'`)+and+(SELECT+1+FROM+(select+count(*),concat(floor(rand(0)*2),(substring((sele
ct+CONCAT(0x7c,userid,0x7c,pwd)+from+`%23@__admin`+limit+0,1),1,62)))a+from+info
rmation_schema.tables+group+by+a)b)%23@`\\'`+]=a" "Googlebot/2.1 (+http://www.go
ogle.com/bot.html)Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, a
pplication/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-power
point, application/msword, */*"
References:
-
Stopping an Attacker with the Route Reject Command
MoonPoint Support
Date: April 15, 2007
-
Arrays in requests, PHP and DedeCMS
Internet Storm Center
By: Bojan, ISC Handler
[/security/attacks]
permanent link
Fri, Jan 08, 2010 12:53 pm
Hostile Host Check
I created a
Bash script
hostile-host-check to allow me to query
DShield, a
"cooperative network security community" to determine if an IP address I've
been notified is engaged in hostile activity is also listed in
DShield's database of IP addresses found by others to be associated with
hostile activity noted at their firewalls.
hostile-host-check.zip
[/security/attacks]
permanent link
Wed, Feb 13, 2008 9:25 pm
FTP Attacks from 221.130.187.49 and 202.57.128.159
The system became unresponsive for a time. I ran
kripp and found two systems conducting FTP brute-force
password guessing attempts.
ftp password :: frostdragon.com -> 202.57.128.159.sta.isp-thailand.com :: anna :: poiuyt [F]
ftp password :: frostdragon.com -> 221.130.187.49 :: james :: purple [F]
ftp password :: frostdragon.com -> 221.130.187.49 :: james :: ranger [F]
ftp password :: frostdragon.com -> 202.57.128.159.sta.isp-thailand.com :: anna :: 111111 [F]
ftp password :: frostdragon.com -> 221.130.187.49 :: james :: purple [F]
ftp password :: frostdragon.com -> 221.130.187.49 :: james :: ranger [F]
ftp password :: frostdragon.com -> 202.57.128.159.sta.isp-thailand.com :: anna :: 111111 [F]
ftp password :: frostdragon.com -> 221.130.187.49 :: james :: 123go [F]
ftp password :: frostdragon.com -> 202.57.128.159.sta.isp-thailand.com :: anna :: 000000 [F]
ftp password :: frostdragon.com -> 221.130.187.49 :: james :: Airhead [F]
ftp password :: frostdragon.com -> 202.57.128.159.sta.isp-thailand.com :: anna :: oracle [F]
ftp password :: frostdragon.com -> 221.130.187.49 :: james :: Braves [F]
ftp password :: frostdragon.com -> 202.57.128.159.sta.isp-thailand.com :: anna :: library [F]
ftp password :: frostdragon.com -> 221.130.187.49 :: james :: Sparky [F]
ftp password :: frostdragon.com -> 202.57.128.159.sta.isp-thailand.com :: anna :: linux [F]
ftp password :: frostdragon.com -> 221.130.187.49 :: james :: angela [F]
ftp password :: frostdragon.com -> 202.57.128.159.sta.isp-thailand.com :: anna :: unix [F]
ftp password :: frostdragon.com -> 221.130.187.49 :: james :: brandy [F]
ftp password :: frostdragon.com -> 202.57.128.159.sta.isp-thailand.com :: anna :: amanda [F]
ftp password :: frostdragon.com -> 221.130.187.49 :: james :: cindy [F]
I blocked the 221.130.187.49 system with route add 221.130.187.49 reject
. I then checked DShield to
learn if it has been observed attacking other systems. The
DShield report
for 221.130.187.49 showed it was first reported engaged in hostile
activity on 2008-02-11 and the last reported incident was today
2008-02-13. The IP address is a Chinese address. When I checked the
IP Details
for the ports the system was attacking, I found it was listed only
for port 21 attacks, i.e. FTP
attacks.
It was also listed at myNetWatchman.
The Incident
Detail report for that IP address at myNetWatchman showed the system
had been attacking other systems on port 21 and port 22 (SSH) as well from
February 5, 2008 onwards.
I then checked the second system attacking, which was
202.57.128.159.sta.isp-thailand.com. The IP address for it is 202.57.128.159.
Note: a reverse lookup on 202.57.128.159 yields a Fully Qualified Domain Name
(FQDN) of 202.57.128.159.sta.isp-thailand.com, but a forward lookup on
202.57.128.159.sta.isp-thailand.com does not yield an IP address.
I ran an nmap scan of it to see what operating system it was running. I got
the following results:
# nmap -P0 -O 202.57.128.159
Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
Insufficient responses for TCP sequencing (1), OS detection may be less accurate
Interesting ports on 202.57.128.159.sta.isp-thailand.com (202.57.128.159):
(The 1588 ports scanned but not shown below are in state: closed)
Port State Service
21/tcp open ftp
80/tcp open http
111/tcp open sunrpc
135/tcp filtered loc-srv
137/tcp filtered netbios-ns
199/tcp open smux
443/tcp open https
445/tcp filtered microsoft-ds
3306/tcp open mysql
4444/tcp filtered krb524
8009/tcp open ajp13
8080/tcp open http-proxy
10000/tcp open snet-sensor-mgmt
Remote operating system guess: Linux Kernel 2.4.0 - 2.5.20
Nmap run completed -- 1 IP address (1 host up) scanned in 173 seconds
Visting http://202.57.128.159/ with
a browser showed "Welcome to web4.thaibestserver.net".
When I checked DShield for any reports
on hostile activity for that IP address, which is a Thai address,
I found it was first reported
engaged in hostile activity on 2008-02-08 with the most recent report
dated 2008-02-09 (see
IP Info
(202.57.128.159)). The
IP Details
202.57.128.159 report showed all of the incidents to be FTP attacks.
There was also an
Incident Detail report for it at
myNetWatchman, which also showed the system engaged in FTP attacks from
February 6 onwards.
I blocked it with route add 202.57.128.159 reject
.
I also turned off the FTP service on the system, since it isn't needed
at the moment.
[/security/attacks]
permanent link
Mon, Jun 25, 2007 7:10 am
Pentagon Takes 1,500 Systems Offline
A
Time article dated Thursday, June 21,
2007, titled
Cyber Attack Hits Pentagon states that the Pentagon
took as many as 1,500 computers offline because of a cyber attack, which
occurred on Wednesday. The article stated that Defense Secretary
Robert Gates
said the Pentagon sees hundreds of attacks a day and this one had no adverse
impact on department operations. Employees whose computers were affected could
still use their handheld BlackBerrys.
I'm not surprised that the Pentagon sees hundreds of attacks a day, but
It is hard for me to believe that taking 1,500 systems offline had no
impact on department operations. Sure employees could still deal with email via
their BlackBerry's, but, even if the systems were used solely for
administrative purposes, I would expect the employees would be hampered by
a lack of access to spreadsheets, presenations, and other documents normally
used in an office environment. Hopefully, the attackers didn't glean
sensitive data from any of those systems.
I was surprised by Mr. Gates response when he was asked if his own e-mail
account was affected. He responded "I don't do e-mail. I'm a very low-tech
person." I understand that for his generation (he's 63 years old) email
may not be as much a part of the fabric of business life as for younger
Americans, but I was surprised to hear him state he doesn't use it at all,
especially since his prior position was president of Texas A&M University.
[/security/attacks]
permanent link
Privacy Policy
Contact