A nemzetközi helyzet fokozódik

Security-all
lastb | awk '/ssh/ {printf("%s\t%s\t%s\n", $1, $2, $3);}' | sort -u
aja	ssh:notty	95.181.188.200
brr	ssh:notty	129.211.185.246
cfz	ssh:notty	111.231.62.191
cgf	ssh:notty	201.48.192.60
ckq	ssh:notty	114.207.139.203
fsp	ssh:notty	120.48.12.77
hye	ssh:notty	111.231.62.191
jgr	ssh:notty	106.52.105.178
job	ssh:notty	106.53.114.90
jxf	ssh:notty	165.227.52.184
ktg	ssh:notty	165.227.52.184
lhsm	ssh:notty	118.25.182.118
llw	ssh:notty	116.177.20.50
lzc	ssh:notty	180.76.249.74
mgh	ssh:notty	106.12.73.198
mho	ssh:notty	61.32.6.30
mmp	ssh:notty	81.71.147.245
mrlh	ssh:notty	167.172.133.221
mrph	ssh:notty	106.75.214.72
mrtx	ssh:notty	165.22.14.228
mzx	ssh:notty	203.195.144.114
oab	ssh:notty	51.81.34.189
pth	ssh:notty	165.22.14.228
qcz	ssh:notty	95.181.188.200
qkm	ssh:notty	209.141.34.47
qwz	ssh:notty	103.232.120.109
qxy	ssh:notty	203.195.144.114
root	ssh:notty	102.164.108.43
root	ssh:notty	103.207.11.6
root	ssh:notty	106.13.182.41
root	ssh:notty	106.38.158.131
root	ssh:notty	106.53.92.254
root	ssh:notty	106.55.4.113
root	ssh:notty	110.45.155.101
root	ssh:notty	111.74.11.82
root	ssh:notty	118.70.170.120
root	ssh:notty	118.89.241.214
root	ssh:notty	119.28.88.198
root	ssh:notty	122.152.220.161
root	ssh:notty	124.152.118.131
root	ssh:notty	125.99.72.27
root	ssh:notty	128.199.141.33
root	ssh:notty	128.199.99.204
root	ssh:notty	14.225.27.88
root	ssh:notty	149.129.39.164
root	ssh:notty	157.230.122.80
root	ssh:notty	159.203.82.179
root	ssh:notty	159.89.82.134
root	ssh:notty	165.84.180.12
root	ssh:notty	167.172.138.176
root	ssh:notty	167.99.224.27
root	ssh:notty	178.128.248.121
root	ssh:notty	188.187.108.131
root	ssh:notty	200.159.91.130
root	ssh:notty	202.61.135.122
root	ssh:notty	203.189.253.170
root	ssh:notty	218.89.222.16
root	ssh:notty	36.112.172.125
root	ssh:notty	43.226.69.103
root	ssh:notty	45.55.189.252
root	ssh:notty	51.68.44.154
root	ssh:notty	58.87.72.225
root	ssh:notty	59.111.89.240
root	ssh:notty	66.249.155.245
root	ssh:notty	91.126.18.130
root	ssh:notty	95.181.131.153
smcx	ssh:notty	61.32.6.30
stzz	ssh:notty	165.232.65.66
xfo	ssh:notty	118.24.158.42
xxf	ssh:notty	106.53.249.98
xxw	ssh:notty	51.81.34.189
yhp	ssh:notty	119.45.60.204
zxl	ssh:notty	129.211.91.213
zzzy	ssh:notty	64.227.96.133

Ez egyetlen nap. Nem szerver. Desktop gép.

  • 2654 megtekintés

( uid_18247 | 2020. 12. 03., cs – 21:23 )

95.181.188.200                                      
country:         EU  #  Country  is  really  world  wide
129.211.185.246                                     
country:         CN                                 
country:         CN                                 
country:         ZZ                                 
country:         CN                                 
111.231.62.191                                      
country:         CN                                 
country:         CN                                 
country:         CN                                 
country:         CN                                 
201.48.192.60                                       
country:         BR                                 
country:         BR                                 
country:         BR                                 
country:         BR                                 
114.207.139.203                                     
country:         KR                                 
country:         KR                                 
country:         KR                                 
country:         KR                                 
120.48.12.77                                        
country:         CN                                 
country:         CN                                 
111.231.62.191                                      
country:         CN                                 
country:         CN                                 
country:         CN                                 
country:         CN                                 
106.52.105.178                                      
country:         CN                                 
country:         CN                                 
country:         CN                                 
country:         CN                                 
106.53.114.90                                       
country:         CN                                 
country:         CN                                 
country:         CN                                 
country:         CN                                 
165.227.52.184                                      
165.227.52.184                                      
118.25.182.118                                      
country:         CN                                 
country:         CN                                 
country:         ZZ                                 
country:         CN                                 
116.177.20.50                                       
country:         CN                                 
country:         CN                                 
country:         CN                                 
180.76.249.74                                       
country:         CN                                 
country:         CN                                 
country:         CN                                 
country:         CN                                 
106.12.73.198                                       
country:         CN                                 
country:         CN                                 
country:         CN                                 
country:         CN                                 
61.32.6.30                                          
country:         KR                                 
country:         KR                                 
country:         KR                                 
country:         KR                                 
81.71.147.245                                       
country:         EU  #  Country  is  really  world  wide
167.172.133.221                                     
country:         US                                 
106.75.214.72                                       
country:         CN                                 
country:         CN                                 
165.22.14.228                                       
203.195.144.114                                     
country:         CN                                 
country:         CN                                 
country:         CN                                 
country:         CN                                 
51.81.34.189                                        
country:         EU  #  Country  is  really  world  wide
165.22.14.228                                       
95.181.188.200                                      
country:         EU  #  Country  is  really  world  wide
209.141.34.47                                       
103.232.120.109                                     
country:         VN                                 
country:         VN                                 
country:         VN                                 
203.195.144.114                                     
country:         CN                                 
country:         CN                                 
country:         CN                                 
country:         CN                                 
102.164.108.43                                      
country:         ZA                                 
country:         ZA                                 
103.207.11.6                                        
country:         IN                                 
country:         IN                                 
106.13.182.41                                       
country:         CN                                 
country:         CN                                 
country:         CN                                 
country:         CN                                 
106.38.158.131                                      
country:         CN                                 
country:         cn                                 
106.53.92.254                                       
country:         CN                                 
country:         CN                                 
country:         CN                                 
country:         CN                                 
106.55.4.113                                        
country:         CN                                 
country:         CN                                 
country:         CN                                 
country:         CN                                 
110.45.155.101                                      
country:         KR                                 
country:         KR                                 
country:         KR                                 
country:         KR                                 
country:         KR                                 
111.74.11.82                                        
country:         CN                                 
country:         CN                                 
118.70.170.120                                      
country:         vn                                 
country:         VN                                 
country:         VN                                 
118.89.241.214                                      
country:         CN                                 
country:         CN                                 
country:         CN                                 
country:         CN                                 
119.28.88.198                                       
country:         HK                                 
country:         CN                                 
country:         CN                                 
122.152.220.161                                     
country:         CN                                 
country:         CN                                 
country:         CN                                 
country:         CN                                 
124.152.118.131                                     
country:         CN                                 
country:         CN                                 
country:         CN                                 
country:         CN                                 
125.99.72.27                                        
country:         IN                                 
country:         IN                                 
country:         IN                                 
country:         IN                                 
128.199.141.33                                      
country:         US                                 
128.199.99.204                                      
country:         US                                 
14.225.27.88                                        
country:         VN                                 
country:         VN                                 
149.129.39.164                                      
country:         SG                                 
country:         SG                                 
157.230.122.80                                      
159.203.82.179                                      
159.89.82.134                                       
165.84.180.12                                       
country:         HK                                 
country:         HK                                 
country:         ZZ                                 
country:         HK                                 
167.172.138.176                                     
country:         US                                 
167.99.224.27                                       
178.128.248.121                                     
country:         NL                                 
188.187.108.131                                     
country:         RU                                 
200.159.91.130                                      
country:         BR                                 
country:         BR                                 
country:         BR                                 
country:         BR                                 
202.61.135.122                                      
country:         HK                                 
country:         HK                                 
203.189.253.170                                     
country:         IN                                 
country:         IN                                 
218.89.222.16                                       
country:         CN                                 
country:         CN                                 
country:         CN                                 
36.112.172.125                                      
country:         CN                                 
country:         CN                                 
43.226.69.103                                       
country:         CN                                 
country:         CN                                 
country:         CN                                 
45.55.189.252                                       
51.68.44.154                                        
country:         FR                                 
58.87.72.225                                        
country:         CN                                 
country:         CN                                 
country:         CN                                 
country:         CN                                 
59.111.89.240                                       
country:         CN                                 
country:         CN                                 
66.249.155.245                                      
91.126.18.130                                       
country:         ES                                 
95.181.131.153                                      
country:         RU                                 
61.32.6.30                                          
country:         KR                                 
country:         KR                                 
country:         KR                                 
country:         KR                                 
165.232.65.66                                       
118.24.158.42                                       
country:         CN                                 
country:         CN                                 
country:         ZZ                                 
country:         CN                                 
106.53.249.98                                       
country:         CN                                 
country:         CN                                 
country:         CN                                 
country:         CN                                 
51.81.34.189                                        
country:         EU  #  Country  is  really  world  wide
119.45.60.204                                       
country:         CN                                 
country:         CN                                 
country:         CN                                 
129.211.91.213                                      
country:         CN                                 
country:         CN                                 
country:         ZZ                                 
country:         CN                                 
64.227.96.133

( _ventura_ v | 2020. 12. 03., cs – 21:40 )

Pár napja teszt notimon teszteltem. PPPoE -n kapott publikus -t, 1 perc alatt 2 helyről léptek be rá ssh-n. :D

Pár éve ehhez 5-10 perc kellett. sok éve meg 1-2 nap.

Fedora 41, Thinkpad x280

Nem vagyok tőle boldog. Szokták támadni a gépet, de ez most 1000/nap fölött van már. Egy másik gépen 1800/nap úgy, hogy a gép csak néhány órát volt bekapcsolva, valamint az ssh nem a 22-es porton van egyik gépen sem. Korábbi támadások megálltak néhány tíz, néhány száznál egy hét alatt. Mi a fene van most?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nincsen semmi, csak a szokasos :D A sok gigabites net, eros gep/telefon stb. Pár hónapja olvastam, hogy egy erős geppel 10GbE-n vagy valami ilyesmi pár pers alatt végig lehet scannelni az egész ipv4 tartományt :D

ipv6-on ez még jóval tovább tart :D

Fedora 41, Thinkpad x280

( Wooody | 2020. 12. 03., cs – 23:34 )

Szerkesztve: 2020. 12. 03., cs – 23:35

Nálunk az egyik családtag "WD TV Media Player-t" + my cloud-t teljesen le kellett tiltani. A gigabites neten és belső hálón, akkora forgalmat csinált, hogy az összes többi gép IP-t sem kapott a dhcp-től.

"ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett" 

és 100 éve még boszorkányt is égettek 

( Mcsiv v | 2020. 12. 03., cs – 23:37 )

ohh, ugyan. Webszerver, honeypot: kb masodpercenként 80-100 csatlakozas ssh-ra, orankent kb 1500 uj ip cimmel gazdagodik a tuzfal

// Happy debugging, suckers
#define true (rand() > 10)

( locsemege v | 2020. 12. 03., cs – 23:40 )

Van arra valami szabály, táblázat, hogy magyarországi szolgáltatók - az összes lehetséges - milyen IP-tartományból oszt címeket? Mert ha igen, csinálnék egy allow list-et, aztán mindenki más már a router-ről lepattanna, országon belülről meg be tudnék ssh-zni a gépre. Akkor is támadható maradnék, csak jelentősen megcsappanna ezek száma.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

iptables geoip modulja pont erre jó

Az erre alkalmas  geoip adatbázis régebben a maxmind-től ingyen leszedhető volt, valamit azóta tekertek a dolgon.

összerakás után kb. ennyi az egész:

iptables -A INPUT   -m geoip --source-country HU  -j ACCEPT

epp arra jartam, catoltam a scriptet, ha valakit erdekel:

function populateipset()
{
    COUNTRY=$1
    IPSET=$2
    GEONAME_ID=$(grep $COUNTRY $TMPDIR/GeoLite2-Country-CSV_*/GeoLite2-Country-Locations-en.csv |cut -d, -f1)

    (echo "create $IPSET hash:net family inet hashsize 4096 maxelem 65536"; \
     grep $GEONAME_ID $TMPDIR/GeoLite2-Country-CSV_*/GeoLite2-Country-Blocks-IPv4.csv|cut -d, -f1|sed "s/^/add $IPSET /")|ipset restore -!
}

TMPDIR=$(mktemp -d -t geoip-XXXXXXXXXX);

YOUR_LICENSE_KEY=`sed -nE 's/LicenseKey (.+)/\1/p' /etc/GeoIP.conf`

wget -qO $TMPDIR/GeoLite2-Country-CSV.zip "https://download.maxmind.com/app/geoip_download?edition_id=GeoLite2-Country-CSV&license_key=$YOUR_LICENSE_KEY&suffix=zip"
unzip -q -d $TMPDIR $TMPDIR/GeoLite2-Country-CSV.zip

#populateipset China china

populateipset Hungary hungary

rm -rf $TMPDIR

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( DJTommyka v | 2020. 12. 04., p – 08:31 )

Szerkesztve: 2020. 12. 04., p – 09:06 
00000000	ssh:notty	106.12.132.224
00000000	ssh:notty	51.161.32.211
0000	ssh:notty	185.153.196.230
0101	ssh:notty	87.251.77.206
0	ssh:notty	185.153.196.230
0	ssh:notty	45.141.84.126
10203010	ssh:notty	106.12.132.224
10203010	ssh:notty	51.161.32.211
111111	ssh:notty	185.153.196.230
111111	ssh:notty	45.141.84.126
1111	ssh:notty	185.153.196.230
1111	ssh:notty	45.141.84.126
1122334	ssh:notty	106.12.132.224
11235813	ssh:notty	111.229.35.95
11235813	ssh:notty	5.183.80.79
1212	ssh:notty	111.229.35.95
12304560	ssh:notty	111.229.35.95
12312312	ssh:notty	111.229.35.95
123321	ssh:notty	185.153.196.230
123321	ssh:notty	45.141.84.126
12345678	ssh:notty	111.229.35.95
123456mm	ssh:notty	106.12.132.224
123456ya	ssh:notty	106.12.132.224
123456ya	ssh:notty	51.161.32.211
12345j	ssh:notty	106.12.132.224
12345j	ssh:notty	51.161.32.211
12345	ssh:notty	171.240.194.8
12345	ssh:notty	185.153.196.230
12345	ssh:notty	45.141.84.126
1234	ssh:notty	141.98.9.162
1234	ssh:notty	185.153.196.230
1234	ssh:notty	45.141.84.126
123abcd	ssh:notty	171.239.249.229
1.2.3.	ssh:notty	111.229.35.95
123	ssh:notty	185.153.196.230
123	ssh:notty	45.141.84.126
1.2.3.	ssh:notty	5.183.80.79
1314521.	ssh:notty	111.229.35.95
1314521.	ssh:notty	5.183.80.79
14725836	ssh:notty	111.229.35.95
1541	ssh:notty	111.229.35.95
1541	ssh:notty	5.183.80.79
159357a	ssh:notty	106.12.132.224
15975346	ssh:notty	5.183.80.79
198611	ssh:notty	5.183.80.79
19941994	ssh:notty	106.12.132.224
1e905c	ssh:notty	116.98.160.160
22	ssh:notty	171.240.194.8
22	ssh:notty	185.153.196.230
22	ssh:notty	45.141.84.126
31415926	ssh:notty	111.229.35.95
31415926	ssh:notty	5.183.80.79
3user	ssh:notty	171.239.249.229
5201314l	ssh:notty	106.12.132.224
54321	ssh:notty	5.183.80.79
55667788	ssh:notty	111.229.35.95
55667788	ssh:notty	5.183.80.79
5fe5d4	ssh:notty	116.98.160.160
666666	ssh:notty	185.153.196.230
7410	ssh:notty	111.229.35.95
77585215	ssh:notty	106.12.132.224
888888a	ssh:notty	106.12.132.224
888888	ssh:notty	185.153.196.230
94.152.3	ssh:notty	34.75.54.3
94.23.11	ssh:notty	54.37.91.197
94.231.1	ssh:notty	54.37.91.197
94.23.1.	ssh:notty	54.37.91.197
94.250.1	ssh:notty	34.75.54.3
aaa12312	ssh:notty	106.12.132.224
aab	ssh:notty	152.136.173.58
aam	ssh:notty	101.36.109.214
aaron	ssh:notty	185.153.196.230
aa	ssh:notty	159.89.237.57
aa	ssh:notty	165.227.182.136
aax	ssh:notty	124.205.84.21
aay	ssh:notty	101.36.109.214
abd	ssh:notty	61.157.18.2
abe	ssh:notty	220.85.233.146
abf	ssh:notty	198.27.66.37
abm	ssh:notty	118.89.138.117
abm	ssh:notty	177.73.2.57
abn	ssh:notty	167.71.254.137
abp	ssh:notty	160.153.252.187
abt	ssh:notty	159.65.137.109
aby	ssh:notty	172.81.206.23
acb	ssh:notty	124.207.98.213
acc	ssh:notty	106.54.57.203
acc	ssh:notty	129.204.33.4
acc	ssh:notty	45.141.84.126
acm	ssh:notty	122.35.120.59
acm	ssh:notty	182.61.168.185
acq	ssh:notty	122.51.77.182
acx	ssh:notty	122.51.77.182
adam	ssh:notty	185.153.196.230
adam	ssh:notty	45.141.84.126
add	ssh:notty	116.98.160.160
ade	ssh:notty	121.46.26.126
adf	ssh:notty	129.211.94.145
adim	ssh:notty	116.98.160.160
adl	ssh:notty	106.52.122.203
admian	ssh:notty	116.98.160.160
admin1	ssh:notty	185.153.196.230
admin2	ssh:notty	45.141.84.126
administ	ssh:notty	116.98.160.160
Administ	ssh:notty	141.98.9.165
administ	ssh:notty	171.239.249.229
administ	ssh:notty	185.153.196.230
Administ	ssh:notty	185.153.196.230
administ	ssh:notty	45.141.84.126
Administ	ssh:notty	45.141.84.126
admin	ssh:notty	116.110.76.168
admin	ssh:notty	116.98.160.160
admin	ssh:notty	139.59.130.53
admin	ssh:notty	141.98.81.194
admin	ssh:notty	141.98.81.196
admin	ssh:notty	141.98.81.202
admin	ssh:notty	141.98.9.164
Admin	ssh:notty	141.98.9.164
admin	ssh:notty	141.98.9.166
admin	ssh:notty	141.98.9.167
admin	ssh:notty	171.227.208.166
admin	ssh:notty	171.239.249.229
admin	ssh:notty	171.240.194.8
admin	ssh:notty	185.153.196.230
Admin	ssh:notty	185.153.196.230
admin	ssh:notty	185.156.214.22
admin	ssh:notty	186.47.81.189
admin	ssh:notty	222.127.151.230
admin	ssh:notty	24.179.47.155
admin	ssh:notty	27.69.245.10
admin	ssh:notty	45.141.84.126
Admin	ssh:notty	45.141.84.126
admin	ssh:notty	61.149.89.249
admin	ssh:notty	87.241.1.186
admin	ssh:notty	87.251.77.206
admi	ssh:notty	116.98.160.160
adm	ssh:notty	171.240.194.8
adm	ssh:notty	185.153.196.230
adm	ssh:notty	45.141.84.126
adn	ssh:notty	118.27.19.96
adn	ssh:notty	165.22.223.121
adrienne	ssh:notty	111.229.35.95
adrienne	ssh:notty	5.183.80.79
adz	ssh:notty	157.245.98.160
aep	ssh:notty	118.89.138.117
aep	ssh:notty	177.73.2.57
aeq	ssh:notty	122.35.120.59
aeq	ssh:notty	182.61.168.185
ae	ssh:notty	109.168.109.50
aff	ssh:notty	202.153.37.194
afj	ssh:notty	5.3.6.82
afs	ssh:notty	160.153.252.187
agent	ssh:notty	185.153.196.230
agent	ssh:notty	45.141.84.126
agf	ssh:notty	109.168.109.50
agm	ssh:notty	61.157.18.2
ags	ssh:notty	160.153.252.187
ahb	ssh:notty	118.89.138.117
ahb	ssh:notty	177.73.2.57
ahh	ssh:notty	121.46.26.126
ahj	ssh:notty	165.232.105.80
aht	ssh:notty	206.189.180.178
ahx	ssh:notty	148.240.70.42
aidvolun	ssh:notty	171.239.249.229
aini1314	ssh:notty	111.229.35.95
aini1314	ssh:notty	5.183.80.79
ainiyibe	ssh:notty	51.161.32.211
aishiter	ssh:notty	111.229.35.95
aja	ssh:notty	124.207.98.213
ajc	ssh:notty	122.53.98.243
ajd	ssh:notty	111.229.194.156
ajf	ssh:notty	165.232.105.80
ajj	ssh:notty	159.89.237.57
ajn	ssh:notty	34.95.29.237
aj	ssh:notty	34.95.29.237
ajs	ssh:notty	153.127.37.59
ajs	ssh:notty	61.149.254.214
aka	ssh:notty	124.205.84.21
akk	ssh:notty	220.85.233.146
ak	ssh:notty	81.70.21.113
.
.
.

5220 line-t nem akarok beilleszteni..

( uid_17626 | 2020. 12. 04., p – 17:27 )

Egyik gépemen 5600 volt a napi próbálkozás. (Van fail2ban)

( Ar0n v | 2020. 12. 04., p – 17:37 )

En nem hasznalom az ssh-t default porton. Persze ez nem vedelem, de atlag bot nem nagyon scannel alternativ portokra.

Ezen felul a pam_google_authenticator-t hasznalom ami tud rate limit-et is.

WireGuard mogott pedig nem ker OTP-t.

Ezen felul ezeket huzom be a routerembe:

http://feeds.dshield.org/block.txt
http://www.spamhaus.org/drop/drop.lasso
https://lists.blocklist.de/lists/all.txt
https://api.abuseipdb.com/api/v2/blacklist (ide reg kell)

( locsemege v | 2020. 12. 05., szo – 10:10 )

Foglalkoznom kell vele, eléggé frusztráló. Ez eddig nem így volt.

su -
Password: 
Last failed login: Sat Dec  5 10:00:47 CET 2020 from 14.63.167.192 on ssh:notty
There were 3140 failed login attempts since the last successful login.

3140 sikertelen próbálkozás az utolsó sikeres óta. Az az utolsó sikeres tegnap este általam volt, azóta alig néhány órát volt bekapcsolva a gépem.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( locsemege v | 2020. 12. 05., szo – 12:11 )

Elmúlt két óra. Ez alatt:

su -
Password: 
Last failed login: Sat Dec  5 12:09:00 CET 2020 from 43.254.156.48 on ssh:notty
There were 3798 failed login attempts since the last successful login.

Nagyon gyorsan foglalkoznom kell ezzel érdemben.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( meditor | 2020. 12. 05., szo – 12:27 )

A mandinert is le DDoS-olták, le kellett vágni a netről.

> Sol omnibus lucet.

Ja, le bizony. Az L7 támadást még csak-csak meg lehetett fogni, viszonylag egyszerűen szűrhető volt a HTTP kérések mintázata alapján (bár ezt is variálták, több ezer IP címről egyébként, amik folyamatosan bővültek), de volt ott L3-L4 is relatíve nagy sávszéllel (60 Gbps), amitől a szolgáltató megfeküdt, és jobb híján blackhole-ra tette a mandiner IP-t. Kifogyhatatlan tűzerőnek tűnt, vagy 10 órán keresztül nem szűnt meg.

( meditor | 2020. 12. 05., szo – 12:32 )

Apropó, melyik portot támadták?

Nekem szép tiszta a logfile. (Az sshd a nem_mondom_meg_melyik porton fut.)

> Sol omnibus lucet.

( Sixday v | 2020. 12. 05., szo – 12:36 )

Szerkesztve: 2020. 12. 05., szo – 12:38

Konyorgom van meg egyaltalan valaki igy 2020 vegen aki olyan naiv hogy default porton futtat ssh-t?

Fel kell rakni valahova 5000 fole es a probalkozasok 99.9%-a azonnal megszunik.

Raadasul ha valaki igy is megtalalja az eros figyelmezteto jel hogy valoszinuleg celzottan szkennelik a gepet, ergo lehet ra rakni sokkal szigorubb fail2ban-t, ertsd: ha itt is raprobal valaki akkor minden porton ban legalabb 1-2 hetre.

a kisebb logfajl az elony

Szerintem ez egy olyan elony, ami miatt mar megeri!

Ha a jovoben talalnak valami exploitalhato hibat az openssh-ban, akkor baj van :/ Ha default porton csung, garantaltan meg fognak probalni bejonni, hiaba van fail2ban, kulcsos login ...

Ha mar non-default porton csucsul akkor atlag bot nem fogja megtalalni. Persze ez kicsit ilyen security by obscurity-szeru, ezert ezen felul mindenkepp meg kell gatolni, hogy egyaltalan be tudjanak csatlakozni.

Mar itt is leirtak ... pl. lehet csak egy jump hostot engedelyezni, vpn, port knocking stb...

Ha mar non-default porton csucsul akkor atlag bot nem fogja megtalalni. Persze ez kicsit ilyen security by obscurity-szeru [...]

Ha lesz olan 0day, amivel be tudnak jönni SSH-n, akkor azt valószínűleg nem a kínai botnet fogja szőnyegbombázásra használni., úgyhogy a port változtatás imho nem sok vizet zavarna már. :)

azert ha a fel vilag ki van zarva a ssh-bol, akkor a kinai botnet nemfog jonni (max csak a magyar). de addig is _nyerhetsz_ idot, hogy kezeld a problemat. bar allitolag ez csak fals szubjektiv biztonsagerzetet ad... :)

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Miből gondolod, hogy a kínai botnetnek nincsenek magyarországi eszközei? Nincs eladva kismillió kínai IP kamera, router, AP, okos-ez-az, ugye? Amelyekben ha nincs is kínai állami backdoor, akkor is az eredeti több éves szoftver fut, sokszor default név és jelszó kombinációval. Na, ezekről fogod kapni a valódi támadást, szóval nyilván nyerhetsz egy szekérderéknyi időt, bármennyi legyen is az.

Tudod, az a baj ezzel a mentalitással, hogy ténylegesen befoltoztál az ezerlyukú szitádon egy-két igen apró lyukat és teljesen megnyugodtál, hogy nyerhetsz időt, ha jön a liszt. Holott a valóság az, hogy vélhetően észre se veszed, hogy megtörtek, csak ha valami nagyon elbaszott rootkit elkezd feltűnően kripto-bányászni. Hamis biztonságérzet, nem győzöm elégszer hangsúlyozni.

Van grafikonod és riasztási küszöböd például arról, hogy mennyi SSH request jön? Ha nincs, akkor honnan tudod, hogy merről fúj a szél és mekkorák a hullámok? Véletlenül épp ránézel és beszarsz, hogy több ezres számot látsz?

https://iotguru.cloud

ezt a hamis biztonsagerzet dolgot nem tudom honnan szivod. en tisztaban vagyok vele hogy csomo minden torheto igy-ugy. de szerintem minden dolog ami csokkenti a bejutas P valoszinuseget, azt erdemes megtenni. attol  hogy megvan ez-az, meg nem dolok hatra hogy "kesz vagyok".

de ha te ugy gondolod hogy a default porton vilag szamara elerheto kulcsos ssh eleg, lelkeld rajta. mas meg ugy gondolja hogy ez nem eleg. nyilvan ez mellett meg kell alert/monitor rendszer ami a loginolasokat figyeli, stbstb.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

ezt a hamis biztonsagerzet dolgot nem tudom honnan szivod.

Én azt nem tudom, hogy mit szívsz, ha például a port áthelyezésével úgy tudod, hogy objektív szempontból nagyobb biztonságba kerülsz.

mas meg ugy gondolja hogy ez nem eleg.

Aha, más úgy érzi, hogy nem elég.

nyilvan ez mellett meg kell alert/monitor rendszer ami a loginolasokat figyeli, stbstb.

És van ilyen?

https://iotguru.cloud

Nem a default porton van. A port továbbításom valami ilyesmi:

config redirect
	option target 'DNAT'
	option src 'wan'
	option dest 'lan'
	option proto 'tcp'
	option src_dport '5432'
	option dest_ip '192.168.0.99'
	option dest_port '22'
	option name 'ssh hostneve'

Értelemszerűen a port, a hostnév és az IP-cím más. Ha jól látom, ez lett belőle:

-A zone_wan_prerouting -p tcp -m tcp --dport 5432 -m comment --comment "!fw3: ssh hostneve" -j DNAT --to-destination 192.168.0.99:22

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

 

Konyorgom van meg egyaltalan valaki igy 2020 vegen aki olyan naiv hogy default porton futtat ssh-t?

Nálam a default porton van. Igaz, a bejutáshoz kettő próbálkozásból ki kell találni egy 4096 bites RSA kulcsot, és egy 6 karakteres TOTP-t. Egyszer tévedni emberi dolog, a másodiknál jön a fail2ban.

Problem? :)

( locsemege v | 2020. 12. 05., szo – 13:41 )

Egyébként annak örülök, hogy többnyire root login-nal próbálkoznak. A PermitRootLogin no miatt. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( locsemege v | 2020. 12. 05., szo – 16:39 )

Azt tudja valaki, hogy az xt_geoip_build parancsa egyes leírások szerint miért hoz létre LE és BE alkönyvtárakat? Érzésre a little endian és big endian a tippem. Azért kérdezem, mert Fedorán ez a perl script országonkénti bontásban az aktuális könyvtárba behányta az eredményt, de gyanítom, hogy itt ez little endian. Vajon a mips_24kc az mi? Aztán mi van, ha az LE és BE mégsem ezt jelenti? Már csak azért is, mert mindenféle doksiban azt látom, hogy mindkét könyvtár tartalmát felteszik a router-re.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Belenéztem a bináris file-ba. Érdekes, mert ránézésre big endian-osnak néz ki:

02 3A A8 00 │ 02 3A AB FF │ 02 3B C4 00 │ 02 3B C7 FF

Ez ebből lett:

2.58.168.0,2.58.171.255,HU
2.59.196.0,2.59.199.255,HU

Ennek az LE változata vajon ez?

00 a8 3a 02 | ff ab 3a 02 | 00 c4 3b 02 | ff c7 3b 02

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ja, hogy így gyorsítanak a kernel modul futásán? Hol így, hol úgy kell, és egyszerűbb duplikáltan tárolni, mint pakolászni a memóriában? Nem tudom, mert szerintem a file elérés nagyságrendekkel lassabb, ha meg az elején RAM-ba húzza, akkor azzal a lendülettel előállíthatná az LE-t is, ha valamiért annyira ügyetlenül írták meg, hogy kell neki ez is, az is.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( Ritter | 2020. 12. 05., szo – 16:53 )

Vagy egy etikus hacker hallgató elbaszta az ip címet valamelyik oktató hálózaton. :)

( locsemege v | 2020. 12. 05., szo – 18:42 )

Közben ránéztem a router logjára. Azt is próbálják felnyomni. :(

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( voiper | 2020. 12. 05., szo – 18:48 )

Nekem bevált, ha sokjegyű számos portra tettem az ssh-t és minden, nem magyar ip címről drop a kapcsolat.

Az eddigi tapasztalat alapján nem Mo-i ip címekről próbálkoznak.

 

A tűzfal szabályom:

 -A INPUT -p tcp -m set ! --match-set hu.zone src -m tcp --dport xxxx -j DROP

 

Ahol xxxx értelemszerűen a használt ssh port.

 

Rebootkor egy script segítségével jön létre a lista, esetleg nem árthat mondjuk ezt az ip listát hetente lekérni.

A script semmi érdekes, ennyi csak a lényege:

 

# Hungary
ipset -F hu.zone
ipset -N hu.zone nethash
for IP in $(wget -O - http://www.ipdeny.com/ipblocks/data/countries/hu.zone)
        do ipset -A hu.zone $IP
        echo $IP
done
 

Most vagyok bajban, mert hiányosak az iptables ismereteim. Lehetne a /etc/firewall.user file-ban egy szabály. Például:

iptables -I zone_wan -p tcp --dport 5432:5433 -m geoip --src-cc HU -j ACCEPT

Értelemszerűen a portok mások, de ezt egyelőre hagyjuk. Eleve -A vagy -I? Meg aztán a példában az 5432-es port forwardolódna a desktop gép felé, míg az 5433 lenne a routerre ssh-zás. Nagyobb gondom, hogy hogyan tudom mindezt tesztelni?

Vagy inverz feltétellel DROP szabály kellene? Nem világos, hogy az OpenWrt-ben megadott többi szabály ezzel logikai ÉS vagy VAGY kapcsolatban lesz, szekvenciális-e a végrehajtás, kilép-e a kernel valamelyik target-nél, vagy hogyan van ez. Mert semmire sem megyek a szabállyal, ha egy másik felülírja azt.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

-I a chain elejére, -I chain n a chain n. helyére, -A a chain végére szúrja be a rule-t.

Szekvenciális. Tesztelni online portscanner-rel.

> Meg aztán a példában az 5432-es port forwardolódna a desktop gép felé, míg az 5433 lenne a routerre ssh-zás

Én létrehoznék egy chain-t, amiben a geoip invertáltja drop, és azt -j az input-ból és a forward-ból.

Bocs, nem ellenségeskedés, de a kérdéseid alapján elég hiányosak az iptables ismereteid ahhoz, hogy egy router tűzfalát konfigold.

Otthoni szappantartón OpenWrt/LEDE daily snapshot, nyugalom, nem céges üzemeltetés. :) A -A-ra és -I-re még emlékeztem, de nem teljesen tiszta az egész. Már nem az append és insert, hanem úgy általában az, hogyan burjánzik át egy csomag a filter szabályokon. Ha a szabály sorában teljesül a feltétel, akkor gondolom, a -j target, és ott kilép, ha nem, akkor jön a következő szabály.

Meg aztán amit forward-olni fog, arra az input szabályok alkalmazva lesznek? Ja, most látom, ezt megválaszoltad. Köszönöm.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

eloszor a port alapjan a vizsgalat menjen egy kulon chainbe. majd abban a chainben lehet a magyart acceptelni, a chain vegen meg egy feltetel nelkuli DROP. elotte akar loggolhatsz is, eseleg ebbe a chainbe felvehetsz egyedi whitellist ipket is.

 

ahogy fenn is irtak, szepen lepked a szabalyokon, es ahol drop/accept/reject/queue/stb -t talal, vegrehajtja, es megall. vannak specialis szabalyok ami utan tortenik valami es folytatodik a lepkedes (return, log)

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Nézem Fedorán a man page-et, meg sem emlékezik olyanról, hogy az ipset-nek lenne -F, -N, -A kapcsolója. Gondolom, a -A az add, a -F talán a flush, a -N pedig a create akar lenni. Bár azt nem tudom, hogyan lehet valamit flush-ölni, ami még nem is létezik. Azt a nethash-t sem értem a for előtti sorban. A többi világos.

Ez a megoldás jobb, mint az iptables geoip modulja? Arra értelemszerűen tudok programot írni, hogy a cím/mask_length párosból kezdőcím,végcím kettőst csináljon, tehát ezt az adatbázist is fel tudom használni a geoip modulhoz.

Most sajnos fontos egyéb elfoglaltságom van, nem tudok vele foglalkozni, de meg fogom csinálni az adatbázis automatikus frissítését a routerben.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ezt voiper írta, nem én:

# Hungary
ipset -F hu.zone
ipset -N hu.zone nethash
for IP in $(wget -O - http://www.ipdeny.com/ipblocks/data/countries/hu.zone)
        do ipset -A hu.zone $IP
        echo $IP
done

Ezek szerint valami ilyesmi lenne:

# Hungary
ipset create hu.zone nethash -exist
ipset flush hu.zone
for IP in $(wget -O - http://www.ipdeny.com/ipblocks/data/countries/hu.zone); do
    ipset add hu.zone $IP
    echo $IP
done

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Közben olvasom, hogy az a nethash is rossz, hash:net kell oda, vagy ki kell találni, hogyan tudja memóriában hatékonyan tárolni ezt, s aszerint lehet neki megmondani, hogy mi legyen. Egyébként ez Kadlecsik Józsi munkája? Mármint az ipset.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

nekem ez volt az v1 scriptem:

(echo -n "flush china\ncreate china hash:net family inet hashsize 4096 maxelem 65536"; curl -s http://www.ipdeny.com/ipblocks/data/countries/cn.zone|sed 's/^/add china /')|ipset restore -!

igy nemkell 28ezerszer meghivni az ipset-et loopban. a v2 script mar valtott geoip-re.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Ja, hát aki elolvassa, hogy van restore. :) Mi miatt dobtad az ipset-et és váltottál geoip-re? Mert OpenWrt-ben van mindkettő, s egyelőre nem döntöttem el, melyik mellett maradjak.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

locsemege nem akartalak félrevezetni, nekem ez működött. Igaz, hogy nem openwrt alapon néztem, ez egy debian.

 

:~# ipset -N test.zone nethash
:~# ipset -A test.zone 15.15.15.15
:~# ipset test test.zone 15.15.15.15
15.15.15.15 is in set test.zone.
:~# ipset version
ipset v6.38, protocol version: 6
:~# cat /etc/debian_version
10.7

( locsemege v | 2020. 12. 05., szo – 22:20 )

Teljesen megháborodott a világ a vélhetően fertőzött zombi csordáival. Az utóbbi órákban 8137 betörési kísérletet tapasztaltam, viszont úgy néz ki, sikerült kifaragnom a megfelelő tűzfal szabályt, így vége a játszadozásnak. 22:08-kor volt az utolsó támadási kísérlet, akkor tettem aktívvá a szabályt. Azért azt is tesztelni kell, hogy engem beenged-e.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( Elbandi v | 2020. 12. 05., szo – 23:45 )

hmm, eljatszadoztam ezzel a ipdeny listaval, es osszehasonlitottam a geoip country (lite) db-vel.

talaltam eleg sok ipt, amit a geoip ch-nak mond, de a ipdeny-n nincs benne a cn.zone-ban

pl: 3.5.236.0/22

de talaltam olyat is amire azt mondja hogy nem cn, a cn.zone-ban meg benne van.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Mivel nekem az otthoni gép elérhetősége kell, elég volt ennyi:

-A forwarding_wan_rule -m geoip ! --source-country HU  -j DROP
-A input_wan_rule -m geoip ! --source-country HU  -j DROP

Elég, ha országon belülről be tudok ssh-zni a router-emre és a gépemre. Majd még az adatbázis frissítését kell megoldanom, de egyelőre jó ez. Lehet, hogy a konverzióra írok egy nyúlfaroknyi C kódot, bár ahhoz jó eséllyel fel kell tennem a gépemre az OpenWrt SDK-ját.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( locsemege v | 2020. 12. 06., v – 00:29 )

Többnyire root, néha root1, root2, rootftp, dmin - így, 'a' nélkül - login nevekkel próbálkoztak. Már béke van. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( _Franko_ v | 2020. 12. 06., v – 11:17 )

Azon túl, hogy idegbajt kapsz, mi bajod van a dologgal?

Ha nem tudnak bejutni, akkor teljesen felesleges ennyire izgulni és bármit tenni; ha hajózni mész a tengerre, akkor fújni fog a szél, ez ilyen.

Ha pedig be tudnak jutni, akkor meg egy jól irányzott próbálkozás is elég, kezelhetsz listákat, tűzfalszabályokat, bármit, attól még ugyanúgy veszélyben vagy, hamis a biztonságérzeted.

https://iotguru.cloud

Megtalálták a portot, ezért próbálkoznak. Nyilván van kulcs hozzá, hiszen én például legálisan bejutok. Tehát nem lehetetlen bejutni, csak nehéz. Ha DROP a policy, nem pedig REJECT, akkor úgy tűnik, mintha nem is létezne ott a port, mintha ki lenne kapcsolva mögötte a gép. Azon túl, hogy a router-en szűrök, a gépig el sem jut a kérés, le fognak szokni a belépési kísérletekről, hiszen látszólag nincs ott semmi. Nem hamis biztonságérzet. Tegnap néhány óra alatt volt emlékeim szerint 8137 betörési kísérlet, azóta, hogy ezeket filterezem, egy sem.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Megtalálták a portot, ezért próbálkoznak. Nyilván van kulcs hozzá, hiszen én például legálisan bejutok.

És vajon mekkora eséllyel találják el a kulcsot, ha amúgy kötött név-jelszó kombinációkkal próbálkoznak?

Nem hamis biztonságérzet.

Miért, hány százalékról hány százalékra csökkentetted így a bejutási esélyeket? Ezek a cold call próbálkozások nulla kockázattal pattannak le, egy célzott támadás meg úgy hasít át a "védelmeden", hogy észre se veszed.

Tegnap néhány óra alatt volt emlékeim szerint 8137 betörési kísérlet, azóta, hogy ezeket filterezem, egy sem.

Ezek nem betörési kísérletek voltak, mert esélyük se volt bejutni. Semmit nem akadályoztál meg.

https://iotguru.cloud

Túl sok időm megy a lelked ápolására. kötekszel közéleti kérdésekben, szakmai kérdésekben egyaránt, miközben az ég egy adta világon semmit nem adsz hozzá teszem azt műszaki tartalom tekintetében egy alapvetően műszaki fórumon. És bizony, ez így nem frankó. Részemről távolságtartóan viselkedem, nem látom értelmét az efféle csevegésnek. Keress mást, akibe beleköthetsz. Az ugyanis egy emberi játszma, amikor úgy vetsz fel valamit, hogy meg kellene indokolnom, mit miért teszek. Miért kellene? Különösképp neked miért? Sem a műszaki sem pedig a közéleti, politikai gondolkodásomat és döntéseimet nem fogom hozzád szabni. Ebben a topicban láthatsz példát arra, milyen az érdemi kooperáció. Tanulj belőle!

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Teljesen valid műszaki kérdéseket tettem fel a témával kapcsolatban, de tudod, felőlem küzdhetsz a szélmalmokkal...

Ha én mindössze azzal támadlak, hogy külföldi IP címekről kitartóan próbálok bejutni nálad nem létező viszonylag kevés tételből álló username:password kombinációkkal és tiltod a külföldi IP címeket, akkor ezzel egyáltalán nem növelted a rendszered biztonságát. Ha nem tiltod ezeket, hagyod megtörténni, azzal nem csökkentetted a rendszered biztonságát. Teljesen feleslegesen vagy ideges olyan dolgok miatt, amelyek kockázatmentesek.

Vedd úgy, hogy ha valaki idetéved és elolvassa a sok kooperációs "megoldást", akkor azért tudja meg azt is, hogy ezek nem fokozzák a biztonságot.

https://iotguru.cloud

Zöldséget beszélsz. Ha volt néhány ezer támadás alig néhány óra alatt, most pedig nulla, akkor csökken a feltörés valószínűsége. Ha teszem azt, eddig 1e-10 volt annak valószínűsége, hogy feltörik a gépet, s most 1e-14 lett ez, akkor nőtt a biztonság.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ha volt néhány ezer támadás alig néhány óra alatt, most pedig nulla, akkor csökken a feltörés valószínűsége.

Szerinted mitől változna a feltörés valószínűsége, ha egyszer vagy ha tíz milliószor próbálok bejutni az aaa:111 kombinációval? Ha van ilyen, akkor elsőre bejutok, ha nincs, akkor tízmilliószor próbálva se jutok be, te meg közben komplett idegösszeomlást kapsz, hogy fel akarnak törni.

Az a tévedésed, hogy ezek nem támadások, mert ezeknek nem növekszik a bejutási kockázata a kérésekkel arányosan, mert ugyanazt a pár száz elemű kombinációt próbálják. Ha lett volna ilyen nálad, már feltörtek volna. Ha nincs ilyen felhasználóneved és jelszód, pláne csak kulcs alapján enged be az SSH, akkor nem tudnak feltörni, bármennyszer is próbálnak bejönni ugyanazokkal a kombinációkkal. Egy közepesen erős jelszóval a brutal force évekbe kerül, észrevennéd, hogy létező felhasználónévvel próbálkoznak.

Ha teszem azt, eddig 1e-10 volt annak valószínűsége, hogy feltörik a gépet, s most 1e-14 lett ez, akkor nőtt a biztonság.

Mitől nőtt volna? Nem próbálkoznak szisztematikusan, nem is támadnak célzottan.

https://iotguru.cloud

Amit írsz, az is egy feltételezésen alapul, mint ahogyan az is, hogy én azt a modellt vettem alapul, hogy olykor nagy jelszó adatbázisik kerülnek forgalomba, s azzal próbálkoznak, vagy random jelszavakkal.

Te egy kicsit túldimenzionálod ezt a helyzetet... egyrészt, mégis, mi a lófasznak próbálkoznának egy random otthoni IP tartomány random helyre tett SSH portján egy több milliós adatbázissal... hátha ugyanaz az SSH user:pass, mint amit egy megtört pornóoldalon használtál? Semmi haszna nincs. Itt ismert (=gyári default) vagy gyenge (például admin:admin) user:pass párokkal próbálnak "megtörni" különféle hálózati eszközöket: router-t, AP-t, nyomtatót, kamerát, egyebet.

Ha erős jelszavad van, amit nem használsz máshol és/vagy kulccsal engedsz csak belépést akkor védve vagy. Ha gyenge jelszavad van vagy máshol is használod, akkor meg nem vagy védve ezzel a módszerrel. Színtiszta hamis biztonságérzet.

https://iotguru.cloud

Semmi haszna nincs.

Ezzel vitatkoznek. Anno mikor a mikrotik exploit elszabadult, csunya dolgokat muveltek az otthoni cuccokkal. Ezen felul itt-ott penzt is tudtak lopni.

Parszor szedtem szet ilyen binarist, es az elso par ezer portot scannelik ... meg eleve a a konnyu predara utaznak.

Az "infected" eszkozok scannelnek, igy full automata, nem faj nekik ha vegigtolnak egy rockyou-t :)

Ha erős jelszavad van, amit nem használsz máshol és/vagy kulccsal engedsz csak belépést akkor védve vagy.

Es, atomtamadasellenisvedez? Ahogy irtam fentebb is, egy esetleges openssh hiba eseten nem ved. Ezt nem szabad elfelejteni: https://github.com/g0tmi1k/debian-ssh

En Gyuri bacsi modjara, blokkolnam :D

Jumphost, port-knocking (mondjuk http keresre), VPN stb...

Ezzel vitatkoznek. Anno mikor a mikrotik exploit elszabadult, csunya dolgokat muveltek az otthoni cuccokkal. Ezen felul itt-ott penzt is tudtak lopni.

Oszt? Ezt nem lehet megtenni ezek szerint egy magyarországi botnetből? Vagy elkonfigurált GeoIP szűrő által mégis átengedett forgalomból?

Parszor szedtem szet ilyen binarist, es az elso par ezer portot scannelik ... meg eleve a a konnyu predara utaznak.

Oszt? Bárhova teszed, megtalálják hamar, nem erőforrásigényes egy teljes portscan és ugyanott vagy.

Ahogy irtam fentebb is, egy esetleges openssh hiba eseten nem ved.

Ahogy egy csomó egyéb szoftverhiba ellen se véd, az se, ha kreatívan próbálsz védekezni, aztán nyugodtan hátra dőlsz, hogy 0 "támadás" jön. Biztonság vagy biztonságérzet.

Azért mennek más portra is a 22/tcp porton kívül, mert kurva sok a balfasz, aki áttette máshova és hátradőlt megelégedve, hogy védve van.

Azért van distributed próbálkozás, mert kurva sok a balfasz, aki rátett valami szűrést a bejövő forgalomra és hátradőlt megelégedve, hogy védve van.

Holott annyi történt, hogy jelentősen növekedett a szubjektív biztonságérzete, de a biztonsága semmivel se lett jobb.

Jumphost, port-knocking (mondjuk http keresre), VPN stb...

Frissen tartás, értelmes konfiguráció, mint olyan? A támadással arányos védekezés, mint olyan?

https://iotguru.cloud

Oszt?

Oszt, nem igazan Franko ez a stilus!

Olvasd el megegyszer kerlek amit irtam! Behoztal meg 10 masik szempontot, pedig en csak ketto kijelenteseddel kapcsolatban irtam le a gondolataimat.

A security by obscurity nem tilos, csak nem elegseges -> Az, hogy az SSH service nem a default porton csucsul az egy jo dolog, de nem elegseges.

Igy erdemes meg extra lepeseket is tenni a risk csokkentese erdekeben.

Bárhova teszed, megtalálják hamar, nem erőforrásigényes egy teljes portscan és ugyanott vagy.

Csak sok hostra idoigenyes, ezert nem is maxoljak ki. Az emlitett "balfaszokra" utaznak. De ez igazabol mind1.

Ezt nem lehet megtenni ezek szerint egy magyarországi botnetből? Vagy elkonfigurált GeoIP szűrő által mégis átengedett forgalomból?

De lehet. En nem mondtam, hogy nem.

Frissen tartás, értelmes konfiguráció, mint olyan?

Szerintem ez alap. Ismeretlen hibara viszont nehez updatet talalni. Ezen felul egy 0-day eseten ido kell mig kapsz frissiteseket.

A támadással arányos védekezés, mint olyan?
Itt ismert (=gyári default) vagy gyenge (például admin:admin) user:pass párokkal próbálnak "megtörni"

Te most az eppen aktualis threat-re szukitetted le ezt az aranyt, ami szvsz. hiba.

Ha alapbol zarva van a akarmilyen service port es mondjuk valami kulso sajat/berelt VPN service cimerol engeded be kizarolag a kapcsolatot haza, az ugy jelentosen lecsokkenti a risk-et. Vagy barmi mas megoldas is jo (pl. par dollaros VPS jumphostnak), csak ne tudjanak kozvetlenul kapcsolatot nyitni a service fele.

Ugyhogy firewall ruleokban mindig Gyuri bacsinak van igaza! En blokkolnam!

Az, hogy az SSH service nem a default porton csucsul az egy jo dolog, de nem elegseges.

Ha nem vagy vulnerable és amúgy is megtalálják, akkor minek is?

Igy erdemes meg extra lepeseket is tenni a risk csokkentese erdekeben.

Egészen pontosan milyen kockázatot csökkentesz ilyenkor? Biztonságot vagy biztonságérzetet?

Ismeretlen hibara viszont nehez updatet talalni. Ezen felul egy 0-day eseten ido kell mig kapsz frissiteseket.

Hány olyan 0day SSH sebezhetőség volt, ahol támadható voltál és az védett meg, hogy nem default porton volt az SSH?

Te most az eppen aktualis threat-re szukitetted le ezt az aranyt, ami szvsz. hiba.

Nem, én továbbra is azt mondom, hogy a GeoIP alapú tiltás és a port mozgatása nem fokozza a biztonságot. Csak a biztonságérzetet növeli, hamis képet ad a rendszer biztonságáról.

Ugyhogy firewall ruleokban mindig Gyuri bacsinak van igaza!

Plusz üzemeltetési kockázat, minden egyes felesleges rule...

https://iotguru.cloud

Te miert zarod be a lakas ajtodat? egy profinak nem akadaly a zar, akkor meg minek is? :)

Pont olyan ajtóm és záram van, ami arányos védekezés. Amiről itt most szó van, az nagyjából az, hogy a lábtörlő alól valamelyik virágcserépbe teszed a kulcsot...

Úgy indulnak, hogy full port scan? Igen. Megtalálják az SSH-t, ha nem a 22-es portra teszed? Meg. Mennyi haszna van akkor, hogy nem a 22-es porton van? Semmi.

Ha ettől jobban alszol, csináld. Csak ne terjeszd, hogy biztonságosabb.

https://iotguru.cloud

Ha visszaolvasod, nekem ezzel a kijelenteseddel van szakmai gondom:

Ha erős jelszavad van, amit nem használsz máshol és/vagy kulccsal engedsz csak belépést akkor védve vagy.

Tobb multbeli esemeny is alatamasztja, hogy ez nem eleg.

Ezt a non-default port dolgot te hoztad be ... Azt irtam, hogy ez mind1, ne erre hegyezzuk ki.

Ha nem vagy vulnerable és amúgy is megtalálják, akkor minek is?

Nincs mit megtalaljanak. A service port legyen filterezve, kiveve 1-2 cimnek legyen kizarolag engedelye csatlakozni. Ezen felul mindig azt kell feltetelezni, hogy vulnerable vagy.

Azt kell feltetelezned, hogy korhazba kerulsz es fizikailag keptelen vagy updatelni es pont akkor jon ki egy 0-day. Jon valaki es letitkositja a csaladi fotoidat majd penzt ker erte. Ok? :D

Egészen pontosan milyen kockázatot csökkentesz ilyenkor? Biztonságot vagy biztonságérzetet?

Hol irtam olyat, hogy ez barmilyen kockazatot csokkentene? Tegyuk fel feltorik a VPN szervert es hozzafernek a privat halozathoz. *Lehet* nem talalja meg az ssh service-t a 65000-es porton a tamado.

Analizaltam mar par botot, en azt lattam, hogy 10-bol 1-2 csinal csak full scan-t, igy a szamossagat legalabb csokkentheted, ami jo.

Ezutan meg kellene neki egy kulcs vagy valami vulnerability is. Sok sikert.

Hány olyan 0day SSH sebezhetőség volt, ahol támadható voltál és az védett meg, hogy nem default porton volt az SSH?

Hany olyan eset volt, hogy eluthetett volna valami de te tovabb setaltal es nem is vetted eszre, hogy mi tortent?

Mar nem emlekszem pontosan, de volt talan egy Redhat? ssh update, amiben egy trojan volt, illetve a debian randomizacios fuckup. Ha default porton csung garantaltan megtalalnak, amugy meg lehet nem, fuck knows.

Hany eltitkolt exploit szaladt ki innen-onnan az utobbi 10 evben? :D Ezen felul megbizol egy distroban, aki ilyen-olyen patchet alkalmaz forditas+csomagolas elott. Nyilvan a lancban mindenki crypto-ban jartas szakember...

Nem, én továbbra is azt mondom, hogy a GeoIP alapú tiltás és a port mozgatása nem fokozza a biztonságot. Csak a biztonságérzetet növeli, hamis képet ad a rendszer biztonságáról.

Igen, ebben igazad van. De EN, hol is kerdojeleztem ezt meg? Epp azt irtam, hogy az security by obscurity-nak minosul es nem elegseges.

Plusz üzemeltetési kockázat, minden egyes felesleges rule...

Akkor te nem blokkollnad?

Tobb multbeli esemeny is alatamasztja, hogy ez nem eleg.

Viszont a GeoIP szűrés és a port áthelyezése sem.

Ezt a non-default port dolgot te hoztad be ... Azt irtam, hogy ez mind1, ne erre hegyezzuk ki.

Nem én hoztam be, ezek a megoldási javaslatok születtek arra, hogy ne kerüljön kiírásra, hogy x failed login volt n órája. Az ellen valóban jó, hogy az x/n ne legyen egy viszonylag nagy szám, de a biztonságot nem növeli.

Analizaltam mar par botot, en azt lattam, hogy 10-bol 1-2 csinal csak full scan-t, igy a szamossagat legalabb csokkentheted, ami jo.

Mi lenne, ha támadást analizálnál és nem pár botot?

Igen, ebben igazad van. De EN, hol is kerdojeleztem ezt meg? Epp azt irtam, hogy az security by obscurity-nak minosul es nem elegseges.

Na, akkor most görgess vissza oda, ahonnan indult ez az egész szál.

Akkor te nem blokkollnad?

Nem.

https://iotguru.cloud

Viszont a GeoIP szűrés és a port áthelyezése sem.

Persze, ugy ahogy az amit te irsz sem es ultimately semmi sem oldja ezt meg tokeletesen.

Egy valodi szakmai erv arra, hogy ne mogasd a portot 1023 fole az lenne, hogy egy sima user is tud listen-elni rajta. Igy ha megall a process indithat a helyen barki amit akar. De most egy otthoni halozatrol van szo, ha mar van shell access akkor mar mind1.

Na, akkor most görgess vissza oda, ahonnan indult ez az egész szál.

Az a baj, hogy nehez igy. Osszemosod az eszreveteleimet mas kijelenteseivel. En nem locsemege-nek irtam, hanem neked.

Picit ugy erzem, altalaban tamadasnak veszik amit irok, de eppen a tudasomat osztom meg, ahogy te is.

Mi lenne, ha támadást analizálnál és nem pár botot?

I do this for a living ... :P

Maradjunk annyiban, hogy en blokkolnam! :D

Persze, ugy ahogy az amit te irsz sem es ultimately semmi sem oldja ezt meg tokeletesen.

Minden biztonság arányosságra törekszik. Aránytalan biztonságnak nincs sok értelme.

Én mindössze annyit írtam, hogy a szálban felhozott megoldási javaslatok nem fokozzák a biztonságot, csak a biztonságérzetet. És úgy látom, hogy ennek a biztonságérzetnek célszáma a "There were X failed login attempts since last N hours." üzenetben az X/N minimalizálása. Semmi több.

Osszemosod az eszreveteleimet mas kijelenteseivel. En nem locsemege-nek irtam, hanem neked.

Akkor nyiss egy új szálat a témában.

Picit ugy erzem, altalaban tamadasnak veszik amit irok, de eppen a tudasomat osztom meg, ahogy te is.

Ha hajózni mész a tengerre, akkor fújni fog a szél és hullámok lesznek. Ha kinyitsz egy portot a nagyvilág felé, akkor próbálgatni fogják. Ez a természete ezeknek a világoknak. Ha kinyitsz egy VPN portot, akkor azt fogják próbálgatni, mindegy, milyen portot nyitsz ki, próbálgatni fogják. Ha ettől ideges leszel ("eléggé frusztráló", "nagyon gyorsan foglalkoznom kell ezzel érdemben", satöbbi), akkor nem való neked a portnyitás, maradj a szárazföldön.

És tudod: fogadni merek egy láda sörbe amúgy, hogy a kérdező nem szokta és nem is tudja detektálni azt, hogy bejutottak-e, vagy már fut-e kártevő a gépén. De ma már nyugodtan aludt, mert az X/N kellően alacsony volt.

https://iotguru.cloud

Minden biztonság arányosságra törekszik. Aránytalan biztonságnak nincs sok értelme.

A zero-trust model alkotoinak is ird ezt le pls. Valami papirt is publikalj a temaban, hogy hogyan lehet ezt az aranyt pontosan megallapitani!

Akkor nyiss egy új szálat a témában.

Ja, hogy akkor arra amit szakmailag kifogasolok a TE irasodban, nyissak egy teljesen fuggetlen uj szalat? Micsodaaaa?

Ha hajózni mész a tengerre, akkor fújni fog a szél és hullámok lesznek. Ha kinyitsz egy portot a nagyvilág felé, akkor próbálgatni fogják. Ez a természete ezeknek a világoknak. Ha kinyitsz egy VPN portot, akkor azt fogják próbálgatni, mindegy, milyen portot nyitsz ki, próbálgatni fogják. Ha ettől ideges leszel ("eléggé frusztráló", "nagyon gyorsan foglalkoznom kell ezzel érdemben", satöbbi), akkor nem való neked a portnyitás, maradj a szárazföldön.

Meg ezzel is egyet tudnek erteni, csak ha tobb reteged van, akkor egynel tobb dolgot kell baszogatnia, ami tobb ido, nagyobb nehezseg. Ez nem csak a biztonsag erzetet noveli.

És tudod: fogadni merek egy láda sörbe amúgy, hogy a kérdező nem szokta és nem is tudja detektálni azt, hogy bejutottak-e, vagy már fut-e kártevő a gépén

Ha ugy indulsz neki egy vitanak, hogy azt feltetelezed, hogy a masik fel tuti ostoba, akkor konnyen megutheted a bokad.

A zero-trust model alkotoinak is ird ezt le pls.

Á, szóval te a világ összes katonaságánál is erősebb és megbízhatóbb magánhadsereggel véded a cuccaidat? Ha nem, akkor most köpj fel és állj alá.

Valami papirt is publikalj a temaban, hogy hogyan lehet ezt az aranyt pontosan megallapitani!

Pontosan sehogy, de a hasztalan, ám látványos, sőt, látványosan statisztikázható dolgok ezen nem igazán segítenek.

Ja, hogy akkor arra amit szakmailag kifogasolok a TE irasodban, nyissak egy teljesen fuggetlen uj szalat? Micsodaaaa?

Az én írásomban mit is kifogásoltál? Továbbra is annyit állítok, hogy a GeoIP szűrés és a port áthelyezése hamis biztonságérzetet ad, a biztonságot nem befolyásolja.

Meg ezzel is egyet tudnek erteni, csak ha tobb reteged van, akkor egynel tobb dolgot kell baszogatnia, ami tobb ido, nagyobb nehezseg. Ez nem csak a biztonsag erzetet noveli.

Növeli a biztonságot? Kitiltod az IP-k felét és már dupláztad a biztonságot?

1, Ha a szokásos "tamádások" jönnek, mint ebben a témában is látható, azok ártalmatlanok, engedheted mind, nem fognak bejutni, nem növeltél biztonságot.
2, Ha véletlenül elosztott brutal force vagy DDoS támadás jön, azt amúgy is észreveszed, mert kiemelkedő forgalom lesz és nem befolyásolja az, hogy mennyi IP-t tiltasz, nem növeltél biztonságot.
3, Ha elosztott 0day exploit támadás jön, akkor elég egy, ami betalál, nem növeltél biztonságot.

-

Olyan ez, mint SMTP-n anno a greylisting, egy darabig fasza volt, mert lehetett szopatni a spammert, aztán megtanulták és azóta semmi haszna, szinte mindenki ki is kapcsolta. Pont ilyen az SSH port máshova mozgatása és a különféle IP listák alapján való tűzfalazás és a fail2ban, egy darabig fasza volt, mert lehetett szopatni a botokat, aztán megtanulták és azóta semmi haszna, átmennek rajta, mint meleg kés a vajon.

Ha valami hasznos védelmet akarsz, akkor ne ezek legyenek, mert ezek nem védenek és ne vetődj árnyékokra, mert hamis biztonságérzetet ad mindössze.

Ha ugy indulsz neki egy vitanak, hogy azt feltetelezed, hogy a masik fel tuti ostoba, akkor konnyen megutheted a bokad.

Ja, hogyne. De azért érdekelne, hogy futtat-e valamilyen rendszerességgel offline checksum ellenőrzéseket és keres-e gyakori kártevőket. Vagy ott tart még, hogy ez Linux, erre nem kell víruskereső.

https://iotguru.cloud

Arányos védelemmel: automatikusan települő security update; riasztásokkal egybekötött monitoring; arányos tűzfalazás, rendszeres időnként offline checksum és ilyesmi. Léggömbhámozással, security by obscurity és egyéb látszattevékenységekkel nem foglalkozok, nem fogok attól jobban aludni, hogy óránként csak 50 és nem 5000 request jön az SSH-ra, mert nem kockázat, ha papírgalacsinnal dobálják a várfalat.

https://iotguru.cloud

Sehol nem írtam, hogy a monitoring rendszer csak akkor szól, ha bejutottak. Azt írtam, hogy szól, ha valóban támadnak olyan módon, aminek a legvégén valódi esély van a bejutásra. Amíg egyszer nem próbálják meg azt a felhasználónevet, ami létezik, addig minek forgolódjak álmatlanul attól, hogy ebből óránként mennyi volt? Akkor vagyok igen-igen kicsi veszélyben, ha azzal a felhasználónévvel akarnak belépni jelszavakat próbálva, ami létezik, de csak kulccsal lehet bejönni, mert valahonnan kiszivárgott és ki kell nyomozni, hogy hol volt szivárgás. A valódi veszély az lenne, ha lenne kulcsuk is...

Ezt amúgy te észreveszed, hogy van kulcsuk és elsőre bejönnek? Mert a többi, amit művelsz, az közönséges survivorship bias, ott pakolod a páncélt a repülőre, ahol amúgy védett a találatok ellen és nem azt nézed, hogy hol védtelen.

https://iotguru.cloud

aha, es azzal az ssh 0dayel mi lesz ahol egybol bash-t kap a tamado? nincs usernev, nincs kulcs, nincs logbejegyzes sem... jo hat ilyen a Franko vilagban nem letezik, nem is kell ellene vedekezni :)

Megtalálja máshol az SSH-t? Meg. Lesz magyarországi botnet, ahonnan elosztva próbálkozik? Lesz. Bejut a kurvára védettnek gondolt gépedre? Be.

Válaszolj kérlek őszintén: nálad automatikusan települnek a security frissítések? Mert nálam jelenleg maximum 5 percig lesz védtelen rendszer, nálad ez maximum mennyi idő?

https://iotguru.cloud

valaszoltam, a fenti csomag vegzi, bar nem tudom mi koze van ehhez egy 0day-hez :/

Akkor újra: a kérdés az volt, hogy nálad ez mindenhol fut-e. Mivel kerülöd az egyenes választ, gondolom nem fut, az van, mint Ar0n esetén, hogy "korhazba kerulsz es fizikailag keptelen vagy updatelni", de persze két tűzfal közé tenni kell egy harmadikat és az SSH-t szarrá kell tűzfalani, mert attól aztán kurva nagy biztonság lesz.

A 0day-hez annyi köze van, hogy szinte azonnal felkerül a javítás a rendszeredre, akkor is, ha nem tudsz róla, hogy kiderült és jött rá patch... vagy pedig alszol nyugodtan, a rendszereid meg lyukasak, mert a "változás rossz", főleg, ha automatikus.

A nem közismert, javítás nélküli 0day-hez meg annyi köze van, hogy azt nem a te gépeden fogják demonstrálni és ha igen, akkor bizony lófaszt nem véd az, amiről úgy gondolod, hogy csökkenti a feltörés esélyeit...

de mind1 hagyjuk. istenhivokkel nincs mar kedvem vitatkozni :)

Ezt magaddal beszéld meg, mert kettőnk közül te hiszel abban, hogy nagyobb biztonságban attól, hogy nem a default porton van az SSH és egy országra szűkíted bejövő kéréseket. Én meg tudom, hogy ezekkel nem leszek nagyobb biztonságban, felesleges pótcselekedet, színtiszta survivorship bias. Ha már csinálsz valamit, akkor olyat tegyél, amitől növekszik a biztonságod, a biztonságérzetedet hiába növeled, attól még simán feltörnek egy 0day sebezhetőséggel mondjuk egy magyarországi IP kameráról indítva a támadást, mert az ellen nem véd.

https://iotguru.cloud

Az én írásomban mit is kifogásoltál? Továbbra is annyit állítok, hogy a GeoIP szűrés és a port áthelyezése hamis biztonságérzetet ad, a biztonságot nem befolyásolja.

"Semmi haszna nincs."

"Ha erős jelszavad van, amit nem használsz máshol és/vagy kulccsal engedsz csak belépést akkor védve vagy."

"Plusz üzemeltetési kockázat, minden egyes felesleges rule..."

"A támadással arányos védekezés"

Ezt mindet.

Növeli a biztonságot? Kitiltod az IP-k felét és már dupláztad a biztonságot?

Te amugy igy latod amiket irok? "Nincs mit megtalaljanak. A service port legyen filterezve, kiveve 1-2 cimnek legyen kizarolag engedelye csatlakozni."

Ha nem, akkor most köpj fel és állj alá.

Ki az aki bant teged, hogy itt vezeted le a feszultseget? :)

"Ha erős jelszavad van, amit nem használsz máshol és/vagy kulccsal engedsz csak belépést akkor védve vagy."

Ha erős jelszavad van, akkor üzemszerű körülmények között (nem üzemszerűt lásd lejjebb) még közepesen gyenge jelszó esetén is minimum évekig tartó brutal force alatt vagy törhető, ha nincs jelszavad, hanem csak kulcsod van, akkor pláne. És persze ehhez ki kell találni a felhasználónevet is, ami létezik az adott rendszeren és ez azért nem triviális, ha nem "admin" vagy "user" az a felhasználónév. Ezekre tudsz tenni metrikát, igen alacsony riasztási küszöbbel, hogy elkezdték próbálgatni valamelyik felhasználót, tehát információ szivárgás van vagy volt, aminek ki kell deríteni a forrását.

Kurvára értelmetlen azon pörögni, hogy olyan felhasználókkal próbálnak belépni, amelyek nálad nem léteznek és olyan metódussal próbálnak, amivel amúgy sem engeded be.

"Plusz üzemeltetési kockázat, minden egyes felesleges rule..."

Egyszer zárod ki magad tűzfalszabállyal, amikor fontos lenne belépned, akkor rájössz, hogy miért üzemeltetési kockázat. Beállítod, hogy csak magyarországi IP engedjen be, aztán kapsz egy olyan IP-t a UPC hálózaton, ami osztrák (megtörtént eset), aztán próbálsz onnan olyan helyre tovább menni, ahonnan be tudsz lépni. Másrészt, ha statikus az IP adatbázisod van, akkor elmászik alatta a világ, egyre többször szaladhatsz bele problémákba; ha dinamikus, akkor vagy kézimunka, ami üzemeltetési kockázat vagy automatizálod, akkor meg máshonnan húzol be üzemeltetési kockázatot. Ha meg elbaszod az automatikát, mert nincs rá out-of-the-box megoldás (nem véletlenül), akkor bizony könnyedén kicsukod magad.

"A támadással arányos védekezés"

Az ellen védekezz, ami veszélyes, annyira, amennyire veszélyes és kockázatos.

A témaindító "támadás" annyi, mintha papírgalacsinnal dobálnák a várfaladat, azt röhögjed ki, ne számolgasd nyüszítve, hogy mennyi papírgalacsin per óra épp a "támadás" mennyisége, teljesen ártalmatlan az egész.

Ha feszegetik valamelyik kaput vagy próbálgatnak jelszavakat, mert tudják a felhasználónevet, akkor erre legyen alacsony küszöbű riasztás és nézd meg, hogy vajon honnan szivároghatott ki egy felhasználónév. Nekem eddig még nem tudták kitalálni, hogy mi a felhasználónév, nemhogy jelszóval próbálkoztak volna, amivel amúgy nem jutnak be...

Ha jön biztonsági javítás, mert kiderül, hogy a szennyvízcsatornán keresztül fel lehet mászni a várba és belülről kinyitni a kaput, akkor legyen automatikus eljárásrended arra, hogy a lehető legkevesebb időn belül felmenjen a security fix, humán interakció nélkül.

Ha kiderül egy 0day sebezhetőség és nincs rá azonnal security fix (ez ritka), akkor is minimum tudjál róla, hogy van 0day sebezhetőség és legyen rá workaround terved, amivel védeni tudod magad. Nem általánosságban, hogy hátha nem jönnek be, ha felezem az IP címeket, hanem tényleges és működő workaround, amivel ténylegesen megvéded magad.

Ha van 0day sebezhetőség és nem derült még ki, akkor van esélye, de igen-igen kicsi, hogy rajtad kezdik kihasználni, mert egy nem javított és ismeretlen 0day sebezhetőségnek komoly ára van a feketepiacon, nem fogják jelentéktelen gépeken ellőni, ahol felmerül, hogy mi van, ha "korhazba kerulsz es fizikailag keptelen vagy updatelni", hanem olyan célpontokon fogják használni, ahol van bőven anyagi haszna is. Ez ellen nem véd az, ami megoldásokat itt látunk, mert humán intelligencia fog támadni, kombinált sebezhetőségekkel, social engineering és egyéb dolgokkal; amikor már botokkal nyomják tömegesen, akkor már napokkal, hetekkel, hónapokkal a security fix után vagyunk.

És persze nézni kell azt, hogy bejutottak-e, mert a sikeres támadást pont nem fogod észrevenni se a tűzfal, se a monitoring, se a többi dolog nem jelzi, főleg, ha ügyesen csinálják. Linkeltem az előbb, ez az SSH hekkelés tipikus survivorship bias, szanaszét lőhetik az SSH logot, nem lesz belőle egyáltalán bajod, viszont mivel sok találat van, egyszerűen pszichológiai okokból akarsz ezzel foglalkozni.

Ki az aki bant teged, hogy itt vezeted le a feszultseget? :)

Az itt olvasott hülyeségek bántanak, amelyek megoldásként születtek a feldobott problémára.

https://iotguru.cloud

"Az ellen védekezz, ami veszélyes, annyira, amennyire veszélyes és kockázatos."

Koszonom, mostmar akkor ertem! A "brutal force" az!

szanaszét lőhetik az SSH logot, nem lesz belőle egyáltalán bajod

Szeritnem az is baj, ha tarolnom kell vagy ha felporgetik a lemezeimet feleslegesen.

Te csinald igy! En meg majd szomoruan hasznalom a kis kulso par dollaros jumphostomat meg a kulso VPN-emet, hogy elerjem az otthoni SSH-t. Rettegek majd, mert az otthoni halozatom uzemeltetesi kockazatai magasak a 2 darab allow rule miatt. Szomoru leszek mert szerinted hulyeseg.

Koszonom, mostmar akkor ertem! A "brutal force" az!

Nem, a brutal force nem veszélyes. Az a veszélyes, hogy kiszivárgott egy használt felhasználónév, ez egy indikátor, hogy valahol adatszivárgás van a rendszerben, valaki valahol bejutott vagy valaki valahova olyan dolgot publikált, amiben benne van.

Szeritnem az is baj, ha tarolnom kell vagy ha felporgetik a lemezeimet feleslegesen.

Logrotate, mint olyan? A monitoring real-time feldolgozza, utána eldobható a konkrét log, nincs benne hasznos dolog.

En meg majd szomoruan hasznalom a kis kulso par dollaros jumphostomat meg a kulso VPN-emet, hogy elerjem az otthoni SSH-t. Rettegek majd, mert az otthoni halozatom uzemeltetesi kockazatai magasak a 2 darab allow rule miatt. Szomoru leszek mert szerinted hulyeseg.

Hajrá. De azért ez kissé messzebb van attól, hogy zárjuk ki a fél világot és tegyük máshova az SSH portot, mert az majd megvéd.

https://iotguru.cloud

ez olyan mint a lotto nyeres: aki nem vesz (=probalkozik sshn) szelvenyt, nem nyerhet (=sikeres belepes). nyilvan meg egy csomo mindennek kell egyeznie, pl eltalalni a megfelelo szamokat (=eltalalni a megfelelo u/p). amugy nem feltetlenul rossz az ha a felesleges problakozokat (=zajt) kiszurjuk, lehet koncentaralni a maradek probalkozora.

 

de amugy igaza van locsemegenek, minden valaszod olyan mintha az lenne az egyeduli es megdonthetetlen igazsag a vilagon, mindenki mas meg egyszeruen hulye. :/

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

ez olyan mint a lotto nyeres: aki nem vesz (=probalkozik sshn) szelvenyt, nem nyerhet (=sikeres belepes). nyilvan meg egy csomo mindennek kell egyeznie, pl eltalalni a megfelelo szamokat (=eltalalni a megfelelo u/p).

Bocsánat, de nem, ez olyan, mintha csak öt számot játszanál meg a hatoslottón és várnád, hogy mikor nyersz.

amugy nem feltetlenul rossz az ha a felesleges problakozokat (=zajt) kiszurjuk, lehet koncentaralni a maradek probalkozora.

Ha továbbra is naplózod, csak máshol is, akkor kettő helyen kell nézned, hogy mi a helyzet. Ha meg nem naplózod, akkor nem tudod, hogy mi történik, azt hiszed, hogy biztonságban vagy.

És akkor jönnek az olyan önszopatások, mint amikor kapsz véletlenül egy külföldi GeoIP címet és faszán ki is csuktad magad.

de amugy igaza van locsemegenek, minden valaszod olyan mintha az lenne az egyeduli es megdonthetetlen igazsag a vilagon, mindenki mas meg egyszeruen hulye. :/

Alapvetően az a baj, hogy a biztonság az objektív dolog, a biztonságérzet meg szubjektív dolog. Nincsen semmi baj azzal, hogy ha valaki túlaggódja a dolgokat, akár azzal se, ha paranoiás és ide hallom hogy szinte nyüszít, mert támadják, aztán csinál egy értelemetlen dolgot és megnyugszik, csak tegyük oda, hogy nem az objektív biztonságot fokozta ezzel, hanem a szubjektív biztonságérzetét.

Értem, hogy most már nyugodtan alszik, tök jó dolog, de ne írjuk le, hogy biztonságosabb lett ezzel a rendszere, mert az egyszerűen nem igaz.

https://iotguru.cloud

a biztonsagot en nem egy bites szamkent kezelem hanem egy allapotot a 0 es a vegtelen kozott valahol. minden olyan dolog ami megtilt/bezar/stb valamit, az odebb loki az allapotot a vegtelen fele, van ami nagyot valtoztat, van ami kisebbet. minel tobb minden van, annal tavolabb van az inserucre 0-tol. 

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

most valtoztathatok jelszot, mert kitalaltad! :D

de latod a mozgas szubjektiv ertek: szerinted 0, szerintem meg picit. hogy pontosan mennyit, nemtudom. de az biztos hogy tavolabb kerultunk a 0-tol mint ahol voltunk.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

jo hat a megdonthetetlen igazsagokon nem tudok valtoztatni. de nincs baj. ha te ugy gondolod hogy eleg az sshkulcs, akkor ne is csinalj tobbet. en meg csinalok ezt-azt. akik meg olvassak a szalat, eldontik hogy eleg-e a Frako's security, vagy ok is csinalnak-e meg tovabbi "fals" biztonsagi dolgokat :)

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Attól tartok, a probléma az, hogy kedves @locsemege kolega fél a lebukástól, hogy még ennyi év informatikai és/vagy Linux hókuszpókusz után sem volt szándékában kikommentezni a "PasswordAuthentication" sort az sshd_configjában...

Vagy, ami még nagyobb gáz lenne, ha kiderülne, hogy a "prohibit-password"-ot viszont sikerült eltüntetnie a "PermitRootLogin" mellől.

 

De, hogy ennél is (technikailag) relevánsabb legyen eme hozzászólásom, kérdezem:

Mit fog csinálni a kedves kolega akkor, amikor egy hazai botnet cuppan rá a portjára kopogtatni??
(Mert feltörhető/lejárt támogatású/távolkeleti IP-kamerák penetrációjának tekintetében igencsak rosszul állunk e téren.) vagy

Mit fog csinálni, ha egyszer külföldre viszi útja, és rájön, hogy szar dolog az embernek maga alatt vágni a fát??
 

Mert, ha mondjuk egy TV szolgáltató vagy, és valamelyest korlátozni szeretnéd, az adás nézhetőségét a világ egyes tájairól, akkor megértem, hogy van értelme a GEOIP-féle bohóckodásnak, vagy ha egy nagyobb szolgáltató vagy, és mindenképpen szükség van a passwordauth-os ügyfelek kiszolgálására, akkor a fail2ban ssh-ra reszelésének, de azt, hogy a 4-5 biten kifejezhető darabszámú (ráadásul otthoni) felhasználók szintjén miért nem lehet áttérni az ssh, kulcsos használatára, azt nem tudom megérteni!...
 

Abban, viszont maximálisan igazat adok @_Franko_ kolegának, hogy, ha évek múltán, tfh. egy leendő rendszergazda tanonc ránéz erre a topikra, akkor értelmes, és valódi megoldást is lásson, ne csak hamis biztonságérzetet adó félmegoldást.

Éppen ezért a pikánsabb megjegyzéseimet is idebiggyesztem:

Vajon megéri-e a perfomancia-veszteség a SOHO routeren, (fogadjunk, hogy TP-Link), amit az iptables GEOIP modulja okoz számára?
(Mert itt sincsen ingyen a húsleves)

De mondok jobbat is:
Tedd odébb legalább 10 bitnyivel azt a fránya ssh-portot, és meglátod, hogy újabb hónapokra békén hagynak.
(saját tapasztalat)

Tedd odébb legalább 10 bitnyivel azt a fránya ssh-portot, és meglátod, hogy újabb hónapokra békén hagynak. (saját tapasztalat)

Nem hagynak békén, ugyanúgy megtalálják, mintha a default helyen lenne. Ráadásul a kérdező már áthelyezte és úgy "támadják".

https://iotguru.cloud

Nem állítottam, hogy örökre békén hagynak, csak azt, hogy egy ideig.
(Ha az az idő, tfh. másra nem, de legalább arra jó, hogy higgadtan átgondolja az ember a dolgokat.)

Az nekem is feltűnt, hogy az utóbbi hónapokban nagyságrendekkel jobban felszaporodtak az ilyen jellegű próbálkozások.

Ugyanakkor az, azért még mindig igaz, hogy egy DROP policy-s tűzfalon, a teljes tartomány végigszkennelése relatíve hosszú idő, ezért még most is él az a hagyomány, hogy a 10K alattiakat szeretik tesztelni.

És ezt az én statisztikám is alátámasztja:
(elmúlt 2 hónap, nyilvános ip)

3-4K    közötti ssh port: 40.384 sikertelen
30-40K közötti ssh port: 94 sikertelen

 

A fenti GEOIP-re egy (nem állítom, hogy sokkal jobb) alternatíva:

A fail2ban-nal átmenetileg letiltod magát a megcélzott usert, és nem csak a támadó 1db címét.
Ez a nagyon sok forrású botnet ellen egy relatíve "olcsó" védelem, de kétségtelen, a támadás alatt, a valódi user is kiesést fog tapasztalni.
 

 

Ami viszont mostanában engem idegesít, azok a célzott adathalász támadások.

Amikor az egész webmail,honlap,stb felületét lemásolják, majd elküldenek az ismert (mondjuk honlapon kintlévő) címekre egy helpdesk levelet, a hamis linkkel, az egyszeri kolega meg, (nem ellenőrizvén a böngésző címsorát) azt hiszi, hogy jó helyen jár, és belép.

(És sajnos egyre javul a magyarságuk is, talán a google translate fejlődésének köszönhetően?)

Korábban ilyenek mifelénk, (talán érdektelenség végett) nem voltak, és ez ellen a GEOIP, meg a fail2ban sem véd...

 

Tűzfal => VPN + token => Tűzfal => Port Knocking

- port scanner ip-k: 30 napra tilt
- aki ssh-zni / ftp-zni / winbox / stb. akar: 30 napra tilt
- ami nem adott 8 országból jön eldob
- ping eldob
- kintről minden zárt
- partnerek is csak VPN-en jöhetnek

Kkv szinten béke van, vagy csak azt hisszük! ;-]

Kinél még milyen tipp van ami bevált?

Köszi!

2 faktoros auth.

Kulcs, amit épp kiolvashat az általad említett malware + jelszó, amit menet közben gépel be a user ÉS memóriában nem tárol le. Ilyet beállítás van openvpn-re.

Persze, ha keylogger fut a gépen, fertőzött a gép, rég megette a fene. Hálózatra tiszta gépet illik kapcsolni.

Tompítani vpn auth-tal összekötött ip szűréssel tudsz. Vagy tokennel emelni a biztonságon.

Egy yubikey nano-m van. Tulajdonkeppen ugyanolyan mint egy smartcard, a kulcsot az eszkoz generalja es tarolja a HSM moduljaban es azt remelhetoleg soha nem hagyja el.

Mar ~3 eve van meg, nem volt vele gond.

Volt valami minor security problema es kuldtek uj kulcsokat. Szvsz jo ceg.

Ezen felul van benne FIDO, ugyhogy webes cuccokhoz is hasznalom.

Mennyivel tartod biztonságosabbnak, jobbnak a Yubikey-t, mint pl a Google Authenticator appot?

Kb egy éve beszéltem egy ismerőssel, aki azt mondta, hogy teljesen áttértek a cégnél a szoftveres megoldásra. Meglepődtem, mert nagy cégről van szó, akiknél az egyik fő üzletág a biztonsági rendszerek.

Nehez megmondani, jo beallitassal es megfelelo oktatassal szerintem megkozelitheto. Sok emberre azert jo draga egy ilyen hardveres megoldas, valoszinuleg nem eri meg. Ki merem jelenteni, hogy tulzas is egy picit.

De egy harveres megoldas mondjuk tenyleg nehezen duplikalhato.

Btw, nekem amugy sokkal kenyelmesebb egy ilyet hasznalni mint minden ssh loginnal vacakolni valami app-al.

Ez egyértelmű, de ha meg akarom védeni a postafiókomat, github fiókomat,... jelent-e plusz biztonságot?

Párszor nekifutottam, hogy veszek, de mindig elakadtam ott, hogy ha a kulcscsomómra teszem, akkor az egész kulcscsomót viszem a géphez, két gépet használok,... Ha nem teszem a kulcscsomómra, kb soha nem lesz nálam. A telefon mindig nálam van.

Vagy a leggyakrabban használt gép be van állítva megbízható gépnek, és csak az idegen helyen való bejelentkezéshez van használva?

Tényleg érdekel, hogy milyen pluszt ad a gyakorlatban. Hogy érdemes használni.

jelent-e plusz biztonságot?

Igen, nagyon sok hardveres vedelem van benne arra, hogy ne lehessen duplikalni, kiolvasni belole az informaciot.

Vagy a leggyakrabban használt gép be van állítva megbízható gépnek, és csak az idegen helyen való bejelentkezéshez van használva?

Ez altalaban rad van bizva. Ha elmented a gepet akkor igen, ennyi.

Tényleg érdekel, hogy milyen pluszt ad a gyakorlatban. Hogy érdemes használni.

Van benne TRNG. Nekem a kulcsomat is ez generalta es soha nem hagyja el a belsejet, olyan mint egy smartcard.

Minden software megoldas, igazabol csak egy hack :)

a telefonomat feltörhetik távolról, a hardveres megoldást fizikailag is meg kell szerezni?

Amikor regisztralod a authenticatort altalaban beolvasol egy QR kodot. Ha az megvan barkinek akkor ugyanazt az OTP-t tudja generalni. Masik, hogy megbizolt egy 3rd partyban.

A szoftveres megoldásokat nevezhetjük simán hacknek, de a szoftveres megoldásokkal könnyebb alkalmazkodni az aktuális körülményekhez.

Ez igy van. Igy mindig fel kell merni, hogy mit vedunk, mekkora a kockazat es jonnek meg az anyagiak is.

Barcsak mindenhol lenne lehetoseg softveres OTP hasznalatara.

Ha lehet hinni a leírásoknak, a WireGuard VPN rejtőzködő üzemmódban figyel UDP-n: nem válaszol olyan kérésre, ami nem megfelelő kulccsal érkezik. Elvileg így nem lehet észrevenni szkenneléssel. Eleve nincs egy meghatározott port, én 50000 fölé szoktam állítani.

( opt | 2020. 12. 08., k – 16:28 )

Nálam is sok próbálkozás van a magas porton elérhető ssh-n, és még attól is több a port szkennelés az otthoni routeren. Tényleg nagyon megugrott az utóbbi időben.

Nem csak a közvetlen támadások (gagyi próbálkozások) miatt teszem el magasabb portra az ssh-t, ..., hanem hogy egyszerűen feketelistához tudjam adni a próbálkozó IP-ket. Ma port szkennelésre, ssh törésre használják a botnetet, holnap már nem érdekel mire, mert tűzfalon tiltva vannak. Tudom, hogy nem az ilyen "védelmektől" alszik nyugodtan az ember, változnak az IP-k,... de egy kis plusz, amit könnyen be tudok állítani az otthoni routeren.

( opt | 2020. 12. 26., szo – 14:44 )

Ha már így szóba került, hogy több támadás éri az otthoni eszközöket, érdekel, hogy van-e olyan, aki átnézte a saját rendszerét, hogy minden rendben van-e? Esetleg módosított-e valamit?

( lpds | 2020. 12. 28., h – 11:33 )

Ummm, azt hiszem en nyeretem :) 

# lastb | awk '/ssh/ {printf("%s\t%s\t%s\n", $1, $2, $3);}' | sort -u | wc -l 
499113
#

Ez egy dev szerver ami lehet, hogy itt ott dodgy egy kicsit - a prod parjanal csak 3-4k ilyen probalkozas van.