MoonPoint Support Logo

 


Shop Amazon Warehouse Deals - Deep Discounts on Open-box and Used ProductsAmazon Warehouse Deals



Advanced Search
December
Sun Mon Tue Wed Thu Fri Sat
      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 31  
2021
Months
Dec


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

  1. Blocking SSH break-in attempts with fail2ban
    Date: October 23, 2021
  2. Finding which package provided a file on a CentOS Linux system
    Date: October 23, 2021
  3. 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:

  1. Stopping an Attacker with the Route Reject Command
    MoonPoint Support
    Date: April 15, 2007
  2. 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

Once You Know, You Newegg AliExpress by Alibaba.com

Shop Amazon Local - Subscribe to Deals in Your Neighborhood

Valid HTML 4.01 Transitional

Privacy Policy   Contact

Blosxom logo